Sharing my thoughts and experiences

Lazy Dev


# driftd: A Self-Hosted Terraform Drift Detection Daemon

Terraform is fantastic until reality diverges from state. Someone clicks through the AWS console. An auto-scaling policy changes an instance type. A DNS record gets edited manually. The state file says one thing, the actual infrastructure says another — and you only find out when something breaks.

I built **driftd** to catch this quietly before it becomes a problem. It's a single Go binary that runs as a daemon, periodically scans your Terraform state against live AWS and Cloudflare resources, and surfaces any drift through a web UI, REST API, and Slack notifications.

## The Problem with Drift

If you've run Terraform in production for any length of time you've seen it: the dreaded "changes detected on refresh" output that shows up unexpectedly. In a solo setup this is annoying. In a team environment with multiple engineers, multiple environments, and a mix of Terraform-managed and manually-adjusted resources — it compounds fast.

The existing solutions either require a full Terraform Cloud subscription, a heavy observability stack, or a CI job that runs `terraform plan` against every workspace on a schedule (which means storing credentials, managing state backend access, and waiting for plan execution times).

I wanted something simpler: a daemon that understands Terraform state files and knows how to query the matching resources directly.

## Architecture: One Binary, Everything Inside

The entire tool ships as a single statically-linked Go binary. There's no separate database server, no frontend deployment step, no sidecar. Everything is embedded:

```
driftd (single binary)
├── Cobra CLI          — serve, scan, workspace, version commands
├── SQLite database    — scan history, drift results, workspace config
├── HTTP API           — REST endpoints at /api/v1
├── React frontend     — embedded via go:embed from ui/dist
└── Scheduler          — cron-based scan dispatcher
```

The internal structure follows a clean layered approach:

```
internal/
├── config/      Viper-based YAML configuration
├── database/    SQLite init + schema migrations
├── models/      Domain types (Workspace, ScanRun, DriftResult)
├── store/       CRUD layer over SQLite using sqlx
├── api/         HTTP handlers using stdlib net/http
├── scanner/     Core drift detection logic
│   ├── state.go        State file readers (S3 + local)
│   ├── fetcher.go      AWS resource fetchers
│   ├── diff.go         Comparison with smart field ignoring
│   └── cloudflare_fetcher.go
├── scheduler/   Cron-based scan scheduling
└── notifier/    Slack + webhook notifications
```

### Key Technology Decisions

A few choices that shaped the design:

**Pure Go SQLite (`modernc.org/sqlite`)** — no CGO, no C compiler required, cross-compiles cleanly. The driver name is `"sqlite"` (not `"sqlite3"`). Paired with `sqlx` for raw SQL instead of an ORM — gives full control over queries and makes the data model explicit.

**Single writer enforced**: `db.SetMaxOpenConns(1)` plus WAL mode. SQLite is single-writer by design; enforcing this at the connection pool level prevents mysterious write conflicts.

**ULIDs for IDs** — sortable, URL-safe, timestamp-embedded. Querying by creation time works naturally without extra `ORDER BY` clauses on a separate timestamp column.

**Interface-based fetchers** — each resource type implements:

```go
type AWSFetcher interface {
    ResourceType() string
    Fetch(ctx context.Context, resourceID string, stateAttrs map[string]any) (map[string]any, error)
}
```

Adding a new resource type means implementing this interface and registering it — no changes to the core scanner loop.

**Stdlib `net/http`** — no Gin, no Echo, no Chi. For a daemon with a handful of REST endpoints the standard library is sufficient and removes a dependency.

## How a Scan Works

The scan loop is straightforward:

1. **Read state file** — from a local path or S3 object, depending on workspace configuration
2. **Walk managed resources** — iterate every `resource` block in the state
3. **Fetch live attributes** — for each resource type driftd supports, query the cloud provider directly
4. **Compare** — diff the state attributes against the live attributes, ignoring computed fields that are expected to vary
5. **Store results** — persist each resource's status (`in_sync`, `drifted`, or `deleted`) with a timestamp and the diff payload
6. **Notify** — if drift is found and notifications are configured, fan out to Slack and/or webhooks

The comparison step uses per-resource-type ignore lists to avoid noise. For EC2 instances, fields like `arn`, `public_dns`, and `public_ip` are excluded — these are computed by AWS and will always differ from what's in state after a plan/apply cycle.

## Supported Resources

### AWS

| Terraform Type | Compared Attributes |
|----------------|---------------------|
| `aws_instance` | instance_type, ami, availability_zone, tags |
| `aws_s3_bucket` | bucket, region |
| `aws_security_group` | name, description, vpc_id |
| `aws_db_instance` | instance_class, engine, engine_version, db_instance_status |
| `aws_vpc` | cidr_block, state, is_default |

### Cloudflare

Cloudflare fetchers activate automatically when credentials are present in the environment:

```bash
export CLOUDFLARE_API_TOKEN=<scoped-token>   # preferred
# or
export CLOUDFLARE_API_KEY=<global-key>
export CLOUDFLARE_EMAIL=<account-email>
```

| Terraform Type | Compared Attributes |
|----------------|---------------------|
| `cloudflare_record` | name, type, content, proxied, ttl, comment |
| `cloudflare_ruleset` | name, kind, phase, description |
| `cloudflare_zone_settings_override` | full settings block |

## Quick Start

```bash
# Build (requires Node.js for the embedded frontend)
make build

# Copy and edit the config
cp driftd.yaml.example driftd.yaml

# Start the server (binds to :8080 by default)
./driftd serve

# Open the UI
open http://localhost:8080
```

### Add a Workspace

```bash
# Terraform state stored in S3
./driftd workspace add \
  --name production \
  --source-type s3 \
  --source-config '{"bucket":"my-tfstate","key":"prod/terraform.tfstate","region":"us-east-1"}' \
  --region us-east-1 \
  --schedule "@every 6h"

# Local state file
./driftd workspace add \
  --name local-env \
  --source-type local \
  --source-config '{"path":"/path/to/terraform.tfstate"}' \
  --region us-east-1
```

### Run a One-Shot Scan

```bash
./driftd scan --workspace production
```

## Configuration

```yaml
server:
  port: 8080
  host: "0.0.0.0"

database:
  path: "./driftd.db"

log:
  level: "info"   # debug, info, warn, error

aws:
  region: "us-east-1"
  # profile: "my-profile"   # optional named profile

notifications:
  slack_webhook_url: "https://hooks.slack.com/services/..."
  webhook_url: "https://your-receiver.example.com/hook"
  on_drift: true      # notify when drift is detected
  on_delete: true     # notify when a resource disappears
  on_all_scans: false # notify after every scan regardless of result
```

AWS credentials follow the standard SDK chain: environment variables → `~/.aws/credentials` → IAM instance profile. No credentials are ever stored in the config file or database.

## Scan Scheduling

Each workspace can have its own schedule. driftd accepts standard cron expressions and the `robfig/cron` descriptors:

```
@every 15m        every 15 minutes
@every 6h         every 6 hours
@daily            once a day at midnight
0 */6 * * *       every 6 hours (standard cron)
```

An empty schedule means manual-only. The scheduler tracks running scans per workspace to avoid concurrent runs — if a scan is already in flight when the next trigger fires, the new invocation is skipped and logged.

## REST API

All endpoints are under `/api/v1`. Responses use a consistent envelope:

```json
{ "data": { ... } }
```

Errors return:

```json
{ "error": "descriptive message" }
```

| Method | Path | Description |
|--------|------|-------------|
| `GET` | `/workspaces` | List workspaces |
| `POST` | `/workspaces` | Create workspace |
| `GET` | `/workspaces/:id` | Get workspace |
| `PUT` | `/workspaces/:id` | Update workspace |
| `DELETE` | `/workspaces/:id` | Delete workspace |
| `GET` | `/workspaces/:id/scans` | Scan history for a workspace |
| `GET` | `/scans/:id` | Get a specific scan run |
| `GET` | `/scans/:id/results` | Drift results for a scan |
| `GET` | `/health` | Health check |

Deleting a workspace cascades — all scan runs and drift results for that workspace are removed automatically via SQLite foreign key constraints.

## Notifications

The notification pipeline uses a composite `MultiNotifier` that fans out to all configured receivers. A single notifier failing (e.g., Slack webhook returning 5xx) is logged as a warning and doesn't prevent other notifiers from firing.

Trigger conditions are evaluated once per scan:
- `on_drift: true` — at least one resource has `drifted` status
- `on_delete: true` — at least one resource has `deleted` status (no longer exists in the live account)
- `on_all_scans: true` — always notify, including clean scans

The Slack payload includes the workspace name, scan timestamp, and a formatted list of drifted resources with their attribute differences.

## What's Not Included (Intentionally)

driftd is deliberately scoped. It does not:

- **Run `terraform plan`** — no Terraform binary required, no state locking during scans
- **Apply changes** — read-only, never modifies infrastructure
- **Store cloud credentials** — uses the standard AWS SDK chain and environment variables for Cloudflare
- **Require a cloud database** — SQLite is sufficient for the scan volumes a typical team produces

The goal was a tool I could drop on a small VM or into a Kubernetes pod and forget about, not another service that needs its own managed database and credential rotation pipeline.

## CLI Reference

```
driftd serve                         Start the HTTP server and scheduler
driftd scan --workspace <name>       Run a one-shot scan
driftd workspace list                List all workspaces
driftd workspace add --name ...      Create a workspace
driftd workspace delete <name>       Delete a workspace
driftd version                       Print version
```

Use `--config` / `-c` on any command to point at a non-default config file.

---

The repository is at [github.com/georg-nikola/driftd](https://github.com/georg-nikola/driftd). Contributions welcome — especially additional resource fetchers for other AWS resource types or cloud providers.


How I built a single-binary Go daemon that detects configuration drift between Terraform state and live AWS/Cloudflare infrastructure, with an embedded React UI and scheduled scans.

driftd: A Self-Hosted Terraform Drift Detection Daemon


## Why Build a Developer Portal?

Every team with more than a handful of services eventually hits the same problem: no one knows what's running, who owns it, or where the docs are. The answer to this is usually [Backstage](https://backstage.io) — Spotify's open-source developer portal. It's excellent, but it's also a TypeScript monolith with a plugin ecosystem that can feel like overkill when you just want a catalogue of services with status indicators and links.

So I built my own — a mini Backstage that does exactly what I need and nothing more.

**Repository**: [dev-portal on GitHub](https://github.com/georg-nikola/dev-portal)

## What It Does

The portal is a service catalogue with the following per-service fields:

- **Name, team, description** — the basics
- **Status** — `healthy`, `degraded`, `down`, or `unknown`
- **Health check URL** — if provided, the backend pings it every 60 seconds and updates status automatically
- **Links** — docs, GitHub, and dashboard URLs surfaced as icon buttons on each card
- **Tags** — for filtering

The frontend has a sidebar with live filters (status, team, tags), a debounced search bar, and sidebar stats that always reflect the full dataset. All filtering is done client-side against an in-memory array fetched on load and refreshed every 30 seconds — snappy UX with no extra round trips.

## Stack

The same stack I use across my homelab projects, because consistency pays dividends at 2am when something breaks:

| Layer | Technology |
|---|---|
| Frontend | Vanilla JS, HTML, CSS — no build step, no framework |
| Backend | FastAPI (Python), async SQLAlchemy, asyncpg |
| Database | PostgreSQL 16 |
| Ingress | Traefik v3 via IngressRoute CRDs |
| Tunnel | Cloudflare Tunnel → no open inbound ports |
| GitOps | ArgoCD + Image Updater |
| CI | GitHub Actions — build, Trivy scan, Playwright tests |

The frontend is intentionally framework-free. For a portal this size it's the right call: zero build complexity, instant load, and the whole thing is four files (`index.html`, `style.css`, `app.js`, and `nginx.conf`).

## Architecture

```
Browser
  ↓
Cloudflare Edge (DNS / WAF / DDoS protection)
  ↓
Cloudflare Tunnel (outbound-only, zero open ports)
  ↓
Traefik (IngressRoute: /api → API, everything else → frontend nginx)
  ↓
┌─────────────────────┐   ┌────────────────────────────────┐
│  nginx (static)     │   │  FastAPI (API)                 │
│  dev-portal:80      │   │  dev-portal-api:8000           │
│                     │   │  ├── /api/services CRUD        │
│  Serves HTML/JS/CSS │   │  ├── /api/services/{id}/check  │
│                     │   │  ├── /api/health               │
└─────────────────────┘   │  └── background health checker │
                          └──────────────┬─────────────────┘
                                         │
                          ┌──────────────▼─────────────────┐
                          │  PostgreSQL StatefulSet         │
                          │  NetworkPolicy: API pods only   │
                          └────────────────────────────────┘
```

The Traefik routing uses two IngressRoutes:

```yaml
# Frontend: everything that isn't /api
match: Host(`dev-portal.georg-nikola.com`) && !PathPrefix(`/api`)

# API: requests with /api prefix
match: Host(`dev-portal.georg-nikola.com`) && PathPrefix(`/api`)
```

No `StripPrefix` middleware — the FastAPI app registers its routers with `prefix="/api"`, so the paths are preserved end-to-end. This mirrors how my [movie-picker](https://github.com/georg-nikola/movie-picker) API is wired up.

## The Background Health Checker

The most interesting piece of the backend is the async background task that polls service health endpoints:

```python
async def _run_status_checks():
    while True:
        try:
            await asyncio.sleep(settings.status_check_interval)  # 60s
            async with AsyncSessionLocal() as db:
                result = await db.execute(
                    select(Service).where(Service.status_url.isnot(None))
                )
                svcs = result.scalars().all()

            for svc in svcs:
                new_status = await _ping_url(svc.status_url)
                async with AsyncSessionLocal() as db:
                    obj = await db.get(Service, svc.id)
                    if obj:
                        obj.status = new_status
                        obj.last_checked_at = datetime.now(timezone.utc)
                        await db.commit()
        except asyncio.CancelledError:
            break
        except Exception as exc:
            logger.exception("Error in background status checker: %s", exc)
```

It's launched as an `asyncio.Task` in the FastAPI lifespan context manager and cancelled cleanly on shutdown. Each ping returns `healthy` for HTTP 2xx, `degraded` for non-2xx, and `down` for connection errors or timeouts.

There's also a `POST /api/services/{id}/check` endpoint that triggers an immediate check for a single service — surfaced on each card as a "Check now" button.

## Playwright Integration Tests

I added a full Playwright test suite that runs on every CI push. The tests cover 44 assertions across 15 test groups:

- Page load and brand rendering
- Add service modal (open, form fields, close via Cancel and Escape)
- Creating a service and verifying the card appears with correct name, status badge, team, tags, and links
- Sidebar stats updating after create
- Search debouncing and empty state
- Status, team, and tag filter toggle behaviour
- Edit modal pre-filling and saving
- Delete flow with confirm modal (including cancel)
- Validation (empty name blocked)
- Toast notifications
- Zero console errors

```bash
# Run against docker-compose
docker compose up -d
python tests/test_dev_portal.py --url http://localhost:8080

# Run against the deployed cluster via port-forward
kubectl port-forward svc/dev-portal 18080:80 -n dev-portal &
kubectl port-forward svc/dev-portal-api 18001:8000 -n dev-portal &
python tests/test_dev_portal.py --url http://localhost:18080 --api-url http://localhost:18001
```

The `--api-url` flag uses Playwright's `page.route()` to intercept `/api/*` requests and redirect them to the separately port-forwarded API service. This lets the tests run against the actual deployed cluster without needing to touch DNS.

In CI (GitHub Actions), the Playwright job runs after both Docker builds complete, spins up the full stack with `docker compose up --build`, waits for the API health check, then runs the suite.

## Deployment with ArgoCD and Helm

Three ArgoCD Application manifests manage the deployment (in my private [talos-configs](https://github.com/georg-nikola/talos-configs) repo):

- `postgresql-dev-portal` — PostgreSQL StatefulSet with 5Gi PVC, NetworkPolicy restricting access to API pods only
- `dev-portal-api` — FastAPI, `readOnlyRootFilesystem: true`, `/tmp` as tmpfs emptyDir, non-root user
- `dev-portal` — nginx serving static assets

All three are annotated for ArgoCD Image Updater with semver strategy, so pushing a `v*.*.*` git tag automatically triggers a CI build, publishes `ghcr.io/georg-nikola/dev-portal:X.Y.Z` and `ghcr.io/georg-nikola/dev-portal-api:X.Y.Z`, and ArgoCD rolls out the new images.

## Debugging: The Cloudflare Tunnel Trap

Getting the portal live took longer than building it, for two reasons.

**First**, the Helm chart templates had `tls: certResolver: cloudflare` in the IngressRoutes. This Traefik instance doesn't have a cert resolver configured — TLS is terminated by Cloudflare at the edge before traffic reaches the cluster via the tunnel. Traefik silently dropped both routes with `"Router uses a nonexistent certificate resolver"` in its logs, resulting in a clean 404 with no obvious error visible to the browser. The fix: remove the `tls` block entirely, matching how every other app in the cluster is configured.

**Second**, even after fixing Traefik, the site was still 404. The issue this time was that `dev-portal.georg-nikola.com` was never in the Cloudflare tunnel's ingress config. My initial Python patch to the ConfigMap had silently failed — the entry wasn't saved. Without it, cloudflared hit its catch-all `http_status:404` rule for every request, so traffic never even reached Traefik.

Both bugs produced the same symptom (404), which made them harder to separate. The breakthrough was testing routing directly against Traefik via port-forward with an explicit `Host:` header — that returned 200, which proved Traefik was fine and pointed the finger squarely at the tunnel.

Lesson: always verify the tunnel config explicitly after patching it. I've now added the entry to the `config.yaml` in talos-configs so it's version-controlled and won't drift again.

## What's Next

A few things I'm considering adding:

- **Dependency graph** — draw edges between services that call each other
- **On-call ownership** — link a service to a rotation or contact
- **Changelog per service** — embed the last few GitHub releases from the API
- **Read-only API key** for external tooling to query the catalogue

For now though, it does exactly what I wanted: one URL, every service, current status, all the links. No YAML schemas to write, no plugin registry to manage.

Live at [dev-portal.georg-nikola.com](https://dev-portal.georg-nikola.com) — source at [github.com/georg-nikola/dev-portal](https://github.com/georg-nikola/dev-portal).


Building a Mini Backstage: An Internal Developer Portal on Kubernetes

docs-drift: Catching Documentation Drift Before It Breaks Your Users

Building DevMind Pipeline: ArgoCD-Powered GitOps for AI-Enhanced DevOps

A comprehensive guide to transforming an old desktop into a production-ready Kubernetes cluster using Talos Linux. Learn how to set up an immutable, secure, cloud-native home server with real-world configurations.

Building a Production-Grade Home Server with Talos Linux and Kubernetes

Building Sentinel Mesh: A Cloud-Native Monitoring Platform with ML-Powered Intelligence

Modernizing a Next.js Blog: From Static Hosting to Kubernetes with Cloudflare Tunnel


# Migrating from AWS RDS to Aurora: A Step-by-Step Guide

Migrating your database from AWS RDS to Aurora can offer performance improvements, cost-efficiency, and enhanced features. In this guide, we'll walk through the steps to make this migration as smooth as possible.

## Pre-requisites

- AWS Account
- Existing RDS instance
- AWS CLI installed and configured

## Step 1: Backup Your RDS Instance

Before making any changes, it's crucial to backup your existing RDS instance.

```bash
aws rds create-db-snapshot --db-instance-identifier [Your RDS Instance Name] --db-snapshot-identifier [Snapshot Name]
```

## Step 2: Create an Aurora Replica

Create an Aurora replica of your RDS instance.

```bash
aws rds create-db-cluster --engine aurora --replication-source-identifier [Your RDS Instance ARN]
```

## Step 3: Promote Aurora Replica

Once the replica is in sync, promote it to become a standalone Aurora cluster.


```bash
aws rds promote-read-replica-db-cluster --db-cluster-identifier [Your Aurora Cluster ID]
```


## Step 4: Update Connection Strings

Update your application's database connection strings to point to the new Aurora instance.

## Step 5: Test and Monitor

Thoroughly test the new Aurora instance to ensure it meets your performance and reliability requirements.

## Conclusion

Migrating from AWS RDS to Aurora can offer numerous benefits. By following this guide, you can ensure a smooth transition and make the most out of your new Aurora database.



Migrating from AWS RDS to Aurora: A Step-by-Step Guide


# A Day in the Life of an SRE Engineer 

Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems. , SREs play a crucial role in ensuring that services are reliable and scalable. Here's a glimpse into a typical day.

## Morning: Stand-up Meeting

The day starts with a stand-up meeting where the team discusses the status of ongoing projects and any incidents from the previous day.

## Mid-Morning: Code Reviews

SREs spend time reviewing code to ensure that it meets quality and performance standards.

## Lunch: Knowledge Sharing

Lunchtime is often an opportunity for knowledge sharing sessions where team members present on topics of interest.

## Afternoon: Incident Management

SREs are responsible for incident management. They use tools like PagerDuty to stay alert to any issues that may arise.

## Late Afternoon: Capacity Planning

One of the key responsibilities is capacity planning to ensure that systems can handle growth.

## Evening: Documentation

The day often ends with updating documentation, a critical task that ensures everyone on the team can understand the systems in place.

## Conclusion

Being an SRE  is a challenging but rewarding role that requires a mix of software engineering and systems engineering skills. The focus is always on ensuring reliability, scalability, and performance of services.



A Day in the Life of an SRE Engineer 


# Maintaining Infrastructure and Developing CI/CD Pipelines in Google Cloud

In today's fast-paced development environment, maintaining a robust infrastructure and an efficient CI/CD pipeline is crucial. We leverage Google Cloud Platform (GCP) to achieve this. Here's how.

## Infrastructure Maintenance

### 1. Monitoring

We use Google Cloud Monitoring to keep an eye on our resources.

### 2. Logging

Stackdriver is our go-to service for logging all our applications and services.

### 3. Security

We implement VPCs, firewalls, and IAM roles to ensure a secure environment.

## CI/CD Pipeline Development

### 1. Source Control

We use Cloud Source Repositories to manage our codebase.


Maintaining Infrastructure and Developing CI/CD Pipelines in Google Cloud


# Working as a SysAdmin : An Insider's Perspective

System Administrators (SysAdmins) are the backbone of any IT organization, and at Unify, a subsidiary of Atos, the role is no different. This post aims to provide an insider's perspective on what it's like to work as a SysAdmin at Unify.

## Morning Routine: System Checks

The day usually starts with a routine check of all the systems to ensure they are running smoothly. Any alerts or issues from the previous night are addressed immediately.

## Mid-Morning: Patch Management

One of the key responsibilities is to keep all systems up-to-date with the latest patches. This involves careful planning to minimize downtime.

## Lunch Break: Team Meeting

Lunch breaks often include informal team meetings where we discuss ongoing projects, upcoming changes, and any challenges faced.

## Afternoon: User Support

SysAdmins at Unify are also responsible for user support. This includes resolving tickets, managing user accounts, and troubleshooting issues.

## Late Afternoon: Backup and Recovery

Ensuring that all data is securely backed up is a critical task. We use a combination of on-premises and cloud-based solutions for this.

## Evening: Documentation and Reporting

The day usually ends with updating documentation and generating reports to keep track of system performance, security incidents, and other key metrics.

## Skills Required

- Strong understanding of Linux/Unix systems
- Networking knowledge
- Scripting skills (Bash, Python)
- Familiarity with cloud services

## Conclusion

Working as a SysAdmin at Unify offers a challenging yet rewarding experience. The role requires a diverse skill set, from technical know-how to excellent communication skills, making it a fulfilling career choice for those interested in IT operations.



Working as a SysAdmin : An Insider's Perspective


# Developing a Monitoring System from Scratch: A Comprehensive Guide

Monitoring is crucial for maintaining the health, performance, and security of your applications. In this post, we'll guide you through the process of developing a monitoring system from scratch.

## Pre-requisites

- Basic understanding of programming
- Familiarity with Linux/Unix commands

## Step 1: Define Metrics

Identify the key metrics you want to monitor, such as CPU usage, memory usage, and response time.

## Step 2: Choose a Data Store

Decide where to store the metrics. Options include time-series databases like InfluxDB or relational databases like MySQL.

## Step 3: Data Collection

Develop scripts or use existing tools to collect the metrics.

```bash
#!/bin/bash
# collect_cpu_usage.sh

cpu_usage=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *\$[0-9.]*\$%* id.*/\\1/" | awk '{print 100 - $1}')
echo "CPU Usage: $cpu_usage%"
```


## Step 4: Data Aggregation

Aggregate the collected data for analysis.

```python
# Python code to aggregate CPU usage
import pandas as pd

data = pd.read_csv('cpu_usage.csv')
average_cpu_usage = data['cpu_usage'].mean()
```

## Step 5: Visualization

Use tools like Grafana to visualize the metrics.

## Step 6: Alerts

Implement alerting mechanisms to notify you when metrics cross certain thresholds.

```python
# Python code for alerting
if average_cpu_usage > 80:
    send_alert("High CPU usage")
```



## Conclusion

Building a monitoring system from scratch can be a rewarding experience that gives you full control over your application's health metrics. By following this guide, you can develop a robust monitoring system tailored to your needs.

