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.
VPS log review checklist
| Check | Frequency | Evidence | Escalation |
|---|---|---|---|
| Authentication failures, successes after failures, and new sources | Daily | Reviewed time window, query/filter, notable identity/source, controlled evidence link | Security or server owner for unexplained access |
| Privilege, identity, key, firewall, and administrative changes | Daily | Change identifier or exact event summary and approving owner | Security/server owner for unapproved change |
| Application, web/proxy, and database error spikes or restarts | Daily | Error comparison, affected route/service, timestamps, user impact | Application owner; incident lead when users are affected |
| Backup, cron, queue, and scheduled-job failures | Daily | Job/run identifier, exit state, last success, retry result | Recovery or service owner before recovery coverage is at risk |
| Disk, inode, filesystem, memory, and other exhaustion warnings | Daily | Current/trend measurement and affected service | Server owner; incident lead for active service risk |
| Recurring exceptions, 4xx/5xx patterns, noisy alerts, and silent sources | Weekly | Trend comparison, examples, decision, follow-up owner | Service owner when a persistent defect or blind spot is confirmed |
| Administrative activity and retained review evidence | Weekly | Named reviewer, time window, sources, findings, evidence reference | Accountable owner for unexplained action or missing evidence |
When a VPS is the right fit
A VPS gives your team access to operating-system, application, proxy, database, job, and security logs. Your team also needs to configure collection, permissions, retention, alerts, and a review routine that someone can maintain.
Virtarix VPS services are self-managed. Virtarix does not review customer application or operating-system logs or operate the customer's alert and escalation routine. A single VPS remains one failure domain; centralise or otherwise protect required evidence when losing that server would also remove the logs needed for investigation.
FAQs
How often should VPS logs be reviewed?
Use a short daily review for immediate access, service, backup/job, and resource failures, plus a weekly trend review. Increase frequency for incidents and high-risk changes; base the cadence on impact and response needs.
What evidence should a reviewer keep?
Record the time window, sources and filters checked, notable events, comparison or baseline, decision, owner, and a controlled evidence reference. Do not copy reusable secrets into the record.
What if sensitive data appears in a log?
Stop or correct the logging source, restrict the affected evidence, rotate exposed credentials, and identify retained copies in collectors, exports, and backups. Redact at the source for future events.
When should a log finding be escalated?
Escalate unexplained access or administrative changes, active user impact, data or recovery risk, resource exhaustion, persistent defects, and missing visibility that prevents a required check. Name the owner and urgency in the review record.
