Привет, %username%! Держи немного запоздавших тезисов с доклада “Твой observability мёртв, мой тоже”, который читал Дроздецкий Владимир на прошедшем недавно KuberConf, куда мне удалось попасть.

Классический стек мониторинга:

• Prometheus, Grafana, AlertManager - основные компоненты

Мониторинг метрик:

• VictoriaMetrics, Thanos, Grafana Mimir - рассматривались как хранилища метрик
• Разнообразие метрик в каждом сервисе
• Необходимость согласования правил именования метрик и библиотек для Observability
• Важность проведения аудита метрик и их названий

Визуализация данных:

• Важность DrillDown для удобства анализа
• Разделение каналов оповещений по важности

Grafana OnCall и автообзвон:

• Связка для оповещения дежурного ночью

Правила эскалации оповещений:

• Последовательность отправки сообщений и звонков

Использование Telegram для Grafana OnCall:

• Удобство работы с оповещениями через Telegram

Взаимодействие с разработчиками:

• Обсуждение формата логов и обязательных полей
• Не создавать оповещения из логов без тщательного обдумывания

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

• Jaeger устарел, предпочтение OpenTelemetry
• Grafana Tempo и Grafana - интегрированная экосистема для визуализации трейсов

Использование Sentry:

• Sentry только для исключений, не для хранения логов

Организация реагирования на инциденты:

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

Postmortem и туллинг:

• Защита Postmortem на ROI
• Важность тестирования API и UI

Идеальная Observability:

• Невозможно достичь идеального уровня Observability
• Необходимость изучения и интеграции множества инструментов

Что думаешь по поводу идеального мониторинга?

#KuberConf2024 #Conference #Минуткатезисов