Southbridge corporate blog
System administration
Server Administration
DevOps
Comments 27
+3
Спасибо, хорошая статья, для понимания основ. Но переводы терминов (счетчики, измерители и т.п.) на русский, имхо, лишнее. Оригинальные названия встречаются чаще и привычнее.
+2
На мой взгляд, можно просто при первом использовании терминов «счетчики» и «измерители» указывать их оригинальные названия — counter и gauges — и далее использовать русский вариант. Перевод же.
0
Prometheus работает с парами «ключ-значение»

Но ведь это не так. Имя это просто специальная метка типа __name__, что позволяет в том числе по нему удобно искать. И оно не обязательно. То есть такие запросы сработают:


{__name__="cpu_usage"}
{cpu="0"}
+4
Какое-то странное у вас полное руководство — огрызок. Я надеялся на полный перевод официальной документации. Зачем писать такие обманчивые заголовки?
+2
Про минусы жалко как обычно не пишут, с минусами все сталкиваются когда уже втянулись :)

Из-за pull модели опроса, prometheus не очень подходит для отслеживания метрик «быстрых» процессов, которые успевают начаться и звершиться между опросами метрик, а это почти все задачи обработки HTTP запросов.

Тут начинаются пляски с промежуточными агрегаторами метрик, которые принимают push, а потом отдают их через pull в prometheus… только полноценных нету, и ещё они должны уметь метрики «складывать» если это гистограммы, gauge и т.д.

За серверами следить с помощью prometheus однозначно «ДА», свободное дисковое пространство, свободная память и другие подобные метрики всегда можно получить прямо тут, но если ваши метрики нельзя посчитать в любую произвольную секунду, то тут уже надо думать :)

Отправляется сообщение о факте, что сервис получил сообщение об ошибке 404 за последние пять минут.


Тут тонкий момент, «сервис» получивший 404 это сборщик prometheus, но сколько 404 он пропустит прежде чем он всё же встретит плавающий 404?
Неоднозначна штука.
+1
Да смотрел конечно, но из описания Pushgateway:
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 они агрегируются. Но там потом заморочки с очисткой этой директории в «нужные моменты», отслеживание какой процесс умер и его метрики уже можно удалить…

И потом всёравно на двух серверах уже это не будет работать, а потребность такая есть.
0
А Telegraf в качестве промежуточного агрегатора рассматривали? С какими недостатками столкнулись, если пробовали использовать?
+2
Вопрос про переход на Prometheus с Zabbix.

Уже написано некоторое количество скриптов, отдающих какие-то значения системе мониторинга. Например, скрипты, проверяющие валидность и срок истечения SSL-сертификата веб-сервиса, состояние NTP-клиента(синхронизирован или нет), наличие пакетов, имеющих доступные обновления, и всё в этом духе.

Соответствующий экспортер я не нашёл, самое близкое — [script_exporter](https://github.com/adhocteam/script_exporter), но он смотрит только на exit code и длительность выполнения.

Можно запускать скрипты по крону и отдавать curl-ом в Pushgateway, но это костыли.

Какой правильный способ передать данные от этих скриптов в Prometheus?
+1
А доступ до машинок, на которых живут скрипты не потерян?
ИМХО прикрутить костыль к скриптам, который выводит метрики в формате, который переваривает Пром (РБНФ-подобная: имя_метрики{роль_1=«значение_роли»,..., роль_N=«значение_роли»} %float(«значение_метрики»)%), писать всё в одну директорию в файл[ы] %name%.prom, развернуть Node exporter и прописать --collector.textfile.directory=/path/to/dir. От крона вы не избавитесь, но зато все полезные метрики Node exporter'а соберёте — не придётся мучиться с системными.
+1
Или вам надо сделать Веб-сервер, в котором каждому вашему скрипту будет соответствовать URL и отдавать в формате prometheus метрики.
Или объединить запуск всех скриптов и отдавать один большой список метрик.
+3
Ужасы какие, по сравнению с zabbix/nagios/whatever сильно увеличивается время на поддержку и сопровождение такой конструкции.
0
А Вы их вообще сравнивали?
Не буду говорить за производительность ибо с настоящим тру хайлоадом с >10k VM или >1k железок или с >100k RPS не сталкивался, но как минимум а) Заббикс не кушает метрики по стандартному и привычному для всех HTTP[S] без танцев с бубном (по-крайней мере так было в последний раз когда я это проверял); б) PromQL кайфовый, тут без комментариев.
0
Zabbix прекрасно получает данные с HTTP(S) и одним запросом может наполнить кучу item'ов. Более того, Zabbix даже имеет встроенную поддержку Prometheus-формата (с версии 4.2)
+1
Zabbix хороший, гибкий и фичастый, но у него есть врождённые недостатки:

— на больших объёмах данных тормозит. Там внутри честный SQL, ничего с этим не сделаешь.
— графики опять же тормозят, потому что опять же честный SQL
— минимальное время обновления item(кроме тех, которые отсылает active agent) — 30 секунд. Терпимо для мониторинга, уведомляющего о проблемах людей, но не очень хорошо если нужна автоматическая реакция на события.

0

По последнему — не припомню лимита в 30 секунд для пассивных проверок.

0
Хм, посмотрел документацию, такого там нет. Странно, я был абсолютно уверен что такой лимит есть. Может, было в более ранних версиях?
0
Видимо перепутали с максимальным таймаутом в 30 секунд для агентских проверок.
0
А что вас сподвигло на такой переход, если не секрет?
Упс, пропустил ветку выше.
0
Подскажите а как можно заалертить если появилась метрика? Есть динамически создаваемая метрика, которой либо нет совсем, либо она появляется с значением 1 сразу и постепенно увеличивается (счетчик ошибок). Нулевого состояния метрики нет вовсе. Как можно алерт на такое сделать?
0
Предполагаю, что с помощью diff(5m)}>1 как-то так. Т.Е. изменения за последние 5 минут больше 1
Или на пример nodata(5m) тогда когда появится сработает триггер…
Only those users with full accounts are able to leave comments. , please.