в очень динамичном окружении на тысячи серверов это конечно проблематично все, согласен

Тут вопрос в том для чего нужны метрики

если для алертинга то чаще всего достаточно хостовых метрик для каких-то per host алертов

но per-service уже нет

Хм... А если я в prometheus в node_exporter делаю ключи —collector.xxxx, он всё остальное выбрасывает что ли?

есть дефолтный список, а ты его переопределяешь

не самое удобное решение чуваки выбрали конечно

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

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

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

в блокчейн

микросервисный блокчейн метрик

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

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

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

и у тебя каждый инсанс приложения шлет тонны треша

или просто люди решили что UUID клиента нужно указать в метрике

а клиентов десятки тысяч )

новых

чота я короче посмотрел на то что я делаю

и понял что переизобретаю prometheus-operator

кто им пользовался? какие впечатления?

sum (container_spec_memory_limit_bytes{id=~"/kubepods/.*"}) / sum (machine_memory_bytes{kubernetes_io_role="node"}) возвращает мне 44% а sum(kube_pod_container_resource_limits_memory_bytes) / sum(machine_memory_bytes{kubernetes_io_role="node"})возвращает мне 27%

понятно что где-то что-то не то считаю

навскидку не знаете, что?

Вроде же разные сущности, нет?

а вроде одна и та же

по-разному экспортируемые

первое - из cadvisor, второе из kube-state-exporter

первое - из cadvisor, второе из kube-state-exporter

а ты курлом постучи, и сам посчитай)

да понятно что надо смотреть и сравнивать

может я прост что-то очевидное пропустил

первое - из cadvisor, второе из kube-state-exporter

ну state это limits а cadvisor это usage ... нет?

ну state это limits а cadvisor это usage ... нет?

не, и там и там limits

оказалось что это хитрая логика работы burstable подов в кубере, надо отфильтровывать по id!~"/kubepods/burstable.*"

ну или научиться правильно их обрабатывать

насколько проще стало жить с kube-state-metrics

sum(kube_pod_container_resource_requests_memory_bytes) by (node) / sum(kube_node_status_capacity_memory_bytes and on (node) kube_node_labels{label_kubernetes_io_role="node"}) by (node)

и всё красиво сразу показывает

и для cpu: sum(kube_pod_container_resource_requests_cpu_cores) by (node) / sum(kube_node_status_capacity_cpu_cores and on (node) kube_node_labels{label_kubernetes_io_role="node"}) by (node)

да с этими "контейнерами" та ещё фигня, у меня есть центось а эта зараза при рестарте контейнера меняет его id и id сетевых интерфейсов и вот их лови каждый раз, прям хоть коллектд патчь :)

зачем их знать ваще?

ну то есть с одной стороны неразберихи стало много, а с другой - да и норм всё

IMS – не является в компании системой мониторинга, мониторинг отдельная тема, другое подразделение, другое ПО. Статистика нагрузки и использования ресурсов собирается IMS-ом и используется в процессе прогнозирования и планирования мощностей (Capacity Planning) ИТ-инфраструктуры. типа а тут я немного вышиваю, о кровавом ынтырпрайзе, это МТС на хабре про свою инвенторилку поведал

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

Защиту от такого кажется не слишком сложно вставить дженерно

да с этими "контейнерами" та ещё фигня, у меня есть центось а эта зараза при рестарте контейнера меняет его id и id сетевых интерфейсов и вот их лови каждый раз, прям хоть коллектд патчь :)

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

так оно в общем принципиально скорее сломано чем верно, так как под каждый рестарт виртуалки новая метрика или продолжение чьейто старой, словарь и вот это всё внешними скриптами, так костыль на время

Для меня откровенная загадка, почему все Тулы собирают по id, а не по name

Для меня откровенная загадка, почему все Тулы собирают по id, а не по name

Как это *все* ?

С платными я не знаком из-за особенностей работы

Cadvisor, collectd и zabbix так делают

Защиту от такого кажется не слишком сложно вставить дженерно

Нуууу... Тут вылезает то что у тебя люди будут искать новые способы насрать метриками, а каждая защита будет ещё резать что то легитимное

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

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

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

Cadvisor отдает имя и id, а имена вроде можно фетчить даже из cgoups

ну что ж... остаётся порадоваться за гугля и опечалится состоянием опенсорца :)

Слушайте, а какие-нибудь типовые дашборды на node_exporter покидайте мне, пожалуйста. Ну рекомендуете которые конечно. диск, xfs, la, память, сеть, что там ещё бывает

На сайте графаны не?

На сайте графаны есть почти под любой популярный экспортер, да

Ну вот xfs в экспортере есть, а в дашбордах не нашел

Ну и хотелось бы сейчас на поглазеть а там зоопарк

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

Зафлудить нетфильтр, забить канал и тд

Кстати, если кто помнит, был у меня вопрос с 401 ошибками. В общем, таким образом графана сообщает, что SQLite не подходит ей в качестве базы. Стоило заменить SQLite на PostgreSQL - всё сразу магическим образом исчезло.

Зафлудить нетфильтр, забить канал и тд

Не, считаешь это хорошей идеей - твое право :)

Нихрена с прометеем и джобами не понял, и лейблами. Это влияет на графану. Если там вот эта хрень как приборная доска - не дай бог у вас с джоба на джоб что-то переехало и оно об этом не знает

джобы довольно стабильны. врятли они перезежают

ну я игрался. я кстати так и не понял что это. дашборды многие прибиты гвоздями к названию джобов

да. я не знаю зачем так делают

я поле джоб вообще ставлю во время дискаверинга

Коллеги, а есть в прометее метрика, которая показывает статус ноды кубернетеса: Ready или NotReady? Или для этого какой-то особый экспортер нужен?

Бери kube-state-metrics

Бери kube-state-metrics

А как метрика называется? Я ведь такую информацию только с мастера смогу получить.

ищи по kube_node_...

Прямо щас посмотреть не могу, через полчасика напомни,если сам не найдёшь к тому времени

господа, а можете объяснить несколько нубских вопросов по графиту? В связке graphite-carbon. Как понимаю, сам карбон шлет метрики memUsage, metricsRecieved, cpuUsage и тд?

Прямо щас посмотреть не могу, через полчасика напомни,если сам не найдёшь к тому времени

Нашёл kube_node_status_condition, но что-то не могу разобраться, что там за данные. В состоянии true больше нод, чем у меня есть. Может другая метрика?

хз, щас гляну

sum(kube_node_status_condition) by (condition, status)

вот там есть condition="Ready"

кажется это то что тебе надо

{condition="Ready",status="false"} {condition="Ready",status="true"} {condition="Ready",status="unknown"}

Ну да. То, что нужно. У меня почему-то есть метрики с меткой "app", и без неё. Поэтому их в 2 раза больше. Спасибо.

ты возможно релейбелингом её добавляешь сам

из аннотаций кубера

Кто будет мониторить систему мониторинга...?

разделение мониторингов - один шлет алерты, другой рисует графики, третий логи складирует

тогда когда заваливается один из них, то полностью не слепнешь

хм, почему-то мне куберовские метрики для некоторых нод возвращают что requests > limits

sum(kube_pod_container_resource_limits_cpu_cores) by (node) / sum(kube_pod_container_resource_requests_cpu_cores) by (node)

есть и больше единицы и меньше единицы

Добрый день господа подскажите пожалуйста как вы мониторите smart через prometheus?

Добрый день господа подскажите пожалуйста как вы мониторите smart через prometheus?

textcollector + cron

raid-ы так же

textcollector + cron

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

зачем помнить?

руками что ли эти кроны пишешь?

даже если не руками если какимнить ансиблом а кто-то начнет править ансибл и сломается мониторинг мне что гадать это крон не работает? или smartctl недоступно?