← Back to Home
Home/Production Projects/Project 3: Add Monitoring, Tracing & GitOps
🎯

Project 3: Add Monitoring, Tracing & GitOps

The operational layer that turns a running app into a production-grade system.

⏱12 min read📚DevOps Fundamentals

Your app is containerised, provisioned with Terraform, and running on Kubernetes. It works — but can you see it, and how do you deploy changes safely? Project 3 adds the operational layer: monitoring (Prometheus + Grafana), tracing (Zipkin), and GitOps delivery (Argo CD). This is what makes it truly production-grade — and completes your portfolio.

🎯 Learning Objectives

Step 1 — Monitoring

First, expose a /metrics endpoint in the app (using a Prometheus client library), then tell Prometheus to scrape it. On Kubernetes this is usually annotation-based or via a ServiceMonitor:

yaml
# add scrape annotations to the app's pods/service
metadata:
annotations:
  prometheus.io/scrape: "true"
  prometheus.io/port: "3000"
  prometheus.io/path: "/metrics"

Then build a RED dashboard in Grafana (Rate, Errors, Duration) — the same pattern from the monitoring track:

text
# Request rate
sum(rate(http_requests_total{app="myapp"}[5m]))

# Error ratio
sum(rate(http_requests_total{app="myapp",status=~"5.."}[5m]))
/
sum(rate(http_requests_total{app="myapp"}[5m]))

# p95 latency
histogram_quantile(0.95,
sum(rate(http_request_duration_seconds_bucket{app="myapp"}[5m])) by (le))

Add an alert (via Alertmanager) for a sustained high error rate, and you’ll know about problems before users complain.

Step 2 — Tracing

Instrument the app with OpenTelemetry exporting to Zipkin (as in the tracing track), so requests across services produce a waterfall you can inspect:

javascript
traceExporter: new ZipkinExporter({
url: "http://zipkin.observability:9411/api/v2/spans",
})

Now when the RED dashboard shows a latency spike, you don’t guess — you open Zipkin, find the slow trace, and see exactly which span (a slow DB query, a retrying downstream call) is responsible. Metrics detect; traces localize.

💡 Observability before you need it

Add monitoring and tracing while things are calm, not during an incident. The whole point is that when something breaks at 3am, the dashboards and traces are already there waiting for you.

Step 3 — GitOps Delivery with Argo CD

Now replace any manual kubectl apply with GitOps. Commit all your Kubernetes manifests to a repo and let Argo CD keep the cluster in sync:

yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: myapp
namespace: argocd
spec:
project: default
source:
  repoURL: https://github.com/you/myapp-config.git
  targetRevision: main
  path: k8s
destination:
  server: https://kubernetes.default.svc
  namespace: myapp
syncPolicy:
  automated: { prune: true, selfHeal: true }

The delivery loop is now fully automated and safe:

text
CI builds image  →  bumps image tag (SHA) in myapp-config repo
                       │
                  Argo CD detects the commit
                       │
                  syncs cluster to match Git  →  new version live

Deploys become pull requests; rollbacks become git revert; drift is auto-corrected. Every one of the earlier tracks now clicks into place.

⚠ Close the loop end-to-end

For your portfolio, make sure the whole chain works without manual steps: push code → CI builds & publishes a SHA-tagged image → the config repo is updated → Argo CD deploys it → the dashboard shows the new version healthy. That end-to-end demo is what impresses interviewers.

The Complete System

Step back and look at what you’ve built — a genuine production-grade system that exercises the entire roadmap:

text
  Code ──▶ CI/CD (build, test, SHA-tag image)         [Docker, GitHub Actions]
                   │
            Config repo (Git)                        [GitOps source of truth]
                   │
              Argo CD sync                            [Argo CD]
                   ▼
 Kubernetes cluster (provisioned by Terraform)        [Terraform, Kubernetes]
                   │
      ┌────────────┼─────────────┐
 Prometheus     Zipkin        Grafana                 [Monitoring, Tracing]
 (metrics)     (traces)      (dashboards+alerts)

That single diagram is your elevator pitch: “I built and operate a containerised app, provisioned with IaC, deployed to Kubernetes via GitOps, with full monitoring and tracing.” That’s a DevOps engineer.

🧪 Hands-on Lab

📝

Tell the End-to-End Story

Write the sequence of what happens, across all your tooling, from the moment you push a one-line code change to the moment the new version is confirmed healthy in production.

🧠 Knowledge Check

Knowledge Check

In the finished system, how does a code change reach production?

Knowledge Check

How do monitoring and tracing complement each other during an incident?

💼 Interview Preparation

Interview Q&A

Describe an end-to-end production-grade system you'd be proud to show.

🎓 Track Complete

Congratulations — you’ve built a complete, production-grade DevOps system and, with it, a portfolio that ties together every skill on the roadmap: Linux and Git foundations, containers, Kubernetes, Terraform, CI/CD, monitoring, tracing, GitOps, and even AI-assisted operations with MCP.

You now have the vocabulary, the hands-on patterns, the interview answers, and a real project to point to. The best next step is to build your own variation — pick a different app, a different cloud, add a feature — and make the story yours.

Up Next

Back to the Roadmap — explore any skill

You've mastered this lesson. Continue your journey to becoming a DevOps Engineer.

Start Next Lesson→