Комментарии 30
Спасибо, хорошая статья, для понимания основ. Но переводы терминов (счетчики, измерители и т.п.) на русский, имхо, лишнее. Оригинальные названия встречаются чаще и привычнее.
Prometheus работает с парами «ключ-значение»
Но ведь это не так. Имя это просто специальная метка типа __name__, что позволяет в том числе по нему удобно искать. И оно не обязательно. То есть такие запросы сработают:
{__name__="cpu_usage"}
{cpu="0"}
Какое-то странное у вас полное руководство — огрызок. Я надеялся на полный перевод официальной документации. Зачем писать такие обманчивые заголовки?
Про минусы жалко как обычно не пишут, с минусами все сталкиваются когда уже втянулись :)
Из-за pull модели опроса, prometheus не очень подходит для отслеживания метрик «быстрых» процессов, которые успевают начаться и звершиться между опросами метрик, а это почти все задачи обработки HTTP запросов.
Тут начинаются пляски с промежуточными агрегаторами метрик, которые принимают push, а потом отдают их через pull в prometheus… только полноценных нету, и ещё они должны уметь метрики «складывать» если это гистограммы, gauge и т.д.
За серверами следить с помощью prometheus однозначно «ДА», свободное дисковое пространство, свободная память и другие подобные метрики всегда можно получить прямо тут, но если ваши метрики нельзя посчитать в любую произвольную секунду, то тут уже надо думать :)
Тут тонкий момент, «сервис» получивший 404 это сборщик prometheus, но сколько 404 он пропустит прежде чем он всё же встретит плавающий 404?
Неоднозначна штука.
Из-за pull модели опроса, prometheus не очень подходит для отслеживания метрик «быстрых» процессов, которые успевают начаться и звершиться между опросами метрик, а это почти все задачи обработки HTTP запросов.
Тут начинаются пляски с промежуточными агрегаторами метрик, которые принимают push, а потом отдают их через pull в prometheus… только полноценных нету, и ещё они должны уметь метрики «складывать» если это гистограммы, gauge и т.д.
За серверами следить с помощью prometheus однозначно «ДА», свободное дисковое пространство, свободная память и другие подобные метрики всегда можно получить прямо тут, но если ваши метрики нельзя посчитать в любую произвольную секунду, то тут уже надо думать :)
Отправляется сообщение о факте, что сервис получил сообщение об ошибке 404 за последние пять минут.
Тут тонкий момент, «сервис» получивший 404 это сборщик prometheus, но сколько 404 он пропустит прежде чем он всё же встретит плавающий 404?
Неоднозначна штука.
А Pushgateway стандартный Вы пропустили мимо или забраковали?
Да смотрел конечно, но из описания Pushgateway:
Это я и в json файл могу складывать всё, а потом в prometheus отдавать :)
Наворачивать statsd и писать клиента python и тестировать как себя ведёт Weavework's gateway даже не стал :) У них клиент JS только.
Для python вроде как решили эту проблему со сбором и агрегацией и передачей в prometheus метрик github.com/prometheus/client_python… но там решение на уровне одного сервера, метрики каждого процесса кладутся в отдельный файл, потом при pull они агрегируются. Но там потом заморочки с очисткой этой директории в «нужные моменты», отслеживание какой процесс умер и его метрики уже можно удалить…
И потом всёравно на двух серверах уже это не будет работать, а потребность такая есть.
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 они агрегируются. Но там потом заморочки с очисткой этой директории в «нужные моменты», отслеживание какой процесс умер и его метрики уже можно удалить…
И потом всёравно на двух серверах уже это не будет работать, а потребность такая есть.
А Telegraf в качестве промежуточного агрегатора рассматривали? С какими недостатками столкнулись, если пробовали использовать?
Вопрос про переход на Prometheus с Zabbix.
Уже написано некоторое количество скриптов, отдающих какие-то значения системе мониторинга. Например, скрипты, проверяющие валидность и срок истечения SSL-сертификата веб-сервиса, состояние NTP-клиента(синхронизирован или нет), наличие пакетов, имеющих доступные обновления, и всё в этом духе.
Соответствующий экспортер я не нашёл, самое близкое — [script_exporter](https://github.com/adhocteam/script_exporter), но он смотрит только на exit code и длительность выполнения.
Можно запускать скрипты по крону и отдавать curl-ом в Pushgateway, но это костыли.
Какой правильный способ передать данные от этих скриптов в Prometheus?
Уже написано некоторое количество скриптов, отдающих какие-то значения системе мониторинга. Например, скрипты, проверяющие валидность и срок истечения 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'а соберёте — не придётся мучиться с системными.
ИМХО прикрутить костыль к скриптам, который выводит метрики в формате, который переваривает Пром (РБНФ-подобная: имя_метрики{роль_1=«значение_роли»,..., роль_N=«значение_роли»} %float(«значение_метрики»)%), писать всё в одну директорию в файл[ы] %name%.prom, развернуть Node exporter и прописать --collector.textfile.directory=/path/to/dir. От крона вы не избавитесь, но зато все полезные метрики Node exporter'а соберёте — не придётся мучиться с системными.
Или вам надо сделать Веб-сервер, в котором каждому вашему скрипту будет соответствовать URL и отдавать в формате prometheus метрики.
Или объединить запуск всех скриптов и отдавать один большой список метрик.
Или объединить запуск всех скриптов и отдавать один большой список метрик.
А чем Zabbix не угодил?
А Вы их вообще сравнивали?
Не буду говорить за производительность ибо с настоящим тру хайлоадом с >10k VM или >1k железок или с >100k RPS не сталкивался, но как минимум а) Заббикс не кушает метрики по стандартному и привычному для всех HTTP[S] без танцев с бубном (по-крайней мере так было в последний раз когда я это проверял); б) PromQL кайфовый, тут без комментариев.
Не буду говорить за производительность ибо с настоящим тру хайлоадом с >10k VM или >1k железок или с >100k RPS не сталкивался, но как минимум а) Заббикс не кушает метрики по стандартному и привычному для всех HTTP[S] без танцев с бубном (по-крайней мере так было в последний раз когда я это проверял); б) PromQL кайфовый, тут без комментариев.
Zabbix хороший, гибкий и фичастый, но у него есть врождённые недостатки:
— на больших объёмах данных тормозит. Там внутри честный SQL, ничего с этим не сделаешь.
— графики опять же тормозят, потому что опять же честный SQL
— минимальное время обновления item(кроме тех, которые отсылает active agent) — 30 секунд. Терпимо для мониторинга, уведомляющего о проблемах людей, но не очень хорошо если нужна автоматическая реакция на события.
— на больших объёмах данных тормозит. Там внутри честный SQL, ничего с этим не сделаешь.
— графики опять же тормозят, потому что опять же честный SQL
— минимальное время обновления item(кроме тех, которые отсылает active agent) — 30 секунд. Терпимо для мониторинга, уведомляющего о проблемах людей, но не очень хорошо если нужна автоматическая реакция на события.
А что вас сподвигло на такой переход, если не секрет?
Упс, пропустил ветку выше.
Упс, пропустил ветку выше.
Было полезно.
Подскажите, пожалуйста, чем этот продукт отличается от zabbix?
Подскажите а как можно заалертить если появилась метрика? Есть динамически создаваемая метрика, которой либо нет совсем, либо она появляется с значением 1 сразу и постепенно увеличивается (счетчик ошибок). Нулевого состояния метрики нет вовсе. Как можно алерт на такое сделать?
Если позволите, комментарий по оформлению. Отличная идея, использовать bold, но когда его слишком много, глаза понемногу начинают уставать.
Я бы хотел оставить фидбек. Хорошо, что вы пытаетесь перевести текст. Но очень плохо, что вы пишете только переводы терминов, не указывая оригинальное название.
Приведу пример такого перевода: В операционной системе "человечность" есть папка "/итд", в которой есть файлы "пароль" и "тень" :-)
Люди нигде не найдут просто "счетчик" или "измеритель", они везде будут видеть "counter" и "gauge". Лучше писать оригинальный термин, а в скобках указать ваш вариант перевода. Это действительно будет полезно.
Например, так: gauge ("измерение"). Много лет назад (до появления google translate и прочих) этот термин ввел меня в ступор. Было бы очень полезно узнать его перевод в тот момент.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Полное руководство по Prometheus в 2019 году