Какие «четыре золотых сигнала» мониторинга используете

Question

deepseek-v3.2 · Accepted Answer

## **Четыре золотых сигнала мониторинга**

В DevOps-практике «четыре золотых сигнала» (Four Golden Signals) — это концепция, популяризированная Google в книге «Site Reliability Engineering» (SRE). Она фокусируется на ключевых метриках, которые наиболее полно отражают пользовательский опыт и здоровье приложения. Эти сигналы позволяют быстро выявлять проблемы, не утопая в избыточных данных. Я активно использую их в мониторинге распределённых систем, так как они обеспечивают целостное понимание производительности.

### **1. Задержка (Latency)**
**Задержка** измеряет время, необходимое для обслуживания запроса. Важно разделять задержку успешных и неудачных запросов, так как медленные ошибки (например, таймауты) могут маскировать реальные проблемы.
*   **Что измеряем:** Время от запроса до ответа (обычно перцентили P50, P95, P99).
*   **Инструменты:** Prometheus + Grafana для визуализации, Jaeger для трассировки.
*   **Пример метрики в Prometheus:**
    ```promql
    histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
    ```
*   **Практическое применение:** Резкий рост P99-задержки может указывать на проблемы с базой данных или сетью.

### **2. Трафик (Traffic)**
**Трафик** — это мера нагрузки на систему, обычно выражаемая в количестве запросов в секунду (QPS, RPS) для веб-служб, активных соединениях или пропускной способности сети.
*   **Что измеряем:** Объём входящих запросов (например, HTTP-запросы/сек).
*   **Инструменты:** Nginx/Ingress-контроллеры (логи), Prometheus, ELK-стек.
*   **Пример метрики:**
    ```bash
    # Пример запроса Prometheus для HTTP-трафика
    rate(http_requests_total{job="api-service"}[5m])
    ```
*   **Практическое применение:** Внезапное падение трафика может означать сбой upstream-компонента, а резкий рост — DDoS-атаку или виральный эффект.

### **3. Ошибки (Errors)**
**Ошибки** — это частота неудачных запросов, выраженная в виде кодов HTTP 5xx/4xx, исключений в коде, таймаутов или сбоев зависимостей (например, недоступность БД).
*   **Что измеряем:** Процент ошибок от общего числа запросов (Error Rate).
*   **Инструменты:** Логи приложений (структурированные JSON), Sentry для отслеживания исключений, Prometheus для счётчиков ошибок.
*   **Пример алерта в Prometheus:**
    ```yaml
    # alertmanager правило
    - alert: HighErrorRate
      expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) * 100 > 5
      for: 2m
    ```
*   **Практическое применение:** Рост доли ошибок выше порога (например, 1-2%) требует немедленного расследования.

### **4. Насыщенность (Saturation)**
**Насыщенность** показывает, насколько «заполнена» система, то есть степень использования критических ресурсов (CPU, память, дисковое I/O, сетевые лимиты). Это прогнозный сигнал, указывающий на приближение к пределам.
*   **Что измеряем:** Использование ресурсов с учётом лимитов (например, нагрузка на CPU, потребление памяти, свободное дисковое пространство, очередь сообщений в Kafka).
*   **Инструменты:** Node Exporter для хостов, cAdvisor для контейнеров, мониторинг облачных ресурсов (CloudWatch, Azure Monitor).
*   **Пример метрики для памяти контейнера:**
    ```promql
    container_memory_working_set_bytes{container="app"} / container_spec_memory_limit_bytes{container="app"} * 100
    ```
*   **Практическое применение:** Постепенный рост насыщенности диска может предупредить о необходимости очистки или масштабирования.

## **Как я применяю золотые сигналы на практике**
*   **Сбор метрик:** Внедряю **инструментирование приложений** (через библиотеки OpenTelemetry) и инфра, собираю всё в единое хранилище (часто **Prometheus** или VictoriaMetrics).
*   **Визуализация:** Настраиваю **дашборды в Grafana**, группируя метрики по четырём сигналам для каждого сервиса. Например:
    *   **Латентность:** Графики перцентилей.
    *   **Трафик:** RPS по эндпоинтам.
    *   **Ошибки:** Процент 5xx и 4xx.
    *   **Насыщенность:** Использование CPU/памяти и диска.
*   **Алертинг:** Настраиваю **алерты в Alertmanager**, основанные на комбинации сигналов. Например, «если трафик высокий И латентность растёт И процент ошибок > 2%» — критический алерт.
*   **Автоматизация:** Интегрирую с **инцидент-менеджментом** (PagerDuty, Opsgenie) и **CI/CD-пайплайнами** (например, автоскейлинг при насыщенности CPU > 80%).

**Ключевое преимущество** подхода — его универсальность: он применим к микросервисам, монолитам, базам данных и очередям. Комбинируя эти сигналы, можно быстро локализовать проблему: например, высокая задержка при низкой насыщенности может указывать на проблему в коде, а не на нехватку ресурсов. Это основа для построения **наблюдаемости** (observability) и соблюдения **SLA/SLO**.

Какие «четыре золотых сигнала» мониторинга используете

Комментарии (1)

Четыре золотых сигнала мониторинга

1. Задержка (Latency)

2. Трафик (Traffic)

3. Ошибки (Errors)

4. Насыщенность (Saturation)

Как я применяю золотые сигналы на практике