Метрики vs Логи

Логи - это про точность мы собираем информацию на каждое событие. Можно агрегировать и детализировать до каждого события, но логировать каждый чих плохо масштабируется

Метрики это сразу общая картина о состоянии приложения. Мы собираем не все детали, а только общую выжимку. Картину мы так же получаем но в детали провалится нельзя, зато хорошо масштабируется и быстро работает, если нужны детали то можно решать точечно

Push vs Pull

Push - принцип такой же как с логами или БД: пришло событие, пишем в хранилище, можно пачками, способ простой

Pull - наоборот, приложения хранят в памяти данные, кто то периодически приходит и собирает их, например по HTTP.
Сложнее реализовать но проще отлаживать, у каждого приложения есть свой endpoint и видно что там происходит

Time Series Database (TSDB)

Особенности такой БД это обработка временных рядов, т.е. однотипных измерений во времени.
БД такого типа оптимизируют хранение какого то числа, которое записано через равные интервалы времени
Например чтобы хранить ежедневную температуру нам нужно хранить только одно число и больше ничего. т.е TSDB нужны чтобы сохранять время и одно число, привязанное к этому времени

Специфика:

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

Раз на sql это все не похоже то и поддерживать сложный язык запросов нет необходимости, и часто делают свой, метрико-ориентированный простой язык

Info

Представляет формат представления Prometheus с некоторыми улучшениями
Все базовые спецификации такие же как у Prometheus, включая использование PromQL, OpenMetrics обеспечивает некоторые улучшение (поддержка Push и Pull, у прометеуса только Pull; по умолчанию секунды вместо миллисекунд и еще несколько)

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

"Клиент Prometheus Python является эталонной реализацией и внутренне использует модель данных OpenMetrics. Prometheus при парсинге будет отдавать предпочтение OpenMetrics"\\

похоже что добавляет метку «_created» к метрикам, но это не точно, что то везде упоминается, пока точно неясно что именно значит
И про синтаксический анализатор Python тоже гругом говорится, похоже что OpenMetrics как таковой это же стандарт, а обеспечивает его некая python надстройка над клиентом Prometheus, но это наверно на принимающей строне, отправляющая это наше приложение, ему надо в нужном формате отправлять данные, в формате OpenMetrics

Info

Ну да, в первом только метрики, тут кроме метрик еще журналы, трассировки, кстати в качестве метрик поддерживает OpenMetrics. Либо прямо использует формат OpenMetrics для передачи метрик

Имеет клиентские библиотеки, встраивается в код приложения

Основа для комплексного стека наблюдения со спецификациями для обработки журналов, трассировок и метрик

Scrape метрик

Приложение выставляет HTTP страницу с метриками, сервер периодически делает GET запросы по настроенным ендпоинтам, ответы сохраняет с текущим timestamp
Идея в том что прометеус собирает срез во времени, а потом его средствами мы уже вычисляем изменения

Безопасность
По умолчанию ходит без аутентификации, варианты обезопашевания:

• настройка аутентификации средствами прометея
• хостить ендпоинт на отдельном порту
• файерволл
• whitelist на уровне приложения

Альтернативные способы скрапинга
Если например приложение не запущено постоянно и/или не имеет HTTP ендпоинта, есть промежуточные средства для сбора и передачи метрик:

• Pushgateway - компонент прометеус, который может собирать метрики затем передавать их серверу
• Telegraf - в стоке есть output-плагин для публикации в HTTP endpoint
• StatsD Exporter - еще какая то тема, аналогично

Prometheus - Формат данных

# HELP http_requests_total Requests made to public API
# TYPE http_requests_total counter
http_requests_total{method="POST", url="/messages"} 1
http_requests_total{method="GET", url="/messages"} 3
http_requests_total{method="POST", url="/login"} 2

Каждая метрика содержит поля:

• HELP описание
• TYPE тип метрики
• <http_request…> название
• набор key-value лейблов (теги)
• значение метрики (double)
• после сборка добавляется еще timestamp

Хранение: имя метрики на самом деле такой же тег, со стандартным именем «name«
Все теги вместе описывают собой time series (временной ряд), т.е. это как бы имя таблицы, составленное из всех key-value. В этом ряду лежат только время и одна цифра значение метрики
Из примера выше у нас одна метрика но три таблицы (GET /message; POST /message; POST /login), в каждую таблицу, каждые 30 сек (итерация скрабинга) пишется одно число (никаких int-ов, никаких строк, ничего, только число)

Кардинальность
Каждое новое значение тега это уже новый временной ряд, т.е. новая таблица
Например метрика о HTTP запросах, перемножаем все возможные значения тегов: 2 HTTP глагола, 7 урлов, 5 реплик сервиса, 3 вида ответов, 4 браузера, итого 840 временных рядов, т.е. это как 840 таблиц в sql
В целом TSDB справляется и с десятками миллионов рядов, но комбинаторный взрыв устроить очень легко

Типы метрик

В данном случае, понятие «тип метрики» достаточно условно, под капотом разницы нет и все хранится в double
Тип скорее нужен для программистов и библиотек, с помощью которых метрики пишутся и анализируются, т.е. это некое «соглашение» о том как ведет себя метрика

Counter
Счетчик, монотонно возрастающее число, никогда не убывает, может быть сброшен в ноль в случае перезагрузки приложения
Как узнать сколько было запросов если есть всего одно число? смотреть дельту, т.к. прометеус сохраняет это число каждые 30 секунд

Gauge
«Стрелка» - число которое может гулять вверх вниз

Histogram
Гистограмма - агрегация чего то самим приложением, когда нам интересно знать распределение величин по заранее определенным группам (buckets). Качественное распределение

Например определили 4 бакета с длительностью запроса, (условно по секунде, меньше или равно), пришла очередная метрика с длительностью запроса, он увеличил на единицу все бакеты «меньше или равно» его длительности
В метриках добавляется тег «le» (less than or equal)
Гистограмма считает считает кол-во попаданий в какую то группу т.е. запоминает счетчики а не сами значения. Каждый бакет как бы отдельная метрика
Удобно агрегировать в т.н. квантили. Если вы не знаете какие бакеты нужны, есть другой тип Summary

Summary
Сводка. Это результат агрегации гистрограммы, она выдает сразу квантили, можно сказать количественное распределение

Примечания

В случае с Прометеем, для группировки интервалов следует использовать переменную $rate_interval** вместо «$interval», она поддерживается только в нем
Переменная интервала призвана динамически подбирать интервал, для прометея rate_interval оптимизирована гораздо лучше
</details> <details> <summary> </summary> </details> <details> <summary> </summary> </details> <details> <summary> </summary> </details> <details> <summary> </summary> </details>