🟢 Junior Level

Моніторинг — це спостереження за здоров’ям усіх сервісів у реальному часі.

Три ключові сигнали (Golden Signals):

1. Latency — скільки часу займає запит
2. Traffic — скільки запитів за секунду
3. Errors — скільки помилок за секунду
4. Saturation — наскільки заповнені ресурси (CPU, memory)

Інструменти:

• Prometheus — збір метрик
• Grafana — візуалізація
• Alertmanager — алерти

---

🟡 Middle Level

Метрики

Application metrics:

- Request rate (req/s)
- Error rate (%)
- Latency (p50, p95, p99)
- Active connections
- Thread pool usage

Infrastructure metrics:

- CPU usage
- Memory usage
- Disk I/O
- Network I/O

Prometheus + Grafana

// Micrometer для Spring Boot
@RestController
public class OrderController {
    private final Counter orderCounter;
    private final Timer orderTimer;

    public OrderController(MeterRegistry registry) {
        this.orderCounter = registry.counter("orders.created");
        this.orderTimer = registry.timer("orders.processing.time");
    }

    @PostMapping("/orders")
    public Order createOrder(@RequestBody OrderRequest req) {
        return orderTimer.record(() -> {
            // MeterRegistry — інтерфейс Micrometer (Spring Boot Actuator).
            // record() — замірює час виконання лямбди і записує в Timer.
            orderCounter.increment();
            return orderService.create(req);
        });
    }
}

Типові помилки

1. Too many alerts:

   100 алертів за годину → alert fatigue → справжні пропускаються
   Рішення: тільки actionable alerts
   // Actionable alert = якщо спрацював, інженер знає ЩО робити.
   // Якщо alert спрацював, а робити нічого — це noise, його треба прибрати або покращити.
   

---

🔴 Senior Level

RED method

For services:
- Rate: requests per second
- Errors: failed requests per second
- Duration: request latency distribution

USE method

For resources:
- Utilization: average time resource was busy
- Saturation: amount of work queued
- Errors: error count

Production Experience

Prometheus config:

scrape_configs:
  - job_name: 'user-service'
    metrics_path: '/actuator/prometheus'
    scrape_interval: 15s

  - job_name: 'order-service'
    metrics_path: '/actuator/prometheus'
    scrape_interval: 15s

Alerting rules:

groups:
- name: service_alerts
  rules:
  - alert: HighErrorRate
    expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
    // Це >5% error rate, а не >0.05 запитів/сек.
    for: 5m
    labels:
      severity: critical

Best Practices

✅ Golden Signals
✅ RED/USE методи
✅ Actionable alerts тільки
✅ Dashboard per service
✅ SLI/SLO tracking

❌ Too many alerts
❌ Without dashboards
❌ Without SLO

---

🎯 Шпаргалка для співбесіди

Обов’язково знати:

• Golden Signals: Latency, Traffic, Errors, Saturation
• Prometheus — збір метрик, Grafana — візуалізація, Alertmanager — алерти
• Micrometer + Spring Boot Actuator — стандарт для Java-додатків
• RED method (Rate, Errors, Duration) — для сервісів
• USE method (Utilization, Saturation, Errors) — для ресурсів
• Тільки actionable alerts — якщо спрацював, інженер знає ЩО робити
• p50, p95, p99 latency — p99 показує worst-case досвід користувача

Часті уточнюючі питання:

• Що таке actionable alert? Alert, при якому інженер знає конкретну дію. Без action = noise, прибрати.
• RED vs USE? RED — для сервісів (Rate, Errors, Duration), USE — для ресурсів (Utilization, Saturation, Errors).
• Чому p99 а не average? Average ховає outliers — p99 показує досвід 1% найгірших користувачів.
• Alert fatigue що це? 100 алертів за годину → справжні пропускаються → тільки actionable alerts.

Червоні прапорці (НЕ говорити):

• “Чим більше alerts — тим краще” — ні, alert fatigue призводить до пропуску реальних
• “Average latency достатньо” — ні, ховає outliers, p99 важливий
• “Метрики = логи” — ні, метрики = агреговані числа, логи = деталізація
• “Prometheus без Grafana — норм” — без dashboards неможливо оперативно реагувати

Пов’язані теми:

• [[22. Що таке distributed tracing]]
• [[21. Як моніторити розподілену систему мікросервісів]]
• [[5. Що таке патерн Circuit Breaker]]
• [[17. Як забезпечити відмовостійкість мікросервісів]]
• [[26. Які інструменти використовуються для оркестрації мікросервісів]]