Samozrejme, existuje aj skupina problémov – napríklad problémy tretích strán (dátové centrá, poskytovatelia pripojenia, chyba na strane developera, atď.), ktoré sa nedajú predvídať pomocou monitoringu. Na to slúžia iné mechanizmy. Monitoring vám však pomôže aj v tejto situácii a umožní vám rýchle zaznamenanie problémov.
Aktuálne poznáme stovky monitorovacích systémov, ktoré sa delia na základe rôznych kategórií, ako napríklad:
- objektu (všeobecný alebo dedikovaný),
- metódy získavania údajov – Push (CollectD, Zabbix a InfluxDB) alebo Pull (Prometheus, SNMP a JMX),
- režimu nasadenia (samostatný, distribuovaný, SaaS),
- metódy získavania údajov (typ rozhrania, DSL alebo SQL),
- komerčných atribútov: open-source a bezplatné, komerčný typ s otvoreným zdrojom a uzavretý komerčný typ.
Monitoring na základe metódy získavania údajov
Pozrime sa spoločne, ako prebieha monitoring na základe získavania údajov bez ohľadu na to, či ide o open-source riešenie alebo komerčný produkt.
Monitorovací systém na základe Pull modelu aktívne získava v určitom časovom intervale dáta „metrics“ (indikátory) potrebné pre
monitoring objektov. Dáta sú viazané na čas a zväčša sa vyhodnocujú ako zmena v čase, nazývajúce sa tiež „time series data“. Súčasťou takého záznamu môžu byť aj key-value páry „labels“, ktoré ďalej rozširujú zaznamenanú informáciu.
Monitorovacie systémy na základe Push modelu aktívne nezískavajú dáta, ale monitorované objekty ich aktívne tlačia.
Monitorovací systém na základe získaných dát, alebo ich absencie, zašle varovanie o potencionálnom probléme cez niektorú z doručovacích metód, ktoré si môžete nastaviť podľa závažnosti problému či DevOps tímu, ktorého sa týka (e-mail, SMS, hlasová správa, IM atď.).
Súčasťou monitoringu je aj dashboard, ktorý vám umožňuje grafickú analýzu dát, vrátane dát historických.
Prometheus a exportér
Pre monitoring v rámci modelu Pull používame monitorovací back-end systém Prometheus, ktorý dopĺňa:
- Alertmanager, doručovanie alertov,
- Grafana, grafická analýza,
- celá rada exporterov pre získavanie dát.
Prometheus bol uvedený na trh v roku 2012 a získal veľkú popularitu. Je lídrom v cloudovom prostredí a riadi sa HTTP pull modelom, ktorý bežne šrotuje “scrapuje” metriky v prometheus formáte z koncových bodov. Ako vôbec druhý projekt po Kubernetese, bol zaradený pod Cloud Native Computing Foundation.
Popularita Promethea ma celú radu výhod, ako spomenuté:
- all-in-one riešenie v jednej binárke,
- jednoduchá integrácia do existujúceho softvéru,
- veľký výber exportérov umožňujúcich monitoring širokej škály služieb,
- cloudovo orientovaná automatická konfigurácia a získavanie cielov monitorovania.
Podstatné pre získanie popularity Promethea a dôvod širokej integrácie je v Prometheovi samotnom, hlavne veľmi nízkych systémových požiadavkách, za ktoré vďačí efektívnej internej databáze TSDB vyvinutej v rámci Promethea a PromQL jazyku.
Väčšina monitorovacích riešení sa spolieha na externú databázu ako MySQL či PostgreSQL, ktoré však nie sú optimálne pre tento účel, ako aj samotné SQL. Výhodou Promethea, ktorá sa nedá zanedbať je aj HTTP protokol používaný na komunikáciu, ktorý umožňuje jednoduchý troubleshooting, kontrolu či použitia štandardných HTTP proxy.
Architektúra monitoringu na cloud platforme CREATIVE sites využíva dve samostatné inštancie.
- Interný monitoring, ktorý zabezpečuje monitorovanie služieb (softvéru) na serveroch a monitorovanie serverov samotných. Táto inštancia je nasadená interne v rámci serverov v dátovom centre.
- Externý monitoring nasadený mimo dátového centra, ktorý je úplne nezávislý a monitoruje služby dostupné pre klientov „užívateľov“ a dostupnosť dátového centra ako takého.
Externý monitoring
Setup pre externý monitoring na platforme CREATIVE sites pozostáva z častí:
- monitorovací systém Prometheus,
- Alertmanager,
- Blackbox exporter,
- Script exporter,
- Grafana.
Umiestnený je na virtuálnom serveri v dátovom centre s geograficky odlišnou lokalitou ako služby, ktoré má pod dohľadom, aby výpadok v dátovom centre neovplyvnil jeho funkčnosť. Zároveň je pod dohľadom interného monitoringu.
Medzi najpodstatnejšie úlohy patria:
- monitorovanie webových stránok a presmerovaní,
- monitorovanie dostupnosti sieťových prvkov (stavu pripojenia) v dátovom centre,
- monitorovanie FTP serverov,
- monitorovanie SMTP a IMAP serverov.
Najpodstatnejšie pre našich klientov je monitorovanie webových stránok, kde sa monitoruje response code (HTTP code), veľkosť body, stav TLS certifikátov a rýchlosť odozvy v jednotlivých stupňoch ako DNS preklad, konekcia, TLS handshake, spracovanie requestu na strane servera a prenesenie response voči monitoringu (klientovi).
V rámci monitoringu potrebujeme poznať zoznam všetkých domén, ktoré je potrebné monitorovať. Tento zoznam musí byť aktuálny a pri veľkom počte domén a častých zmenách je nevyhnutná automatizácia.
Alertmanager umožňuje na základe labelov nastavených v rámci notifikačných pravidiel v Prometheovi zaradiť alert do rôznych kategórií. Jednotlivé kategórie určujú komu a akou metódou či kanálom má byť správa doručená a ako často sa má správa opakovať. Alertmanager umožňuje spájanie správ – čo znamená, že čaká definovaný časový interval na podobnú správu (rovnaké labels) a následne sa doručuje ako jedna správa.
Ďalšia možnosť je potlačiť menej dôležité správy, ak je aktívny alert s vyššou prioritou pre rovnaký objekt, alebo došlo k masívnemu zlyhaniu, kedy by sa mohli doručiť stovky až tisícky správ s rovnakou chybou pre rôzne objekty. Alerty je tiež možné dočasne odložiť cez webové rozhranie Alertmanagera alebo permanentne vyňať v rámci notifikačných pravidiel – ideálne dáta, ktoré nepotrebujeme, nescrapovať alebo neukladať do databázy.
Interný monitoring
Interný monitoring je architektonicky podobný externému monitoringu s rozdielom v tom, že konfigurácie neobsahujú zoznam “list” domén ale IP:PORT párov stoviek exporterov pre rôzne technologické časti infraštruktúry, ktoré sú generované staticky (admin) alebo dynamicky (Service discovery).
Okrem systému serverov a hardvéru monitorujeme MariaDB, ElasticSearch, Nginx, PHP-FPM, Redis Cluster, Memcached, Gearman, Thumbor, Gitlab, DRBD, Dovecot, Postfix, Pacemaker a Corosync cluster.
Zaznamenávame takmer 75 000 rôznych „time series“ každých 10–30s v závislosti na dôležitosti a frekvencii s akou sa menia.Vykonáva sa nad nimi cez sto notifikačných pravidiel. Interný monitoring poskytuje prehľad nad stavom infraštruktúry, čo nám umožňuje rýchlo konať v prípade problému a predchádzať problémom podobne ako pri externom monitoringu. Zároveň nám ale slúži ako nevyhnutný prvok pri optimalizácií konfigurácie softvéru a hardvéru.
Základný a jeden z najdôležitejších exportérov je node_exporter vyvíjaný v rámci Prometheus systému, ktorý zabezpečuje monitorovanie operačného systému, základný prehľad služieb a stavu hardvér servera.
Systémové notifikácie zahŕňajú varovania o nedostatku fyzickej pamäte – „memory pressure“, ktorého zvýšená hodnota je znakom nárastu alokácie pamäte EDAC, ktoré zaznamenáva opraviteľné a neopraviteľné chyby pamäte, vysoké alebo nízke vyťaženie CPU, čakanie CPU na IO (filesystem), dosiahnutie maximálnej priepustnosti sieťového pripojenia alebo stratu či opakované posielanie paketov.
Notifikácie slúžia na upozornenie o probléme ideálne predtým, ako nastal, pre optimalizácie a plánovanie infraštruktúry slúži nástroj Grafana, ktorý umožňuje grafické zobrazenie metrík a zároveň je pomôckou pre riešenie problémov alebo identifikáciu podmienok, ktoré problémom predchádzali. Grafana sa používa aj v rámci externého monitoringu, avšak len na historickú analýzu či štatistické účely.
Aj pri monitoringu je optimalizácia dôležitá rovnako ako pri službách ktoré monitorujeme.
Monitoring a exportéri môžu mať negatívny dopad na výkon, a preto je nevyhnutné scrapovať len dáta, ktoré naozaj potrebujeme. Často sa dajú niektoré dáta vydedukovať alebo priamo spočítať na základe iných dát.
Záver:
Význam monitorovania rástol od prvých počítačových systémov, kde bolo nutné zistiť, či aplikácie plné využívajú dostupný hardvér, až po súčasnosť, kedy denne používame nespočetné množstvo aplikácií, ktoré často bez nášho vedomia pristupujú k službám na vzdialených serveroch. Ich funkčnosť a rýchlosť berieme za samozrejmosť, no bez správneho monitorovania to nie je možné dosiahnuť.
Monitorovací systém už neslúži len na zistenie stavu serverov a siete, ktorá ich prepája s užívateľmi, ale stal sa nevyhnutným nástrojom pre budúce plánovanie, optimalizácie ale aj zdroj informácií, ktoré priamo neslúžia iba DevOps tímom, ale dajú sa použiť aj pre business a marketingové účely.
