MRTG и 2к хостов

[twg 871]

Вопрос такой: есть ли у кого опыт с МРТГ и большим количеством хостов? Как поведет себя сабж при 2к хостов, на которые ему нужно будет рисовать графики?

Может и глупый вопрос, но не знаю что придумать, как лучше рисовать графики поюзерно, попортово. И не с биллинга брать счетчики, а именно или с портов свитчей, или с ВиФиЦПЕшек напрямую тем же SNMP. Бо бывает непонятный кратковременный всплеск трафика во влане, который до бордера не долетает и отследить сложно тем же tcpdump'oм. А увидев всплеск трафика на кокретном порту/CPE круг поисков сужается.

Відредаговано 2015-10-13 11:05:34 twg

[Lynx100 90]

Вопрос такой: есть ли у кого опыт с МРТГ и большим количеством хостов? Как поведет себя сабж при 2к хостов, на которые ему нужно будет рисовать графики?

Может и глупый вопрос, но не знаю что придумать, как лучше рисовать графики поюзерно, попортово. И не с биллинга брать счетчики, а именно или с портов свитчей, или с ВиФиЦПЕшек напрямую тем же SNMP. Бо бывает непонятный кратковременный трафик во влане, который до бордера не долетает и отследить сложно тем же tcpdumpom. А увидев всплеск трафика на кокретном порту/CPE круг поисков сужается.

от 2k графиков серверу скорее всего будет "тяжко"

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

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

 

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

Відредаговано 2015-10-13 11:09:24 Lynx100

[twg 871]

 

Вопрос такой: есть ли у кого опыт с МРТГ и большим количеством хостов? Как поведет себя сабж при 2к хостов, на которые ему нужно будет рисовать графики?

Может и глупый вопрос, но не знаю что придумать, как лучше рисовать графики поюзерно, попортово. И не с биллинга брать счетчики, а именно или с портов свитчей, или с ВиФиЦПЕшек напрямую тем же SNMP. Бо бывает непонятный кратковременный трафик во влане, который до бордера не долетает и отследить сложно тем же tcpdumpom. А увидев всплеск трафика на кокретном порту/CPE круг поисков сужается.

от 2k графиков можна точно сказать что серверу будет "тяжко"

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

 

Сейчас у меня крутится скрипт, котрый берет по SNMP трафик со всех CPE с одной БС и забрасывает в RRD и тотже RRDtool рисует гифки. При последовательном обхоже около 70 цпе вся процедура занимает около 20 секунд. Если обход распаралелить, то будет быстрее. Но трабл с РРД в том, что он не правильно обрабатывает обнуление счетчиков и рисует нереальный пик. Так было при типе DS COUNTER. Переписал на тип DERIVE c min=0 и пока наблядаю. Просто смущает, что МРТГ сам обрабатывает такую коллизию, а ррд не умеет. ..

[sv-lex 38]

Смотрите в сторону Cacti. По-умолчанию опрашивает раз в 5 минут. Удобные шаблоны для разных устройств, недостающие можно поискать на форуме, импортируются просто. Нагрузки никакой практически. 50 хостов 1150 rrd файлов, P4 нагрузка 10%, но там еще нагиос и dns. Опрашивает за 20 сек, это с учетом того, что рисуются графики пингов.

[muff 114]

+1 за cacti.

Только в качестве поллера используйте spine, а не дефолтный cmd.php

Відредаговано 2015-10-13 13:13:52 muff

[Ajar 92]

2 twg  -  в свое время на мртг было под 300 графиков, как страшный сон сейчас вспоминаю !  Перешел на кактус, уже под 6к графиков. В кактусе можно настроить сбор данных по снмп как в мртг, примеров валом.

[Ruslik 27]

Плюсану за кактус.

Рисует много графиков, сервер на атоме жив пока.

[twg 871]

Спасибо, буду грызть кактус )

[martin 170]

ну кактус вообще то RRD тот же юзает ))

[АНТИдемпинг 31]

а чому не zabbix?

[kha0s 112]

Советовать заббикс там где есть сомнение в работоспособности mrtg? Хм.

[twg 871]

ну кактус вообще то RRD тот же юзает ))

Утром в своем скрипте изменил тип данный в DS с COUNTER на DERIVE и установил минимальное допустимое значение в 0 и за целый день либо ни один счетчик не переполнился, либо глюк с неправильной обработкой обнуления счетчиков не такой критичный и не так заметно на картинке графика. Понаблюдаю ещё пару дней, если все гуд, то сам по себе кактус и не нужен. Допишу скрипт, который с билинга будет гребсти хосты и буду складывать по ним счетчик в РРД. А рисовать графики можно и на лету в пару строчек кода на пхп.

А можно и spine попробовать заюзать без кактуса.

Відредаговано 2015-10-13 18:03:03 twg

[l1ght 377]

ну типо если много метрик снимать и много хостов тут graphite нужен, имхо

[Ромка 567]

ну типо если много метрик снимать и много хостов тут graphite нужен, имхо

А я за zabbix. Ему только рамы много надо, а так масштабируется и вдоль и в поперек.

ПС: [offtop] Лайт поздравляю с выздаровлением ножки), и c 1100 сообщением) [/offtop]

Відредаговано 2015-10-13 19:37:03 Ромка

[muff 114]

Zabbix функціональний "комбайн", вміє багато чого. Але їсть доволі багато ресурсів.

[kvirtu 315]

Zabbix функціональний "комбайн", вміє багато чого. Але їсть доволі багато ресурсів.

A cacti ?

[l1ght 377]

 

ну типо если много метрик снимать и много хостов тут graphite нужен, имхо

А я за zabbix. Ему только рамы много надо, а так масштабируется и вдоль и в поперек.

ПС: [offtop] Лайт поздравляю с выздаровлением ножки), и c 1100 сообщением) [/offtop]

 

пасибо за поздравление, но по теме:

zabbix даже не в 10 раз медленее графита, если правильно сделано, типо такой стори

 

 

 

Из особенностей:

1) carbon-writer любит ssd'шки, поэтому лучше держать базу графита на ssd (это в общем касается даже rrd).

2) carbon написан на питоне и, видимо, не самым лучшим образом, поэтому один инстанс writer'а (и relay'а) может прокачать примерно 250 тысяч точек в минуту (при условии что диск столько запишет).

3) carbon-relay призван делать роутинг (притом с consistent hashing'ом, чтобы одни и те же метрики всегда попадали одному и тому же writer'у), но у него те же проблемы что и у остальных carbon-демонов. Как решение - можно взять carbon-relay-ng (https://github.com/graphite-ng/carbon-relay-ng), он написан на Go и сильно быстрее (один инстанс может прокачать до 1.2млн метрик в минуту, что уже близко к разумному пределу на Ceres'е). Плюс еще есть места, где его можно оптимизировать и выжать больше. но у него нет consistent hashing'а (пока), поэтому прийдется или впиливать руками или ждать пока впилят за тебя (есть в ближайших планах)

4) Касательно морды - есть штатная морда, graphite-web, она довольно жирная (Django и все такое), есть альтернативная - graphite-api, но она не умеет ceres (нужно плагин портировать), сам церес нужно подпачить слегка (есть PR https://github.com/dkulikovsky/ceres/pull/2 на это), он на flask'е, тоньше, быстрее и чище (и у него очень адекватный апстрим, всегда можно поговорить с разработчиком и хорошие PRы разработчик быстро принимает).

Но вся эта штука очень любит CPU - что graphite-web/graphite-api, что carbon. И узкое место будет именно в процессоре (при наличии ссд дисков конечно же).

Как альтернативную базу данных для графита, можно взять influxdb (influxdb.com + https://github.com/vimeo/graphite-influxdb), на запись оно работает довольно адекватно (хотя возможно есть баги), но вот чтение данных лучше делать как можно реже (оно очень медленно данные читает, вот прям очень-очень).

Касателньо конкретных цифр - яндексовая схема вида: haproxy -> 8x carbon-relay -> 12x carbon-writer выжимает примерно 1-1.5млн точек в минуту на 2x e5-2660, 64GB Ram, Raid 10 из 4x300GB Intel 520 (SSD). Замена carbon-relay на carbon-relay-ng позволит пиково получать примерно 4-5 млн точек в минуту (примерно столько же и на influxdb), но постоянная скорость будет ограничена диском уже (примерно на уровне 2 млн, может даже меньше), у influx'а - 4млн точек в минуту легко будет писаться почти что сколь угодно долгое время (я сам тестировал на более слабом железе, примерно 12 часов записи по 4млн в минуту оно выдерживало). Только вот прочитать эти данные будет сложновато.

И еще небольшой UPD: graphite-api конечно быстрый, но с очень большим колличеством запросов тоже плохо справляется. Он прекрасно (с виду) работает с pypy-2.4, притом прекрасно = в несколько раз быстрее.

Запустил сборщик для RX/TX с 640 устройств. Это 43358 метрик. В среднем они собираются за 15 секунд. В карбон передаются за 2,5 секунды. Интервал опроса 300 секунд.

Параметры карбона:

MAX_CACHE_SIZE = inf - чтобы не надо было дозировать метрики (иначе получается переполнение и соединение виснет)

MAX_UPDATES_PER_SECOND = 2000

MAX_CREATES_PER_MINUTE = 2000

Теперь посмотрим на графики. Синяя линия - создание файлов метрик. Зеленая - обновление. Красная - принятые метрики. Из-за способа отрисовки кажется, что данные передаются в течении двух минут, но на деле там 2-3 секунды.

С красной линией все понятно - всегда передается одинаковое кол-во метрик. А вот с двумя другими интересно. Судя по синей линии, карбон не спешит создавать все сразу. 2000 в минуту это где-то 33 в секунду, но на графиках линия падает до 0, а не идет параллельно горизонту. Обновление метрик (зеленая линия) происходит только для созданных файлов. Где то через 75 минут все файлы создаются, тогда красная и зеленая линии начинают совпадать.

Делаю снимки файлов раз в несколько секунд и смотрю что обновилось:

2014-11-04 18:12:47 - 0 - после запуска ничего не обновилось

2014-11-04 18:13:01 - 12 - 12 метрик самого карбона

2014-11-04 18:13:14 - 12 - // -

2014-11-04 18:13:26 - 3545 - пошло обновление

2014-11-04 18:13:40 - 25673

2014-11-04 18:13:53 - 43370 - все метрики обновлены. 43358 + 12 = 43370

2014-11-04 18:14:08 - 43370

2014-11-04 18:14:22 - 43370

Відредаговано 2015-10-14 13:55:06 l1ght

[supportod 1]

Вопрос такой: есть ли у кого опыт с МРТГ и большим количеством хостов? Как поведет себя сабж при 2к хостов, на которые ему нужно будет рисовать графики?

Может и глупый вопрос, но не знаю что придумать, как лучше рисовать графики поюзерно, попортово. И не с биллинга брать счетчики, а именно или с портов свитчей, или с ВиФиЦПЕшек напрямую тем же SNMP. Бо бывает непонятный кратковременный всплеск трафика во влане, который до бордера не долетает и отследить сложно тем же tcpdump'oм. А увидев всплеск трафика на кокретном порту/CPE круг поисков сужается.

 

Сacti пишет овер 5k rrd на железе - двуядерный атлон и 4ГБ памяти, софт RAID из двух винтов.

[XNeo 0]

Четыре вот таких графика(часы, дни, месяцы) для каждого пользователя (1700шт) + для каждого тарифа (20 шт)

 

CPU: Старенький Pentium Dual-Core 2x2.6GHz

Потребление ОЗУ меньше 100мб.

Загрузка CPU меньше 1%.

 

Сбор данных через NetFlow. 

Відредаговано 2015-12-14 22:16:56 XNeo

[philippe46 12]

Cacti для всего?! MRTG? Мать моя женщина! Не насилуйте труп: на дворе почти 2016 год.

Разделите вашу задачу на три части:

1. Сбор (читка и передача дальше) метрик поручите прекрасному collectd. Он умеет ТОЛЬКО собирать метрики с разных источников и отсылать их в удобном формате кому-то: на всякие HTTP-службы, Graphite, RRD, RRDCached, InfluxDB, другой collectd, а также на - другие программы с поддержкой протокола collectd см. https://collectd.org/wiki/index.php/Binary_protocol .

2. Хранение метрик поручить либо RRD либо InfluxDB. RRD - хорош, быстр да и уже давно стандарт, но не обладает гибкостью.

Если Вы хотите не просто графики рисовать, но как-то произвольно анализировать наборы стат. данных, то вам на InfluxDB. 

Да, издержки на IO у него повыше, но его возможности стоят того.

3. Визуализация. Я думаю, что тут все очевидно. Есть RRDGraph и прямые ручки, есть CGraphz (полное дерьмо, если честно между нами и по секрету), Cacti как вариант - только для визуализации (читай http://forums.cacti.net/about28169.html)

Чтобы получать визуально данные из InfluxDB советую Grafana. Там необходимо будет запросами доводить графики до себя (читай матан и статистику).

 

Такое разделение поможет Вам собрать схему которая Вам нужна. Если у Вас будет очень большая сеть, то вы сможете разнести сбор и хранение и обработку метрик на разные узлы, что намного лучше вашей некросхемы "все-в-одном".

 

Graphite не советую: он жестко вешает систему в IO-wait при использовании HDD. И фу-фу-фу Python, на который я сквозь пальцы смотрю, ибо crap для серьезных нагрузок.

[leshik 13]

Cacti для всего?! MRTG? Мать моя женщина! Не насилуйте труп: на дворе почти 2016 год.

Разделите вашу задачу на три части:

1. Сбор (читка и передача дальше) метрик поручите прекрасному collectd. Он умеет ТОЛЬКО собирать метрики с разных источников и отсылать их в удобном формате кому-то: на всякие HTTP-службы, Graphite, RRD, RRDCached, InfluxDB, другой collectd, а также на - другие программы с поддержкой протокола collectd см. https://collectd.org/wiki/index.php/Binary_protocol .

2. Хранение метрик поручить либо RRD либо InfluxDB. RRD - хорош, быстр да и уже давно стандарт, но не обладает гибкостью.

Если Вы хотите не просто графики рисовать, но как-то произвольно анализировать наборы стат. данных, то вам на InfluxDB. 

Да, издержки на IO у него повыше, но его возможности стоят того.

3. Визуализация. Я думаю, что тут все очевидно. Есть RRDGraph и прямые ручки, есть CGraphz (полное дерьмо, если честно между нами и по секрету), Cacti как вариант - только для визуализации (читай http://forums.cacti.net/about28169.html)

Чтобы получать визуально данные из InfluxDB советую Grafana. Там необходимо будет запросами доводить графики до себя (читай матан и статистику).

 

Такое разделение поможет Вам собрать схему которая Вам нужна. Если у Вас будет очень большая сеть, то вы сможете разнести сбор и хранение и обработку метрик на разные узлы, что намного лучше вашей некросхемы "все-в-одном".

 

Graphite не советую: он жестко вешает систему в IO-wait при использовании HDD. И фу-фу-фу Python, на который я сквозь пальцы смотрю, ибо crap для серьезных нагрузок.

 

 Из опыта: именно эта схема (collectd->influxDB->grafana) работает на  ~100*24 портах+еще ~1000 всякой ерунды. По ключевым словам много доки на habrahabr.ru

[Phsm 19]

Только хотел ответить про collectd Мегабыстрая штука, только я пишу в graphite, а не influxdb.

[bos 39]

Коллеги, а как вы пишите из collectd 5.4.1 (snmp)  type table  в инфлакс 0.9.6, у меня в упор не передаются значения. если не таблицу или одно значение - все хорошо, если все порты с железки, то ничего не прилетает(   в логе collectd чисто. можно примерчики? Спасибо  

Делаю по аналогии с
<Data "traffic">

     Type "if_octets"

     Table true

     Instance "IF-MIB::ifDescr"

     Values "IF-MIB::ifInOctets" "IF-MIB::ifOutOctets"

     Scale 8

  </Data>
в хост блоке естественно traffic есть.

 

Был невнимателен, вопрос снимается как глупый

добавились два новых замера

show measurements;

snmp_rx

snmp_tx

 

Відредаговано 2016-02-17 19:32:14 bos