Application Monitoring, Logs, and Uptime Checks

Why Monitoring Matters

Deploying an application is not the finish line—keeping it running reliably is an ongoing responsibility. Servers crash, disks fill up, misconfigurations slip through, and traffic spikes happen without warning. Application monitoring gives you visibility into what your server and software are doing right now, what they did in the past, and whether your site is reachable by the outside world. Without monitoring, you learn about outages from angry users instead of automated alerts.

This lesson covers three core monitoring skills: reading system and service logs with `journalctl`, watching Nginx web server logs in real time, and setting up an external uptime check. You will also practice the professional habit of writing an incident report after a service failure.

Reading System Logs with journalctl

`journalctl` is the command-line tool for reading the systemd journal—the centralized log store used by most modern Linux distributions, including Ubuntu 20.04 and later. Every service managed by systemd writes structured log entries to the journal automatically.

Key flags you will use today:

• `journalctl -u nginx` — show all journal entries for the Nginx unit (service).
• `journalctl -u nginx --since today` — limit output to entries from midnight of today onward.
• `journalctl -u nginx -f` — follow mode; new entries appear as they are written, similar to `tail -f`.
• `journalctl -p err -u nginx` — filter to entries at priority error or worse.

Each log line contains a timestamp, hostname, process name, PID, and the message. When Nginx fails to start or encounters a configuration error, the journal entry will usually say exactly which file and line caused the problem. Read the full message before trying a fix.

Watching Nginx Access and Error Logs

Nginx writes two plain-text log files by default:

• `/var/log/nginx/access.log` — one line per HTTP request, including client IP, request method, URL, HTTP status code, and response size.
• `/var/log/nginx/error.log` — problems Nginx encountered processing requests or starting up.

The command `tail -f /var/log/nginx/access.log` streams new lines to your terminal as requests arrive. This is invaluable for watching live traffic during a deployment or debugging session.

Reading HTTP status codes in the access log:

• 200 — request succeeded.
• 301 / 302 — redirect; usually expected.
• 404 — the client requested a resource that does not exist on this server.
• 500 — the server encountered an internal error (a bug in your application code or a misconfiguration).
• 502 / 503 — gateway or upstream errors; common when the application process behind Nginx has crashed.

When you see a flood of 404s for the same path, someone may be scanning your site or a link on your page is broken. When you see 500s, your application code needs immediate attention.

External Uptime Monitoring

Log files tell you what happened on the server. They do not tell you whether a user in another city can reach your site. External uptime monitoring sends HTTP requests to your site from outside your network on a schedule and alerts you if it gets no response or gets an unexpected status code.

UptimeRobot offers a free tier that checks your site every five minutes and sends email alerts when a monitor goes down or recovers. To set up a basic monitor:

1. Create a free account at uptimerobot.com.

2. Click Add New Monitor, choose type HTTP(s).

3. Enter your site's URL and a friendly name.

4. Set the check interval (5 minutes on the free tier).

5. Add your email address as an alert contact.

6. Save the monitor.

Once active, UptimeRobot will notify you within minutes if your site stops responding. The free tier is sufficient for learning and small personal or student projects.

Responding to a Service Failure

When an alert fires, work through a quick mental checklist:

1. Confirm the outage — can you reach the site from your browser? Does `systemctl status nginx` show the service as failed or inactive?

2. Read the logs — run `journalctl -u nginx --since today` and check the error log. Find the first error message, not just the last one.

3. Fix the cause — restart the service with `sudo systemctl restart nginx` only after you understand why it stopped; otherwise it may fail again immediately.

4. Verify recovery — confirm the service is active (`systemctl status nginx`) and that your browser can load the site.

5. Document the event — write an incident report.

Incident Reports

An incident report is a brief professional record of what went wrong. A minimal report answers:

• Who detected the issue (and who resolved it).
• What service or system was affected.
• When it started and when it was resolved.
• How it was resolved and what, if anything, will prevent recurrence.

Writing incident reports is a professional habit that protects you and your team. It builds a searchable history of past failures so the same problem is not diagnosed from scratch next time.

Safety and Professional Notes

Log files can contain sensitive information—user email addresses, IP addresses, form data that leaked into URLs, and authentication tokens if logging is misconfigured. Treat log files as confidential. Do not paste raw logs into public chat rooms or forums without scrubbing personal data. On a shared or production server, log file permissions should allow only privileged users to read them. Always use your VPS account credentials responsibly and never test destructive commands on a system that serves real users without permission.