Monitoring & updates

Key takeaways A deployment isn’t done when it starts — you have to keep it healthy. Metrics track trends over time and alerts notify you when something breaks. Ship new versions as updates while watching health, and keep the previous versioned artifact so you can roll back instantly if a release goes wrong. Safe updates are all about being able to undo them.

This lesson is about the long tail of deployment: watching a running service and changing it without breaking it.

From health checks to metrics and alerts

A health check tells you up or down. Metrics go further — numbers sampled over time that reveal trends:

request rate and error rate
latency (how long responses take)
memory and CPU use
app-specific gauges (for GopherTrunk, active channels, decode rate)

A tool like Prometheus scrapes these from a /metrics endpoint (GopherTrunk labels its compose service for exactly this) and stores them so you can graph them. Alerts sit on top: define a rule — “error rate above 5%” or “service down for 2 minutes” — and get notified automatically, so you learn about problems from a page, not from an angry user.

Rolling out a new version

When a new version is ready, updating a container deployment is a pull-and-recreate:

docker compose pull        # fetch the new image
docker compose up -d       # recreate the container with it

For a systemd binary, you install the new binary and restart the service. Either way, right after the update you watch the health check and metrics — the update isn’t “done” until the new version proves healthy under real traffic.

Rolling back

Here’s why immutable, versioned artifacts matter so much: if the new version misbehaves, you don’t debug in production under pressure — you roll back to the previous known-good version, which still exists:

docker compose pull gophertrunk:1.4.1   # the previous good version
docker compose up -d

Because the previous versioned artifact still exists, a bad release is undone by redeploying it — no live debugging.

Update safely, sleep well

Good update habits:

Update one thing at a time so if something breaks, you know what caused it.
Watch after every deploy — health, metrics, logs — for long enough to trust it.
Keep the last known-good version ready to redeploy.
Automate it through your CI/CD pipeline so updates are consistent, not improvised.

Quick check: what makes rolling back a bad release possible?

Recap

Keep a deployment healthy with metrics (trends over time) and alerts (automatic notification).
Ship new versions as updates — pull and recreate — then watch health and metrics.
Keep the previous versioned artifact so you can roll back instantly.
Update one thing at a time, watch after each deploy, and automate through CI/CD.

Next up: Unit 5 — deploy GopherTrunk end to end, using everything you’ve learned.

Frequently asked questions

What is the difference between logs, metrics, and alerts?

Logs are a detailed record of individual events. Metrics are numbers measured over time — request rate, error count, memory use — good for spotting trends. Alerts are automatic notifications when a metric crosses a threshold, like errors spiking or the service going down, so a human finds out without watching dashboards.

How do you update a deployed service safely?

Deploy the new versioned artifact, watch its health check and metrics, and keep the previous version available. If the new one misbehaves, roll back by redeploying the previous artifact. Doing updates in a way that lets you quickly return to a known-good version is what makes them safe.