Prometheus + Grafana. Настраиваем 4 golden signals

• Приветствие участников вебинара.  

• Представление Тани Гребенюковой, директора курсов Слерм.  

• Анонс нового курса по мониторингу в Grafana.  

• Введение в программу курса и ранний доступ.  

• Приветствие Сергея, лидера команды Dodo Engineering.  

• Обзор подходов к мониторингу и их реализация на базе Prometheus и Grafana.  

• Цель вебинара: расширить кругозор и понять основы мониторинга.  

• Мониторинг как сбор, обработка и отображение количественных показателей системы в реальном времени.  

• Важность мониторинга для понимания поведения приложения в продакшене.  

• Преимущества мониторинга: прозрачность, раннее оповещение о проблемах, аналитические возможности.  

• Разделение на white box и black box мониторинг.  

• White box мониторинг: наблюдение технических метрик изнутри системы.  

• Black box мониторинг: наблюдение за системой с точки зрения пользователя.  

• Три популярных подхода к мониторингу: задержка, трафик, ошибки.  

• Примеры метрик: время выполнения запроса, объем трафика, количество ошибок.  

• Важность учета всех возможных типов ошибок и их влияния на пользователей.  

• Показатель загруженности помогает оценить, насколько загружено приложение.  

• Важно понимать, что многие системы деградируют до достижения 100% загрузки.  

• Подход включает анализ четырех золотых сигналов и рейд.  

• Утилизация показывает, сколько времени система выполняет полезную работу.  

• Объем работы в очереди указывает на нехватку ресурсов.  

• Важно стремиться к приемлемой утилизации и избегать накопления работы в очереди.  

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

• Это снижает когнитивную нагрузку на инженеров и администраторов.  

• Четыре золотых сигнала считаются универсальной метрикой для мониторинга.  

• Усреднение скрывает проблемы, что может привести к неправильным выводам.  

• Квантиль помогает выявить проблемы, но имеет свои недостатки.  

• Важно учитывать распределение таймингов запросов внутри квантиля.  

• Prometheus и Grafana используются для мониторинга метрик.  

• Prometheus отвечает за сбор и хранение метрик, но его хранилище ненадежно.  

• Для длительного хранения метрик лучше использовать другие решения, такие как Victoria или Metric.  

• Prometheus собирает метрики и отправляет алерты.  

• Конфиг описывает таргеты для сбора метрик.  

• Prometheus может изменять метрики перед отправкой.  

• Prometheus проверяет условия алертов и отправляет их в арт-менеджер.  

• Арт-менеджер решает, куда отправлять алерты.  

• Prometheus работает по pull-модели, но может использовать push-модель для редких событий.  

• Grafana визуализирует метрики Prometheus.  

• Grafana использует PromQL для работы с данными.  

• Grafana может отображать метрики из различных источников.  

• Данные хранятся в виде временных рядов.  

• Каждый временной ряд идентифицируется именем и набором лейблов.  

• Prometheus не любит уникальные значения в лейблах, чтобы избежать высокой кардинальности.  

• Счетчики: монотонно возрастающие метрики.  

• Шкалы: могут уменьшаться или увеличиваться.  

• Гистограммы: распределяют значения по бакам и считают их количество.  

• Кватеры: редко используются, считают предопределенные кванты.  

• Подходы к мониторингу: white-box, black-box.  

• Использование четырех золотых сигналов.  

• Взаимодействие Prometheus и Grafana.  

• Модель данных Prometheus и типы метрик.  

• Приложение на Go с шестью точками.  

• Первые три точки возвращают случайный код.  

• Следующие три точки возвращают 200, но с разным временем ответа.  

• Метрики собираются через Prometheus и Grafana.  

• Приложение работает в Docker-контейнере.  

• Prometheus и Grafana также работают в контейнерах.  

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

• Скрипт генерирует нагрузку для тестирования метрик.  

• Приложение запущено, метрики отображаются в браузере.  

• Приложение работает на порту 8080.  

• Интересуют метрики, связанные с производительностью языка.  

• Приложение выдает несколько метрик, включая "total request".  

• Для увеличения метрик запускается нагрузка.  

• Метрики показывают количество запросов и их распределение по методам и путям.  

• Приложение приостанавливается и запускается для проверки метрик.  

• Метрика "total request" сбрасывается до нуля.  

• Приложение продолжает работать, метрики обновляются.  

• Метрика "inflight max" показывает количество запросов в обработке.  

• Метрика "flight max" показывает максимальное количество запросов в единицу времени.  

• Приложение обрабатывает разное количество запросов в секунду.  

• Метрики "batch" показывают количество запросов в заданном временном интервале.  

• Вспомогательные метрики включают общее количество запросов и общее время ответа.  

• Квантили помогают оценить среднее время ответа.  

• Приложение продолжает работать, накапливая метрики.  

• Графики и анализ метрик будут использованы для дальнейшего анализа.  

• Пакет метрикс перечисляет все метрики с разбивкой по паттерну, пути, методу и статусу.  

• Метрика про инфлей показывает количество обрабатываемых запросов.  

• Эстетическая метрика показывает максимальное количество обрабатываемых запросов одновременно.  

• Гистограмма показывает распределение запросов по времени обработки.  

• Метрики считаются через библиотеку прометеуса.  

• Каждый новый запрос запоминается и обрабатывается.  

• Значение шкалы увеличивается при получении запроса и уменьшается при его обработке.  

• Метрики не предназначены для использования в продакшне.  

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

• Прометеус собирает метрики раз в 30 секунд.  

• Приложение называется эп, контейнер называется эп.  

• Перезапуск контейнера для обновления метрик.  

• Прометеус добавляет служебные лейблы к метрикам.  

• Метрика ап показывает, что метрики собираются.  

• Переход к визуализации метрик с помощью графана.  

• Подключение прометеуса к графану.  

• Проверка работы связки метрик.  

• Создание графика для визуализации метрик.  

• Создание графика для метрики ап.  

• Отображение трафика и расчет рпс.  

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

• Рейт считает изменение метрики за секунду.  

• Для оценки трафика достаточно просуммировать рейты по энд-пойнту.  

• В Prometheus есть функция сумм для этого.  

• Убираем легенду и отображаем максимальное и последнее значение.  

• Убираем лишние цифры после запятой для красоты.  

• Указываем, что это РПС и сохраняем график.  

• Копируем трафик и переименовываем его в логичные ошибки.  

• Фильтруем по лейблу статус и суммируем по статусу.  

• Умножаем на 60 для отображения количества ошибок в минуту.  

• Инкриз считает изменение метрики за указанный период.  

• Заменяем рейт на инкриз для упрощения графика.  

• Делаем второй график с ошибками, считая общее количество ошибок и деля на общее количество запросов.  

• Копируем панельку трафика и переименовываем в лейтенси.  

• Считаем количество запросов в секунду для разных бакетов.  

• Используем функцию гистограмм-квант для расчета квантиля.  

• Указываем, что это лейтенси в секундах и отображаем график.  

• Создание графика с использованием саморе.  

• Фильтрация ненужных метрик.  

• Указание лейбла для отображения в легенде.  

• Сравнение 99-го квантиля в саморе и в Grafana.  

• Преимущества использования саморе для гибкого агрегирования данных.  

• Ограничения использования саморе для сложных запросов.  

• Расчет самого на основе метрик.  

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

• Сортировка данных по трафику и ошибкам.  

• Визуализация метрик в Grafana.  

• Изменение метрик с помощью ручек в Grafana.  

• Перезапуск приложения для обновления данных.  

• Добавление красок для отображения критических значений.  

• Изменение графиков при изменении метрик.  

• Реализация четырех золотых сигналов.  

• Подведение итогов по мониторингу и использованию Prometheus и Grafana.  

• Анонс курса по Prometheus и Grafana.  

• Ответы на вопросы зрителей о работе с репозиторием и реализации метрик.  

• Холст чек проверяет базовые сценарии, такие как доступность базы данных и кэшей.  

• Стандартные поинты помогают определить, что трафик на приложение нельзя опускать.  

• В случае проблем, чек может показать, что что-то пошло не так.  

• Блэк бокс может проверять сценарии, но это зависит от того, что именно проверять.  

• Проверка может быть разной в зависимости от источника и метода.  

• Прометей собирает метрики раз в 30 секунд, но автообновление дашборда можно настроить на более редкое обновление.  

• Это не имеет смысла, так как нагружает Прометей без необходимости.  

• Описание языка можно найти в документации Прометея.  

• Примеры использования можно найти на сайте Брайана Брезила.  

• Критичные метрики для бизнеса: количество заказов в минуту.  

• Графики помогают отслеживать состояние приложения и выявлять проблемы.  

• Прометей развернут в Kubernetes для удобства и доступности.  

• Прометей-оператор позволяет хранить конфигурацию рядом с приложениями.  

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

• В некоторых случаях лучше использовать РПС для оценки состояния приложения.  

• Хеллс чек помогает определить, что приложение не работает.  

• Мониторинг с разных географических точек важен для выявления проблем.  

• Графана умеет слать алерта, но это менее гибко, чем в Прометее.  

• Будет отдельная тема для обсуждения преимуществ и недостатков.  

• Хит мэп показывает, какие запросы уложились в определенные тайминги.  

• Квантили помогают оценить общую производительность приложения.  

• Проблемы с подключением к сети.  

• Продолжение обсуждения будет позже.  

• Обсуждение подходов к мониторингу, а не конкретных инструментов.  

• Графит может справиться с большими объемами данных.  

• Виктория Метрикс и Танос рассматриваются как дополнения к Prometheus.  

• Переход на новые инструменты мониторинга, такие как Grafana, рассматривается как дополнение к Prometheus.  

• В будущем планируется переход на Grafana и изучение её преимуществ.  

• Использование стандартного или кастомного Alert Manager.  

• Добавление JSON конфига для дашборда в Grafana.  

• Возможность описания дашбордов в JSON.  

• Обсуждение скорости обновлений в Grafana и Prometheus.  

• Использование Grafana в работе, несмотря на наличие косяков.  

• Возможность тестирования Grafana, особенно для бесплатного использования.  

• Кластеризация Grafana для хранения данных.  

• Использование нескольких экземпляров Grafana для балансировки нагрузки.  

• Вопрос о самой вкусной пицце.  

• Завершение доклада и благодарность за внимание.