1.4 Мониторинг и Observability

1.4 Мониторинг и Observability #

🎯 Зачем нужен мониторинг #

Представьте, что вы управляете самолетом без приборной панели. Примерно так себя чувствует DevOps-инженер без мониторинга — не знает, что происходит с системой, пока она не упадет.

Мониторинг отвечает на вопрос: “Что происходит?”
Observability отвечает на вопрос: “Почему это происходит?”

📊 Три столпа Observability #

1. Метрики (Metrics) #

Числовые данные о состоянии системы

Примеры метрик в формате Prometheus:

Количественные показатели состояния системы:

  • Общее количество HTTP-запросов (GET-метод, статус 200): 1547
  • Процент использования CPU: 67.3%
  • Объем используемой оперативной памяти: 1,073,741,824 байта (1 ГБ)
  • Среднее время ответа: 0.234 секунды

Типы метрик:

  • Counter — только растет (количество запросов)
  • Gauge — может расти и убывать (использование CPU)
  • Histogram — распределение значений (время ответа)

2. Логи (Logs) #

Текстовые записи о событиях в системе

Примеры структурированных логов:

Текстовые записи о событиях в системе с метками времени и уровнями:

  • 15 января 2024, 10:30:15 - INFO: Пользователь 12345 успешно авторизовался (сервис UserService)
  • 15 января 2024, 10:30:16 - WARN: Превышен лимит времени оплаты заказа 67890 (сервис PaymentService)
  • 15 января 2024, 10:30:17 - ERROR: Исчерпан пул соединений с базой данных (сервис DatabaseService)
  • 15 января 2024, 10:30:18 - DEBUG: Попадание в кэш по ключу user_profile_12345 (сервис CacheService)

Уровни логирования:

  • DEBUG — детальная информация для разработки
  • INFO — общая информация о работе
  • WARN — предупреждения о потенциальных проблемах
  • ERROR — ошибки, требующие внимания
  • FATAL — критические ошибки, приводящие к остановке

3. Трейсы (Traces) #

Путь запроса через микросервисы

Пример распределенного трейса:

Путь запроса через микросервисы с временем обработки:

  1. Пользователь отправляет запрос (1 мс)
  2. API Gateway маршрутизирует запрос (5 мс)
  3. Auth Service проверяет авторизацию (15 мс) ← Узкое место!
  4. User Service обрабатывает запрос (25 мс)
  5. Обращение к базе данных (40 мс)

Общее время обработки: 86 мс

🛠️ Популярные инструменты мониторинга #

Prometheus + Grafana (Open Source стек) #

Prometheus — сбор и хранение метрик Пример конфигурации Prometheus:

Настройка собирателя метрик:

  • Глобальный интервал сбора: 15 секунд
  • Конфигурация для веб-приложения:
    • Целевой адрес: localhost:8080
    • Путь для метрик: /metrics
    • Интервал сбора: 5 секунд (чаще глобального)

Grafana — визуализация метрик Пример конфигурации Grafana dashboard:

Описание дашборда для визуализации метрик:

  • Название дашборда: “Web Application Dashboard”
  • Панель для отображения времени ответа:
    • Заголовок: “Response Time”
    • Тип: график
    • Источник данных: метрика http_request_duration_seconds

ELK Stack (Elasticsearch + Logstash + Kibana) #

Для работы с логами: Пример конфигурации Logstash:

Настройка пайплайна для обработки логов:

Входные данные:

  • Чтение лог-файлов из папки /var/log/app/
  • Начало чтения с начала файла

Фильтрация:

  • Парсинг сообщений с помощью Grok-паттернов
  • Извлечение метки времени, уровня логирования и содержимого

Выходные данные:

  • Отправка обработанных логов в Elasticsearch
  • Адрес Elasticsearch: localhost:9200
  • Индекс с датой: application-logs-YYYY.MM.dd

Jaeger (Distributed Tracing) #

Пример инструментирования Python-приложения для Jaeger:

Настройка распределённого трейсинга:

Инициализация трейсера:

  • Импорт библиотеки jaeger_client
  • Конфигурация с полным сэмплингом (параметр 1)
  • Включение логирования
  • Имя сервиса: ‘user-service’

Инструментирование API-маршрута:

  • Создание спана с именем ‘get_user’
  • Добавление метки с ID пользователя
  • Выполнение запроса к базе данных
  • Добавление метки о результате поиска
  • Возврат JSON-ответа

🚨 Алертинг (Alerting) #

Принципы хорошего алертинга #

1. Алертьте на симптомы, а не на причины Принципы хорошего алертинга:

Неправильно: Алерт на высокое использование CPU (причина, а не симптом)

Правильно: Алерт на медленный ответ (симптом, который замечают пользователи)

2. Actionable алерты Пример actionable алерта:

Конфигурация алерта с полной информацией для реагирования:

  • Условие: База данных недоступна (статус up = 0)
  • Время ожидания: 5 минут (чтобы избежать ложных срабатываний)
  • Краткое описание: “База данных недоступна”
  • Подробное описание: “База данных недоступна более 5 минут”
  • Ссылка на runbook: пошаговое руководство по устранению
  • Действия: конкретные шаги для реагирования

3. Правильные пороги Пример правильного определения порогов:

Конфигурация алерта на основе статистических данных:

  • Метрика: частота HTTP-ошибок статусов 5xx за последние 5 минут
  • Порог: более 0.01 (1% error rate)
  • Обоснование: 1% - стандартный порог для ошибок в веб-приложениях
  • Время ожидания: 2 минуты для подтверждения тренда

Каналы уведомлений #

Пример конфигурации Alertmanager:

Настройка маршрутизации и доставки алертов:

Маршрутизация:

  • Группировка: по именам алертов
  • Время ожидания группы: 10 секунд
  • Интервал между группами: 10 секунд
  • Интервал повтора: 1 час

Каналы уведомлений:

  • Slack: канал #alerts с кратким описанием алерта
  • Email: отправка на devops@company.com с темой, содержащей имя алерта

📊 Ключевые метрики для мониторинга #

RED метрики (для сервисов) #

  • Rate — количество запросов в секунду
  • Errors — процент ошибок
  • Duration — время ответа

Примеры вычисления RED метрик:

Rate (частота): Количество HTTP-запросов в секунду за последние 5 минут

Errors (ошибки): Процент ошибок - отношение запросов с 5xx статусами к общему количеству запросов

Duration (длительность): 95-й персентиль времени ответа (время, которое не превышают 95% запросов)

USE метрики (для ресурсов) #

  • Utilization — загруженность ресурса
  • Saturation — очереди и ожидание
  • Errors — количество ошибок

Примеры вычисления USE метрик:

CPU Utilization (загруженность): 100% минус средний процент времени простоя CPU

Memory Utilization (загруженность памяти): Процент использования оперативной памяти (общая минус доступная)

Disk Saturation (насыщенность диска): Частота времени выполнения дисковых операций

SLI/SLO/SLA #

SLI (Service Level Indicator) — метрика качества сервиса Пример вычисления SLI:

Availability SLI (доступность): Отношение успешных запросов (не 5xx) к общему количеству запросов за 5 минут

SLO (Service Level Objective) — целевое значение SLI Примеры SLO (целевые показатели):

API Availability (доступность API):

  • Метрика: availability (доступность)
  • Цель: 99.9% (успешно должны выполняться 99.9% запросов)

API Latency (задержка API):

  • Метрика: latency_p95 (95-й персентиль задержки)
  • Цель: 500ms (95% запросов должны выполняться быстрее 500 мс)

SLA (Service Level Agreement) — договор с клиентом Пример SLA (соглашение об уровне сервиса):

Коммерческие обязательства перед клиентами:

  • Доступность: 99.5% времени работы в месяц
  • Производительность: время ответа менее 2 секунд для 90% запросов
  • Компенсация: при нарушении SLA - скидка 10% за месяц

🎯 Реальный кейс: Внедрение мониторинга #

Проблема: E-commerce без мониторинга #

  • Пользователи жалуются на медленный сайт
  • Непонятно, какие страницы тормозят
  • Узнаем о проблемах от пользователей
  • Много времени на поиск причин

Решение: Поэтапное внедрение #

Этап 1: Базовые метрики (1 неделя) Пример Docker Compose для развертывания мониторинга:

Конфигурация для быстрого развертывания стека мониторинга:

Prometheus (сбор метрик):

  • Образ: prom/prometheus
  • Порт: 9090 (веб-интерфейс)
  • Монтирование конфигурации из локального файла

Grafana (визуализация):

  • Образ: grafana/grafana
  • Порт: 3000 (веб-интерфейс)
  • Пароль администратора: admin

Этап 2: Логирование (1 неделя) Пример добавления структурированного логирования:

Модификация Python-приложения для сбора структурированных логов:

Настройка:

  • Импорт библиотеки structlog для структурированного логирования
  • Инициализация логгера

Инструментированный API-маршрут:

  • Замер времени выполнения операции
  • Логирование успешного создания заказа с метаданными: ID заказа, ID пользователя, сумма, время выполнения
  • Логирование ошибок с контекстом: текст ошибки, ID пользователя, время выполнения

Этап 3: Алерты (1 неделя) Пример критических алертов для e-commerce:

Конфигурация важнейших алертов для интернет-магазина:

Алерт на высокий процент ошибок заказов:

  • Условие: отношение неудачных заказов к общему количеству > 5%
  • Время ожидания: 2 минуты
  • Описание: “Высокий процент ошибок заказов” + фактическое значение

Алерт на медленный checkout:

  • Условие: 95-й персентиль времени checkout > 10 секунд
  • Время ожидания: 5 минут
  • Описание: “Оформление заказа занимает слишком много времени” + фактическое значение в секундах

Результат через месяц #

  • MTTR: 2 часа → 15 минут
  • Proactive alerts: 0% → 80% проблем выявляется до жалоб
  • Customer satisfaction: +25%
  • Time to debug: -70%

🏗️ Dashboard Design Best Practices #

1. Правило 5 секунд #

Пользователь должен понять состояние системы за 5 секунд

🟢 Все хорошо - зеленые метрики
🟡 Есть проблемы - желтые предупреждения  
🔴 Критично - красные алерты

2. Иерархия дашбордов # 

Level 1: High-level overview (для менеджмента)
├── System health: 99.8% ✅
├── User satisfaction: 4.2/5 ✅
└── Revenue impact: $0 ✅

Level 2: Service-level (для команд)  
├── API response time: 234ms
├── Error rate: 0.1%
└── Throughput: 1.2K req/s

Level 3: Deep dive (для debugging)
├── Database query performance
├── Cache hit rates
└── Individual service metrics

3. Контекст и аннотации # 

Panel Title: "API Response Time (P95)"
Description: "95th percentile response time for all API endpoints. 
             Target: < 500ms. Alert threshold: > 1000ms"
             
Thresholds:
- Green: < 500ms  
- Yellow: 500-1000ms
- Red: > 1000ms

🎯 Практические задания #

Задание 1: Настройка базового мониторинга #

  1. Установите Prometheus и Grafana через Docker Compose
  2. Добавьте мониторинг собственного приложения
  3. Создайте dashboard с основными метриками
  4. Настройте простой алерт

Задание 2: Structured logging #

  1. Добавьте структурированное логирование в приложение
  2. Настройте отправку логов в Elasticsearch
  3. Создайте dashboard в Kibana
  4. Найдите и исправьте проблему по логам

📚 Полезные ресурсы #

Документация #

Книги #

  • “Site Reliability Engineering” by Google
  • “Observability Engineering” by Charity Majors
  • “The Art of Monitoring” by James Turnbull

Блоги #

🎯 Заключение #

Мониторинг и Observability — это глаза и уши DevOps-инженера. Ключевые принципы:

✅ Мониторьте то, что важно пользователям
✅ Алертьте на симптомы, а не на причины
✅ Стройте дашборды для разных аудиторий
✅ Используйте SLI/SLO для измерения качества
✅ Логируйте структурированно и осмысленно

Помните: Хороший мониторинг — это не про количество метрик, а про возможность быстро понять, что происходит с системой и почему.

Следующий раздел: 1.5 Облачные технологии

Previous 1.3 Infrastructure as Code (IaC) 1.5 Облачные технологии Next