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

В посте про 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 неплох, но далек от совершенства. На текущий момент разрабатывается несколько независимых систем отображения графиков, но порекомендовать какой-либо пока не могу.

Story URL: