ну или чо у тебя там

bird - стильно, модно, молодежно

можно конечно birdc show proto all | $@$#^#$%^#$%& | $@$%@$%#$%^#%^ > /var/lib/node_exporter/metrics/bgp.prom

но вот я так не хочу это начинать снова

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

можно конечно birdc show proto all | $@$#^#$%^#$%& | $@$%@$%#$%^#%^ > /var/lib/node_exporter/metrics/bgp.prom

а что в этом такого плохого? так или иначе, вам надо выгружать маршруты из bird'а. ну вы можете вместо использования bird show proto all самостоятельно сходить в сокет и спросить.

а что в этом такого плохого? так или иначе, вам надо выгружать маршруты из bird'а. ну вы можете вместо использования bird show proto all самостоятельно сходить в сокет и спросить.

я конечно могу сходить. сам.

мне надо чтобы без этого вот всего вне зависимости от bgp демона видел node_exporter кол-во маршрутов в RIB

а то я на exabgp собрался ехать

сто раз переделывать

можно дернуть нетлинк и спросить все роуты в какой-нибудь таблице маршрутизации. впрочем получится почти ip route ls table $tbl | wc -l

cat /proc/net/route | wc -l кстати еще похоже на то что вам нужно.

так да, понятно что это легко берется и путем баша перекладывается. а хочется от этого отойти :)

запатчи нод-экспортер, чтобы он считал кол-во роутов по таблицам

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

ну вот прямой путь, да. только если уж писать - то в node_exporter, потому что разводить детский сад экспортеров в продакшене вообще не хочется.

с двумя и то заебся.

так да, понятно что это легко берется и путем баша перекладывается. а хочется от этого отойти :)

отойти куда? ну возьмите любой нормальный ЯП, сходите в нетлинк и возьмите оттуда число роутов.

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

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

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

ну вот читаю, да. объекты вытащить можно. а кол-во объектов пока не могу найти :)

чтобы без лишней математики не дергать full-view чтобы посчитать

ребят, а объясните тупому, есть у меня прометеус, на нодах экспортеры, графана с бекендом прометеуса, а телеграф куда пихать? это вместо чего-то или в дополнение?

я чет читал гитхаб их и не вкурил

у telegraf есть конфигурируемый output который называется prometheus

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

конфигурируешь чтобы он отдавал тебе всё чего node_exporter не отдаст

ну т.е. это вместо экспортеров

потому что node_exporter - это pure server metrics (tm)

не вместо а в дополнение

ну там мильён экспортеров и без телеграфа

на любой вкус

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

)

а, т.е. в этом соль?

автодискавери-швейцарский-нож?

ну вот читаю, да. объекты вытащить можно. а кол-во объектов пока не могу найти :)

патч на ядро.

чего мелочиться-то

соль в том чтобы не разводить балаган экспортеров :)

ведь ip r s | wc -l это неудобно

ведь ip r s | wc -l это неудобно

я сказал что это криво

а степень неудобства - субъективно, кому как

ну криво, неважно. кому что, на самом деле. кому-то шашки, кому-то ехать. мое мнение - если костыль не имеет side-эффектов и не стукнет потом по лбу вследствие отсутствия side-эффектов - это не костыль, а вполне работающее решение.

кстати, интересный вопрос, сколько реально времени занимает получение списка маршрутов нетлинком, когда их настолько много?

# time netstat -rn > routes.txt real 0m5.437s user 0m2.545s sys 0m1.111s

# cat routes.txt | wc -l 646092

блин когда 640k то стало нихрена не понимаю.

нет, это очень грязное время

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

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

Жень, напомни завтра

Я выбирал сидел

Жень, напомни завтра

Ок. Я пришла к выводу, что проще самой экспортер написать, чем использовать готовый: там нет того, что нужно

Да все, пацаны, не нужно уже, отбой)

Лолок

Ок. Я пришла к выводу, что проще самой экспортер написать, чем использовать готовый: там нет того, что нужно

Посмотри телеграф

Там много еще

А, я слоу - тебе уже написали

Свой экспортер хорошо, пока не возникает ситуация, когда расчет метрики занимает больше интервала сбора

Посмотри телеграф

никогда

никогда

У меня норм работает

Но мне, как выяснилось, вполне хватает нод экспортёра

никогда

почему никогда?

почему никогда?

вытекает. ломается.

вытекает. ломается.

на пустом месте ломается? или после апдейтов?

на пустом месте ломается? или после апдейтов?

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

@freeseacher а у тебя какие такие траблы были? (судя по коменту из статьи у вас prometheus + telegraf юзается)

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

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

если есть возможно не использовать телеграф - воспользуйся ей

ERROR: S client not available

Народ, утренний наброс. Кто мне скажет - насколько это правильно, что Zabbix снимает load_avg по умолчанию, исходя из количества ядер (load per core). Node Exporter так не делает, например.

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

# curl -s localhost:9100/metrics | grep node_load | grep -v "#" node_load1 2.79 node_load15 2.86 node_load5 2.79 # uptime 08:43:42 up 37 days, 4:13, 1 user, load average: 2.88, 2.81, 2.86

получается говнаббикс просто показывает в LA цифры, которые в N (кол-во ядер) меньше общепринятого восприятия метрики LA.

доброго утра )

Ну да, я про это и спрашиваю

Доброго

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

А топ не так, поэтому триггеры бесполезные получаются

ну то есть у тебя есть сервер, мониторится говнаббиксом. там, например, 16 ядер. тебе надо заранее ловить проблемы когда LA вытастает до 20, потому что у тебя уже есть userstoty что при LA>20 началась какая-нибудь абстрактная жопа. соответственно, говнаббикс тебе аварию просрёт потому что покажет 20 только когда там LA будет 20*16=320.

насколько это правильно?

Это неправильно

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

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

не использовать percpu

Из википедии: Располагая двумя процессорами, можно (теоретически) одновременно выполнять в два раза большее число программ. Это означает, что средняя нагрузка 2.00 (на двухпроцессорном компьютере) будет эквивалентна средней нагрузке 1.00 (на однопроцессорном компьютере). На самом деле это не совсем так. Из-за дополнительной нагрузки, вызванной планированием и некоторыми другими факторами, двухпроцессорный компьютер не обеспечивает удвоения быстродействия по сравнению с однопроцессорным вариантом.

насколько это правильно?

Абсолютно неправильно. Коллектор в идеале не должен менять метрики которые собирает

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

виимо пойти к говнаббиксу в репозиторий, переписать там код дефолтного шаблона выпилив percpu, сделать PR, ждать реакции сообщества.

Причем, для метрики system.cpu.load[<cpu>,<mode>] у них по дефолту правильный параметр. А в шаблоне стоит percpu.

Абсолютно неправильно. Коллектор в идеале не должен менять метрики которые собирает

Он не меняет. Он просто по-умолчанию снимает не la а la per second. А вот вторая метрика в отличии от первой имеет хоть какой-то смысл

Меняет, если ставишь percpu, то он просто делит на кол-во cpu в системе.

cpu - possible values: all (default), percpu (total load divided by online CPU count)

Он не меняет. Он просто по-умолчанию снимает не la а la per second. А вот вторая метрика в отличии от первой имеет хоть какой-то смысл

Нет, меняет, делит ее. Это неправильно

percpu is supported since Zabbix 2.0.0.

надо спросить, зачем это добавили.

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

Или ещё чо

я вот получил disk_write_bytes и что мне нужно в графане нарисовал, хочу - сколько за день Tb записал, хочу - сколько пишет Mb в секунду. мне вообще нужны обе метрики. а что такое LA в секунду?

Он не меняет. Он просто по-умолчанию снимает не la а la per second. А вот вторая метрика в отличии от первой имеет хоть какой-то смысл

что такое la per second?

получается говнаббикс просто показывает в LA цифры, которые в N (кол-во ядер) меньше общепринятого восприятия метрики LA.

Общепринятого?

Ну опечатался спросонья. Пер цпу конечно

А как вообще без количества ядер сырой LA воспринимать?