2. Observability: Monitoring / Logging / Tracing

Monitoring = การเฝ้าดูสิ่งที่เรารู้อยู่แล้วว่าต้องดู (known-unknowns). Observability = ความสามารถในการ "ถามคำถามใหม่" กับระบบจากข้อมูลที่มี โดยไม่ต้อง deploy ใหม่ (unknown-unknowns). SRE ที่ดีออกแบบระบบให้ ตั้งคำถามได้ ไม่ใช่แค่มี dashboard.

Core Concepts

สามเสาหลัก: Metrics vs Logs vs Traces

Four Golden Signals (จาก Google SRE)

RED vs USE

• RED (สำหรับ request-driven services): Rate, Errors, Duration.
• USE (สำหรับ resource เช่น CPU/disk/queue): Utilization, Saturation, Errors.

จำง่าย ๆ: request ให้คิดแบบ RED, resource ให้คิดแบบ USE.

Prometheus + PromQL

Prometheus ใช้โมเดล pull: server ไป scrape endpoint /metrics ของแต่ละ target เป็นระยะ (ต่างจาก push แบบ CloudWatch agent). ข้อมูลเป็น time series ที่ระบุด้วย metric name + labels เช่น http_requests_total{method="GET", status="200"}.

# error rate (%) ของ 5xx ในช่วง 5 นาที
sum(rate(http_requests_total{status=~"5.."}[5m]))
  /
sum(rate(http_requests_total[5m]))

# p99 latency จาก histogram — ต้อง sum by (le) ก่อนเข้า histogram_quantile
histogram_quantile(
  0.99,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

Prometheus scrape config และ alert rule ตัวอย่าง:

scrape_configs:
  - job_name: "checkout-api"
    metrics_path: /metrics
    scrape_interval: 15s
    static_configs:
      - targets: ["checkout:8080"]
---
groups:
  - name: slo-alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.02
        for: 10m               # ต้องเป็นจริงต่อเนื่อง 10 นาที กัน alert เด้งมั่ว
        labels:
          severity: page
        annotations:
          summary: "error rate เกิน 2% ที่ checkout-api"

Logging & Tracing tools

• Structured logging (JSON/logfmt) ดีกว่า plain text เพราะ query/aggregate ได้. ใส่ trace_id เพื่อเชื่อม log ↔ trace:

{"ts":"2026-09-13T10:02:11Z","level":"error","service":"checkout","trace_id":"a1b2c3","msg":"payment gateway timeout","latency_ms":5123}

• ELK / OpenSearch (Elasticsearch + Logstash/Beats + Kibana) = เก็บและ query log จำนวนมาก.
• Jaeger / OpenTelemetry = distributed tracing; แต่ละ request มี trace_id และ ประกอบด้วยหลาย span ที่บอก latency ของแต่ละ hop → หา bottleneck ใน microservices ได้.
• Grafana = ชั้น visualization/alert ที่ต่อได้ทั้ง Prometheus, Loki, OpenSearch.

เชื่อมกับ AWS / Cloud ที่คุณรู้อยู่แล้ว

Diagram — pipeline ของ observability

คำถาม interview ที่เจอบ่อย + แนวคำตอบ

1. "metrics, logs, traces ต่างกันยังไง เลือกใช้เมื่อไร?" → metrics = health รวม (ถูก, ทำ alert); logs = รายละเอียดเหตุการณ์ (หา "ทำไม"); traces = latency ข้าม service (หา "ตรงไหน"). ใช้ metric จับปัญหา → trace ระบุจุด → log หาสาเหตุ.

2. "Four Golden Signals มีอะไรบ้าง?" → Latency, Traffic, Errors, Saturation. เสริมว่า latency ต้องดู percentile และแยก error ออก.

3. "cardinality คืออะไร ทำไมอันตราย?" → จำนวน combination ของ label values. label ที่มีค่าไม่จำกัด (เช่น user_id, request_id) ทำให้ time series ระเบิด → Prometheus กิน memory จนล่ม. ให้ใส่เฉพาะ label ที่ cardinality ต่ำและมีความหมายต่อการ aggregate.

4. "Prometheus pull หรือ push? ข้อดีคือ?" → pull เป็นหลัก. ข้อดี: Prometheus รู้ว่า target ไหน down (scrape fail = สัญญาณ), จัดการ target ผ่าน service discovery ง่าย, และควบคุมโหลดฝั่ง server ได้. งาน batch/short-lived ใช้ Pushgateway เสริม.

5. "จะลด alert fatigue ยังไง?" → alert บน symptom (ที่ผู้ใช้เจอ เช่น error rate/latency) ไม่ใช่ทุก cause; ใช้ for: กัน flapping; ผูก alert กับ SLO burn rate; ทุก alert ต้อง actionable + มี runbook.

Pitfalls — จุดที่ผู้สมัครมักพลาด

Quiz ท้ายบท

Cheat Sheet — อ่านก่อนเข้าห้องสัมภาษณ์