А icinga/nagios может же отправлять стату в graphite

Хорошая идея, пойду погуглю

А icinga/nagios может же отправлять стату в graphite

кстати интересно да. скорее всего можно забирать простым плагином

нашёл обратный вариант, добавить graphite в icinga2, а вот что б данные отправлялись чего-то не могу найти

а как задача стоит? отправить данные из исинги в графит? вообще же в него можно отправить curl-ом простым....

а нативно - https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/object-types#objecttype-graphitewriter

а нативно - https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/object-types#objecttype-graphitewriter

Дада, уже нашёл

Но задача была другая, это костыль по большому счёту

Вообщем тож херня.

Надо свой плагин писать

А поясни.

Поподробнее. Совсем развернуто

Чем заббикс отличается от ицинги внешне? Это значениями пороговыми, т.е. value, max, waring, crit. В graphite уходит информацию по этому value, но, нет обработки того что мне нужно, т.е. UserParameter=custom.vfs.dev.write.cifs,/usr/bin/cifsiostat | head | tail -n2 | awk '{print $3}'|sed -e 's/\,/\./' оно не обрабатывается, хотя по идеи должен отправлять эти данные так же в icinga, но она их держит у себя и дальше не переправляет.

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

Эм.. как бэ правильно объяснить agent > icinga/zabbix > graphite > grafana, на шаге icinga > graphite вот эти данные что выше, не уходят, хотя по идеи это значение должен получить, ведь в icinga они отображаются

Вроде написал как есть..

так стоп, ты ицингой метрики собираеш

так стоп, ты ицингой метрики собираеш

Я не могу собрать метрику чем-то другим для cifs

Т.е. я собирал данные с помощью той строчки что написал выше, они отображались в zabbix/icinga(2), но они не отправляются в graphite

а что в логах?

Что б собрать метрику для graphite напрямую нужно писать отдельный плагин

а что в логах?

Логах чего? в icinga пусто, в graphite тож

логах исинги, конечно - раз уж она не осиливает отправить

Ну т.е. там есть, что есть сбор и всё. Дальше молчок

вообще самый простой вариант - читать отсюда: /proc/fs/cifs/Stats

Типа всё норм

вообще самый простой вариант - читать отсюда: /proc/fs/cifs/Stats

Это агентить надо, т.е. писать сборщик, я не уметь/лень

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

https://github.com/deniszh/collectd-iostat-python - можно это дело переделать, там уже основное есть, но это тоже, так себе решение

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

Угу, верно. И встаёт проблема, что лучше и как лучше. Типа "нормально дейлай, нормально будет"

да, универсальный принцип. мы не можем себе позволить ХХИП просто потому, что сами же будем с этим работать.

А нельзя сделать ещё один сетевой интерфейс, выдать ему отдельный ip и по нему маунтить?

Тогда можно просто мерить интерфейс

Эм нет, я же хочу писать с 4 серверов рид/врайт в эту папку как на диск

Т.е. получить объём использования что ли

Объём залитых данных за сутки через df получить можно, а вот именно график загрузки/нагрузки

Объём залитых данных за сутки через df получить можно, а вот именно график загрузки/нагрузки

С хера ли? Ты не умеешь считать потребление канала на интерфейсе?

Нодеэкспортер в Прометей и привет

Нодеэкспортер в Прометей и привет

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

С хера ли? Ты не умеешь считать потребление канала на интерфейсе?

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

Вообщем хз, надо подумать

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

Ну, виртуальный интерфейс, да

Если это дорого, то может дешевле писать костыли, не знаю

Мы так посчитали потребление трафика отдельным апи

Ну, виртуальный интерфейс, да

С этой стороны и не думал даже

Ну минут 20 я это конфигурил и потом рассказал всем хостам новый конфиг

Мы так посчитали потребление трафика отдельным апи

т.е. каждый endpoint - отдельный интерфейс?

Или как правильно называются точки апи

т.е. каждый endpoint - отдельный интерфейс?

Ну надо было одного:) целого апи, отдельного, с кучей ендпоинтов

Понял.

Причем чужого

Мне вот кстати интересно, а никто тренды той же ицинги как метрики не использует?

А подскажите, куда бы лить статистику с netflow с большой пачки серверов, чтобы посчитать сколько на каждый наш ип пришло и сколько с него ушло, причем посчитать это не считая трафик между серверами. То ли гугл меня забанил, то ли я ничего готового не вижу. Писать своё на кликхаус?

netams'ом пользовались для этого лет 5 назад

http://www.netams.com/

оно платное ж поди?

и нет, нам не надо такой биллинг, который типа биллинг, и сертифицированный. Я хочу что-то простое, готове и опенсурсное, а дальше мы на это накрутим всё сами

а, вижу, оно теперь бесплатно

flow-tools и flow-report в нем

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

А для чего собирать, какой профит? Пы.Сы. туповат

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

Не задумывался о таком, наверное оно мне просто не нужно. Спасибо за разъяснения

ERROR: S client not available

Как правило, никому не нужно. Но бывают исключения и проекты, где много "истоически сложилось". Там пригождается :)

А для чего собирать, какой профит? Пы.Сы. туповат

Кнутов - хостер

нетамс это что-то из 90х

Более современного и менее провайдерского из готовых год назад не нашёл:( Если кто поделится чем-то интересным буду весьма признателен :). Мне надо будет скоро подобной тулзой офисную сеть "считать"

А подскажите, куда бы лить статистику с netflow с большой пачки серверов, чтобы посчитать сколько на каждый наш ип пришло и сколько с него ушло, причем посчитать это не считая трафик между серверами. То ли гугл меня забанил, то ли я ничего готового не вижу. Писать своё на кликхаус?

мы используем nprobe

Вечер в келью

У меня есть прометеус

И вот он хранит метрички 15 дней

А мне надо бы год

И если растянуть его на год - он же агрегировать не начнет

Экспорт в графит ?

Ну - можно же не экспорт, а прямо сразу в графит

Если фичи прометеуса не нужны то можно

А мы про какие фичи, алертинг?

Алертинг нужен, наверное

Нечисловые метрики

Но алертить может и риман

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

А подскажите, куда бы лить статистику с netflow с большой пачки серверов, чтобы посчитать сколько на каждый наш ип пришло и сколько с него ушло, причем посчитать это не считая трафик между серверами. То ли гугл меня забанил, то ли я ничего готового не вижу. Писать своё на кликхаус?

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

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

пока что они мне говорят, что готового нет и проще каждый раз самим написать. А я пока с ними не согласен и считаю это это слишком дорого по времени

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

ну снимаю то трафик я с роутера на входе, вопрос как его потом агрегировать per внутренний ip, и как хранить

упрощенно, нам нужно последние 60 минут с градацией по минуте, последние пару суток с градацией по5 минут и дальше по часу

ну т.е. нам это надо чем-то получить, агрегировать пер ип, немного похранить, и слить потом в наш биллинг

потратив минимум ресурсов

я не понимаю немного конечную цель?

все-таки биллинг?

аккаунтинг трафика потребляемого серверами внутри ДЦ

как бы биллинг, но на самом деле просто статистика