Cacti

[B@F]

Дорого утра всем.

Существует много систем мониторинга. Сначала я знал только MRTG и юзал ее. Система очень хорошая, надежная, но мало функциональная, как оказалась после установки Cacti+Plagin Arhitectur+куча плагинов. Но 1 одну из самых важных функций в кактусе я так и не сделал - это как сделать так что бы кактус писал скорости как в мртг: 800(80%), кактус проценты не пишет, а нужно. Может кто чем помочь?

[Yuriy_Y]

Оффтоп:
Я обычно мунин использую, только он проц грузит сильно. Процы класса Атома и Цаплерон на 478-м сокете почему-то пики до 100% доходят, хотя и плагинов не много подключенных. Все никак руки не доходят, поставить на них кактус попробовать. А вот Атлоны, даже младшие, на AM2 и AM3 почти и не замечают этой нагрузки.

[B@F]

Вот  тут нашел темплайт для кактуса, что бы кактус дописывал проценты. В общем то легко и просто, но дело в том, что проценты пишутся не верно

440.6 Mb/s - 5.51% а интерфейс гиговый. Не пойму в чем дело.
_____________________________________________________________________________________________

Копец, я разобрался с процентами. Дело в том, что в темплейте значения процентов делает  CDEFs функция. Оказалось, что она какти по умолчанию берет данные не в битном значении, а в байтном. И потому темплайт переводил значения процентов из байт. Отсюда и странные значения процентов. Я создал свою  CDEFs функцию, в которая сначала переводит из байт/с в бит/с, а затем вычесляет проценты. Подправил темплейт на новую функцию и все получилось. Если кому надо вот ссылка . Я так понял такой темплейт есть только у меня, т.к. я его сделал, ну и у всех посетителей этого форума   http://linuxforum.kz/public/style_emoticons/<#EMO_DIR#>/blush.gif\' class=\'bbc_emoticon\' alt=\':blush:\' /> кому он потребуется конечно.

[B@F]

Оффтоп:
Я обычно мунин использую, только он проц грузит сильно. Процы класса Атома и Цаплерон на 478-м сокете почему-то пики до 100% доходят, хотя и плагинов не много подключенных. Все никак руки не доходят, поставить на них кактус попробовать. А вот Атлоны, даже младшие, на AM2 и AM3 почти и не замечают этой нагрузки.

Про нагрузку теперь и я могу сказать. Сейчас в кактус заведено больше 1000 устройств по 20-300 графиков, в зависимости от устройства. Среднее значения нагрузки от 0,5 до 1 и я думаю это очень мало. В момент опроса устройств подпрыгивает загрузка CPU: php - 40% spine - 30% примерно. Раз в сутки кактус делает реиндекс и в это время средняя загрузка вырастает на 1,5-2 но это тоже ни как не сказывается на работу сервера. А вообще щас он крутится на целероне с 2-я ядрами, гигом оперативки(потребляет менее 100 метров на ос debian 6), 80 hdd и ему вполне хватает. Я даже запихнул туда виртуалбокс, поднял на нем заббикс 2 и ужаснулся. Заббиксу для мониторинга всего 2-х хостов не хватило виртуалки, он жутко тормозил. Так что думаю еще очень очень долго будет стоять кактус и делать свою работу, пока телеком не развалится совсем или я сам не уволюсь заранее   .

[B@F]

Только рассказал про нагрузку как бац и все ухудшилось в разы. Я проводил эксперемены и так получилось, что база кактуса за ночь увеличилась на с 500-1000 метров до 5,8 гигов. Жесть, учитывая, что это все текстовая информация из syslog. Теперь раз в 5 минут получаю следующее

Код [Выделить] Expand

top - 17:11:14 up 1 day,  7:31,  2 users,  load average: 2.74, 1.35, 1.12
Tasks: 112 total,   1 running, 110 sleeping,   1 stopped,   0 zombie
Cpu(s):  8.6%us,  4.9%sy,  0.0%ni, 30.3%id, 54.4%wa,  0.3%hi,  1.4%si,  0.0%st
Mem:   1024040k total,  1002940k used,    21100k free,    20644k buffers
Swap:  1952760k total,       48k used,  1952712k free,   776116k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP COMMAND                                                                
 1277 mysql     20   0  151m  52m 3172 S   25  5.3 118:18.52  99m mysqld                                                                
 1072 root      20   0 39056 1980 1084 S    0  0.2   0:09.45  36m rsyslogd                                                              
 1504 root      20   0 41196 8800 3372 S    0  0.9   0:03.55  31m apache2                                                                
12234 www-data  20   0 47484  15m 3696 S    0  1.5   0:00.31  31m apache2                                                                
12157 www-data  20   0 47620  15m 3796 S    0  1.6   0:00.99  30m apache2
мускуль жеско грузит винт, тот не успевает и грузится вся система до load average:6 бывает доходит(проц 2 ядра целерон).

Кто подскажет при таком размере БД это нормально или что-то нужно менять?

Еще не понятно почему в верху свап 48К, а процесс мускуля и другие показывает 98 и т.д метров. В чем прикол не пойму

Код [Выделить] Expand

free -k
             total       used       free     shared    buffers     cached
Mem:       1024040    1001000      23040          0      21528     777900
-/+ buffers/cache:     201572     822468
Swap:      1952760         48    1952712

[НаРазДва]

Кто подскажет при таком размере БД это нормально или что-то нужно менять?

Конечно не нормально. В общем-то, мускуль должен использоваться кактусом по-минимуму.

Ошибки-то какие? Думаю таймауты по опросу девайсов?

[B@F]

Конечно не нормально. В общем-то, мускуль должен использоваться кактусом по-минимуму.

Ошибки-то какие? Думаю таймауты по опросу девайсов?

В стандарте то по минимуму, но у меня куча плагинов и вся трабла произошла из-за плагина syslog. Так например таблица syslog весит 4,8 гига. Я выставил в настройках отчистить ее через 3 дня, так что в пятницу база станет нормальной, не хочу через phpmyadmin лезть туда, пусть само сделает.


Вопрос в другом, виноват в этом винт(или с ним связанное) или какой винт не ставь при таком размере БД все равно будет кака?

П.С. Использую Cacti+Plugin(syslog,thold,Weathermaps,monitor), Кактус не только строит графики, он следит за их уровнями, собират с железок(серваки, маршрутизаторы, коммутаторы) логи через syslog(благо это стандарт везде), это дело все обрабатывается и прилетает на почту в случаи проблемы. А весь косяк произошел по тому, что я включил дебаг(делал один скриптик, который не работал), в дебаге было слово "warning", для суслога это правило, которое он обрабатывает и генирит аварию. Так это вот сообщение варнинг и зацыклилось. Оно каждые 5 минут повторялось десятки тысяч раз, пока не кончалась вся виртуальная память и процесс php_syslog не завис, при этом он и создал нереально большую БД. load average тогда был больше 16 в каждом интервале.

[НаРазДва]

Код [Выделить] Expand

top - 17:11:14 up 1 day,  7:31,  2 users,  load average: 2.74, 1.35, 1.12
[size=2]Cpu(s):  8.6%us,  4.9%sy,  0.0%ni, 30.3%id, [b]54.4%wa[/b],  0.3%hi,  1.4%si,  0.0%st[/size]


[/size]

вот то что 54% wait - означает простой проца и вероятнее всего из-за юзания в это время харда.
в это время надо еще снять показания иостата

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

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

PS: еще для увеличения производительности кактуса юзается спайн, может уже и стоит, но на всякий случай пишу,
тем более мониторятся 1000 девайсов.

[B@F]

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

Код [Выделить] Expand

----[ Changelog
   --- 1.22  ---
 bug: Correct issue where 'warning' is used instead of 'warn' on log insert
у меня стоял 1.21. Если да же перенести базу на другой сервак, то думаю операция ввода/вывода все равно перенесется на него. Видимо в этом случаи пора переходить на более мощную БД.