ну для прома не очень.

для инфлюкса довольно да.

собственно остается только графит :)

Он стабильнее?

ну приседать там тоже надо. но у меня в эксплуатации были только эти двое. про графит может много сказать @Civiloid

Он стабильнее?

коллектор какой ?

А под коллектором кого имеешь ввиду?

что собирает метрики

Сам сижу пишу

В текущий момент - заббикс агент с безумной башовой обвязкой

Но это говно должно умереть

Пока написал коллектор на golang, уже дня 4 работает

по какой причине не подошли существующие ?

существующий коллектор? Я видел где в углу интернета, что их можно завернуть на пром

Но там очень страшное говно, и его надо срыть

(И оторвать руки тому, кто это писал)

в описании канала есть полный список того что вообще бывает

если есть дополнения к списку велкам

Это табличка которая?

существующий коллектор? Я видел где в углу интернета, что их можно завернуть на пром

у меня в качестве коллеткора telegraf. хвалить не буду. ругать сильно тоже. работает и довольно всеяден.

у меня в качестве коллеткора telegraf. хвалить не буду. ругать сильно тоже. работает и довольно всеяден.

С плагинами у него пожирнее, чем у прома.

да там паритет в приципе

Экспортёр к каучу например пришлось писать руками

Тот что есть на гитхабе- года два как мертв

у прома много анлистед экпортеров

лучше всего смотреть их в табличке port_allocataions

Буду иметь ввиду.

И я тут подумал, наверно ещё недели две потыкаю пром

Если совсем плохо, попробую в графит

телеграф может в все три более менеее базы

ну и я очень надеюсь что релиз прома будет вот вот

Там кстати по срокам что обещали?

И есть ли хоть что то по прому на русском?

сомневаюсь что вообще что то на русском пригодное есть для чтения.

Ну повод начать что то писать на русском. Давно хотел завести блог на медиуме)

по прому много на https://www.robustperception.io/

собственно его один из разработв и ведет

И ещё, животрепещущий вопрос

Можно ли добавлять хосты прому без ребута

Может там метод есть на перечитку конфига?

да. сервис дискавери же есть

Пойду гуглить

https://prometheus.io/docs/operating/configuration/#configuration-file

всё что _sd_

https://github.com/lomik/go-carbon/releases/Version 0.11.0 was tagged

Если совсем плохо, попробую в графит

Учти что тебе алертилку надо будет выбрать

но за нарушение регламента использования - сядут

Как человек пиливший скаду много лет - нет не сядет. Скада это мониторинг режима. Она не используется для критически важных функций. У нас был случай, когда из-за бага со временем (использовалось локальное время, которое ВНЕЗАПНО прыгнуло на час назад, код не вывез такого) режим на одной АС был ненаблюдаем в течении часа. В итоге даже разработчика не уволили. От вашего NOC нормальная скада отличается тем, что в ней есть модель системы, она не просто циферки мониторит, а знает что это частота, это генерация, это переток. Она может быть испольована для расчета того что произойдет тогда, когда, например, подстанция будет выведена из эксплуатации на плановый ремонт, какие перетоки возникнут в системе если оборвется ЛЭП и тд и тп. В общем, NOC project на скаду не оч. похож. Я не пытаюсь доказать что он плох, если что. Просто занудствую за терминологию.

я утверждал, что NOC - это SCADA?

кстати, fm/pm в NOC сидят как раз поверх inventory. Так что NOC не цифирки мониторит, а каждая величина имеет размерность и смысл. И он снял именно напряжение, а не длину удава

и эти данные вполне можно использовать для моделирования

и NOC достаточно умен, чтобы понять, что не просто упала железка и утащила за собой n сервисов

но и этим падением разорвалось кольцо и еще m сервисов остались без резерва

SCADA упоминалась в контексте того, что мониторинг “критически важных” функций — это ближе к SCADA

чем к рисованию графиков

и не надо путать ситуацию, когда объект остался без мониторинга на какое-то время

и ситуацию, при которой объект остался без мониторинга и случилась авария, которую можно было предотвратить при своевременной реакции и которая привела к жертвам

в РТ - любой несчастный случай - комиссия, расследование, с результатами которого должны ознакомиться все руководители

валятся постоянно

хорошо мозги прочищает

а про “критичный для бизнеса web-сервис” — как-то смешно читать. Обычно сильно преувеличивают масштабы и не учитывают, что не прошедшие транзакции в большинстве случаев совершают потом

badoo и иннову в то время, когда я ими занимался, сложно было назвать маленькими ?

и ситуацию, при которой объект остался без мониторинга и случилась авария, которую можно было предотвратить при своевременной реакции и которая привела к жертвам

Так не бывает. SCADA (любая вообще) это не делает. Она вообще не управляет процессами. Существует множество уровней защиты от аварий на той же АС и SCADA в их число не входит.

Учти что тебе алертилку надо будет выбрать

Вот это отдельная боль. Очень не хочу конфигурть графики и Алерты в разных местах

а про “критичный для бизнеса web-сервис” — как-то смешно читать. Обычно сильно преувеличивают масштабы и не учитывают, что не прошедшие транзакции в большинстве случаев совершают потом

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

ну я вот выбирал из 3х вариантов: 1) все на пром - условно проще но имеем условно заббикс некст ген 2) вариации двух бекендов один из которых пром с алертингом 3) карбон + бозон + карбон-кликхаус жизнь-боль

ERROR: S client not available

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

компания разорилась и ушла с рынка?

акционеры захотели потратить хотя бы 50% от “ущерба” на железо для резервирования “критичного” сервиса?

ну я вот выбирал из 3х вариантов: 1) все на пром - условно проще но имеем условно заббикс некст ген 2) вариации двух бекендов один из которых пром с алертингом 3) карбон + бозон + карбон-кликхаус жизнь-боль

2) вот это как?

ну вот допустим кликхаус для статистики и пром для собственно мониторинга с алертингом

они не удивлялись, что система мониторинга этого “критичного” сервиса крутится на списанном серваке с помойки?

в моем понимании “критичный ущерб” == “непоправимые последствия"

прибило кого, компания разорилась

я когда стал разгребать все эти мониторинги понял что если на что то сяду то потом будет почти такая же боль слезать (если что) на что то новоемолодежноевотэтовсе - поэтому пихнул в архитектуру между коллектингом и бекендом систему доставки (кафку)

во всех остальных случаях - критичность — просто треп ради красивого словца

стало все потолще, но появились плюшки

затраты должны соотноситься с ущербом

во всех остальных случаях - критичность — просто треп ради красивого словца

да так и есть, в мелких телекомах которые живут иногда за счёт пары жирных клиентов это вообще обычная тема, не хотят потратить один раз на железо 5X рублей, а потом теряют абонента который приносил им в месяц 1X

я даже обратное видел

не хотели тратить суммы меньше месячного платежа

@Anc1ent я видел одну компанию которая арендовала железо в одном немецком хостере. Из-за особенностей хостера у них было примерно 4-6 дней дней когда часть сервиса лежала. Это стоило в недополученной прибыли примерно годиной аренды в нормальном датацентре и приближалась к цене покупки своего-своего железа

но народ думал как бы подать в суд на хостера

по мне - все это - управляемые риски

ну я пока сколько живу почему-то вижу что про риски думают только "админы", а не эффективные менеджеры

чудеса

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

@Anc1ent я видел одну компанию которая арендовала железо в одном немецком хостере. Из-за особенностей хостера у них было примерно 4-6 дней дней когда часть сервиса лежала. Это стоило в недополученной прибыли примерно годиной аренды в нормальном датацентре и приближалась к цене покупки своего-своего железа

ну вот тоже

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

сложна

ну тогда он не критичный

?

ну тогда он не критичный

критичный!

но делать его распределенным - сложна

или legacy

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

да это вообще нормально когда что-нибудь не работает или просто всё выключили, а назад не включилось

поэтому он например на ручном приводе переключается

ну вот пример

ага типа ибмка размером со слона