Како изградивме мониторинг на Прометеј, Кликхаус и ЕЛК

Јас се викам Антон Бадерин. Работам во Центарот за висока технологија и работам системска администрација. Пред еден месец заврши нашата корпоративна конференција на која го споделивме нашето акумулирано искуство со ИТ заедницата на нашиот град. Зборував за следење на веб-апликации. Материјалот беше наменет за помлади или средно ниво, кои не го изградија овој процес од нула.

Камен-темелникот на кој било систем за следење е решавањето на деловните проблеми. Мониторингот заради мониторинг не е од интерес за никого. Што сака бизнисот? Така што сè работи брзо и без грешки. Бизнисите сакаат да бидат проактивни, за ние самите да ги идентификуваме проблемите во услугата и да ги поправиме што е можно побрзо. Тоа, всушност, се проблемите што ги решив цела минатата година на проект за еден наш клиент.

За проектот

Проектот е една од најголемите програми за лојалност во земјата. Им помагаме на малопродажните синџири да ја зголемат фреквенцијата на продажба преку различни маркетинг алатки како бонус картички. Вкупно, проектот вклучува 14 апликации кои работат на десет сервери.

За време на процесот на интервју, постојано забележав дека администраторите не секогаш пристапуваат правилно кон следењето на веб-апликациите: многумина сè уште се фокусираат на метриката на оперативниот систем и повремено ги следат услугите.

Во мојот случај, системот за следење на клиентите претходно беше базиран на Icinga. Тоа не ги реши горенаведените проблеми на кој било начин. Честопати самиот клиент не информираше за проблемите, а почесто едноставно немавме доволно податоци за да дојдеме до дното на причината.

Дополнително, имаше јасно разбирање за залудноста на неговиот понатамошен развој. Мислам дека ќе ме разберат оние кои се запознаени со Icinga. Така, решивме целосно да го редизајнираме системот за следење на веб апликации за проектот.

Прометеј

Го избравме Прометеј врз основа на три главни индикатори:

1. Огромен број на достапни метрики. Во нашиот случај ги има 60 илјади. Се разбира, вреди да се напомене дека не ги користиме огромното мнозинство од нив (веројатно околу 95%). Од друга страна, сите тие се релативно евтини. За нас ова е другата крајност во споредба со претходно користената Icinga. Во него, додавањето метрика беше посебна болка: постојните беа скапи (само погледнете го изворниот код на кој било приклучок). Секој додаток беше скрипта во Bash или Python, чие лансирање е скапо во однос на потрошените ресурси.
2. Овој систем троши релативно мала количина на ресурси. 600 MB RAM, 15% од едно јадро и неколку десетици IOPS се доволни за сите наши метрики. Се разбира, треба да водите извозници на метрика, но сите тие се напишани во Go и исто така не се многу гладни за енергија. Не мислам дека во модерната реалност тоа е проблем.
3. Обезбедува можност за мигрирање во Кубернетес. Со оглед на плановите на клиентите, изборот е очигледен.

ELK

Претходно, не собиравме или обработувавме дневници. Недостатоците се јасни на сите. Го избравме ЕЛК бидејќи веќе имавме искуство со овој систем. Таму ги складираме само дневниците на апликациите. Главните критериуми за избор беа пребарувањето во целосен текст и неговата брзина.

Сликхаус

Првично, изборот падна на InfluxDB. Ја сфативме потребата да се соберат логови на Nginx, статистика од pg_stat_statements и да се складираат историските податоци на Прометеј. Не ни се допадна Influx затоа што периодично почна да троши голема количина на меморија и паѓаше. Покрај тоа, сакав да групирам прашања по remote_addr, но групирањето во овој DBMS е само по ознаки. Ознаките се скапи (меморија), нивниот број е условно ограничен.

Повторно ја започнавме нашата потрага. Она што беше потребно беше аналитичка база на податоци со минимална потрошувачка на ресурси, по можност со компресија на податоци на диск.

Clickhouse ги исполнува сите овие критериуми и никогаш не сме зажалиле за нашиот избор. Во него не пишуваме никакви извонредни количини на податоци (бројот на вметнувања е само околу пет илјади во минута).

RуРелиќ

NewRelic историски е со нас бидејќи тоа беше избор на клиентот. Ние го користиме како APM.

Zabbix

Ние користиме Zabbix исклучиво за следење на Црната кутија на различни API-и.

Дефинирање на пристап за следење

Сакавме да ја разложиме задачата и со тоа да го систематизираме пристапот кон следењето.

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

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

Зошто овој пристап е погоден:

• знаеме кој е одговорен за работата на секое ниво и, врз основа на ова, можеме да испраќаме предупредувања;
• можеме да ја користиме структурата кога ги потиснуваме предупредувањата - би било чудно да испратиме предупредување за недостапноста на базата кога виртуелната машина како целина е недостапна.

Бидејќи нашата задача е да ги идентификуваме прекршувањата во работата на системот, на секое ниво мораме да истакнеме одреден сет на метрика на кои вреди да се обрне внимание при пишувањето правила за предупредување. Следно, да ги поминеме нивоата „VMS“, „Оперативен систем“ и „Системски услуги, стек софтвер“.

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

Хостинг ни доделува процесор, диск, меморија и мрежа. И со првите два имавме проблеми. Значи, метриката:

Украдено време на процесорот - кога купувате виртуелна машина на Амазон (t2.micro, на пример), треба да разберете дека не ви е доделено цело јадро на процесорот, туку само квота од неговото време. И кога ќе го исцрпите, процесорот ќе ви биде одземен.

Оваа метрика ви овозможува да ги следите таквите моменти и да донесувате одлуки. На пример, дали е неопходно да се земе подебела тарифа или да се дистрибуира обработката на заднинските задачи и барањата за API на различни сервери?

IOPS + CPU време на чекање - поради некоја причина, многу облак хостинг грешат со тоа што не обезбедуваат доволно IOPS. Покрај тоа, распоредот со низок IOPS не е аргумент за нив. Затоа, вреди да се собере процесорот iowait. Со овој пар графикони - со низок IOPS и високо I/O чекање - веќе можете да разговарате со хостингот и да го решите проблемот.

Оперативен систем

Метрика на оперативниот систем:

• количина на достапна меморија во %;
• swap-употреба активност: vmstat swapin, swapout;
• број на достапни иноди и слободен простор на датотечниот систем во %
• просечно оптоварување;
• број на врски во две состојби;
• Контрак полнота на табелата;
• Квалитетот на мрежата може да се следи со помош на алатката ss, пакетот iproute2 - добијте индикатор за RTT конекции од нејзиниот излез и групирајте го по дестинација.

Исто така на ниво на оперативен систем имаме таков ентитет како процеси. Важно е да се идентификуваат во системот збир на процеси кои играат важна улога во неговото функционирање. Ако, на пример, имате неколку pgpools, тогаш треба да соберете информации за секој од нив.

Комплетот на метрика е како што следува:

• Процесор;
• меморијата е примарно резидентна;
• IO - по можност во IOPS;
• FileFd - отворете и ограничувајте;
• значителни неуспеси на страницата - на овој начин можете да разберете кој процес се заменува.

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

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

Секоја апликација има свои специфики и тешко е да се издвои одреден сет на метрика.

Универзалниот сет е:

• стапка на барање;
• број на грешки;
• латентност;
• сатурација.

Нашите највпечатливи примери за следење на ова ниво се Nginx и PostgreSQL.

Најоптоварената услуга во нашиот систем е базата на податоци. Во минатото, честопати имавме проблеми да откриеме што прави базата на податоци.

Видовме големо оптоварување на дисковите, но бавните дневници навистина не покажаа ништо. Го решивме овој проблем користејќи pg_stat_statements, приказ кој собира статистика за барања.

Тоа е се што му треба на администраторот.

Градиме графикони на активноста на барања за читање и пишување:

Сè е едноставно и јасно, секое барање има своја боја.

Подеднакво впечатлив пример се логовите на Nginx. Не е изненадувачки што малкумина ги анализираат или спомнуваат во листата на задолжителни работи. Стандардниот формат не е многу информативен и треба да се прошири.

Лично, додадов request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Ние го исцртуваме времето на одговор и бројот на грешки:

Ние градиме графикони за време на одговор и број на грешки. Се сеќавате? Дали зборував за деловни задачи? До брзо и без грешки? Овие прашања веќе ги опфативме со два графикони. И веќе можете да ги повикате дежурните администратори користејќи ги.

Но, останува уште еден проблем - да се обезбеди брза елиминација на причините за инцидентот.

Резолуција на инцидентот

Целиот процес од идентификување до решавање на проблемот може да се подели на неколку чекори:

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

Важно е тоа да го направиме што е можно побрзо. И ако во фазите на идентификување проблем и испраќање известување не можеме да добиеме многу време - во секој случај ќе потрошиме две минути на нив, тогаш следните се едноставно неорано поле за подобрувања.

Да замислиме дека заѕвони телефонот на дежурниот. Што ќе прави? Барајте одговори на прашањата - што пукна, каде пукна, како да реагирате? Еве како одговараме на овие прашања:

Ние едноставно ги вклучуваме сите овие информации во текстот на известувањето, му даваме врска до вики-страница која опишува како да одговориме на овој проблем, како да го решиме и да го ескалираме.

Сè уште не сум кажал ништо за слојот на апликацијата и деловната логика. За жал, нашите апликации сè уште не спроведуваат собирање метрика. Единствениот извор на какви било информации од овие нивоа се дневниците.

Неколку точки.

Прво, напишете структурирани дневници. Нема потреба да се вклучува контекст во текстот на пораката. Ова ги отежнува групирањето и анализирањето. На Logstash му треба многу време за да се нормализира сето ова.

Второ, правилно користете ги нивоата на сериозност. Секој јазик има свој стандард. Лично, разликувам четири нивоа:

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

Дозволете ми да резимирам. Треба да се обидете да изградите мониторинг врз основа на деловната логика. Обидете се да ја следите самата апликација и да работите со такви метрики како што се бројот на продажби, бројот на регистрации на нови корисници, бројот на моментално активни корисници итн.

Ако целиот ваш бизнис е едно копче во прелистувачот, треба да следите дали кликнува и работи правилно. Сите останати не се важни.

Ако го немате ова, можете да се обидете да го достигнете во дневниците на апликации, дневниците на Nginx и така натаму, како што направивме ние. Треба да бидете што е можно поблиску до апликацијата.

Метриката на оперативниот систем е секако важна, но бизнисот не е заинтересиран за нив, не сме платени за нив.

Извор: www.habr.com