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

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

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

О проекте

Проектът е една от най-големите програми за лоялни клиенти в страната. Ние помагаме на търговските вериги да увеличат честотата на продажбите чрез различни маркетингови инструменти като бонус карти. Общо проектът включва 14 приложения, които работят на десет сървъра.

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

В моя случай системата за наблюдение на клиента преди това беше базирана на Icinga. Това не реши горните проблеми по никакъв начин. Често самият клиент ни информира за проблемите и по-често просто не разполагаме с достатъчно данни, за да стигнем до дъното на причината.

Освен това имаше ясно разбиране за безсмислието на по-нататъшното му развитие. Мисля, че тези, които са запознати с Icinga, ще ме разберат. Затова решихме напълно да преработим системата за наблюдение на уеб приложенията за проекта.

Прометей

Избрахме Prometheus въз основа на три основни показателя:

1. Огромен брой налични показатели. В нашия случай те са 60 хиляди. Разбира се, заслужава да се отбележи, че ние не използваме по-голямата част от тях (вероятно около 95%). От друга страна, всички те са сравнително евтини. За нас това е другата крайност в сравнение с използваната преди това Icinga. В него добавянето на показатели беше особена болка: съществуващите бяха скъпи (просто погледнете изходния код на всеки плъгин). Всеки плъгин беше скрипт в Bash или Python, чието стартиране е скъпо от гледна точка на изразходваните ресурси.
2. Тази система консумира относително малко количество ресурси. 600 MB RAM, 15% от едно ядро ​​и няколко дузини IOPS са достатъчни за всички наши показатели. Разбира се, трябва да стартирате програми за износ на метрики, но всички те са написани на Go и също не са много гладни за енергия. Не мисля, че в съвременните реалности това е проблем.
3. Предоставя възможност за мигриране към Kubernetes. Имайки предвид плановете на клиента, изборът е очевиден.

ELK

Преди това не събирахме и не обработвахме регистрационни файлове. Недостатъците са ясни на всички. Избрахме ELK, защото вече имахме опит с тази система. Там съхраняваме само регистрационни файлове на приложения. Основните критерии за избор бяха пълнотекстово търсене и неговата скорост.

Сликхаус

Първоначално изборът падна върху InfluxDB. Осъзнахме необходимостта да събираме регистрационни файлове на Nginx, статистики от pg_stat_statements и да съхраняваме исторически данни на Prometheus. Influx не ни хареса, защото периодично започна да консумира голямо количество памет и да се срива. Освен това исках да групирам заявки по remote_addr, но групирането в тази СУБД е само по тагове. Таговете са скъпи (памет), броят им е условно ограничен.

Започнахме търсенето отново. Необходима беше аналитична база данни с минимална консумация на ресурси, за предпочитане с компресиране на данни на диск.

Clickhouse отговаря на всички тези критерии и никога не сме съжалявали за избора си. Ние не записваме никакви извънредни количества данни в него (броят на вмъкванията е само около пет хиляди на минута).

NewRelic

NewRelic исторически е с нас, защото това е изборът на клиента. Използваме го като APM.

Zabbix

Ние използваме Zabbix изключително за наблюдение на черната кутия на различни API.

Определяне на подход за мониторинг

Искахме да декомпозираме задачата и по този начин да систематизираме подхода към мониторинга.

За да направя това, разделих нашата система на следните нива:

• хардуер и VMS;
• операционна система;
• системни услуги, софтуерен стек;
• приложение;
• бизнес логика.

Защо този подход е удобен:

• знаем кой е отговорен за работата на всяко ниво и въз основа на това можем да изпращаме сигнали;
• можем да използваме структурата, когато потискаме предупреждения - би било странно да изпратим предупреждение за недостъпност на базата данни, когато виртуалната машина като цяло е недостъпна.

Тъй като нашата задача е да идентифицираме нарушения в работата на системата, трябва на всяко ниво да подчертаем определен набор от показатели, на които си струва да обърнем внимание, когато пишем правила за предупреждение. След това нека преминем през нивата „VMS“, „Операционна система“ и „Системни услуги, софтуерен стек“.

Виртуални машини

Хостингът ни предоставя процесор, диск, памет и мрежа. И с първите две имахме проблеми. И така, показателите:

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

Този показател ви позволява да проследявате такива моменти и да вземате решения. Например, необходимо ли е да вземете по-висока тарифа или да разпределите обработката на фонови задачи и API заявки на различни сървъри?

IOPS + CPU iowait time - по някаква причина много облачни хостинги грешат, като не предоставят достатъчно IOPS. Освен това график с нисък IOPS не е аргумент за тях. Следователно си струва да събирате CPU iowait. С тази двойка графики - с ниски IOPS и високо I/O чакане - вече можете да говорите с хостинга и да разрешите проблема.

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

Показатели на операционната система:

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

Също така на ниво операционна система имаме такова образувание като процеси. Важно е в системата да се идентифицира набор от процеси, които играят важна роля в нейното функциониране. Ако, например, имате няколко pgpool-а, тогава трябва да съберете информация за всеки от тях.

Наборът от показатели е както следва:

• ПРОЦЕСОР;
• паметта е предимно резидентна;
• IO - за предпочитане в IOPS;
• FileFd - отваряне и ограничаване;
• значителни грешки на страницата - по този начин можете да разберете кой процес се разменя.

Ние внедряваме цялото наблюдение в Docker и използваме Advisor за събиране на данни за показатели. На други машини използваме process-exporter.

Системни услуги, софтуерен стек

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

Универсалният комплект е:

• скорост на заявка;
• брой грешки;
• латентност;
• насищане.

Нашите най-ярки примери за мониторинг на това ниво са Nginx и PostgreSQL.

Най-натоварената услуга в нашата система е базата данни. В миналото често имахме проблеми да разберем какво прави базата данни.

Видяхме високо натоварване на дисковете, но бавните регистрационни файлове всъщност не показаха нищо. Решихме този проблем с помощта на pg_stat_statements, изглед, който събира статистически данни за заявките.

Това е всичко, от което се нуждае администраторът.

Изграждаме графики на активността на заявките за четене и писане:

Всичко е просто и ясно, всяка заявка има свой собствен цвят.

Също толкова ярък пример са регистрационните файлове на Nginx. Не е изненадващо, че малко хора ги анализират или споменават в списъка на задължителните неща. Стандартният формат не е много информативен и трябва да бъде разширен.

Лично аз добавих request_time, upstream_response_time, body_bytes_sent, request_length, request_id Графицираме времето за отговор и броя на грешките:

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

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

Разрешаване на инциденти

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

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

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

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

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

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

Няколко точки.

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

Второ, използвайте правилно нивата на тежест. Всеки език има свой собствен стандарт. Лично аз различавам четири нива:

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

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

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

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

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

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