Доки Арута

Алертинг

Алертинг

Теория. SLI, SLA, SLO

Построение алертинга основывается на концепциях SLI, SLA и SLO.
SLI, SLA и SLO помогают обеспечить качественный уровень обслуживания в IT.

SLI (Service Level Indicator) - набор ключевых метрик, по которым можно определить жизненный статус сервиса, его производительность, «удовлетворенность» конечных юзеров работой сервиса.
Например, в SLI может входить кол-во 500-х ошибок или кол-во активных юзеров.

SLA (Service Level Agreement) - «соглашение об уровне доступности сервиса» - внешнее обязательство перед конечным юзером/клиентом.
Например, SLA чьей-то круглосуточной техподдержки обычно составляет 15 минут - за это время поддержка обязуется отреагировать на запрос/инцидент клиента, и это не зависит от внутренних обстоятельств.

SLO (Service Level Objective) - набор целевых, «желаемых» значений SLI, выход за пределы которых может нарушить SLA сервиса/компонента.
Максимально допустимое отклонение от «идеальных» показателей в данной концепции называется Error Budget (право на ошибку).
Например, максимальное кол-во 500-х ошибок за 5м, максимальное время недоступности веб-страницы, максимально допустимая нагрузка на CPU и т.д.

Если ставить алерты на отклонение от SLO, то может возникнуть “алертный шум” (много notifications, когда система нормально работает); еще есть риск получить алерт только в момент нарушения SLA.
А алерт должен срабатывать не тогда, когда всё уже хуево, и не от каждой помехи, а тогда, когда возникли траблы, но еще можно что-то исправить.

Здесь рекомендуют ставить внутренние алерты на значения между SLO и Error Budget - когда поведение системы еще можно назвать штатным, но если ничего не делать, есть риск выйти за пределы SLA.

Базовые алерты

CPU

  • CPU idle < 10% в течении 10 минут
    (avg(irate(node_cpu_seconds_total{mode="idle"}[10m])) * 100) < 10

  • CPU load avg превышает возможности CPU (>100%) и не равно 0 в течение 5 минут
    Если одно ядро у процессора на сервере, например
    node_load1 > 1 for 5m

RAM

Выше нагрузка на RAM и ближе к 100% utilization → выше вероятность тормозов (или даже OOM Killer проснется 😱).

  • Заполнение SWAP > 90%
    (актуально для версий ядра Linux младше 3-й)
    uname -r

  • Активная запись в SWAP (swapin > 1 Мбайт/с) в течение 2-5 минут
    (актуально для новых версий ядра Linux)
    (rate(node_vmstat_pswpin[5m]) / 1024^2) > 1

  • RAM utilization > 85%
    ((1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100) > 85

Disk

Слишком высокая нагрузка на диск → полная деградация whole системы.

  • Нагрузка на диск (iostat) > 95% в течение 1 часа
    ((1 - avg_over_time(node_filesystem_avail_bytes[1h]) / avg_over_time(node_filesystem_size_bytes[1h])) * 100) > 95

  • Свободное место на диске (по каждому разделу) < 10%
    доп. алерт, если < 5%
    ((node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100) < 10

(Доп: Free inodes (по каждому разделу) < 10%)

Синхронизация времени

Рассинхронизация времени может привести к сложнодиагностируемым траблам. Мониторить ее можно, запрашивая статус используемых на сервере утилит синхронизации времени (ntpd, chronyd, systemd-timesyncd).

  • 500 миллисекунд в течение 5 минут

  • < 500 миллисекунд в течение 5 минут

    PromQL выражение для обоих алертов:
    ntp_drift_seconds is within range [0.5ms to -0.5ms] for 5m
    **если находится вне этого диапазона**

Как их настроить: ntp_exporter

Сеть

  • Входящая нагрузка > 75% (или 90% от лимита)
    (irate(node_network_receive_bytes_total{device="eth0"}[5m]) / 1024^2 / 200 * 100) > 75

  • Исходящая нагрузка > 75% (или 90% от лимита)
    (irate(node_network_transmit_bytes_total{device="eth0"}[5m]) / 1024^2 / 200 * 100) > 75

200 - максимальная скорость интернета на сервере (Мбит/сек)

  • Алерт на резкий (и при этом нехарактерный) скачок вход./исход. трафика

Алерты для доп. мониторинга дисков и RAID-массивов, опять же, в соусе
Здесь не вижу смысла расписывать пока.

Сервисы

  • Процесс сервиса запущен
  • Количество рестартов процесса сервиса не превышает 5 за 1 минуту

Nginx

  • Нет запросов (с любым кодом ответа) за промежуток времени
  • Процент пятисотых кодов ответа за 1 минуту
  • Процент ошибочных кодов ответа по отношению к двухсотым кодам
  • Время обработки 95 % запросов не укладывается в промежуток времени
  • SSL-сертификат истекает через 7 дней

MySQL

  • Используется более 80 % доступных соединений
  • Количество медленных запросов
  • Состояние репликации

Бэкенд

  • Количество процессов php-fpm превысило лимит
  • Размер очереди ожидающих коннектов
  • Количество принятых коннектов превышает порог в течение 5 минут

Инфа (по большей части) отсюда: https://www.itsumma.ru/blog/alerts
Инфа отсюда использовалась в Module 22

metricsalertmanagermonitoringalerting

Graph View

Backlinks