Как изградихме мониторинг с Prometheus, Clickhouse и ELK

Мен казвам Антон Бадерин. Работя в Центъра за Високи Технологии и се занимавам с системно администриране. Преди месец приключи нашата корпоративна конференция, където споделихме натрупания опит с IT обществото на нашия град. Аз говорих за мониторинг на уеб приложения. Материалът беше предназначен за нива junior или middle, които не са изградили този процес от нулата.

Крайъгълният камък, лежащ в основата на всяка система за мониторинг — решаване на бизнес задачи. Мониторингът заради мониторинга не интересува никого. Какво желае бизнесът? Да работи всичко бързо и без грешки. Бизнесът иска проактивност, така че сами да откриваме проблемите в работата на услугата и да ги отстраняваме максимално бързо. Това са по същество задачите, които решавах през изминалата година в проекта на един от нашите клиенти.

За проекта

Проектът е една от най-големите програми за лоялност в страната. Помагаме на търговските мрежи да увеличават честотата на продажбите чрез различни маркетингови инструменти като бонусни карти. В проекта участват общо 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. Създаваме графики на времето за отговор и броя на грешките:

Създаваме графики на времето за отговор и броя на грешките. Помните ли? Говорех за бизнес задачите? За да бъдат бързо и без грешки? Вече с две графики затворихме тези въпроси. И по тях вече може да се обаждате на дежурните администратори.

Но остава още един проблем — да осигурим бързо отстраняване на причините за инцидента.

Отстраняване на инциденти

Целият процес от откритие до решаване на проблема може да бъде разбит на ред стъпки:

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

Важно е да правим това максимално бързо. И ако на етапите на идентификация на проблема и изпращане на уведомление не можем да спестим време — две минути на тях ще отидат така или иначе, то последващите — просто неосеяно поле за подобрения.

Нека просто си представим, че телефонът на дежурния звъни. Какво ще направи той? Ще търси отговори на въпросите - какво е счупено, къде е станало, как да реагира? Ето как отговаряме на тези въпроси:

Просто включваме цялата тази информация в текста на уведомлението, даваме в него линк към страницата в Wiki, където е описано как да реагираме на този проблем, как да го решим и да го ескалираме.

Все още не съм споменал нищо за нивото на приложението и бизнес логиката. За съжаление, в нашите приложения все още не е реализирано събиране на метрики. Единственият източник на информация от тези нива са логовете.

Няколко момента.

На първо място, пишете структурирани логове. Не е нужно да включвате контекста в текста на съобщението. Това затруднява групирането и анализа им. Logstash изисква много време, за да нормализира всичко това.

На второ място, използвайте правилно levels for severity. Всеки език има свой стандарт. Лично аз различавам четири нива:

1. няма грешка;
2. грешка от страна на клиента;
3. грешка от наша страна, не губим пари, не носим рискове;
4. грешка от наша страна, губим пари.

В заключение. Трябва да се опитваме да изграждаме мониторинг именно на базата на бизнес логиката. Трябва да се опитваме да следим самото приложение и да оперираме с метрики като брой продажби, брой нови потребителски регистрации, брой активни потребители в момента и т.н.

Ако целият ви бизнес е само един бутон в браузъра, трябва да следите дали той се натиска, дали работи правилно. Всичко останало не е важно.

Ако нямате това, можете да се опитате да го наваксате в логовете на приложението, логовете на Nginx и т.н., както направихме ние. Трябва да бъдете колкото се може по-близо до приложението.

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

Източник: habr.com