Пользователь
0,0
рейтинг
11 мая 2010 в 02:18

Администрирование → collectd — собираем системную и пользовательскую статистику

Вопрос номер 0 — зачем?



В посте про pnp4nagios я писал «Nagios/Pnp4Nagios не замена комплексу сбора статистики о состоянии системы». Почему я так думаю? Потому что 1) статистика состояния системы обширна и включает множество показателей 2) не всегда есть смысл их мониторить, точнее генерировать алерты. Например, знать сколько сколько операций ввода-вывода делает диск или происходит переключений контекста неплохо, но почти никогда не критично. Ну и кроме того, Nagios просто не предназначен для этого. В данной статье я не буду делать полное описание системы, ограничусь лишь особенно интересными, с моей точки зрения, моментами.

Вопрос номер 1 — почему collectd?



Основные моменты почему из Munin, Cacti и прочих я выбрал collectd:
  1. Масштабируемость
  2. Легковесность
  3. Концепция — всё есть плагины
  4. Сбор и запись данных разделены
  5. Количество собираемых показателей
  6. Расширяемость




Общая схема работы collectd:
image

Масштабируемость

Для забора данных на центральную ноду(ы) используется push (в отличии от poll/pull в Cacti/Munin). Хранением данных может заниматься более чем одна нода и более того, можно разделить данные для хранения на разных нодах. Передачей данных занимается отдельный плагин — network.

Легковесность

Основной демон и плагины написаны на C и легко переживают 10ти секундный интервал сбора данных не нагружая систему.

Всё есть плагины

Сборщик данных о загрузке процессора — плагин. Информация о процессах — плагин. Запись и создание RRD/CSV — плагин.

Сбор и запись данных разделены

Данные можно как читать так и записывать. collectd разделяет плагины на «читателей» и «писателей». Те, что собирают информацию — читатели. После тогда как данные прочитаны, они отправляются к зарегистрированным писателям, которые в общем случае могут быть любыми. Наиболее «популярный» писатель это плагин network который отправляет данные на центральную ноду и RRDTool, под RRD как правило, и подразумевают статистику. Таким образом на ноде можно иметь как статистику в RRD, так и отправлять данные на дальнейшую обработку.

Количество собираемых показателей

На текущий момент существует более 90 базовых плагинов для сбора информации о системе и приложениях.

Расширяемость

Для добавления собственных источников данных существуют:
  1. Плагин exec в общем стандартный способ расширения — запускается программа, выводимые на stdout данные обрабатываются, но и здесь есть у collectd плюс — программа не обязана выходить после вывода значений, более того, рекомендуется запуститься и выводить данные в цикле, экономя ресурсы на запуске, что особенно актуально для скриптов.
  2. Python/Perl/Java биндинги — являются как читателями так и писателями, более подробное описание ниже


Расширямость за счёт биндингов (bindings)


Привязки, это по сути плагины для доступа к внутренним механизмам collectd из других языков и написания плагинов на них. На текущий момент поддерживаются Java/Perl/Python. Например, для Python'a интерпретатор запускается при старте collectd, содержится в памяти экономя ресурсы на запуск каждые несколько секунд и даёт возможность скриптам иметь доступ к API.

Так скрипт может зарегистрироваться как поставщик данных (reader) и/или как писатель (writer), зарегистрированная процедура будет вызываться каждый заданный в конфигурации интервал времени. Если с читателем всё понятно, то на писателя стоит обратить отдельное внимание — ваш скрипт легко может быть встроен для обработки всех проходящих данных, т.е. можно, например, сделать свою базу хранимых значений. Простой пример такого плагина на Python есть в документации проекта.

Интересные и полезные особенности плагинов


  • Перво-наперво мне понравился плагин disk — он из коробки умел мерять среднее время ответа диска:
    sdb disk access time


  • Плагин tail — позволяет читать файлы как tail(1) и при помощи регекспов выдергивать значения. Из отмачченых значений можно взять минимум/максимум/среднее, посчитать общее количество записей, просуммировать, например для nginx'a можно собрать статистику по времени ответа и реквестам для локейшна примерно так:
    1. Добавляем в лог nginx'a запись о времени обслуживания запроса:
      log_format maintime '$remote_addr - - [$time_local] reqtime=$request_time "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$host" upstream: $upstream_addr gzip:"$gzip_ratio"';

    2. Создаем запись в конфиге collectd:
      LoadPlugin tail
      <Plugin "tail">
              <File "/var/log/nginx/somesite.access.log">
                      Instance "nginxproxy"
                      <Match>
                              Regex " reqtime=([0-9]+\\.[0-9]+) "
                              DSType "GaugeMax"
                              Type "latency"
                              Instance "max responce time"
                      </Match>
                      <Match>
                              Regex " reqtime=([0-9]+\\.[0-9]+) "
                              DSType "GaugeAverage"
                              Type "latency"
                              Instance "avg responce time"
                      </Match>
                      <Match>
                              Regex ".*"
                              DSType "CounterInc"
                              Type "derive"
                              Instance "requests"
                      </Match>
              </File>
      </Plugin>
      


    Получаем графики общего количества запросов, максимального времени ответа и среднего времени ответа соответственно:
    image
    image
    image
    Схожими возможностями обладает плагин Curl
  • Плагин processes — может собирать информацию о количестве запущенных процессов попадающих под фильтр, количестве их тредов, размере занимаемой памяти, вводе-выводе, например:
    image
    В данном случае данные не совсем верны — это не дисковые операции read/write а вообще все, т.е. запись в сокет токже посчитана. Авторам я сообщил, возможно исправят в следующей версии.
  • плагин UnixSock позволят обмениваться данными при помощи простого текстового протокола, в частности можно получить или отправить значение счётчика. При помощи данного плагина возможна интеграция в Nagios.


Другие возможности


Фильтры и цепочки

Начиная с версии 4.6 появился механизм фильтров и цепочек, схожий с цепочками в iptables. При помощи данного механизма можно фильтровать данные, например отсекать значения у которых временная метка ( timestamp ) больше или меньше текущего времени на N, что может быть полезно если на каком-то сервере собьются часы. RRD попадет время из будущего и показания будут искажены.

Нотификация и threshholds

Базовая система извещений и пороговых значений появилась начиная с версии 4.3. Аналогично читателям и писателям, существуют «продюсеры» и «потребители» — первые производят извещения, вторые обрабатывают их. В частности плагин Exec может как реагировать на извещения, например запускать скрипт, так и передавать извещения из скриптов.

Сконфигурировав набор пороговых значений можно создавать извещения при отклонениях от нормы. Стоит, однако, понимать что данные базовые возможности не заменяют тот же Nagios. Для полноценной работы с Nagios можно использовать идущую в комплекте программу collectd-nagios которая позволяет опрашивать сокет созданный плагином UnixSock и возвращать результат в стандартном для Nagios'a формате

Недостатки


К недостаткам я могу причислить по большому счету только систему отображения графиков. Учитывая что с одного хоста может генерироваться около 200т счетчиков, визуализация становится не на последнем месте. Стандартный интерфейс collection3 неплох, но далек от совершенства. На текущий момент разрабатывается несколько независимых систем отображения графиков, но порекомендовать какой-либо пока не могу.

Прочее


Один из разработчиков Sebastian Harl (tokee) является мейнтейнером пакета в Debian посему в бэкпортах почти всегда есть последняя версия
coolcold @coolcold
карма
7,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (39)

  • 0
    штука довольно гибкая, но я так понимаю, ты ее используешь не как замену нагиосу, а в дополнение, чтобы рисовать графики?

    разводить и поддерживать несколько систем мониторинга не сильно ли геморное занятие? =)
    • 0
      Идеологически геморное, да, но сам знаешь, с заббиксами не судьба, поэтому вот так.
      А про рисовать графики да, как дополнение. Если я под 200+ проверок заряжу в нагиос на каждый хост, ему явно не полегчает. А так можно смотреть чего-нить типа — апач затыкался, ага, рама кончалась, а мускуль пух, на дисках росло время ответа, приходил какой-то чудо запрос :)
      • +2
        а почему с забиксами не судьба?
        • +1
          слушай, ну LVM месяц назад только поставили, куда там заббикс
          • +3
            заббикс в инсталляции/настройке прост как валенок, благо мануал просто шикарен — всё по шагам расписано. А функционала дает просто нереальное количество, сохраняя гибкость, удобство и (при правильной настройке БД и поллеров) высокую производительность.
            В общем — рекомендую.
            • 0
              не отрицаю его сильных сторон, но лично у меня пока с ним не сложилось
            • 0
              У заббикса была какая-то беда с количеством нод. Тут камрад год назад плевался — ему заббикс сервер повесил своими опросами. Да и mysql там выглядит лишним для простейших задач.
              • 0
                камрад ваш просто неудачник похоже. Заббикс запросто масштабируется до десятков тысяч нод, далеко не каждая проприетарная Enterprise-система на такое способна.
                А насчет «простейших задач» и mysql смотрите ниже , там есть табличка интересная.
                • 0
                  Лишнее звено просто.
                  • 0
                    между где?
                    rrdtool, к вашему сведению — тоже БД, циклическая.
                    Аллергия на mysql? Используйте sqlite — СУБД на плоских файлах, как rrdtool почти.
                    • +2
                      Бессмысленный оверхед. rrdtool — это конечно БД, а MySQL это уже СУБД с отдельным уходом за ней. А смысл?
                      • –3
                        Я так понимаю понятия «гибкость», «масштабируемость», «удобство сопровождения», «мощные инструменты построения отчетов, аудита, разделения прав, эскалация, графики SLA» вам не знакомы? Тогда ОК, продолжайте мониторить свои полтора сервера при помощи самосборных наколенных инструментов. Те же mysql, postgres или тем более sqlite нуждаются в уходе не больше чем rrd, только первичная установка/настройка.
                        • 0
                          Не надо передёргивать. Всё должно быть оптимально и эффективно. Причём тут «мощные инструменты построения отчетов, аудита, разделения прав, эскалация, графики SLA» и как мне тут поможет mysql я вообще не понял.
                          • –2
                            mysql тут вообще не при чем. А вот rrd и все обвесы к ней вам однозначно не помогут на в чем, кроме как в построении графиков средней паршивости. Называть это «системой мониторинга» некорректно, это просто примитивная «картинкорисовалка». Согласен, многим конторам а-ля SOHO хватит и этого.
                            • +1
                              Я вижу в нашем споре много ксенофобии и «энтерпрайз» яду и мало толку. Чем паршивость графиков из одних и тех же данных из MySQL и rrd будут отличаться? Причём тут система мониторинга и картинки? Вы отдаёте себе отчёт в разнице систем мониторинга и систем сбора статистики? А основные проблемы мониторинга статистической информации можете обрисовать? В каком месте там будет роль стораджа?

                              И что за «конторы а-ля SOHO»? Есть какие-то более расово верные конторы? Назовите их, пожалуйста.
                              • –4
                                SOHO (wiki)
                                Раз вы даже этого не знаете, то про остальное просто промолчу. Мы немного в разных весовых категориях, у меня есть опыт внедрения систем мониторинга в компаниях, где количество серверов превышает 2000, причем сервера совершенно разные — HPUX, AS/400, Linux, Windows, SCO. Я работал и с rrd-tool и его производными (munin, cacti, mrtg, etc.), и с системами Ent-класса (WhatsUp, HP OpenView, zabbix) вы знакомы судя по всему, только с простейшими решениями. Разговор не имеет смысла. Пожелаю вам успехов во всех начинаниях и приношу извинения, если чем обидел.
                                • 0
                                  вотсап жив? ничего ж себе!
                                  • –1
                                    живее всех живых, курилка. )
                                • 0
                                  Какой молодец, какой пример всем нам!
                                  Мерялка не сломается, меряться постоянно?
                                  • 0
                                    выдыхай, бобёр!
                                    • –1
                                      Не знаю, как у таких больших и серьёзных дядек, которые одним движением брови 2000 машин настраивают, но у нас, простых смертных, не принято незнакомым людям тыкать.
                                      • –1
                                        да что ты, мы — такие же люди. ;)
                  • 0
                    а можешь мне, по секрету, рассказать почему тут бд это лишнее звено?
                    • 0
                      Нет смысла. При этом утяжеляет хранилище и вообще становится тонким местом самой системы мониторинга, так как его надо поддерживать в состоянии высокой доступности. Что обычно не так просто. Из-за отсутсвия здравого смысла там такой базы — лишнее звено.
                      • 0
                        — ну мониторингу все равно нужно какое-то хранилище.
                        с этим то ты не споришь?

                        «тонким местом самой системы», «поддерживать в состоянии высокой доступности»
                        в конкретнос случае с mysql ничего не надо. оно ставится из пакета, и пашет до упора. только баккап в крон пропиши, что бы где-то была копия и логи обрезались.
                        • 0
                          Я имел ввиду конечно СУБД, а не сторадж.

                          Ты видимо не настоящий волшебник. MySQL не «пашет до упора» — очень капризная и ломкая вещь.
                          • 0
                            Тогда для начала очерти, что такое сторадж и чем он принципиально не субд (в рамках нашей задачи).

                            у меня есть их в количестве. самый старый года с 2003-4 пашет. чяднт?
            • 0
              жрет память как собака.
              Хотя по гибкости — да, могуч.
    • +1
      А это е несколько систем мониторинга. Одна система общего мониторинга, а вторая — сбор статистики с оповещениями.
  • 0
    Спасибо за статью, в избранном.
    Не видели ли Вы плагина/набора плагинов, который может давать телеметрию? К примеру: у меня на сервере 5 минут назад был Load Average 70: я хочу посмотреть, какие процессы работали 5 минут назад, кто спровоцировал нагрузку, кто занял весь IO, итд. Это умеет collectl, но телеметрия на perl будет отъедать порядка 30-40% ресурсов сервера.
    Лично мне collectd понравился, но кроме того, что делает nagios/zabbix — он особо много, как мне показалось, не умеет (поправьте меня, если я неправ)
    • 0
      Нет, так collectd не умеет, тут нужно что-то вроде splunk'a — www.splunk.com/. По заранее заданным критериям отобрать процессы для сбора статистики он может, но чтобы вот вообще всё собирать это несколько другая задача.

      Zabbix да, заббикс близко, но нагиос совсем далеко — это алерты, статистика показателей как таковая там отсутствует. Собственно я ссылку в начале привел на предыдущий пост, который как раз немного про статистику ( графики ) в Нагиосе. Я вот только не уверен насчет того сколько «счётчиков» будет держать заббикс на своей стандартной базе в виде posrgresql, что может для 5ти серверов и не критично, а для 500 уже важно.
      • +1
        Заббикс рекомендуется держать в MySQL, по производительности реализация в pg проседает. Это даже в доках было. Вообще, для 500+ серверов на 1.8.2 не так и много надо, говорят. У меня мониторилка на полтора десятка — хорошо работает на офисной машинке.
        • 0
          Ну я про заббикс ничего конкретного не скажу в общем, пользовался пару недель и то года 3 назад.
        • 0
          а вы точно доки от заббикса читали? Там есть хорошая табличка:



          www.zabbix.com/documentation/ru/1.8/manual/installation/requirements
          • +1
            Действительно, Вы правы. В своё время я одновременно пилил zabbix и otrs, и некоторые требования смешались. Эта проблема была у otrs.
      • 0
        он умеет принимать параметром текстовую строчку и хранить ее?

        если да, то все просто, делаем ps, выводим поле %cpu и имя процесса, сортируем по первому, отрезаем первые 5-7 строк, сохраняем их как строчку в базе. то же по памяти.
        в итоге на любой момент измерения есть строка с самыми жрущими процессор и память.
    • 0
      Поиграйтесь с atop
    • 0
      в смысле сбор статистики по процессам на разных серверах, графики?
      symon+symux->rrd
      rrdbotd(snmp)->rrd
      rrd->drraw рисовалка

      Вот кстати, кто-нибудь знает drraw с нормальной веб-мордой?
  • 0
    Спасибо! Кратко и содержательно! Но, все равно пока посижу еще на munin, для моих 2х никсосерваков и 3 и 4х виндовых(3 из которых в филлиалах) его вполне достаточно.

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