Deutsch
Review VPS logs for changes that need a response: unfamiliar logins, failed services, rising error rates, missed backups, or growing resource pressure. Compare a defined time window with normal activity so you can distinguish an expected event from a developing problem.
Start with authentication, application, web, database, and scheduled-job logs, adding the sources your software needs. Assign a reviewer, record the findings, and send issues to the person responsible for the affected service.
Pick the logs that matter
The minimum set depends on the software installed, but review these sources where applicable:
- Authentication: successful and failed SSH or console logins, account lockouts, and new source addresses.
- Privilege changes: sudo use, changes to users or groups, new keys, and modifications to authentication or privilege policy.
- Firewall/security events: blocked or newly allowed traffic, security-tool actions, and changes to listening services.
- Application errors: exceptions, failed requests, dependency failures, and application restarts.
- Web/proxy 4xx and 5xx patterns: changes by status, route, source, upstream, or time rather than isolated expected responses.
- Database errors: connection failures, lock or recovery warnings, storage errors, and unexpected restarts.
- Backup, cron, and job failures: missed schedules, non-zero exits, retry exhaustion, and incomplete backup or verification jobs.
- Disk/filesystem warnings: low space, inode pressure, read-only remounts, I/O errors, and failed log rotation.
For every source, record where it lives, which service produces it, its timestamp and timezone behavior, retention, and owner. Confirm that expected logs are still arriving; silence can mean a quiet system, a disabled logger, or a broken collection path.
Review for patterns
Compare the review window with the service's normal activity and recent changes. Look specifically for:
- repeated login failures or a successful login after repeated failures;
- new source IP addresses, locations, clients, or access times;
- recurring exceptions or the same failed dependency across services;
- sudden or sustained error-rate spikes rather than one isolated line;
- unexpected process, service, database, or VPS restarts;
- memory, disk, inode, file-descriptor, connection, or other resource-exhaustion warnings;
- unusual administrative actions, new identities, privilege grants, firewall changes, or log clearing.
Compare timestamps across authentication, system, proxy, application, database, and job logs, accounting for timezone differences. For example, a 502 response may coincide with an application restart or database connection failure. Preserve the relevant records and identifiers before rotation removes them.
Protect sensitive entries
Applications must not log full passwords, private keys, session cookies, access tokens, API keys, recovery codes, or other reusable credentials. Redact or structurally omit those fields at the source; relying on reviewers to ignore them leaves the secret exposed in files, collectors, backups, and screenshots.
Restrict log access to people and services that need it. Protect local files, central collectors, exports, and review evidence with appropriate permissions and retention. When sharing incident evidence, include only the necessary fields and mask personal or sensitive data according to the organisation's policy.
If a credential appears in a log, treat it as exposed: stop further logging, restrict the affected evidence, rotate the credential, and investigate where copies were retained. Deleting the one visible line is not complete remediation.
Connect logs to alerts
Alert on events that require prompt action, such as a backup failure that threatens recovery, disk exhaustion, a service-down condition, confirmed unauthorised access, or an error surge causing user impact. Each alert needs an owner, severity, supporting context, and a defined first check.
Keep routine review for trends and context: slowly rising error rates, repeated but non-urgent retries, new low-volume 404 patterns, recurring administrative work, and log sources that have become noisy or silent. Turn a reviewed pattern into an alert only when the team can define a useful threshold, owner, and response.
Group repeated events and suppress known harmless cases after review. Each alert should describe something the recipient can investigate or act on. Check whether alerts led to useful action, and adjust rules that repeatedly interrupt the team without identifying a problem.
Keep the routine lightweight
Perform a short daily pass over immediate security, service, backup/job, and resource failures. Use the weekly review to compare patterns, correlate systems, inspect administrative changes, and improve noisy or missing signals. Increase frequency during incidents, launches, migrations, or known elevated risk.
Record the time window, sources and filters checked, notable patterns, decision, and escalation owner. Link to the relevant records in controlled log storage so another administrator can follow the review. Keep reusable secrets out of notes and exports.
