Детализированный мониторинг запросов к Apache при помощи Python и Munin

Одним из заданий во время моей недавней стажировки в ТомТоме ^[1] было улучшение средств мониторинга веб-серверов компании. Конкретнее, необходимо было написать несколько плагинов к Munin ^[2], которые выводили бы подробную статистику запросов к нашим API из логов доступа Apache. Задача эта изначально может показаться примитивной — всего-то и нужно, что распарсить файл лога и вывести результаты в понимаемом Munin формате. Однако, для создания действительно надежной и удобной утилиты с гибкими возможностями настройки мне пришлось немало повозиться. Чтобы эта работа не пропала зря, я разместил код на Гитхабе под названием elfstats ^[3]. В этой статье я расскажу о том, какие задачи способна решать данная утилита, чтобы заинтересовавшиеся сетевые инженеры смогли применить её в своих окружениях.

Вкратце, перед началом работы с elfstats необходимо описать обрабатываемые веб-сервером запросы при помощи регулярных выражений. После этого программа будет регулярно парсить логи доступа и генерировать файл отчета, содержащий количество запросов и распределение времени отклика для каждого из описанных шаблонов. Далее, этот отчет будет обрабатываться при помощи Munin и выводиться в виде соответствующих графиков. Таким образом, установив и настроив elfstats, вы сможете легко отслеживать изменения в работе ваших приложений и поведении пользователей на уровне веб-сервера.

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

Вывод количества запросов к группе API, описанной одним выражением

За основу нового решения я также взял двухкомпонентный подход. Для сбора статистики из логов был написан демон, который запускается через определенные интервалы времени и анализирует данные, сгенерированные со времени предыдущего запуска. Собранная информация записывается в файл отчета, который потом может быть использован плагинами к Munin или к другим средствам визуального мониторинга реального времени. Поскольку все задачи обработки данных возлагаются на демон, плагины получаются очень простыми и отрабатывают очень быстро, что весьма критично для нашего центрального сервера Munin, который медленно и печально собирает статистику по очереди с пары сотен нод. Кроме этого, поскольку плагины практически не содержат никакой логики, кроме разбора короткого файла отчета и возврата значений в munin-node, они легко могут быть переписаны для других утилит мониторинга. Демон при этом трогать не придется.

Текущая версия программы поддерживает следующую функциональность.

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

Распределение времени отклика для одного из вызовов API

При помощи elfstats можно мониторить следующие данные.

• Общее количество запросов в логе.
• Количество запросов по каждой описанной группе (и отдельно количество медленных запросов).
• Распределение времени отклика по каждой группе — минимум, максимум, среднее, произвольные перцентили.
• Распределение кодов возврата — в целом для сервера и отдельно для каждой группы запросов.
• Количество (различных) совпадений для заданных шаблонов.
• Количество разобранных, пропущенных и ошибочных записей для мониторинга демона и отладки конфигурации.

Для отображения этих данных используются шесть различных плагинов для Munin ^[4], написанных на основе фреймворка PyMunin. Плагины распространяются отдельно от демона, они независимы друг от друга и могут включаться и выключаться по необходимости.

Мониторинг кодов возврата

Код демона и плагинов написан на Python 2.6, в будущем возможна поддержа версии 3.х. Бинарная сборка доступна в виде rpm-пакетов, собранных на Linux RedHat 6. Для работы с другими операционными системами необходимо собрать демон и плагины из исходных кодов. Для упрощения установки elfstats на машины с RHEL6 поддерживается RPM с предустановленным виртуальным окружением для питона, которое включает все необходимые зависимости. Исходные коды демона открыты под лицензией MIT, плагины распространяются под GPLv3, как того требует взятый за основу фреймворк PyMunin. Для первичного развертывания и обновления elfstats на серверах используются манифесты Puppet. Они же модифицируют файлы настроек под необходимые задачи, разные для всех серверов. Манифестов в репозиториях пока нет, они будут добавлены несколько позже.

Как мне кажется, написанная мной программа получилась довольно функциональной и гибкой. Уже несколько месяцев она используется для мониторинга довольно большого количества серверов и работает без нареканий. Я буду рад, если вы захотите применить elfstats для контроля своих серверов и с удовольствием отвечу на вопросы по работе этой утилиты в комментариях и трекере.

Автор: dzzh

Источник ^[5]