Мониторинг приложений на Go | Golang с использованием Prometheus и Grafana

• Лекция посвящена мониторингу приложений на гос с использованием Prometheus и Grafana.  

• Лектор - Гаяз Юсипов, лекция десятая по обсервабилити.  

• Рассматриваются метрики, Prometheus, язык PromQL и Grafana.  

• Метрики - это поименованные числовые значения во времени.  

• Метрики должны быть доступны для обработки быстро, но могут иметь погрешность.  

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

• SLI - количественная оценка работы сервиса.  

• SLO - желаемое целевое значение SLI.  

• Примеры SLI: время обработки запроса пользователя, процент успешно обработанных запросов.  

• Prometheus собирает метрики таргетов через HTTP-запросы.  

• Архитектура Prometheus включает Discovery Service для определения таргетов и Pushgateway для короткоживущих приложений.  

• Prometheus использует PromQL для визуализации метрик.  

• Pushgateway рекомендуется для короткоживущих приложений.  

• Недостатки Pushgateway: единая точка отказа, проверка состояния ноды, хранение тайм-сервисов.  

• Pushgateway используется как частный случай.  

• Prometheus собирает метрики через HTTP-запросы каждые 10 секунд.  

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

• Важно правильно проектировать метрики, чтобы минимизировать объем данных.  

• За скрепинг собирается около 232 миллионов метрик.  

• Интервал скрепинга установлен на 30 секунд.  

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

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

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

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

• Push-гейт может не удалять метрики после получения, что приводит к их накоплению.  

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

• Для коротких заданий лучше использовать Push-гейт, чтобы гарантировать корректные данные.  

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

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

• Метрики возвращаются в текстовом формате, состоящем из метрик, лейблов и значений.  

• Метрики должны быть в определенном формате, с указанием вендора и единицы измерения.  

• Лейблы не должны содержать высококардинальные значения, такие как email или ID.  

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

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

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

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

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

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

• Кастомные метрики создаются для отражения бизнес-процессов.  

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

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

• Модуль состоит из трех основных пакетов: Prometheus, Prometheus-Auto и Prometheus-Typing.  

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

• Exporters — приложения, которые подключаются к другим системам и экспонируют их метрики.  

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

• Запуск Docker-compose с Prometheus и Grafana.  

• Настройка глобального и локального скрейп-интервалов.  

• В 99% случаев используется пул-модель для сбора метрик.  

• Push-модель сложнее и используется реже.  

• Квантили будут рассмотрены в гистограмме.  

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

• Обсуждение горизонтально масштабируемых баз данных.  

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

• Пример использования Tanoos для хранения данных.  

• Введение в четыре типа метрик, включая счетчик.  

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

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

• Методы инк и эт для увеличения и уменьшения счетчика.  

• Регистрация счетчика через Prometheus.  

• Пример использования Prometheus для регистрации и получения метрик.  

• Объяснение необходимости инициализации генератора случайных чисел.  

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

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

• Объяснение, почему в Go нужно указывать зерно для рандомайзера.  

• Генерация случайных чисел в Go и их надежность.  

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

• Регистрация счетчика в Prometheus и получение метрик.  

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

• Пример отображения метрик в виде графика.  

• Объяснение функции sum для суммирования метрик по измерениям.  

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

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

• Подсчет свободной памяти в мегабайтах.  

• Вычитание лимита памяти и деление на 1024 для получения мегабайт.  

• Важность порядка выполнения операций.  

• Функция рейнд показывает среднюю скорость роста метрики.  

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

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

• Резкий рост графика в первые пять минут.  

• Прогрев приложения и сбор метрик.  

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

• Сам должен быть снаружи, рейнд внутри.  

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

• Уменьшение значения метрики и поведение Prometheus.  

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

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

• Неравномерный рост графика из-за задержек между увеличениями.  

• График показывает скорость роста счетчика.  

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

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

• Обсуждение интервалов времени для графиков.  

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

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

• Методы метрики "гейч": сет, инк, дек, аэд, сап, шортат.  

• Использование метрики для передачи константной информации, например, версии Go.  

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

• Библиотека Prometheus для подсчета количества запросов.  

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

• Метрика "гейч" представлена в виде одной тайм-сервис.  

• Введение в векторные метрики с суффиксом "-век".  

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

• Создание и запись метрик с лейблами для анализа.  

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

• Пример с метрикой "акма катербек" и необходимость правильной настройки лейблов.  

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

• Пример использования метрик из пакета Prometheus.  

• Возможность регистрации метрик вручную.  

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

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

• Пример отображения объема занимаемой памяти.  

• Агрегирование значений с помощью шкалы времени.  

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

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

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

• Пакеты - это кумулятивные метрики, показывающие значения в определенных интервалах.  

• Кумулятивные значения включают предыдущие значения.  

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

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

• Можно использовать дефолтные или пользовательские пакеты.  

• Гистограмма дает более полную картину происходящего.  

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

• Интерфейс гистограммы прост: один метод для обсчета.  

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

• Основная функция - подсчет квантилей, например, 90-го процентиля.  

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

• Количество пакетов должно быть в разумных пределах, максимум - 12.  

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

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

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

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

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

• Вопросы по гистограмме и персоналиям.  

• Бакеты указываются при инициализации гистограммы.  

• По умолчанию используются 3, 6, 9, 11 бакетов.  

• Бакеты определяют границы, в которые попадают метрики.  

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

• Бакеты задают верхнюю границу для метрик.  

• Метрики не могут выйти за пределы бакетов.  

• Бакеты можно создавать динамически.  

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

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

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

• Можно изменять размерность бакетов в зависимости от изменений метрик.  

• Число бакетов влияет на точность построения процентилей.  

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

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

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

• Метрики могут не собираться из-за ограничений.  

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

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

• Сводки уже агрегированы на уровне приложения.  

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

• Сводки дороже в производительности на стороне сервера.  

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

• Гистограммы позволяют агрегировать данные, что улучшает производительность.  

• В гистограммах добавляются пакеты, в сводках — квантили.  

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

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

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

• Использование Docker-образа для Grafana.  

• Порт по умолчанию - 3000.  

• Интерфейс Grafana с дефолтными логином и паролем.  

• Подключение Grafana к Prometheus.  

• Prometheus работает на порту 9000.  

• Использование Docker Compose для связи контейнеров.  

• Импорт готовых панелей из Grafana.  

• Настройка источников данных для панелей.  

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

• Группировка метрик по лейблам.  

• Настройка глобальных переменных для фильтрации метрик.  

• Фильтрация метрик по названию приложения и квантилям.  

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

• Необходимость ручного ввода данных для вывода.  

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

• Обзор возможностей Grafana для визуализации данных.  

• Примеры использования демо-досок и промитов.  

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

• Введение в Open Telemetry и его цели.  

• Преимущества использования протокола Open Telemetry.  

• Проблемы с повторным трафиком и их решение.  

• Обсуждение базы данных и настроек Open Telemetry.  

• Использование Prometheus и его преимущества.  

• Вопросы по мониторингу и визуализации данных.  

• Обсуждение различий между Grafana и Zabbix.  

• Zabbix как система мониторинга и алерт-система.  

• Возможности Prometheus в области алерт-менеджмента.  

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

• В Prometheus таких проблем нет.  

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

• Можно собрать информацию о всех запущенных инстансах и их версиях.  

• Это позволяет анализировать, какие сервисы используют больше всего реплик и баз данных.  

• Запросы на аналитику работают эффективно и дешево.  

• В Kubernetes сервис Discovery может вызывать спецэффекты при параллельном запуске старых и новых версий.  

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

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

• Вопросы отсутствуют, но можно писать пожелания и вопросы в чат.  

• Всем хорошего вечера и прощание.