Loading...
Loading...
Metrics, logs, traces, and Golden Signals — what SDE-2 interviews expect.
Metrics, logs, and traces — the 3 pillars of observability, Golden Signals, Prometheus, Grafana, OpenTelemetry, SLIs/SLOs/SLAs, and distributed tracing.
Observability fundamentals: metrics, logs, and traces — monitoring vs observability, Golden Signals (latency, traffic, errors, saturation), Prometheus, Grafana, OpenTelemetry, distributed tracing, SLIs/SLOs/SLAs, error budgets, and production instrumentation.
Observability is increasingly asked in SDE-2 and SRE-flavored frontend interviews — you need to explain the three pillars, how monitoring differs from observability, and how to instrument apps with OpenTelemetry.
This module covers Golden Signals, Prometheus and Grafana, distributed tracing, high-cardinality pitfalls, SLIs/SLOs/SLAs, error budgets, and production observability best practices.
Frontend engineers increasingly own client-side reliability — you will learn to instrument React apps, define meaningful SLOs, avoid alert fatigue, and use traces to debug slow API calls across services.
Topics span metrics vs logs vs traces, Golden Signals, Prometheus pull model, Grafana dashboards, OpenTelemetry instrumentation, SLI/SLO/SLA chains, error budgets, and Kubernetes monitoring with ServiceMonitors.
Observability questions appear in senior frontend and platform interviews. You must explain the three pillars, instrument apps for production debugging, avoid high-cardinality metrics, and connect SLIs to SLOs and error budgets — not just name tools. Client-side errors and slow API calls are increasingly part of the frontend engineer's operational responsibility.
Understanding system behavior through monitoring and metrics.
Observability is the ability to understand and diagnose the behavior of a complex software application using real-time monitoring and metrics. It goes beyond monitoring — enabling debugging, pattern discovery, and proactive anomaly detection.
Pillar 1 — numeric values over time.
Tools: Prometheus, Grafana, Datadog
Pillar 2 — text-based records of events.
Best practice: use structured logging (JSON format).
Tools: Elasticsearch, Kibana, Fluentd, Winston, Bunyan
Pillar 3 — end-to-end request flows across services.
Traces track a request across microservices. Each service adds trace metadata with trace_id, span_id, and parent_id.
{ "trace_id": "abc123", "span_id": "xyz789", "parent_id": "def456" }
Tools: Jaeger, Zipkin, OpenTelemetry
When something is wrong vs why it is wrong.
| Aspect | Monitoring | Observability |
|---|---|---|
| Purpose | Tells you when something is wrong | Helps you understand why |
| Scope | Part of observability | Comprehensive approach |
| Focus | Predefined metrics | Unknown unknowns |
| Debugging | Reactive | Proactive |
| Question | Is it broken? | Why is it broken? |
Google's four signals to assess service health.
| Signal | Description |
|---|---|
| Latency | Time to handle a request |
| Traffic | Demand on the system (requests/sec) |
| Errors | Rate of failed requests |
| Saturation | How full the service is (CPU, memory) |
Standard tool combinations for each pillar.
| Component | Tools |
|---|---|
| Metrics | Prometheus + Grafana |
| Logs | Fluentd/Logstash + Elasticsearch + Kibana |
| Traces | OpenTelemetry + Jaeger |
What SDE-2 interviewers expect you to know.
Common interview questions about observability.