Рубрика развивается при поддержке

Как мы строили мониторинг на Prometheus, Clickhouse и ELK

Меня зовут Антон Бадерин. Я работаю в компании «Центр Высоких Технологий» и занимаюсь системным администрированием. Неделю назад завершилась наша корпоративная конференция, где мы делились накопленным опытом с ИТ-сообществом Ижевска, нашего города. Я рассказывал про мониторинг веб-приложений.

В закладки

Краеугольный камень, лежащий в основе любой системы мониторинга — решение задач бизнеса. Мониторинг ради мониторинга никому не интересен. А чего хочет бизнес? Чтобы все работало быстро и без ошибок. Бизнес хочет от нас проактивности, чтобы мы сами выявляли проблемы в работе сервиса и максимально быстро их устраняли. Это, по сути, и есть задачи, которые я решал весь прошлый год на проекте одного из наших заказчиков.

О проекте

Проект — одна из крупнейших в стране программ лояльности. Мы помогаем розничным сетям увеличивать частоту продаж за счёт различных маркетинговых инструментов вроде бонусных карт. В общей сложности в проект входят 14 приложений, которые работают на десяти серверах.

В процессе ведения собеседований я неоднократно замечал, что админы далеко не всегда правильно подходят к мониторингу веб-приложений: до сих пор многие останавливаются на метриках операционной системы, изредка мониторят сервисы.

В моём случаем прежде в основе системы мониторинга заказчика лежала Icinga. Она никак не решала указанные выше задачи. Часто клиент сам сообщал нам о проблемах и не реже нам просто не хватало данных, чтобы докопаться до причины.

Кроме того, было чёткое понимание бесперспективности её дальнейшего развития. Я думаю, те кто знаком с Icinga меня поймут. Итак, мы решили полностью переработать систему мониторинга веб-приложений на проекте.

Prometheus

Мы выбрали Prometheus, исходя из трех основных показателей:

  1. Огромное количество доступных метрик. В нашем случае их 60 тысяч. Конечно, стоит отметить, что подавляющее большинство из них мы не используем (наверно, около 95%). С другой стороны, они все относительно дешевы. Для нас эта другая крайность, по сравнению с ранее использовавшейся Icinga. В ней добавление метрик доставляло особую боль: имеющиеся доставались дорого (достаточно посмотреть на исходники любого плагина). Любой плагин представлял собой скрипт на Bash или Python, запуск которых недешёвый с точки зрения потребляемых ресурсов.
  2. Эта система потребляет относительно небольшое количество ресурсов. На все наши метрики хватает 600 Мб оперативной памяти, 15% одного ядра и пару десятков IOPS. Конечно, приходится запускать экспортёры метрик, но все они написаны на Go и тоже не отличаются прожорливостью. Не думаю, что в современных реалиях это проблема.
  3. Даёт возможность перехода в Kubernetes. Учитывая планы заказчика — выбор очевиден.

ELK

Ранее мы логи не собирали и не обрабатывали. Недостатки ясны всем. Мы выбрали ELK, поскольку опыт работы с этой системой у нас уже был. Храним там только логи приложений. Основными критериями выбора стали полнотекстовый поиск и его скорость.

Сlickhouse

Изначально выбор пал на InfluxDB. Мы осознавали необходимость сбора логов Nginx, статистики из pg_stat_statements, хранения исторических данных Prometheus. Influx нам не понравился, так как он периодически начинал потреблять большое количество памяти и падал. Кроме того, хотелось группировать запросы по remote_addr, а группировка в этой СУБД только по тэгам. Тэги дороги (память), их количество условно ограничено.

Мы начали поиски заново. Нужна была аналитическая база с минимальным потреблением ресурсов, желательно со сжатием данных на диске.

Clickhouse удовлетворяет всем этим критериям, и о выборе мы ни разу не пожалели. Мы не пишем в него каких-то выдающихся объёмов данных (количество вставок всего около пяти тысяч в минуту).

NewRelic

NewRelic исторически был с нами, так как это был выбор заказчика. У нас он используется в качестве APM.

Zabbix

Мы используем Zabbix исключительно для мониторинга Black Box различных API.

Определение подхода к мониторингу

Нам хотелось декомпозировать задачу и тем самым систематизировать подход к мониторингу.

Для этого я разделил нашу систему на следующие уровни:

  • «железо» и VMS;
  • операционная система;
  • системные сервисы, стек ПО;
  • приложение;
  • бизнес-логика.

Чем удобен такой подход:

  • мы знаем, кто ответственен за работу каждого из уровней и, исходя из этого, можем высылать алертов;
  • мы можем использовать структуру при подавлении алертов — было бы странно отсылать алерт о недоступности базы данных, когда в целом виртуальная машина недоступна.

Так как наша задача выявлять нарушения в работе системы, мы должны на каждом уровне выделить некий набор метрик, на которые стоит обращать внимание при написании правил алертинга. Далее пройдемся по уровням «VMS», «Операционная система» и «Системные сервисы, стек ПО».

Виртуальные машины

Хостинг выделяет нам процессор, диск, память и сеть. И с первыми двумя у нас были проблемы. Итак, метрики:

CPU stolen time — когда вы покупаете виртуалку на Amazon (t2.micro, к примеру), следует понимать, что вам выделяется не целое ядро процессора, а лишь квота его времени. И когда вы её исчерпаете, процессор у вас начнут забирать.

Эта метрика позволяет отслеживать такие моменты и принимать решения. Например, надо ли взять тариф пожирнее или разнести обработку фоновых задач и запросов в API на разные сервера.

IOPS + CPU iowait time — почему-то многие облачные хостинги грешат тем, что недодают IOPS. Более того, график с низкими IOPS для них не аргумент. Поэтому стоит собирать и CPU iowait. С этой парой графиков — с низкими IOPS и высоким ожиданием ввода-вывода — уже можно разговаривать с хостингом и решать проблему.

Операционная система

Метрики операционной системы:

  • количество доступной памяти в %
  • активность использования swap: vmstat swapin, swapout;
  • количество доступных inode и свободного места на файловой системе в %
  • средняя загрузка;
  • количество соединений в состоянии tw;
  • заполненность таблицы conntrack;
  • качество работы сети можно мониторить с помощью утилиты ss, пакетом iproute2 — получать из её вывода показатель RTT-соединений и группировать по dest-порту.

Также на уровне операционной системы у нас появляется такая сущность, как процессы. Важно выделить в системе набор процессов, которые играют важную роль в её работе. Если, к примеру, у вас есть несколько pgpool, то необходимо собирать информацию по каждому из них.

Набор метрик следующий:

  • CPU;
  • память — в первую очередь, резидентная;
  • IO — желательно в IOPS;
  • FileFd — открытые и лимит;
  • существенные отказы страницы — так вы сможете понять, какой процесс свапается.

Весь мониторинг у нас развернут в Docker, для сбора данных метрик мы используем Сadvisor. На остальных машинах применяем process-exporter.

Системные сервисы, стек ПО

У каждого приложения есть своя специфика, и сложно выделить какой-то набор метрик.

Универсальным набором являются:

  • рейт запросов;
  • количество ошибок;
  • латентность;
  • saturation;

Наиболее яркие примеры мониторинга данного уровня у нас — Nginx и PostgreSQL.

Самый нагруженный сервис в нашей системе — база данных. Раньше у нас достаточно часто возникали проблемы с тем, чтобы выяснить, чем занимается база данных.

Мы видели высокую нагрузку на диски, но слоулоги ничего толком не показывали. Эту проблему мы решили с помощью pg_stat_statements, представления, в котором собирается статистика по запросам.

Это всё, что нужно админу.

Строим графики активности запросов на чтение и запись:

Всё просто и понятно, каждому запросу — свой цвет.

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

Лично я добавил request_time, upstream_response_time, body_bytes_sent, request_length, request_id.Строим графики времени ответа и количества ошибок:

Строим графики времени ответа и количества ошибок. Помните? я говорил про задачи бизнеса? Чтоб быстро и без ошибок? Мы уже двумя графиками эти вопросы закрыли. И по ним уже можно звонить дежурным админам.

Но осталась ещё одна проблема — обеспечить быстрое устранение причин инцидента.

Устранение инцидентов

Весь процесс от выявления до решения проблемы можно разбить на ряд шагов:

  • выявление проблемы;
  • уведомление дежурного администратора;
  • реакция на инцидент;
  • устранение причин.

Важно, что мы должны это делать максимально быстро. И если на этапах выявления проблемы и отправки уведомления мы особо времени выиграть не можем — две минуты на них уйдут в любом случае, то последующие — просто непаханное поле для улучшений.

Давайте просто представим, что у дежурного зазвонил телефон. Что он будет делать? Искать ответы на вопросы — что сломалось, где сломалось, как реагировать? Вот каким образом мы отвечаем на эти вопросы:

Мы просто включаем всю эту информацию в текст уведомления, даем в нем ссылку на страницу в вики, где описано, как на эту проблему реагировать, как её решать и эскалировать.

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

Пара моментов.

Во-первых, пишите структурированные логи. Не надо включать контекст в текст сообщения. Это затрудняет их группировку и анализ. Logstash требует много времени, чтобы всё это нормализовать.

Во-вторых, правильно используйте severity-уровни. У каждого языка свой стандарт. Лично я выделяю четыре уровня:

  1. ошибки нет;
  2. ошибка на стороне клиента;
  3. ошибка на нашей стороне, не теряем денег, не несём риски;
  4. ошибка на нашей стороне, теряем деньги.

Резюмирую. Нужно стараться выстраивать мониторинг именно от бизнес-логики. Стараться замониторить само приложение и оперировать уже такими метриками, как количество продаж, количество новых регистраций пользователей, количество активных в данный момент пользователей и так далее.

Если весь ваш бизнес — одна кнопка в браузере, необходимо мониторить, прожимается ли она, работает ли должным образом. Всё остальное не важно.

Если у вас этого нет, вы можете попытаться это наверстать в логах приложения, Nginx-логах и так далее, как это сделали мы. Вы должны быть как можно ближе к приложению.

Метрики операционной системы конечно же важны, но бизнесу они не интересны, нам платят не за них.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Центр Высоких Технологий", "author_type": "self", "tags": ["\u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433"], "comments": 12, "likes": 34, "favorites": 16, "is_advertisement": false, "subsite_label": "dev", "id": 62715, "is_wide": true, "is_ugc": true, "date": "Thu, 28 Mar 2019 10:55:45 +0300", "is_special": false }
Облачная платформа
Основа для цифровизации бизнеса
0
{ "id": 62715, "author_id": 244899, "diff_limit": 1000, "urls": {"diff":"\/comments\/62715\/get","add":"\/comments\/62715\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/62715"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 235819, "last_count_and_date": null }
12 комментариев
Популярные
По порядку
Написать комментарий...
2

В общей сложности в проект входят 14 приложений, которые работают на десяти серверах.

похоже, действительно масштабная штука!

Ответить
0

Если ЦВТ так борется за вычислительные ресурсы, то зачем использовать Zabbix для "телебоньканья" API?
Sensu или старый добрый nagios по ресурсам будут более вменяемы.

Ответить
3

Потому, что он уже есть.
К слову о nagios - когда то давно у нас использовалась исинга. И нельзя сказать, что она потребляла мало ресурсов. Добавление новых метрик - новые скрипты в nagios агенте. Если скрипты на баше - это куча форков, куча походов на диск (да, у нас есть страничный кеш и на диск мы когда то перестанем ходить, но неужели ему не найдется более эффективного применения?). Если на питоне - запускать интерпретатор, что тоже дорого. Zabbix хотя бы часть метрик достает системными вызовами или через интеграцию агента с источниками метрик.
Да и функионал его поширше будет.
У nagios нет будущего. Sensu не использовал.

Ответить
1

"Потому, что он уже есть" - вечная беда. Сама не могу слезть с Puppet и Chef в сторону Ansible по этой же причине.

Ответить
0

У меня аналогичная ситуация с ансиблом, хочу убежать в оркестрацию, но, объективно, такие трудозатраты не скоро окупятся, так что печаль.

Ответить
0

Абсолютно аналогичная ситуация.
Хотя я помню времена, когда обходилась одним capistrano ;)

Ответить
0

Проект представляет собой одну из крупнейших в стране программ лояльности.

Линк или название можно?

Ответить
0

К сожалению, у нас NDA, хотя нам бы очень хотелось рассказать о проекте :(
Там точно есть о чем рассказывать.

Ответить
0

Не менее яркий пример — Nginx-логи. Не удивительно, что мало кто их парсит или упоминает в списке обязательных.

Это же далеко не так. Трейсить запросы без логов невозможно. Лет 10 назад общались с чуваками из Яху и они рассказывали как они обрабатывают логи Хадупа в самом Хадупе. При этом всем нужно обучать модель, которая могла бы переживать флапающие метрики. Хотя наверное в маленьких проектах нет нужды предсказывать выход из строя части мощностей.

Ответить
0

Абсолютно согласен, что без логов никак.
Но практика показывает, что на небольших веб проектах и техподдержке не всегда их смотрят, а если и смотрят, то не всегда по ним алертят.
Статья по большому счету предназначена для джунов и мидлов, которые не выстраивали мониторинг с нуля. Как уже говорил, приходящие к нам на собеседование админы часто по старинке выстраивают мониторинг от железа. Да, следить за ним важно, но мониторить все равно в первую очередь надо приложение.

Ответить
0

Данные из prometheus в clickhouse пишете через PromHouse? Выводите ли потом на графики куда-либо(grafana)?

Ответить
0

Да, через PromHouse. Да, вывожу. Данных совсем немного, только исторические, для планирования ресурсов.

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cgxmr", "p2": "gnwc" } } } ] { "page_type": "default" }