Мониторинг погоды или Cacti HowTo

    Этот пост можно было б начать по разному. Можно по делу: как необходима система мониторинга для поиска ошибок системы и как она помогает обнаружить узкие места. Но, сейчас лето, время отдыха на природе, и начну с того, как я решил узнать, как же часто менятеся прогноз погоды, с помощью популярного средства мониторинга Cacti. Под катом, о любопытный читатель!, тебя ждут рассказы о том как настроить мониторинг произвольных данных в Cacti, да не просто, а с картинками.


    Итак, за неделю до 19 июня(пятница, сами понимаете...) я начал смотреть, какая же будет погода? Смотрел у Яндекса — уж больно люблю я этих web-метеороголов. Погода менялась изо дня в день и мне стало интересно — а какова частота этих изменений? Ощущение погоды — вещь субъективная, а частота изменения прогноза на сайте — вполне измеряемая. Для этих целей я и решил использовать давно знакомое средство мониторинга Cacti. Статья предназначена в основном для программистов и системных администраторов, поэтому вопрос как поставить Cacti я не рассматриваю — эти люди либо уже поставили, либо справятся за 5 минут.
    Если вам интересно, как же часто меняется погода в прогнозах, но Cacti не интересен, проматывайте сразу в конец.

    Философия Cacti



    В основе Cacti лежит RRDTool — средство для работы с круговыми базами данных(RRD — round-robin database). Такие базы данных рассматривают временную координату состоящей из интервалов и записывают значения хранимого параметра в узлах таких интервалов, интерполируя в случае необходимости измеряемое значение. В одной базе данных может быть несколько RRA(round-robin archive) — этим достигается возможность хранить величину с разными интервалами времени(то есть с разной детальностью). Все эти операции Cacti скрывает от пользователя — все что нам нужно для того что бы наладить мониторинг величины — это предоставить средство для получения этой величины и сказать Cacti что нужно запускать poller(сборщик данных — вытаскивает данные из всех исчтоников и сохраняет их в ту самую RRD).

    Для начала, несколько слов о «сущностях», которые есть в Cacti. Они перечислены в левом меню в панели администратора:
    Итак:
    • Data Input Method — описывает то, как будут получаться данные. Основные способы — это SNMP(интересная тема, но не будем углубляться) и внешний скрипт — наш случай
    • Data Template — описывает как часто и с какими параметрами будет использоваться Data Input Method
    • Data Source — собственно RRD — хранит данные в файлике, создается на основе Data Template
    • Graph Template — шаблон графика. Можно описать в нем все детали отображения, кроме источника данных, а можно создать шаблонные параметры для цвета, прозрачности и прочего
    • Graph — собственно график. Приготовить можно смешав Data Source, Graph Template и указав все шаблонные параметры из Graph Template
    • Graph Tree — дерево графиков — если у вас графиков много(например мониторим 10 машин), то удобно создать иерархию
    • Есть еще много чего, но нам оно пока не понадобится.


    Скрипт для добычи погоды


    Чтобы узнать прогноз в данный момент времени, нужно закачать страничку с погодой яндекса и распарсить. Так как заранее мы не знаем, какой день нас интересует, сделам скрипт, который будет на вход принимать дату, на выходе выдавать температуру днем для нее. Обращаться каждые 5 минут к яндексу не стоит — врядли погода будет меняться так часто, поэтому сделаем так, чтобы скрипт кэшировал данные. Не буду особо углубляться здесь, просто приведу код скрипта:
    1. #!/bin/bash
    2. cd /usr/share/cacti
    3. flagdate=$(date "+%Y-%m-%d %H:00")
    4. flagfile=yandex.flag
    5. touch $flagfile -d"$flagdate"
    6. if [  ! -e index.html -o index.html -ot $flagfile ]then
    7.         wget http://weather.yandex.ru/27612/ -O index.html > /dev/null 2>&1
    8. fi
    9. day=$1
    10. pos=$(cat index.html | grep "<th class=\"weekday\">" -A1  |  grep -o "<th class=\"week[^0-9]*[0-9]*[^0-9]*</th>" |  grep -o "[0-9]*" | grep $day -n | grep -o "^[0-9]")
    11. let pos=pos+1
    12. res=$(cat index.html | grep "<tr class=\"data day\">" -A1 | grep -o "+[0-9]*" | sed -n "$pos""p")
    13. echo $res | grep -o "[0-9]*"


    Data Input Method


    Теперь, когда готов скрипт, его нужно куда-нибудь поместить(тут уж на ваше усмотрение). Я, например, положил в /usr/share/cacti/. Но, не забудьте учесть права на чтение и запуск(так же на создание файла) — poller будет запускать этот скрипт под пользоватлем www-data. Далее создаем Data Input Method:

    С помощью конструкции <day> делаем шаблонный параметр для метода ввода. Его нужно декларировать в списке Input Fields — чтобы Data Template знал о нем. Так же надо декларировать Output Field с именем res(имя не важно, так как у нас скрипт возвращает одно значение). Делать Data Input Method одно удовольствие, самое интересное впереди)

    Data Template


    Cоздаем Data Template:

    По умолчанию, нам предлагают ввести все параметры, но некоторые из них можно делегировать Data Source. В нашем случае, мы делегируем название и параметр для скрипта Data Source.

    Data Source


    Сделать Data Source тоже довольно просто:

    Выбираем только что созданный Data Template, имя хоста можно оставить пустым — в нашем случае все происходит на локальной машине. Пишем уникальное имя для Data Source(уникальность не требуется — это нужно что бы потом было легче вставлять в график) и день, который мониторим, в нашем случае 19е число. Имя файла вычисляется на основе id данного Data Source — но можно выбрать и свое(главное что бы не было коллизий).

    Graph Template


    Больше всего, пожалуй, настроек у графиков. Создаем новый Graph Template и видим:

    Сначала перечислены элементы графика — линии, легенды, прочие подписи. Далее шаблонные параметры(куда ж без них, это же шаблон). И потом идет куча параметров графика(я их не стал приводить на рисунке, они довольно очевидные — пределы, логарифмический масштаб и прочие ненужные в нашем случае вещи).
    Для начала создаем визуальные элементы(на риснуке настройки для графика, подписи можно сделать по аналогии):

    Оставляем имя Data Source и цвет пустыми — вынесем их потом в шаблонные паратмеры. Основные параметры визуального элемента:
    • Graph Item Type — тип элемента. В нашем случае будет AREA(собственно график) или GPRINT(подпись внизу графика — будем писать среднее и максимальное значения)
    • Consolidation Function — для графика должна быть AVERAGE, при создании подписей можно выбрать так же LAST/MAX/MIN
    • GPRINT Type — для подписей можно указать расширенный формат вывода. Свой формат можно создать в меню Graph Managment -> GPRINT Presets. Там обычный формат printf, ничего интересного)


    Когда визуальные элементы описаны, можно создать шаблонные параметры в списке Graph Item Inputs:

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

    Почти Финал


    Теперь, когда у нас есть источник данных и шаблон графика, создаем собственно график в меню Graph Managment:

    Если все сделано правильно, то график должен появиться сразу. Но есть одно НО — для отрисовки данных на графике должно пройти как минимум два polling`а — то есть, около 10 минут.
    В процессе настройки новых источников данных удобно пользоваться отдалочной информацией, которой в Cacti достаточно:
    • В /var/log/cacti/ много логов, в частности ошибки поллера poller-error.log
    • В меню System Utilities -> View Cacti Log File


    Финал


    Итак, то, ради чего были все пляски с бубном, динамика изменения прогноза погоды на 19 июня by Yandex.Погода:

    И, в качестве бонуса, динамика изменения курса доллара by ЦБ РФ(там есть пустой участок — это не символ кризиса, а я просто сервер вырубил):


    Что захотите замониторить вы — ошибки апача, количество юзеров, либо количество песен в вашем плэйлисте — вопрос фантазии. Удачи всем, кто заинтересуется, в экспериментах с Cacti!

    P.S. Пока я писал этот пост, Яндекс решил, что 19го будет еще холодней на два градуса… Но тем не менее погода от Яндекса очень классная, ее даже парсить было приятно.
    P.P.S. Cacti далеко не единственное средство для работы с RRD — есть Munin, Ganglia, Nagios и еще куча всего.
    Поделиться публикацией

    Похожие публикации

    Комментарии 36

      +2
      Используем для мониторинга своих серверов — очень приятная вещь. Если готовых плагинов не хватает, то пишутся достаточно просто. Cacti лично мне нравиться именно своим GUI — очень удобно. Пробовали ковыряться с нагиосом для графиков — не понравилось. Так и повелось — нагиос следит что бы все работало, а какти строит красивые графики и обеспечивает удобные их анализ.

      PS. Так же пробовали Munin — понравился меньше чем Cacti
        0
        от себя добавлю что пользовался Ganglia — до удобства Cacti далеко
        0
        отличная статья, не могли бы вы объяснить более детально бешскрипт?
          0
          что именно Вас интересует?
          строчка 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 — найти строчку и вывести еще следующую

          Как то так… разъяснил что к чему?
            0
            вы мой герой!
              0
              да ладно Вам… бывает приходится и пожестче писать…
          +1
          Спасибо! Некогда хотел сделать что-то подобное, но не хватило терпения разобраться со всей структурой. Теперь есть стимул всё-таки разобраться :)
            0
            прикольно! надо будет заюзать кактус (хотя рисовать графики через RRD напрямую тоже не сложно)

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

            т.е. вместо
            cat index.html | grep "<th class=\"weekday\">" -A1  |  ... 
            

            лучше писать так:
            grep "<th class=\"weekday\">" index.html -A1  |  ... 
            


            :_)
              0
              дада, просто так отлаживать удобнее) можно сказать моя вредная привычка
              0
              > для получения этой величины и сказать Cacti что нужно запускать poller
              А вот… интересная тема для обсуждения…
              Почему-то все системы мониторинга работают по принципу опроса данных. А что если мне нужно наоборот — скармливать данные системе мониторинга. Причём безболезненно.

              Вот пример: есть у нас скрипт регистрации пользователей я хочу наблюдать за динамикой этой операции. Я в скрипте добавляю строчку типа IncrementCounter («registers»). Желательно даже предварительно нигде не регистрировать «счётчик» и чтобы накладных расходов было минимум. Супер если бы система мониторинга вообще переваривала эти данные на сепарированной машине в потоке…

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

              Ваши мысли — есть что-то похожее?
                0
                Готового — нет.
                  +1
                  знаете, не факт. Например syslogng-php нечто подобное делает.
                    0
                    Спасибо, посмотрю.
                      0
                      в нагиос это называется пассивные проверки и делается с помощью ncsa
                      nagios.sourceforge.net/docs/3_0/passivechecks.html
                        0
                        # 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, в потоке, без записи в промежуточное хранилище (файл).
                  0
                  сделайти прослойку, например БД. Вы пишите в БД события, далее делаете скрипт, который вытаскивает число событий за предыдущие N минут(N можно настроить произвольным, например 1 минута). Будете видеть динамику операции. Я так делал не раз — всем был доволен.
                    0
                    > прослойку, например БД
                    Нет, БД однозначно не вариант.
                    Такая система во многом нужна для обнаружения неких threshold-ов, порогов срабатывания, пиковых нагрузок, аномалий и т.д. При использовании БД вы обнаружите всё это в самой системе мониторинга :)

                    > далее делаете скрипт, который вытаскивает число событий за предыдущие N
                    т.е. превратите push в poll :)

                    Меня бы устроила примерно следующая схема:
                    * Сервер системы мониторинга со встроенным специализированным хранилищем (естественно не-sql), принимающий данный по сети со всех машин + фронт.
                    * Прокси-сервер, собирающий данные на локальной машине отовсюду и отправляющий эти данные со сжатием, заданной дискретностью и т.д. на сервер мониторинга.
                    * Тулкиты/модули/библиотеки для основых языков программирования, позволяющие произвести «выброс» данных на локальный прокси сервер без увеличения нагрузки на систему и предельно простым способом для программиста.
                    Так, чтобы работа с подобными «счётчиками» была не сложнее записи строчки лога.

                    *
                      0
                      ну БД это не обязательно SQL в принципе. но не будем о терминологии) Посмотрите в сторону syslogng — прокси на рабочих машинах, данные уходят на сервер. и там и там — фильтры. Что делать с данными — на ваше усмотрение. Можно в БД, и тогда получится аля syslogng(я ссылку выше приводил), можно писать какое то свое хранилище не-sql(мне в голову только файлы приходят… ну или демона аля memcache заюзать). Поддержка для всех популярных языков имеется.
                    +1
                    Почему-то все системы мониторинга работают по принципу опроса данных. А что если мне нужно наоборот — скармливать данные системе мониторинга. Причём безболезненно.

                    Приехали. Тыщу лет баяну. В zabbix есть специальный тип данных Trapper. Ему можно присылать данные через клиент zabbix_sender. Берете пишете свой клиент и получаете что надо.
                      +1
                      > Приехали. Тыщу лет баяну.
                      Без пафоса никак? Религия обязывает?

                      > Ему можно присылать данные через клиент zabbix_sender.
                      Да, действительно, решение очень похоже на описанное выше.

                      Правда пока непонятен вопрос с хранилищем (насколько я вижу там sql-based) и прокси-сервером.

                      Попробую.
                        0
                        почему Вас так пугает sql-based решения? SQL вполне большую нагрузку может выдерживать при грамотной организации.
                          0
                          До какого-то определённого предела — да. SQL очень монстровый для подобных задач.
                          0
                          Без пафоса никак? Религия обязывает?

                          Не я говорил:
                          все системы мониторинга работают по принципу опроса данных.


                          Правда пока непонятен вопрос с хранилищем (насколько я вижу там sql-based) и прокси-сервером.

                          Прокси сервером может выступать сам же сервер. Он умеет работать в нескольких режимах. То что там sql это не минус, это плюс. К тому что как опрашивать и сколько хранить там настраивается в широких пределах.
                        +1
                        Можно отправлять данные через syslog. Для кактуса есть плагин syslog, которому через syslogng скармливаются данные. У меня так мониторится очень много показателей, вроде состояния линков, bgp, ошибок авторизации и прочее.
                        +1
                        Если есть желание мониторить именно погоду, то тогда вам ко мне :)
                        mycli.me/
                          0
                          да не, это всего лишь иллюстрация как с cacti работать) Но сайт вас хороший, мне понравился
                          0
                          а выпустите в инет эту красоту, полюбопытствовать )
                            0
                            что Вы имеет ввиду? я ее на хабр выпустил — любуйтесь на здоровье
                              0
                              я имею ввиду — чтоб понажимать, покрутить
                                0
                                не, не дам) тут все таки элемент приватности есть — у меня там куча всего мониторится) Вы поставьте себе Cacti и будет Вам счастье — вдоволь нанажимаетесь и покрутите
                            0
                            я для себя день назад :) сделал почти такую же мурзилку в картинках для scripts+cacti
                              0
                              1. мониторить глазами сотни значений — не вариант, какие существуют системы с элементами самообучения, которые бы обнаруживали отклонение/деградацию показателей от нормы?

                              2. да, я тож думаю сейчас где погоду для сайта тырить, вроде как с яндекса не совсем законно))
                                0
                                1. Можете более подробно объяснить? чему должен обучаться такая система?
                                  0
                                  вот вы увидите, если вдруг какой-нибудь процесс начнет отжирать все больше и больше памяти? (мгновенный скачек покахзателей)
                                  а если это растягивается на месяцы? (деградация показателей)

                                  такая система должна помнить какие были показатели допустим год назад, и не просто тупо сравнивать с текущими а искать именно аномалии
                                    +1
                                    если процесс будет отжирать все больше и больше памяти я увижу. А если растягивается на месяцы, то наверняка. Конечно, система может посчитать отношение средних за разные периоды, прикинуть погрешность и проч… но надо ли? мне, честно говоря, в голову не приходит где это может помочь.

                                    Сделать оповещение по достижению величины какого нибудь предела — да, это полезно. А в остальном человека врядли заменишь.
                                0
                                скрипт я написал, но он на удалённой машине, хотелось бы то, что он пишет мониторить (там один процесс/ два скрипта — память и cpu), как можно получать данные в cacti?

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое