Comments 17
Создалось впечатление, что основное достигнутое — это «красивые картинки для руководства». Вопрос — кроме того, что обеспечивает zabbix «из коробки», достигнуто? Насколько я понимаю, целей для такого рода работ может быть две — понять что привело к проблеме и выявить проблему. Мне всегда хотелось как-то припахать карты Шухарта, не смотрели в эту сторону?
На первом этапе, который описан здесь, стояла задача найти способ мерить показатели не отдельных узлов площадки, а предоставляемого сервиса. Самым сложным оказалось связать между собой поступающие данные с трех его уровней — фронтенда, сервера приложений и сервера БД, что было достигнуто единым для всех уровней идентификатором запроса. Это дает возможность, заметив признаки проблемы на любом из уровней, найти его следы на остальных. Для полноценного мониторинга нам еще не хватает возможностей по измерению отклика вспомогательных сервисов (баз данных, схд, сторонних api) — когда он появится мы сможем находить зависимости между проблемами на главном сервисе и вспомогательных. В этом направлении будем двигаться осенью.
За карты Шухарта — спасибо, пригодится когда будем настраивать триггеры.
За карты Шухарта — спасибо, пригодится когда будем настраивать триггеры.
Мне кажется решение Splunk как раз предназначено для вашей задачи. Без бубнов.
Очень даже может быть, но не без бубнов. Splunk из коробки дает анализатор логов, поиск по ним, красивые картинки, но не имеет никакого «статистического аппарата» (это информация технарей, делавших нам презентацию), его надо расширять самостоятельно на питоне, насколько он будет быстро считать все что нам нужно пока что под большим вопросом. На просьбу распарсить наши двухнедельные логи на стенде сначала бойкий интегратор пропал уже скоро на месяц.
1) Почему в разделителях логов 4 пробела и потом это парсится регуляркой? Можно было взять более уникальный разделитель и нарезать строчки простым split/explode/etc.
У нас, например, в подобных логах используется ' | ' между полями.
2) Если perl скрипт разбора логов работает от предыдущего смещения файла до текущего конца, то как вы выполняете ротацию самого файла лога? Не может же он бесконечно разрастаться.
У нас, например, в подобных логах используется ' | ' между полями.
2) Если perl скрипт разбора логов работает от предыдущего смещения файла до текущего конца, то как вы выполняете ротацию самого файла лога? Не может же он бесконечно разрастаться.
1. Неудачно выразился — мы сначала парсили близкий к традиционному формат регуляркой, потом перешли на четыре пробела и split. Пробелы в числе четырех штук имеют мало шансов появится в наших данных, классические односимвольные разделители — запросто.
2. Перед смещением проверяется текущий размер файла по имени, если он меньше последнего — указатель смещаем в ноль и переинициализируем дескриптор.
2. Перед смещением проверяется текущий размер файла по имени, если он меньше последнего — указатель смещаем в ноль и переинициализируем дескриптор.
Вот у нас, фактически, тоже самое. Дополнительно еще используется graylog2, куда разработчики в real-time шлют результаты работы логики приложения. В нем есть триггеры, которые по регуляркам парсят логи и сразу поднимают тревогу, если сообщений вдруг по каким-либо причинам превышено. То есть все само аггрегируется и проводится первоначальный анализ. Это уже не системные логи, а логи работы приложения. Например, rps клиента с заданным ключом, либо как посчиталась реклама (или не посчиталась).
Критичные и нужные данные (системные и access логи), необходимые для обсчета и анализа, и которые надо хранить хоть чуть-чуть сырыми — складываются также на диск и дальше уже отложено обрабатываются парсерами и анализаторами. Ну и заббикс с кучей логики и веб-проверками.
Также наблюдается тенденция превращения наших фронтендов в web-app. Nginx может сам сформировать нужный лог (с аггрегацией и первичным анализом) и отправить куда-нибудь уже готовую статистику.
Критичные и нужные данные (системные и access логи), необходимые для обсчета и анализа, и которые надо хранить хоть чуть-чуть сырыми — складываются также на диск и дальше уже отложено обрабатываются парсерами и анализаторами. Ну и заббикс с кучей логики и веб-проверками.
Также наблюдается тенденция превращения наших фронтендов в web-app. Nginx может сам сформировать нужный лог (с аггрегацией и первичным анализом) и отправить куда-нибудь уже готовую статистику.
Спасибо за информацию. Скажите — на каком железе у Вас это работает, за какой срок хранятся сырые логи для поиска?
Виртуалки openvz, штук 6 в среднем для всех задач. В каждой 4 камня, 250 Gb disk, 16Gb RAM. Примерно неделю хранятся сырые логи. В основном тут логи Postgres и немного Nginx. Аггрегированая и обработанная статистика от системных сервисов хранится год (собственные скрипты и pgfouine).
Ну еще у нас есть сервис с OLAP кубами, который анализирует бизнес-статистику, про них не скажу, другое подразделение занимается. Заббикс в такой же виртуалке, там данные за год, мониторится порядка 4000 элементов.
А, забыл еще сказать про профилирование скриптов приложений. Мы используем pinba, но там «мгновенная» статистика, только посмотреть и отладить, хранить ее смысла нет. Система постоянно расширяется и дополняется функционалом, вот, доросли до geo распределенного кластера, его тоже надо мониторить, причем с разных точек.
Нам недавно программисты написали тесты для своих аппликух, сейчас пробуем их запускать из Германии, например. Получается что-то типа pingdom или hosttracker, но информации внутри немного больше.
Ну еще у нас есть сервис с OLAP кубами, который анализирует бизнес-статистику, про них не скажу, другое подразделение занимается. Заббикс в такой же виртуалке, там данные за год, мониторится порядка 4000 элементов.
А, забыл еще сказать про профилирование скриптов приложений. Мы используем pinba, но там «мгновенная» статистика, только посмотреть и отладить, хранить ее смысла нет. Система постоянно расширяется и дополняется функционалом, вот, доросли до geo распределенного кластера, его тоже надо мониторить, причем с разных точек.
Нам недавно программисты написали тесты для своих аппликух, сейчас пробуем их запускать из Германии, например. Получается что-то типа pingdom или hosttracker, но информации внутри немного больше.
1. Хорошо бы добавить в статью гиперссылки на доклад и модуль хедхантера
www.slideshare.net/kuchinskaya/sivko
github.com/hhru/nginx_requestid
2. Чтобы работало быстро можно некоторые метрики строить сразу в парсере логов, те которые не требуют пересортировки данных (кол-во запросов в секунду с разбивкой по типам, среднее время ответа, средний размер запроса и т.п.), мы таким образом анализируем свои 400 000 запросов в секунду
3. Те метрики которые требуют обработки всего минутного блока, совершенно не нуждаются в базе данных, какой-нибудь аналог утилиты sort с буфером в памяти должен быстрее и экономичнее, мы считали когда-то так уников, получается быстро
4. посчитанные метрики удобно хранить в Graphite, в него удобно писать метрики из приложений, хранит только данные, а график строит динамически в момент запроса, графики можно очень широко комбинировать и построить практически любой отчет онлайн (например можно выделить графики со всплесками отфильтровав по производной)
5. С тарантулом могут быть сложности, не помню чтобы он умел инвалидировать по Expires блоки записей
6. Отправка логов по UDP хороша, позволяет гарантированно не втуплять в диск на фронтах, чтобы работало на приемной стороне надо увеличивать приемный буфер до нескольких мегабайт, тогда держит порядка 150 000 запросов в секунду
www.slideshare.net/kuchinskaya/sivko
github.com/hhru/nginx_requestid
2. Чтобы работало быстро можно некоторые метрики строить сразу в парсере логов, те которые не требуют пересортировки данных (кол-во запросов в секунду с разбивкой по типам, среднее время ответа, средний размер запроса и т.п.), мы таким образом анализируем свои 400 000 запросов в секунду
3. Те метрики которые требуют обработки всего минутного блока, совершенно не нуждаются в базе данных, какой-нибудь аналог утилиты sort с буфером в памяти должен быстрее и экономичнее, мы считали когда-то так уников, получается быстро
4. посчитанные метрики удобно хранить в Graphite, в него удобно писать метрики из приложений, хранит только данные, а график строит динамически в момент запроса, графики можно очень широко комбинировать и построить практически любой отчет онлайн (например можно выделить графики со всплесками отфильтровав по производной)
5. С тарантулом могут быть сложности, не помню чтобы он умел инвалидировать по Expires блоки записей
6. Отправка логов по UDP хороша, позволяет гарантированно не втуплять в диск на фронтах, чтобы работало на приемной стороне надо увеличивать приемный буфер до нескольких мегабайт, тогда держит порядка 150 000 запросов в секунду
А вы не делали интеллектуальный анализ логов: поиск корреляций, зависимостей, приближенных циклов и повторений? Вопрос скорее общий, не конкретно по описанной задаче. Например, на протяжении продолжительного времени каждый день приходит определенное кол-во запросов с каким-нибудь ключом, а вот сегодня их в два раза меньше, но вместе с этим упали / выросли запросы с другим ключом. Как найти такую закономерность, если точно не знать, что она есть, а только допускать ее возможность?
Sign up to leave a comment.
Анализ логов в реальном времени