If your server fails at 3am and nobody gets alerted, do you even have monitoring?
Monitoring tells you something is wrong right now. Logging tells you what happened and why. Most teams confuse the two, set up one but not the other, and discover outages when users complain rather than when systems alert. In Africa, where power instability and connectivity gaps are real infrastructure variables, a proper alerting strategy isn't optional — it's the difference between a two-minute fix and a two-hour crisis.
There's a version of "having monitoring" that means nothing. You installed a tool, it collects data, and it's been generating alerts so frequently that everyone muted them months ago. That's not monitoring. That's noise with a dashboard attached.
Monitoring vs logging — why teams mix them up
Monitoring is real-time: it watches your systems continuously, compares current values against thresholds, and fires an alert when something breaches a limit. CPU over 90% for 5 minutes, HTTP error rate above 5%, response time over 2 seconds — these are monitoring concerns. Logging is historical: it records a timestamped trail of events, errors, and state changes that you query after the fact to understand what went wrong.
Both are essential. Monitoring without logging means you know the server is down but can't figure out why. Logging without monitoring means you have a perfect record of the outage that nobody knew was happening until the client called. The question isn't which one you need — it's whether you have both configured correctly.
The Prometheus + Grafana stack: what it is and why it's the default
Prometheus is an open-source metrics collection system. It scrapes numeric time-series data from your services at regular intervals — CPU usage, memory, request counts, queue depths, anything that can be expressed as a number over time. Grafana connects to Prometheus (and other data sources) to build visual dashboards and configure alert rules.
Together they've become the default open-source monitoring stack for container environments and infrastructure. Prometheus handles data collection and alerting logic. Grafana handles visualisation. Alertmanager (part of the Prometheus ecosystem) handles routing alerts to the right destination — email, Slack, PagerDuty, or a webhook. The stack is free, runs on modest hardware, and scales well from a single server to a multi-cluster Kubernetes environment.
Loki for logs: what it does differently
Loki is Grafana Labs' log aggregation system. Unlike Elasticsearch (which indexes the full text of every log line), Loki stores compressed log streams and indexes only metadata labels — service name, environment, hostname. This makes it significantly cheaper to run at scale. You query logs using LogQL, which borrows syntax from PromQL. The key advantage of Loki is that it integrates natively with Grafana, so you can view metrics and correlated logs in the same dashboard — pivoting from "the error rate spiked at 03:17" directly to "here are all the log lines from that minute".
Alerting strategy: the part most teams get completely wrong
Bad alerting is worse than no alerting. Alert fatigue — where too many low-signal notifications train your team to ignore everything — is the most common monitoring failure mode. A good alerting strategy starts with the question: what would require a human to act right now, in the middle of the night? Everything that doesn't answer "yes" to that question should be a dashboard annotation or a daily report, not a PagerDuty page.
Good alerts have: a clear name that states what is wrong, a runbook link that explains what to do, a severity level, and a deduplication policy so the same alert doesn't fire 40 times in 10 minutes. Alert on symptoms (users are experiencing errors) not causes (this specific process is using 85% CPU). The second type generates noise; the first type tells you something actionable.
Monitoring in Africa: power and connectivity as infrastructure variables
In Douala, Yaounde, and much of francophone Central Africa, power outages and internet disruptions are not edge cases — they're routine infrastructure variables. This creates specific monitoring challenges that most Western DevOps playbooks don't address. Your monitoring system needs to be resilient to the same failures it's meant to detect.
Practical adaptations: use multiple alert notification channels (SMS and WhatsApp alongside email), because email may not deliver during connectivity issues. Consider a hybrid or on-premise Prometheus setup rather than a fully cloud-dependent monitoring SaaS. Set alert suppression windows for known generator-start delays. And ensure your monitoring infrastructure is on a separate power circuit or has UPS backup — a monitoring system that goes down with the thing it monitors is not a monitoring system. Teams in Cameroon who take these steps often find they know about infrastructure problems before their cloud provider does.
Getting started: a minimal viable observability stack
For a small team, start with: Prometheus + Node Exporter for basic server metrics (CPU, memory, disk, network), Grafana for dashboards, and Alertmanager for routing alerts to a WhatsApp group or Slack channel. Add Loki + Promtail for log aggregation. This entire stack can run on a single modest VM with 2 vCPUs and 4GB RAM. Add Grafana's uptime monitoring (or a free tier of Better Uptime) for external endpoint checks. That's a complete observability foundation for most businesses running 1–20 servers — and it costs essentially nothing to operate.
Key takeaways
- Monitoring and logging are complementary — one tells you something is wrong now, the other tells you why it happened. You need both.
- Prometheus + Grafana + Loki is the de facto open-source observability stack and runs on minimal infrastructure.
- Alert fatigue is a real failure mode — alert on user-facing symptoms, not low-level internal causes.
- In Cameroon and Africa, design your monitoring to survive the same power and connectivity failures it's meant to detect: multiple alert channels, on-prem option, UPS backup.
Frequently asked questions
Monitoring tracks the current state of your systems in real time and triggers alerts when thresholds are breached. Logging records a historical trail of events for forensic investigation after something goes wrong. You need both.
Prometheus is an open-source metrics collection and alerting tool. Grafana is a visualisation layer that connects to Prometheus to build dashboards and alert rules. Together they form the most widely adopted open-source monitoring stack for infrastructure.
Loki is Grafana's log aggregation system, designed to work alongside Prometheus and Grafana dashboards. It stores compressed log streams indexed by labels, making it more resource-efficient than Elasticsearch for most workloads.
Use multiple notification channels (SMS, WhatsApp, email), consider on-premise or hybrid monitoring, set alert suppression for known maintenance periods, and ensure your monitoring infrastructure has UPS backup so it doesn't go down with the thing it's monitoring.
Sources
- Prometheus — Prometheus documentation: overview
- Grafana Labs — Grafana documentation
- Grafana Labs — Loki documentation
- Google SRE Book — Monitoring distributed systems
Ready to apply this? Kaevor helps businesses across Cameroon and Africa set up production-grade monitoring and logging with Prometheus, Grafana, and Loki. Message us on WhatsApp — we respond same day.
Chat on WhatsApp →