Всем привет. Меня зовут Антон Бадерин. Я работаю в компании Центр Высоких Технологий и занимаюсь системным администрированием.
Буквально неделю назад завершилось интересное мероприятие — ЦВТ конф, где мы делились накопленным опытом с IT сообществом нашего города и образовывали молодежь.
Краеугольный камень, лежащий в основе любой системы мониторинга — решение задач бизнеса. Мониторинг ради мониторинга никому не интересен. А чего хочет бизнес? Чтобы все работало, быстро и без ошибок. Бизнес хочет от нас проактивности, чтобы мы сами выявляли проблемы в работе сервиса и максимально быстро их устраняли. Это, по сути, и есть задачи, которые я решал весь прошлый год на проекте одного из наших заказчиков.
О проекте
Проект представляет собой одну из крупнейших программ лояльности. Мы помогаем розничным сетям увеличивать частоту продаж за счет различных маркетинговых инструментов, типа бонусных карт.
Суммарно в проект входят 14 приложений, которые работают на 10 серверах.
Доклад достаточно капитанский, поэтому будет полезен в какой-то степени джунам и мидлам, которые еще не настраивали самостоятельно систему мониторинга на проекте или кого не устраивает существующая.
В процессе ведения собеседований я неоднократно замечал, что админы далеко не всегда правильно подходят к мониторингу веб-приложений: до сих пор многие останавливаются на метриках операционной системы, изредка мониторят сервисы.
Говоря о моем кейсе, до этого в основе системы мониторинга заказчика лежала icinga. Она никак не решала указанные выше задачи. Часто клиент сам сообщал нам о проблемах и не менее часто нам просто не хватало данных чтобы докопаться до причины.
Кроме того, было четкое понимание бесперспективности ее дальнейшего развития. Я думаю, те, кто знаком с ней, меня поймут.
Итак, нами было принято решение о полной переработке системы мониторинга веб-приложений на проекте.
Далее расскажу, как мы делали выбор и на чем остановились.
1. Prometheus
Мы выбрали Prometheus исходя из трех основных показателей.
- Огромное количество доступных метрик. В нашем случае их количество — 60 тысяч. Конечно, стоит отметить, что подавляющее большинство из них мы не используем (наверно, около 95%), с другой стороны они все относительно дешевы. Для нас эта другая крайность, по сравнению с ранее использовавшейся icingой. В ней добавление метрик доставляло особую боль: имеющиеся доставались дорого (достаточно посмотреть на исходники любого плагина). Любой плагин представлял собой скрипт на bash или python, запуск которых уже недешев с точки зрения потребляемых ресурсов.
- Данная система потребляет относительно небольшое количество ресурсов. На все наши метрики хватает 600 мб оперативной памяти, 15% одного ядра и пару десятков iops. Конечно, приходится запускать экспортеры метрик, но все они написаны на go и так же не отличаются прожорливостью. Не думаю, что в современных реалиях это проблема.
- Дает возможность перехода в Kubernetes.
Учитывая планы заказчика — здесь выбор был очевиден.
2. ELK
Ранее мы логи не собирали и не обрабатывали. Недостатки ясны всем.
Мы выбрали ELK поскольку опыт работы с этой системой у нас уже был. Храним там только логи приложений. Основными критериями выбора стали полнотекстовый поиск и его скорость.
3. Сlickhouse
Изначально выбор пал на influxdb. У нас было понимание необходимости собирать логи nginx, статистику из pg_stat_statements, хранить исторические данные прометея.
Influx нам не понравился, так как он периодически начинал потреблять большое количество памяти и падал.
Кроме того, хотелось группировать запросы по remote_addr, а группировка в этой СУБД только по тэгам, тэги дороги (память), их количество условно ограничено.
Мы начали искать сначала. Нужна была аналитическая база с минимальным потреблением ресурсов, желательно со сжатием данных на диске.
Clickhouse удовлетворяет по всем этим критериям, поэтому об этом выборе мы ни разу не пожалели. Мы не пишем в него каких-то выдающихся объемов данных (количество вставок всего около 5 тысяч в минуту).
4. NewRelic
NewRelic исторически был с нами, так как это был выбор заказчика. У нас он используется в качестве APM.
5. Zabbix
Мы используем Zabbix исключительно для black box мониторинга api снаружи.
Определение подхода к мониторингу
Нам хотелось декомпозировать задачу и тем самым систематизировать подход к мониторингу.
Для этого я разделил нашу систему на следующие уровни:
- железо/vms
- операционная система
- системные сервисы, стек ПО
- приложение
- бизнес логика
Чем удобен такой подход:
- мы знаем, кто ответственен за работу каждого из уровней и соответственно можем исходя из этого слать алерты;
- мы можем использовать при подавлении алертов — было бы странно слать алерт о недоступности базы данных, когда в целом виртуальная машина недоступна
Так как наша задача выявлять нарушения в работе системы, мы должны на каждом уровне выделить некий набор метрик, на которые стоит обращать внимание при написании правил алертинга. Далее пройдемся по уровням «vms», «Операционная система» и «Системные сервисы, стек ПО»
Виртуальные машины
Хостинг выделяет нам процессор, диск, память и сеть. И с первыми двумя у нас были проблемы. Итак, метрики:
- cpu stolen time — когда вы покупаете виртуалку на amazon (t2.micro, к примеру), вы должны понимать, что вам выделяется не целое ядро процессора а лишь квота его времени. И когда вы ее исчерпаете, процессор у вас начнут забирать. Cpu stolen time метрика позволяет отслеживать такие моменты и уже исходя из этого принимать какие-то решения. Например, надо ли взять тариф пожирнее или разнести обработку фоновых задач и запросов в api на разные сервера.
- iops + cpu iowait time — почему-то многие облачные хостинги грешат тем, что недодают iops. Более того, график с низкими iops для них не аргумент. Поэтому стоит собирать и cpu iowait. С этой парой графиков — с низкими iops и высоким ожиданием ввода-вывода — уже можно разговаривать с хостингом и решать эту проблему.
Операционная система
Метрики операционной системы:
- количество доступной памяти в %;
- активность использования swap — vmstat swapin, swapout;
- количество доступных inodes и свободного места на файловой системе в %;
- Load Average;
- количество соединений в состоянии tw;
- заполненность таблицы conntrack;
- качество работы сети можно мониторить с помощью утилиты ss пакет iproute2 — получать из ее вывода показатель rtt соединений и группировать по dest порту.
Также на уровне операционной системы у нас появляется такая сущность как процессы. Важно выделить в системе набор процессов, которые играют важную роль в ее работе. Если, к примеру, у вас есть несколько pgpool, то необходимо собирать информацию по каждому из них.
Набор метрик следующий:
- cpu;
- memory — в первую очередь резидентная;
- io — желательно в iops;
- filefd — открытые и лимит;
- major page faults — по нему вы можете понять, какой процесс свапается;
Весь мониторинг у нас развернут в докере, для сбора данных метрик мы используем cadvisor. На остальных машинах применяем process-exporter.
Системные сервисы, стек ПО
У каждого приложения есть своя специфика и сложно выделить какой-то набор метрик.
Универсальным набором являются:
- рейт запросов;
- количество ошибок;
- латентность;
- saturation.
Наиболее яркие примеры мониторинга данного уровня у нас — nginx и postgresql.
Самый нагруженный сервис в нашей системе — база данных. Раньше у нас достаточно часто возникали проблемы с тем, чтобы выяснить, чем занимается база данных.
Мы видели высокую нагрузку на диски, но слоулоги ничего толком не показывали. Эту проблему мы решили с помощью pg_stat_statements представление, в котором собирается статистика по запросам. Это все, что нужно админу.
Строим графики активности запросов на чтение и запись:
Все просто и понятно, каждому запросу — свой цвет.
Другой не менее яркий пример — nginx логи. Не удивительно, что мало кто их парсит или упоминает в списке обязательных. Стандартный формат не очень информативен и его нужно расширять.
Лично я добавил request_time, upstream_response_time, body_bytes_sent, request_length, request_id.
Строим графики времени ответа и количества ошибок:
Строим графики времени ответа и количества ошибок. Помните я говорил про задачи бизнеса? Чтоб быстро и без ошибок? Мы двумя графиками эти вопросы уже закрыли. И по ним уже можно звонить дежурным админам.
Но осталась еще одна проблема — обеспечить быстрое устранение причин инцидента.
Устранение инцидентов.
Весь процесс от выявления до решения проблемы можно разбить на ряд шагов:
- выявление проблемы;
- уведомление дежурного администратора;
- реакция на инцидент;
- устранение причин.
Важно, что мы должны это делать максимально быстро. И если на этапах выявления проблемы и отправки уведомления мы особо времени выиграть не можем — 2 минуты на них уйдут в любом случае, то последующие — просто непаханное поле для улучшений.
Давайте просто представим, что у дежурного зазвонил телефон. Что он будет делать? Искать ответы на вопросы — что сломалось, где сломалось, как реагировать?
Вот каким образом мы отвечаем на эти вопросы:
Мы просто включаем всю эту информацию в текст уведомления, даем в нем ссылку на страницу в вики, где описано, как на эту проблему реагировать, решать, как эскалировать.
Я до сих пор ничего не сказал про уровень приложения и бизнес.
К сожалению, в наших приложениях пока не реализован сбор метрик. Единственный источник хоть какой то информации с этих уровней — логи.
Пара моментов.
Во-первых, пишите структурированные логи. Не надо включать контекст в текст сообщения. Это затрудняет их группировку и анализ. Logstash требует много времени, чтобы все это нормализовать.
Во-вторых, правильно используйте severity уровни. У каждого языка свой стандарт. Лично я выделяю 4 уровня:
- ошибки нет;
- ошибка на стороне клиента;
- ошибка на нашей стороне, не теряем денег, не несем риски;
- ошибка на нашей стороне, теряем деньги.
Подводя итоги вышесказанного. Нужно стараться выстраивать мониторинг именно от бизнес логики. Стараться замониторить само приложение и оперировать уже такими метриками как количество продаж, количество новых регистраций пользователей, количество активных в данный момент пользователей и так далее.
Если весь ваш бизнес — это одна кнопка в браузере — необходимо мониторить, прожимается ли она, работает ли так, как должна. Все остальное — не важно.
Если у вас этого нет, вы можете попытаться это наверстать в логах приложения, nginx логах и так далее, как это сделали мы. Вы должны быть как можно ближе к приложению.
Метрики операционной системы конечно же важны, но бизнесу они не интересны, нам платят не за них./>