Observability in the cloud: logs, metrics and traces
In short: Observability is your ability to understand what a system is doing from the data it emits. Logs record events, metrics track numbers over time and traces follow a single request across services. In cloud systems built from many short-lived parts, all three are needed for both reliability and security.
Monitoring versus observability
Monitoring watches for problems you already know about: CPU above 90 percent, a website returning errors, a disk filling up. Observability is broader: it is how well you can answer new questions about a system from the data it produces, such as "why are checkout requests from one region slow only since this morning's release?"
Cloud systems need this more than traditional ones. Applications are split into many services, containers live for minutes, servers scale up and down automatically, and much of the platform belongs to the provider. You cannot log in to a box and look around; the telemetry is often all you have.
Logs, metrics and traces
| Signal | What it is | Good for | Example |
|---|---|---|---|
| Logs | Timestamped records of individual events | Detail, investigation, security audit | User admin@example.com deleted bucket backups-01 |
| Metrics | Numeric values sampled over time | Trends, dashboards, cheap alerting | p95 latency 420 ms; error rate 2 percent |
| Traces | The path of one request through many services, as timed spans | Finding which service is slow or failing | Checkout 1.8 s, of which payment API 1.5 s |
The signals work best together. A metric alert tells you error rates jumped, a trace shows which service is failing, and that service's logs explain why. Linking them with shared identifiers, such as a trace ID written into each log line, saves a lot of time.
Structured logs (JSON with consistent field names) are far easier to search and correlate than free text. For metrics, watch out for high cardinality: a label with millions of possible values, such as user ID, can make metric storage slow and expensive.
Collecting telemetry
OpenTelemetry (OTel) is an open-source, vendor-neutral standard and toolkit from the Cloud Native Computing Foundation for producing and collecting logs, metrics and traces. You instrument your code once, send data to an OTel Collector, and export it to whichever backends you choose: open-source tools such as Prometheus, Grafana, Loki and Jaeger, or commercial and cloud services.
Each cloud also has native services: Amazon CloudWatch and AWS X-Ray, Azure Monitor with Log Analytics and Application Insights, and Google Cloud Observability. These collect platform telemetry automatically and are usually the easiest starting point.
Why it matters for security
- The same pipeline that finds performance problems can feed a SIEM with audit and access logs.
- Unusual metrics often reveal attacks: a CPU spike from crypto-mining, a surge in outbound traffic from data theft, or many 401 errors from credential stuffing.
- Traces show unexpected call paths, such as a service suddenly calling an internal admin API.
- Telemetry can itself leak data, so keep passwords, tokens and personal data out of logs and traces.
Tip: a simple starting set for any service is the four "golden signals": latency, traffic, errors and saturation.
Practice
Which signal would you use to see which of six microservices makes a request slow?
Why is adding a user ID label to a metric often a bad idea?
What does OpenTelemetry give you?
Key takeaways
- Observability means you can answer new questions from telemetry.
- Logs record events, metrics track numbers, traces follow requests.
- Link signals with shared IDs and use structured logs.
- OpenTelemetry standardises collection across vendors.
- Telemetry supports security detection, but must not leak secrets.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.