Logs
Logs searches current journald-backed service messages by service, severity, date, and text, with safe export and read-state behavior.
Where to find it: SDM root sidebar > Logs.
Available to: root.
What this page does
Use Logs for runtime symptoms: service starts/stops, warnings, errors, and messages that explain why an audited request could not complete. The service catalog is discovered dynamically from the server.
Before you start
Start with the event time and owning service. A broad all-service search can bury the useful line in unrelated routine messages.
Filters, tabs, and limits
- Search text, service, severity (Info, Notice, Warning, Error), and date range.
- The page displays 20 rows at a time and scans up to 200 relevant messages for the interactive view.
- CSV or JSON export can include up to 2,000 matching messages.
- Read state is per user/browser. Auto-read applies only to Info and Notice; Warning and Error are never silently auto-read.
- Server retention and storage may remove older messages; see Server Logs Settings.
Controls and fields
| Control, Field, Or Section | What It Does | What It Affects | Recommended Usage |
|---|---|---|---|
| Search logs | Searches service log messages. | Filters visible server log rows. | Use exact error fragments, service names, or request hints. |
| Service selector | Limits logs to one service/unit when available. | Focuses troubleshooting on DNS, database, web, PHP, or SDM services. | Select the service related to the failing workflow first. |
| Severity selector and severity tabs | Filters and groups logs into Info, Notice, Warning, and Error. | Separates routine messages from urgent failures. | Start with Error and Warning during incidents. |
| Date from / Date to | Limits logs to a time window. | Reduces noise around an incident period. | Use the same timezone as dashboard/audit for correlation. |
| Apply | Applies current log filters. | Reloads visible log rows. | Apply after selecting service, severity, and time range. |
| Reset | Clears log filters and returns to default Info view. | Removes hidden filter state. | Use before switching to a different incident. |
| Refresh | Reloads the active severity tab. | Does not change log data. | Use after reproducing an issue or restarting a service. |
| CSV / JSON export choices | Selects export formats. | Controls how filtered log evidence is downloaded. | Use JSON for support with structured data; CSV for quick review. |
| Export | Downloads filtered service logs. | Creates a portable evidence file. | Export before log pruning or destructive recovery steps. |
| Mark current tab as read | Stores read state for the active severity tab. | Local browser state only. | Use to track review progress. |
| Auto-read this tab | Automatically marks Info/Notice style rows as reviewed while browsing. | Local browser state only. | Avoid auto-read for Warning/Error if your team needs explicit acknowledgement. |
| Previous / Next | Moves through paginated log rows. | Changes visible rows only. | Use after narrowing filters to keep context manageable. |
Practical guidance
- Start with Warning and Error tabs during incidents, then expand to Notice/Info if more context is needed.
How to use it
- Select the suspected service and a short date range.
- Start with Warning or Error, then broaden to Notice/Info for context.
- Open the matching lines and correlate their time with Audit.
- Export the filtered result when escalation needs the raw evidence.
- Fix the owning service or prerequisite, then refresh to confirm new healthy messages.
Result and next check
You have the service-level reason and its timing, not merely a red badge. If expected history is absent, compare the query window with the configured retention and storage coverage.
Theme color