Комментарии 36
Используем для мониторинга своих серверов — очень приятная вещь. Если готовых плагинов не хватает, то пишутся достаточно просто. Cacti лично мне нравиться именно своим GUI — очень удобно. Пробовали ковыряться с нагиосом для графиков — не понравилось. Так и повелось — нагиос следит что бы все работало, а какти строит красивые графики и обеспечивает удобные их анализ.
PS. Так же пробовали Munin — понравился меньше чем Cacti
PS. Так же пробовали Munin — понравился меньше чем Cacti
отличная статья, не могли бы вы объяснить более детально бешскрипт?
что именно Вас интересует?
строчка 1. ну… баш скрипт!
строчка 2. идем в папку в которой будем работать — ибо по крону рабочая папка не совпадает с папкой где скрипт лежит
строчка 3. узнаем текущую дату, оставляя минуты нулями — то есть дата первой минуты текущего часа
стчрока 4. имя файла-флага для определения устарел ли кэш со страницей или нет
строчка 5. проставляем дату изменения файла-флага равной той, что создали в строчке 3.
стчроки 6-8. Если кэш-файл(index.html) отсутствует либо старее чем файл-флаг(то есть закачан более чем один час назад), то закачиваем по новому файл с яндекса
стчрока 9. пишем в переменную day первый аргумент
строчка 10. тут сложно объяснить на пальцах, нужно видеть струтуру файла. Ищем элементы таблицы с датой, грепаем по ним, находим сами числа — будет список подряд идущих числе(нпаример за сегодня — 17 18 19 20 21 22 23 — посмотрите страничку, поймете о чем я) и находим нужное нам число, с помощью grep -n(номер строчки) определяем порядковый номер нужного числа в списке.
стчрока 11. pos+1 кажется потому что в grep и sed нумерация идет… или из за струтуры файла… я думаю если очень заинтересует, простым echo после каждой строчке можно прояснить этот вопрос)
стчрока 12. грепаем блоки с температурой, с помощью sed берем нужную стчроку (sed -n «12p»)
стчрока 13. Profit
P.S. grep -A1 — найти строчку и вывести еще следующую
Как то так… разъяснил что к чему?
строчка 1. ну… баш скрипт!
строчка 2. идем в папку в которой будем работать — ибо по крону рабочая папка не совпадает с папкой где скрипт лежит
строчка 3. узнаем текущую дату, оставляя минуты нулями — то есть дата первой минуты текущего часа
стчрока 4. имя файла-флага для определения устарел ли кэш со страницей или нет
строчка 5. проставляем дату изменения файла-флага равной той, что создали в строчке 3.
стчроки 6-8. Если кэш-файл(index.html) отсутствует либо старее чем файл-флаг(то есть закачан более чем один час назад), то закачиваем по новому файл с яндекса
стчрока 9. пишем в переменную day первый аргумент
строчка 10. тут сложно объяснить на пальцах, нужно видеть струтуру файла. Ищем элементы таблицы с датой, грепаем по ним, находим сами числа — будет список подряд идущих числе(нпаример за сегодня — 17 18 19 20 21 22 23 — посмотрите страничку, поймете о чем я) и находим нужное нам число, с помощью grep -n(номер строчки) определяем порядковый номер нужного числа в списке.
стчрока 11. pos+1 кажется потому что в grep и sed нумерация идет… или из за струтуры файла… я думаю если очень заинтересует, простым echo после каждой строчке можно прояснить этот вопрос)
стчрока 12. грепаем блоки с температурой, с помощью sed берем нужную стчроку (sed -n «12p»)
стчрока 13. Profit
P.S. grep -A1 — найти строчку и вывести еще следующую
Как то так… разъяснил что к чему?
Спасибо! Некогда хотел сделать что-то подобное, но не хватило терпения разобраться со всей структурой. Теперь есть стимул всё-таки разобраться :)
прикольно! надо будет заюзать кактус (хотя рисовать графики через RRD напрямую тоже не сложно)
по поводу баш-скрипта: я где-то читал, что количество пайпов надо всеми способами уменьшать, чтобы снижать загрузку на систему (все относительно конечно же и в данном случае наверно не существенно, но просто на будущее...).
т.е. вместо
лучше писать так:
:_)
по поводу баш-скрипта: я где-то читал, что количество пайпов надо всеми способами уменьшать, чтобы снижать загрузку на систему (все относительно конечно же и в данном случае наверно не существенно, но просто на будущее...).
т.е. вместо
cat index.html | grep "<th class=\"weekday\">" -A1 | ...
лучше писать так:
grep "<th class=\"weekday\">" index.html -A1 | ...
:_)
> для получения этой величины и сказать Cacti что нужно запускать poller
А вот… интересная тема для обсуждения…
Почему-то все системы мониторинга работают по принципу опроса данных. А что если мне нужно наоборот — скармливать данные системе мониторинга. Причём безболезненно.
Вот пример: есть у нас скрипт регистрации пользователей я хочу наблюдать за динамикой этой операции. Я в скрипте добавляю строчку типа IncrementCounter («registers»). Желательно даже предварительно нигде не регистрировать «счётчик» и чтобы накладных расходов было минимум. Супер если бы система мониторинга вообще переваривала эти данные на сепарированной машине в потоке…
Глобально все системы мониторинга наблюдают за внешними показателями, а хочется их как бы вживлять в проект, в код, ещё на этапе разработки.
Ваши мысли — есть что-то похожее?
А вот… интересная тема для обсуждения…
Почему-то все системы мониторинга работают по принципу опроса данных. А что если мне нужно наоборот — скармливать данные системе мониторинга. Причём безболезненно.
Вот пример: есть у нас скрипт регистрации пользователей я хочу наблюдать за динамикой этой операции. Я в скрипте добавляю строчку типа IncrementCounter («registers»). Желательно даже предварительно нигде не регистрировать «счётчик» и чтобы накладных расходов было минимум. Супер если бы система мониторинга вообще переваривала эти данные на сепарированной машине в потоке…
Глобально все системы мониторинга наблюдают за внешними показателями, а хочется их как бы вживлять в проект, в код, ещё на этапе разработки.
Ваши мысли — есть что-то похожее?
Готового — нет.
знаете, не факт. Например syslogng-php нечто подобное делает.
Спасибо, посмотрю.
в нагиос это называется пассивные проверки и делается с помощью ncsa
nagios.sourceforge.net/docs/3_0/passivechecks.html
nagios.sourceforge.net/docs/3_0/passivechecks.html
# An external application checks the status of a host or service.
# The external application writes the results of the check to the external command file.
# The next time Nagios reads the external command file…
Это далеко не то. Это всё та же попытка превратить push в poll, не более того.
Хочется иметь всё это on-the-fly, в потоке, без записи в промежуточное хранилище (файл).
# The external application writes the results of the check to the external command file.
# The next time Nagios reads the external command file…
Это далеко не то. Это всё та же попытка превратить push в poll, не более того.
Хочется иметь всё это on-the-fly, в потоке, без записи в промежуточное хранилище (файл).
сделайти прослойку, например БД. Вы пишите в БД события, далее делаете скрипт, который вытаскивает число событий за предыдущие N минут(N можно настроить произвольным, например 1 минута). Будете видеть динамику операции. Я так делал не раз — всем был доволен.
> прослойку, например БД
Нет, БД однозначно не вариант.
Такая система во многом нужна для обнаружения неких threshold-ов, порогов срабатывания, пиковых нагрузок, аномалий и т.д. При использовании БД вы обнаружите всё это в самой системе мониторинга :)
> далее делаете скрипт, который вытаскивает число событий за предыдущие N
т.е. превратите push в poll :)
Меня бы устроила примерно следующая схема:
* Сервер системы мониторинга со встроенным специализированным хранилищем (естественно не-sql), принимающий данный по сети со всех машин + фронт.
* Прокси-сервер, собирающий данные на локальной машине отовсюду и отправляющий эти данные со сжатием, заданной дискретностью и т.д. на сервер мониторинга.
* Тулкиты/модули/библиотеки для основых языков программирования, позволяющие произвести «выброс» данных на локальный прокси сервер без увеличения нагрузки на систему и предельно простым способом для программиста.
Так, чтобы работа с подобными «счётчиками» была не сложнее записи строчки лога.
*
Нет, БД однозначно не вариант.
Такая система во многом нужна для обнаружения неких threshold-ов, порогов срабатывания, пиковых нагрузок, аномалий и т.д. При использовании БД вы обнаружите всё это в самой системе мониторинга :)
> далее делаете скрипт, который вытаскивает число событий за предыдущие N
т.е. превратите push в poll :)
Меня бы устроила примерно следующая схема:
* Сервер системы мониторинга со встроенным специализированным хранилищем (естественно не-sql), принимающий данный по сети со всех машин + фронт.
* Прокси-сервер, собирающий данные на локальной машине отовсюду и отправляющий эти данные со сжатием, заданной дискретностью и т.д. на сервер мониторинга.
* Тулкиты/модули/библиотеки для основых языков программирования, позволяющие произвести «выброс» данных на локальный прокси сервер без увеличения нагрузки на систему и предельно простым способом для программиста.
Так, чтобы работа с подобными «счётчиками» была не сложнее записи строчки лога.
*
ну БД это не обязательно SQL в принципе. но не будем о терминологии) Посмотрите в сторону syslogng — прокси на рабочих машинах, данные уходят на сервер. и там и там — фильтры. Что делать с данными — на ваше усмотрение. Можно в БД, и тогда получится аля syslogng(я ссылку выше приводил), можно писать какое то свое хранилище не-sql(мне в голову только файлы приходят… ну или демона аля memcache заюзать). Поддержка для всех популярных языков имеется.
Почему-то все системы мониторинга работают по принципу опроса данных. А что если мне нужно наоборот — скармливать данные системе мониторинга. Причём безболезненно.
Приехали. Тыщу лет баяну. В zabbix есть специальный тип данных Trapper. Ему можно присылать данные через клиент zabbix_sender. Берете пишете свой клиент и получаете что надо.
> Приехали. Тыщу лет баяну.
Без пафоса никак? Религия обязывает?
> Ему можно присылать данные через клиент zabbix_sender.
Да, действительно, решение очень похоже на описанное выше.
Правда пока непонятен вопрос с хранилищем (насколько я вижу там sql-based) и прокси-сервером.
Попробую.
Без пафоса никак? Религия обязывает?
> Ему можно присылать данные через клиент zabbix_sender.
Да, действительно, решение очень похоже на описанное выше.
Правда пока непонятен вопрос с хранилищем (насколько я вижу там sql-based) и прокси-сервером.
Попробую.
почему Вас так пугает sql-based решения? SQL вполне большую нагрузку может выдерживать при грамотной организации.
Без пафоса никак? Религия обязывает?
Не я говорил:
все системы мониторинга работают по принципу опроса данных.
Правда пока непонятен вопрос с хранилищем (насколько я вижу там sql-based) и прокси-сервером.
Прокси сервером может выступать сам же сервер. Он умеет работать в нескольких режимах. То что там sql это не минус, это плюс. К тому что как опрашивать и сколько хранить там настраивается в широких пределах.
Можно отправлять данные через syslog. Для кактуса есть плагин syslog, которому через syslogng скармливаются данные. У меня так мониторится очень много показателей, вроде состояния линков, bgp, ошибок авторизации и прочее.
Если есть желание мониторить именно погоду, то тогда вам ко мне :)
mycli.me/
mycli.me/
а выпустите в инет эту красоту, полюбопытствовать )
я для себя день назад :) сделал почти такую же мурзилку в картинках для scripts+cacti
1. мониторить глазами сотни значений — не вариант, какие существуют системы с элементами самообучения, которые бы обнаруживали отклонение/деградацию показателей от нормы?
2. да, я тож думаю сейчас где погоду для сайта тырить, вроде как с яндекса не совсем законно))
2. да, я тож думаю сейчас где погоду для сайта тырить, вроде как с яндекса не совсем законно))
1. Можете более подробно объяснить? чему должен обучаться такая система?
вот вы увидите, если вдруг какой-нибудь процесс начнет отжирать все больше и больше памяти? (мгновенный скачек покахзателей)
а если это растягивается на месяцы? (деградация показателей)
такая система должна помнить какие были показатели допустим год назад, и не просто тупо сравнивать с текущими а искать именно аномалии
а если это растягивается на месяцы? (деградация показателей)
такая система должна помнить какие были показатели допустим год назад, и не просто тупо сравнивать с текущими а искать именно аномалии
если процесс будет отжирать все больше и больше памяти я увижу. А если растягивается на месяцы, то наверняка. Конечно, система может посчитать отношение средних за разные периоды, прикинуть погрешность и проч… но надо ли? мне, честно говоря, в голову не приходит где это может помочь.
Сделать оповещение по достижению величины какого нибудь предела — да, это полезно. А в остальном человека врядли заменишь.
Сделать оповещение по достижению величины какого нибудь предела — да, это полезно. А в остальном человека врядли заменишь.
скрипт я написал, но он на удалённой машине, хотелось бы то, что он пишет мониторить (там один процесс/ два скрипта — память и cpu), как можно получать данные в cacti?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг погоды или Cacti HowTo