"пром" - в смысле в целом prometheus?

да.

механика прома в том что он должен знать что мониторит

ок, а что есть взамен? :)

а если поднимать push gateway, то необходимо обеспечить уникальность ключей метрик для каждого инстанса, т.е. включать туда, например, их имена, да? Т.е. типа "job_some-unique-id_bitrate" ну и т.д.

эхма. Посоветуйте тогда плиз, в какую ещё сторону можно посмотреть

push плохой вариант и стоит его избегать. промовцы много об этом пишут

push мониторинг сейчас на основе графита делают

push плохой вариант и стоит его избегать. промовцы много об этом пишут

а где пишут, если не секрет? Официальная документация не очень многословна, признаться

а где пишут, если не секрет? Официальная документация не очень многословна, признаться

http://robustperception.io/

блог одного из авторов. самого вредного из них. но весьма соображающего

push мониторинг сейчас на основе графита делают

а если надо не только push, но и pull, а push это всего лишь частный случай?

будет солянка чо :)

блог одного из авторов. самого вредного из них. но весьма соображающего

он совсем не дурак, но бесит %)

он совсем не дурак, но бесит %)

вааще. даже авой.

ага

плюс хотелось бы мониторить кое-какое железо по snmp, в общем, как-то систематизировать весь тот зоопарк, что у нас образовался за годы. Я понимаю, что серебряной пули нет и всё придётся допиливать, конкретно в prometheus подкупил язык запросов

будет солянка чо :)

да уже так и есть, эхма :)

да уже так и есть, эхма :)

солянка тут у многих.

да у всех, я думаю

в описании канала есть всякие штуки которые могут быть полезны

если не в мониторинге-метриках, то в другом месте

ну если инженерно подходить к вопросу

да, я прочитал FAQ и вторую ссылку, угу

с этого и начал, собственно :)

нашёл статью про pushgateway, угу

"Instances may come and go but the old metrics for the expired instances will remain in the Pushgateway and thus Prometheus. In order to synchronize, one must remember to delete expired metrics from the Pushgateway using its API" а через API можно получить дату последнего push для метрики в instance?

можно, но прометей её не будет учитывать

да это прометею и не надо, по факту можно раз в неделю например запускать зачистку от старого хлама

костыль, конечно

в пушгейтвее метрики спилятся по-умолчанию через 5 минут вроде бы

вопрос номер 2: если в процессе перегенерации конфига у меня instance_name останется тем же, но поменяется адрес и/или порт, то привязка не слетит, правильно? Старые графики продолжатся и т.д.?

ну можно сделать relabel чтобы метрики остались теми же

к сожалению об этом надо подумать заранее

ладно, почитаю об этом, спасибо за наводку

relabel переписывает метки метрик/таргетов по указанным правилам

например можно всегда отрезать порт от адреса инстанса

и тогда с точки зрения прометея это будет тот же инстанс

у тебя могут быть определены правила, которые из некоторых данных делают другие данные, агрегируют например. И если ты хочешь их хранить дополнительно (а не вычислять каждый раз при обращении, что весьма ресурсоемко), то ты пишешь правило. Правила хранятся в rules-файлах. Параметр, тобою упомянутый, отвечает за то, как часто необходимо перечитывать файл и переприменять настройки.

ты зря на русском читаешь

я? Или задавший удалённый вопрос? :)

подскажи а как поняь метрику с одной точкой ? у меня исинга опрашивает сервис,в сервисе перфдата /var/spool/icinga2/perfdara/serv* там при опросе сервиса получаю DATATYPE::SERVICEPERFDATA TIMET::1528401157 HOSTNAME::gel-servers-UPS3000RLM SERVICEDESC::ups_stats SERVICEPERFDATA::Temp=20;38;45;0 In_Line_Voltage=232;235;;195 Out_Line_Voltage=221;235;;185 Load=27;50;75;0 RunTime=;20;15;0 Diagnostic=0;15;30;0 Calibration=0;15;30;0 SERVICECHECKCOMMAND::check_common_ups HOSTSTATE::UP HOSTSTATETYPE::HARD SERVICESTATE::OK SERVICESTATETYPE::HARD я так понимаю что это одна точка ? если этиданные я буду передавать в флухдб то мне камежтся что эти данные по номальному не лягут (по умолчанию) - по умоолчанию ляжет как 1 метика (или я не прав?)?

как голова ? отошел ?

всем доброго. предыстория стоит исинга2 она опрашивает коммутаторы и упсы,есть 1 сервис по опросу упса внутри сервиса скрипт забрав данные по snmp от упса (температура\питание\ин-оут волтаж\ганрузка обрабатывает их параметры и если они в переделах нормы то просо отдает их исинге с параметром ОК если какойто параметр не гуд то либо Варниг либо КРИТ - но в любом слуае отдает исинге одной строкой - ну сервис же один (получается что 1 сервис мониторин несколько параметров)) в файле /var/spool/icinga2/perfdata строка выглядит как DATATYPE::SERVICEPERFDATA TIMET::1528439857 HOSTNAME::gel-servers-UPS3000RLM SERVICEDESC::ups_stats SERVICEPERFDATA::Temp=20;38;45;0 In_Line_Voltage=226;235;;195 Out_Line_Voltage=221;235;;185 Load=27;50;75;0 RunTime=;20;15;0 Diagnostic=0;15;30;0 Calibration=0;15;30;0 SERVICECHECKCOMMAND::check_common_ups HOSTSTATE::UP HOSTSTATETYPE::HARD SERVICESTATE::OK SERVICESTATETYPE::HARD мне из неё непонятно как данную строку скушает influxdb при стандартной настройке он не поймет данных ERVICEPERFDATA::Temp=20;38;45;0 In_Line_Voltage=226;235;;195 Out_Line_Voltage=221;235;;185 Load=27;50;75;0 RunTime=;20;15;0 Diagnostic=0;15;30;0 Calibration=0;15;30;0 лил примит их за одну метрику ? или както надо указывать что обрабатывать только первое значение ? Грубо говоря у меня потом графана будет строить графики

кстати, стоит смотреть ? https://habr.com/post/412901/

Флант всегда стоит)

скушал флукс нормально

check_common_ups,hostname=gel-servers-UPS3000RLM,metric=Calibration,service=ups_stats check_common_ups,hostname=gel-servers-UPS3000RLM,metric=Diagnostic,service=ups_stats check_common_ups,hostname=gel-servers-UPS3000RLM,metric=In_Line_Voltage,service=ups_stats check_common_ups,hostname=gel-servers-UPS3000RLM,metric=Load,service=ups_stats check_common_ups,hostname=gel-servers-UPS3000RLM,metric=Out_Line_Voltage,service=ups_stats check_common_ups,hostname=gel-servers-UPS3000RLM,metric=Temp,service=ups_stats check_common_ups,hostname=gel-servers-UPS3000RLM,service=ups_stats

надо его дописывать

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

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

блин ни когда вот телеграфом и инфлюкс не пользовался, но о них столько плохого говорят, больше уже чем о Z, что даже интересно глянуть

Z в другом весе выступает :) ему 10+ лет и у него большое русскоязычное сообщество (+ начинающим). А телеграф и инфлюкс как бы модно молодежно и они должны на равных соперничать со всем что написали последние 3-5 лет... Вот по фичам вроде все хорошо, а по качеству кода (архитектуре) - очень хотелось бы лучше

блин ни когда вот телеграфом и инфлюкс не пользовался, но о них столько плохого говорят, больше уже чем о Z, что даже интересно глянуть

А где это плохое почитать?

У нас TICK продукты пока что показывают себя с лучшей стороны, нежели конкуренты

кто это?

У нас TICK продукты пока что показывают себя с лучшей стороны, нежели конкуренты

ну про инфлюкс вообще написано в FAQ этой группу. А про телеграф вот даже Сергей чуть выше не как о супер приложении отозвался

кто это?

influx / telegraf etc

У нас TICK продукты пока что показывают себя с лучшей стороны, нежели конкуренты

и что значит нежели конкуренты? это какие ещё конкуренты могли показать себя хуже

Прометеус над TSDB.

промик с жирными выборками плоховато себя чувствовал

в отличие от...?

T из этого стека я сейчас выбрал по причине что нужно вот прямо сейчас начать сбор метрик с Win машин, а у него достаточно простой конфиг, про I может напеть арию @freeseacher, когда выбирал стек мне хватило его "попаболей" чтобы не ставить над собой эксперименты. Ремарка: если у вас <10к метрик в секунду и количество уникальных метрик <1M - вам повезло и у вас практически все будет нормально работать (можно кстати в FAQ подобную фразу закинуть, если ее там нет :) )

https://prometheus.io/docs/introduction/comparison/ а давно такая подробная страница со сравнением появилась?

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

Хм ... а подскажите, можно ли в проме сделать sum_over_time над delta? что-то в духе sum_over_time(delta(metric{})[3m])[3m])?

нельзя

ERROR: S client not available

рейндж можно только от сырой метрики взять

Печально :(

но ты можешь сделать агрегацию и брать от неё

Через recording rules?

ага

Ребята а что по поводу prometheus high availability ? как сделать два прома с одной базой или както standby

а так делают?

по докладам делают много промов каждый со своей базой

"с одной базой" не делают

делают дубли

по докладам делают много промов каждый со своей базой

И все они снимают одни и те же метрики?

Да

Не совсем прозрачно, графики надо переделывать

В смысле?

доклады выше были, делают проксик и хочешь х2 делаешь х2 прома , хочешь шардирование - пилишь по шардам сбор

В смысле?

В графане

Что именно переделывать?

ну без доп обвязки это я так понимаю не работает

Что именно переделывать?

Сурс же

На какой?

На тот, который не упал с того, который упал

нжинкс&&хапрокси или что то свое

А просто прокси поставить?

два прометеуса могут спокойно одни и теже метрики собирать с тех же хостов

Ну и как бы в худшем случае можно датасорс обновить, а не графики менять

прокси нужна только чтобы просмотр графиков переключать либо в точке между графаной и прометеусом либо перед графаной вообще

Либо нагрузку на чтение разделить между прометеями например

прометей, прометей - скрапи метрики бодрей

По какой причине один и тот же запрос в Grafana в графиках отображается с разным опозданием?

с насколько разным?

с насколько разным?

в одном 3 сек, во втором 14. При этом если новый создаю, то уже 14.