In observability, which artifacts are used together to diagnose issues in distributed systems?

• A. Logs, metrics, and traces
• B. Firewalls, IDS, SIEM
• C. DNS records, certificates, keys
• D. Backups, snapshots, replication

Answer: (A)

Observability relies on three complementary signals to understand how a distributed system behaves: metrics, logs, and traces. Metrics give you quantitative, time-series data such as latency, error rate, throughput, and resource usage, which helps you spot when something is off and how it’s trending over time. Logs capture events with context at specific moments, providing detailed information about what a service was doing when something happened. Traces show how a request moves through multiple services, revealing the path, timing, and dependencies involved, so you can see where delays or failures originate in the chain.

Using these together lets you not only detect that a problem exists but also pinpoint where it started and how it affected the rest of the system. For example, a spike in latency from metrics, a relevant error entry in a service log, and a trace that highlights the slow hop across services together illustrate the root cause more clearly than any single signal alone.

Other options miss the mark for observability. Security-focused tools like firewalls, IDS, and SIEM address threats and compliance rather than providing the day-to-day visibility needed to diagnose performance and reliability issues. DNS records, certificates, and keys relate to identity and security configuration rather than operational signals. Backups, snapshots, and replication are about data protection and disaster recovery rather than real-time system diagnosis.