Метрики 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 для передачи метрик

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

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

Примечания

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