Monitoring & Logging — Từ Vựng DevOps Mà Developer Cần Biết

📱 Học IELTS miễn phí: App IELTS 6.0

Giới thiệu

“The system is down!” — đây là câu không ai muốn nghe lúc 2 giờ sáng. Monitoring và Logging chính là lá chắn giúp bạn phát hiện sự cố trước khi user kịp report.

Trong thế giới DevOps, SRE (Site Reliability Engineering), và Cloud-native, monitoring & logging là kỹ năng bắt buộc. Và toàn bộ documentation, alerting messages, dashboard labels đều bằng tiếng Anh.

Bài viết này giúp bạn:

• Nắm vững từ vựng Monitoring & Logging quan trọng nhất
• Biết cách phát âm (IPA) để tự tin trong incident meetings
• Hiểu qua ví dụ cấu hình thực tế với Prometheus, Grafana, ELK
• Câu mẫu tiếng Anh để thảo luận khi on-call và post-mortem

1. Monitoring Fundamentals — Khái Niệm Giám Sát Cơ Bản

Ví dụ: Health Check Endpoint

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# A simple health check endpoint
@app.get("/health")
def health_check():
    return {
        "status": "healthy",
        "uptime": get_uptime(),
        "checks": {
            "database": check_db_connection(),
            "redis": check_redis_connection(),
            "disk_space": check_disk_usage()
        }
    }

Cách nói trong meeting:

“Our health check endpoint verifies the database connection, Redis, and disk space. If any check fails, the load balancer automatically removes the instance from the pool.”

2. Metrics & Alerting — Chỉ Số & Cảnh Báo

Ví dụ: Prometheus Alert Rules

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# Prometheus alerting rules
groups:
  - name: api-alerts
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High error rate detected"
          description: "Error rate is {{ $value | humanizePercentage }} (threshold: 5%)"

      - alert: HighLatency
        expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "P99 latency exceeds 2 seconds"

Cách giải thích:

“We’ve set up two alerts in Prometheus. The first fires when the error rate exceeds 5% for 5 minutes — that’s critical severity. The second triggers when P99 latency goes above 2 seconds, which is a warning.”

The Four Golden Signals

Google SRE định nghĩa 4 tín hiệu vàng mà mọi service nên monitor:

3. Logging — Ghi Log

Log Levels — Khi nào dùng level nào?

Ví dụ: Structured Logging

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// ❌ Bad: unstructured log — hard to search and parse
console.log("User login failed for [email protected] from IP 192.168.1.1");

// ✅ Good: structured log — easy to query in ELK/Grafana
logger.warn({
  event: "login_failed",
  user: "[email protected]",
  ip: "192.168.1.1",
  reason: "invalid_password",
  attempt: 3,
  correlationId: "req-abc-123"
});

Câu mẫu:

“We migrated from plain text logs to structured logging in JSON format. Now we can filter by any field in Kibana — for example, show all login_failed events from a specific IP in the last hour.”

4. Tracing & Observability — Theo Dõi & Quan Sát

Three Pillars of Observability

Observability dựa trên 3 trụ cột:

Cách giải thích:

“We’ve implemented all three pillars of observability. Metrics in Prometheus tell us what is happening, logs in Loki tell us why, and traces in Jaeger show us where the bottleneck is across services.”

5. Incident Management — Quản Lý Sự Cố

Ví dụ: Post-Mortem Report

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

## Incident Post-Mortem: API Outage 2026-03-15

**Duration:** 45 minutes (14:00 - 14:45 UTC)
**Severity:** SEV-1 (Critical)
**Impact:** 100% of API requests returned 503

### Timeline
- 14:00 — **Alert fired**: Error rate exceeded 90%
- 14:05 — **On-call engineer** acknowledged the alert
- 14:12 — **Root cause** identified: OOM kill on primary DB
- 14:30 — **Mitigation**: Increased DB memory, restarted pods
- 14:45 — **Resolved**: Error rate back to normal

### Root Cause
The nightly batch job consumed excessive memory, causing
the database to be OOM-killed by the kernel.

### Action Items
- [ ] Set memory limits on batch job containers
- [ ] Add memory saturation alert at 80% threshold
- [ ] Update runbook for database OOM scenarios

Cách nói trong post-mortem meeting:

“The root cause was an OOM kill on the primary database. Our MTTD was 0 minutes thanks to the error rate alert, but MTTR was 45 minutes because the runbook didn’t cover this specific scenario. We need to update it.”

6. Tools & Stack — Công Cụ Phổ Biến

7. Practice — Luyện Tập

Exercise 1: Chọn thuật ngữ đúng

Điền thuật ngữ phù hợp vào chỗ trống:

1. “Our ______ shows that P99 latency spiked to 5 seconds at 3 PM.”
2. “We need to add a ______ to track requests across all microservices.”
3. “The ______ fired at 2 AM, so the ______ engineer was paged.”
4. “After the outage, we wrote a ______ to prevent it from happening again.”
5. “Switch log level to ______ in production to reduce log volume.”

Exercise 2: Viết Alert Rule

Dựa trên yêu cầu tiếng Anh, viết mô tả alert:

“Create a critical alert that fires when the API error rate exceeds 10% for more than 3 minutes.”

1
2
3
4
5
6
7
8

- alert: CriticalErrorRate
  expr: rate(http_requests_total{status=~"5.."}[3m]) / rate(http_requests_total[3m]) > 0.10
  for: 3m
  labels:
    severity: critical
  annotations:
    summary: "API error rate above 10%"
    description: "Error rate has been {{ $value | humanizePercentage }} for 3+ minutes"

Exercise 3: Giải thích cho team

Hãy giải thích bằng tiếng Anh:

1. Sự khác biệt giữa SLA, SLO, và SLI.
2. Tại sao cần structured logging thay vì plain text.
3. Three pillars of observability là gì và tại sao cần cả ba.

Kết luận

Monitoring & Logging không phải chỉ là công việc của DevOps — đây là trách nhiệm chung của cả development team. Khi bạn hiểu từ vựng này, bạn có thể:

• Đọc hiểu alert messages và dashboard không cần dịch
• Tham gia incident response và post-mortem hiệu quả
• Viết log messages và alert descriptions rõ ràng
• Thảo luận kiến trúc observability với team quốc tế

3 điều cần nhớ:

1. Four Golden Signals: Latency, Traffic, Errors, Saturation — monitor cả 4
2. Structured Logging: JSON format + Correlation ID = dễ debug gấp 10 lần
3. Post-mortem là văn hóa, không phải blame game — focus vào root cause và action items

Mẹo: Lần tới khi on-call hoặc review alert rules, hãy đọc lại bài này. Bạn sẽ tự tin hơn rất nhiều khi tham gia incident channel bằng tiếng Anh! 🚀