SavePearlHarbor

Observability Checklist. От железа до приложений, или как не остаться слепым в продакшене

—

от автора

admin

Привет, коллеги!

Если вы когда-нибудь просыпались среди ночи от алертов о том, что «всё упало», но не могли понять, почему — эта статья для вас. Поговорим о том, как построить нормальный мониторинг и перестать гадать на кофейной гуще.

В современном мире, где многие компании переходят на облачные технологии и используют managed-сервисы, важно понимать, какие метрики действительно необходимо мониторить самостоятельно, а какие можно оставить на усмотрение провайдера. Managed-ресурсы предоставляют множество преимуществ, включая автоматическое управление инфраструктурой и встроенные инструменты мониторинга. Однако это не освобождает вас от ответственности за мониторинг критичных для бизнеса метрик.

Автор статьи — Максим Гусев, спикер курса «SRE: data-driven подход к управлению надёжностью систем».

Системные метрики: железо и его причуды

CPU: не дайте процессору задохнуться

Load Average

  • Это среднее количество процессов, готовых к выполнению

  • Измеряется за 1,5 и 15 минут

  • Если больше количества ядер — система перегружена

  • Помогает предсказать проблемы с производительностью

  • Пример из жизни: Load Average 30 на 8-ядерной машине. Спойлер: кто-то запустил парсинг логов в проде.

CPU Usage по типам

  • User time — время выполнения пользовательских процессов

  • System time — время выполнения системных вызовов

  • Iowait — время ожидания ввода/вывода

  • Idle — время простоя

  • Steal — для виртуалок: время, украденное гипервизором

  • Реальный кейс: высокий iowait выдал проблему с логированием — приложение писало логи быстрее, чем диск успевал их сохранять.

Context Switches

  • Количество переключений между процессами

  • Высокие значения = потеря производительности

  • Помогает найти проблемы с многопоточностью

  • История из практики: однажды неправильная настройка thread pool привела к 100k+ переключений в секунду. Процессор был занят, но не работой.

Memory: когда «просто добавить оперативки» не помогает

Used/Available Memory

  • RSS (Resident Set Size) — реально используемая память

  • Virtual Memory — зарезервированная память

  • Heap — память для объектов в Java

  • Non-Heap — память для метаданных JVM

  • Dirty pages — данные, ожидающие записи на диск

  • Пример: приложение с memory leak съело всю память за 3 часа. Графики показали проблему за час до падения.

Swap Usage

  • Использование диска как дополнительной памяти

  • Swap In — чтение из swap в память

  • Swap Out — выгрузка из памяти в swap

  • Высокая активность swap = серьезное падение производительности

  • Кейс: система «тормозила», потому что база данных ушла в swap. Спасибо OOM Killer за «помощь».

Application Metrics: что творится в вашем коде

Response Time: почему пользователи жалуются на лаги

Latency (P95/P99)

  • P95 — время ответа для 95% запросов

  • P99 — время ответа для 99% запросов

  • Помогает найти «медленные» запросы

  • Важнее среднего времени ответа

  • Разбивка по эндпоинтам критична

  • Учет размера ответа

  • История: API с средним временем 100ms и P99 в 5 секунд. Причина? Один «тяжёлый» запрос к базе данных.

Apdex Score (Application Performance Index)

  • Оценка удовлетворенности пользователей от 0 до 1

  • T — целевое время ответа

  • Satisfied: < T (считается как 1)

  • Tolerating: < 4T (считается как 0.5)

  • Frustrated: > 4T (считается как 0)

  • Пример: если T = 300ms:

    • Отлично: < 300ms

    • Терпимо: < 1.2s

    • Плохо: > 1.2s.

Traffic: понимаем нагрузку

RPS (Requests per Second)

  • Количество запросов в секунду

  • Разбивка по:

    • HTTP методам (GET, POST, etc)

    • эндпоинтам

    • статус-кодам

  • Помогает планировать мощности

  • Кейс: резкий рост 404 ошибок выявил проблему с кешированием старых URL.

Concurrent Users

  • Количество одновременных пользователей

  • Active Sessions — активные сессии

  • User Flow — путь пользователя по системе

  • Geographic Distribution — распределение по регионам

  • Пример: пиковая нагрузка по понедельникам в 10 утра — готовимся заранее.

Database Metrics: когда база данных решает пойти погулять

Connection Pool

  • Active connections — активные соединения с базой

  • Idle connections — простаивающие соединения

  • Max connections — максимум возможных соединений

  • Connection timeouts — таймауты при получении соединения

  • Connection acquisition time — время получения соединения

  • История из жизни: connection leak в тестах убил прод через неделю после деплоя. Никто не ожидал, что тесты могут влиять на прод.

Query Performance

  • Query execution time — время выполнения запросов

  • Slow queries — запросы дольше определенного порога

  • Table scans — полные просмотры таблиц (спойлер: это обычно плохо)

  • Index usage — использование индексов

  • Lock contentions — конфликты блокировок

  • Buffer cache hit ratio — эффективность кеширования

  • Кейс: один «безобидный» JOIN без индекса положил всю базу. Привет, полночный дебаг!

Storage Metrics

  • Disk IOPS — операций ввода/вывода в секунду

  • Write/Read latency — задержки записи/чтения

  • Storage space usage — использование места

  • WAL/Binlog size — размер журнала транзакций

Пример: однажды логи транзакций съели все место на диске. Угадайте, когда это случилось? Правильно, в пятницу вечером!

Security Metrics: потому что параноик — это не диагноз, а профессия

Authentication Failures

  • Failed login attempts — неудачные попытки входа

  • Password reset requests — запросы сброса пароля

  • Brute force attempts — попытки подбора

  • IP-based patterns — подозрительные паттерны по IP

  • Geographic anomalies — странная география запросов

  • Пример: брутфорс атака из Китая в 3 часа ночи. Спасибо rate limiting и геоблокировке!

Resource Access Patterns

  • Unusual data access — нетипичные обращения к данным

  • Privilege escalations — повышение привилегий

  • API usage anomalies — аномалии использования API

  • Data exfiltration attempts — попытки выгрузки данных

  • Suspicious user behavior — подозрительное поведение пользователей

  • Кейс: необычный паттерн запросов выявил утечку данных через API. Кто-то «умный» пытался выгрузить всю базу клиентов…

Infrastructure Security

  • Port scan attempts — попытки сканирования портов

  • DDoS indicators — индикаторы DDoS атак

  • SSL/TLS issues — проблемы с сертификатами

  • Firewall denials — отказы файрвола

  • История: однажды забытый open port чуть не стал причиной взлома. Теперь у нас есть регулярные проверки.

Cost Metrics: чтобы финансовый директор не поседел раньше времени

Resource Utilization vs Cost

  • Cost per service — стоимость каждого сервиса

  • Resource efficiency — насколько эффективно используются ресурсы

  • Idle resources — простаивающие (и бесполезно дорогие) ресурсы

  • Autoscaling efficiency — насколько правильно работает автомасштабирование

  • Reserved vs On-demand usage — использование зарезервированных мощностей

  • История: забытый тестовый кластер «съел» месячный бюджет за неделю. Теперь у нас есть автоматическое удаление тестовых окружений.

Traffic Costs

  • Egress traffic — исходящий трафик (самый дорогой в облаках)

  • Inter-region traffic — трафик между регионами

  • API calls — вызовы API (особенно платные)

  • Storage operations — операции с хранилищем

  • CDN usage — использование CDN

  • Пример оптимизации: перенос бэкапов в тот же регион сэкономил 30% бюджета. Кто же знал, что межрегиональный трафик такой дорогой?

Роль провайдера в мониторинге

Что обычно берет на себя провайдер:

  • Базовый мониторинг инфраструктуры

  • Автоматическое масштабирование

  • DDoS защита

  • Базовые метрики безопасности

  • Мониторинг доступности сервисов.

Что остается на нашей совести:

  • Мониторинг бизнес-метрик

  • Специфичные для приложения метрики

  • Кастомные алерты и пороговые значения

  • Мониторинг затрат и оптимизация

  • End-to-end мониторинг пользовательского опыта.

Пример из жизни: провайдер радостно рапортовал, что «всё работает», пока пользователи жаловались на тормоза. Оказалось, что наш кеш был жив, но работал как улитка.

Общие рекомендации по настройке мониторинга

1. Начните с главного

  • Определите критичные бизнес-метрики

  • Настройте базовые системные метрики

  • Добавьте мониторинг основных компонентов

  • Кейс: начали с 500 метрик, закончили 50-ю действительно важными.

2. Настройте правильные алерты

  • Избегайте ложных срабатываний

  • Используйте разные уровни важности

  • Добавьте контекст к алертам

  • Настройте правильную маршрутизацию

  • История: после сотого ложного алерта в 3 часа ночи мы наконец научились их правильно настраивать.

3. Правильное хранение метрик

  • Определите retention policy для разных типов метрик

  • Настройте агрегацию для старых данных

  • Планируйте storage capacity заранее

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

  • Пример: CPU metrics каждые 10 секунд, а бизнес-метрики раз в минуту.

4. Визуализация, которая реально помогает

  • Создавайте тематические дашборды

  • Группируйте связанные метрики

  • Добавляйте аннотации для важных событий

  • Используйте разные типы графиков для разных данных

  • Кейс: после добавления deployment markers на графики поиск проблем ускорился в разы.

5. Автоматизация мониторинга

  • Используйте Infrastructure as Code для конфигурации

  • Автоматизируйте создание дашбордов

  • Настройте автоматическое реагирование на типовые проблемы

  • Регулярно проверяйте и обновляйте конфигурацию

  • История: автоматическое увеличение диска при 80% заполнении спасло не один наш уикенд.

Практические советы по внедрению

Для начинающих

  1. Начните с базовых метрик:

    • CPU, Memory, Disk

    • Basic HTTP metrics

    • Error rates

    • Response times.

  2. Добавьте простые алерты:

    • Disk space > 80%

    • Error rate > 1%

    • Response time P95 > 1s.

Для продвинутых

  1. Внедрите трейсинг:

    • Distributed tracing

    • Service mesh metrics

    • Custom business metrics.

  2. Настройте продвинутую аналитику:

    • Anomaly detection

    • Trend analysis

    • Capacity planning.

Типичные ошибки и как их избежать

  1. Слишком много метрик

    • Проблема: Information overload

    • Решение: начните с малого, расширяйтесь по необходимости

    • Пример: из 1000 метрик реально использовались только 100.

  2. Плохие алерты

    • Проблема: Alert fatigue

    • Решение: настраивайте значимые пороги, используйте агрегацию

    • Кейс: после пересмотра порогов количество ночных вызовов уменьшилось на 90%.

  3. Отсутствие контекста

    • Проблема: сложно понять причину проблемы

    • Решение: добавляйте метаданные, связывайте метрики

    • Пример: добавление version tags помогло быстро находить проблемные деплои.

Заключение: как построить мониторинг, который реально работает

Ключевые принципы

  1. Мониторинг должен приносить пользу

    • Не собирайте метрики «просто потому что можно»

    • Каждая метрика должна помогать принимать решения

    • Регулярно пересматривайте набор метрик.

  2. Баланс между полнотой и простотой

    • Слишком много данных так же плохо, как и слишком мало

    • Фокусируйтесь на том, что действительно важно

    • Начинайте с простого, усложняйте по необходимости.

  3. Культура мониторинга

    • Обучайте команду работе с метриками

    • Документируйте решения и настройки

    • Проводите регулярные ревью системы мониторинга.

Чек-лист для проверки вашего мониторинга

✅ Базовые метрики

  •  CPU, Memory, Disk metrics настроены

  •  Application metrics работают

  •  Error tracking налажен

  •  Performance metrics собираются.

✅ Алертинг

  •  Критичные алерты настроены

  •  Есть разные уровни важности

  •  Настроена правильная маршрутизация

  •  Документированы действия по алертам.

✅ Визуализация

  •  Основные дашборды созданы

  •  Метрики сгруппированы логически

  •  Графики понятны и информативны

  •  Есть документация по метрикам.

Напоследок: золотые правила мониторинга

  1. Не усложняйте без необходимости

    • Простой и работающий мониторинг лучше сложного и сломанного

    • Начните с малого, растите постепенно.

  2. Думайте о людях

    • Метрики должны быть понятны всей команде

    • Алерты должны быть действительно важными

    • Документация должна быть актуальной.

  3. Регулярно улучшайте

    • Собирайте фидбек от команды

    • Анализируйте инциденты

    • Обновляйте пороги и правила.

P.S. И помните, хороший мониторинг — это не тот, который собирает все возможные метрики, а тот, который помогает решать реальные проблемы до того, как о них узнают пользователи.

P.P.S. Да, и ещё раз про пятничные деплои — настройте особые алерты на вечер пятницы. Почему-то именно в это время все любят заливать в прод «маленькие безобидные фиксы», которые потом чинит вся команда в субботу.

Полезные ссылки и инструменты

  1. Популярные стеки мониторинга:

  2. Инструменты для трейсинга:

  3. Тулзы для логирования:

Удачного мониторинга! И пусть ваши графики всегда будут красивыми, а алерты — только по делу!

Больше полезного про метрики, алерты и не только — на курсе учебного центра Слёрм «SRE: Observability». Возьмите под контроль состояние системы! Программа и условия — по ссылке.


ссылка на оригинал статьи https://habr.com/ru/articles/888488/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *