Комментарии 30
Prometheus работает с парами «ключ-значение»
Но ведь это не так. Имя это просто специальная метка типа __name__
, что позволяет в том числе по нему удобно искать. И оно не обязательно. То есть такие запросы сработают:
{__name__="cpu_usage"}
{cpu="0"}
Из-за pull модели опроса, prometheus не очень подходит для отслеживания метрик «быстрых» процессов, которые успевают начаться и звершиться между опросами метрик, а это почти все задачи обработки HTTP запросов.
Тут начинаются пляски с промежуточными агрегаторами метрик, которые принимают push, а потом отдают их через pull в prometheus… только полноценных нету, и ещё они должны уметь метрики «складывать» если это гистограммы, gauge и т.д.
За серверами следить с помощью prometheus однозначно «ДА», свободное дисковое пространство, свободная память и другие подобные метрики всегда можно получить прямо тут, но если ваши метрики нельзя посчитать в любую произвольную секунду, то тут уже надо думать :)
Отправляется сообщение о факте, что сервис получил сообщение об ошибке 404 за последние пять минут.
Тут тонкий момент, «сервис» получивший 404 это сборщик prometheus, но сколько 404 он пропустит прежде чем он всё же встретит плавающий 404?
Неоднозначна штука.
The metrics pushed are exactly the same as you would present for scraping in a permanently running program. If you need distributed counting, you could either use the actual statsd in combination with the Prometheus statsd exporter, or have a look at Weavework's aggregation gateway.
Это я и в json файл могу складывать всё, а потом в prometheus отдавать :)
Наворачивать statsd и писать клиента python и тестировать как себя ведёт Weavework's gateway даже не стал :) У них клиент JS только.
Для python вроде как решили эту проблему со сбором и агрегацией и передачей в prometheus метрик github.com/prometheus/client_python… но там решение на уровне одного сервера, метрики каждого процесса кладутся в отдельный файл, потом при pull они агрегируются. Но там потом заморочки с очисткой этой директории в «нужные моменты», отслеживание какой процесс умер и его метрики уже можно удалить…
И потом всёравно на двух серверах уже это не будет работать, а потребность такая есть.
Уже написано некоторое количество скриптов, отдающих какие-то значения системе мониторинга. Например, скрипты, проверяющие валидность и срок истечения SSL-сертификата веб-сервиса, состояние NTP-клиента(синхронизирован или нет), наличие пакетов, имеющих доступные обновления, и всё в этом духе.
Соответствующий экспортер я не нашёл, самое близкое — [script_exporter](https://github.com/adhocteam/script_exporter), но он смотрит только на exit code и длительность выполнения.
Можно запускать скрипты по крону и отдавать curl-ом в Pushgateway, но это костыли.
Какой правильный способ передать данные от этих скриптов в Prometheus?
ИМХО прикрутить костыль к скриптам, который выводит метрики в формате, который переваривает Пром (РБНФ-подобная: имя_метрики{роль_1=«значение_роли»,..., роль_N=«значение_роли»} %float(«значение_метрики»)%), писать всё в одну директорию в файл[ы] %name%.prom, развернуть Node exporter и прописать --collector.textfile.directory=/path/to/dir. От крона вы не избавитесь, но зато все полезные метрики Node exporter'а соберёте — не придётся мучиться с системными.
Или объединить запуск всех скриптов и отдавать один большой список метрик.
Не буду говорить за производительность ибо с настоящим тру хайлоадом с >10k VM или >1k железок или с >100k RPS не сталкивался, но как минимум а) Заббикс не кушает метрики по стандартному и привычному для всех HTTP[S] без танцев с бубном (по-крайней мере так было в последний раз когда я это проверял); б) PromQL кайфовый, тут без комментариев.
— на больших объёмах данных тормозит. Там внутри честный SQL, ничего с этим не сделаешь.
— графики опять же тормозят, потому что опять же честный SQL
— минимальное время обновления item(кроме тех, которые отсылает active agent) — 30 секунд. Терпимо для мониторинга, уведомляющего о проблемах людей, но не очень хорошо если нужна автоматическая реакция на события.
Упс, пропустил ветку выше.
Я бы хотел оставить фидбек. Хорошо, что вы пытаетесь перевести текст. Но очень плохо, что вы пишете только переводы терминов, не указывая оригинальное название.
Приведу пример такого перевода: В операционной системе "человечность" есть папка "/итд", в которой есть файлы "пароль" и "тень" :-)
Люди нигде не найдут просто "счетчик" или "измеритель", они везде будут видеть "counter" и "gauge". Лучше писать оригинальный термин, а в скобках указать ваш вариант перевода. Это действительно будет полезно.
Например, так: gauge ("измерение"). Много лет назад (до появления google translate и прочих) этот термин ввел меня в ступор. Было бы очень полезно узнать его перевод в тот момент.
Полное руководство по Prometheus в 2019 году