Samozřejmě, existuje i skupina problémů – například problémy třetích stran (datová centra, poskytovatelé připojení, chyba na straně developera atd.), které nelze předvídat pomocí monitoringu. K tomu slouží jiné mechanismy. Monitoring vám však pomůže i v této situaci a umožní vám rychlé zaznamenání problémů.
Aktuálně známe stovky monitorovacích systémů, které se dělí na základě různých kategorií, jako například:
- objektu (obecný nebo dedikovaný),
- metody získávání údajů – Push (CollectD, Zabbix a InfluxDB) nebo Pull (Prometheus, SNMP a JMX),
- režimu nasazení (samostatný, distribuovaný, SaaS),
- metody získávání údajů (typ rozhraní, DSL nebo SQL),
- komerčních atributů: open-source a bezplatné, komerční typ s otevřeným zdrojem a uzavřený komerční typ.
Monitoring na základě metody získávávání údajů
Podívejme se společně, jak probíhá monitoring na základě získávání údajů bez ohledu na to, zda se jedná o open-source řešení nebo komerční produkt.
Monitorovací systém na základě Pull modelu aktivně získává v určitém časovém intervalu data „metrics“ (indikátory) potřebná pro
monitoring objektů. Data jsou vázána na čas a většinou se vyhodnocují jako změna v čase, nazývající se také „time series data“. Součástí takového záznamu mohou být i key-value páry „labels“, které dále rozšiřují zaznamenanou informaci.
Monitorovací systémy na základě Push modelu aktivně nezískávají data, ale monitorované objekty je aktivně tlačí.
Monitorovací systém na základě získaných dat, nebo jejich absence, zašle varování o potencionálním problému přes některou z doručovacích metod, které si můžete nastavit podle závažnosti problému či DevOps týmu, kterého se týká (e-mail, SMS, hlasová zpráva, IM atd.) .
Součástí monitoringu je také dashboard, který vám umožňuje grafickou analýzu dat, včetně dat historických.
Prometheus a exportér
Pro monitoring v rámci modelu Pull používáme monitorovací back-end systém Prometheus, který doplňuje:
- Alertmanager, doručování alertů,
- Grafana, grafická analýza,
- celá řada exportérů pro získávání dat.
Prometheus byl uveden na trh v roce 2012 a získal velkou popularitu. Je lídrem v cloudovém prostředí a řídí se HTTP pull modelem, který běžně šrotuje „scrapuje“ metriky v prometheus formátu z koncových bodů. Jako vůbec druhý projekt po Kubernetesu, byl zařazen pod Cloud Native Computing Foundation.
Popularita Promethea má celou řadu výhod jako zmíněné:
- all-in-one řešení v jedné binárce,
- jednoduchá integrace do stávajícího softwaru,
- velký výběr exportérů umožňujících monitoring široké škály služeb,
- cloudově orientovaná automatická konfigurace a získávání cílů monitorování.
Podstatné pro získání popularity Promethea a důvod široké integrace je v Prometheovi samotném, hlavně velmi nízkých systémových požadavcích, za které vděčí efektivní interní databázi TSDB vyvinuté v rámci Promethea a PromQL jazyce.
Většina monitorovacích řešení spoléhá na externí databázi jako MySQL či PostgreSQL, které však nejsou optimální pro tento účel, jakož i samotné SQL. Výhodou Promethea, která se nedá zanedbat je i HTTP protokol používaný ke komunikaci, který umožňuje snadný troubleshooting, kontrolu či použití standardních HTTP proxy.
Architektura monitoringu na cloud platformě CREATIVE sites využívá dvě samostatné instance.
- Interní monitoring, který zajišťuje monitorování služeb (softwaru) na serverech a monitorování serverů samotných. Tato instance je nasazena interně v rámci serverů v datovém centru.
- Externí monitoring nasazený mimo datové centrum, které je zcela nezávislé a monitoruje služby dostupné pro klienty „uživatele“ a dostupnost datového centra jako takového.
Externí monitoring
Setup pro externí monitoring na platformě CREATIVE sites sestává z částí:
- monitorovací systém Prometheus,
- Alertmanager,
- Blackbox exporter,
- Script exporter,
- Grafana.
Umístěn je na virtuálním serveru v datovém centru s geograficky odlišnou lokalitou než služby, které má pod dohledem, aby výpadek v datovém centru neovlivnil jeho funkčnost. Zároveň je pod dohledem interního monitoringu.
Mezi nejpodstatnější úkoly patří:
- monitorování webových stránek a přesměrování,
- monitorování dostupnosti síťových prvků (stavu připojení) v datovém centru,
- monitorování FTP serverů,
- monitorování SMTP a IMAP serverů.
Nejpodstatnější pro naše klienty je monitorování webových stránek, kde se monitoruje response code (HTTP code), velikost body, stav TLS certifikátů a rychlost odezvy v jednotlivých stupních jako DNS překlad, konekce, TLS handshake, zpracování requestu na straně serveru a přenesení response vůči monitoringu. (klientovi).
V rámci monitoringu potřebujeme znát seznam všech domén, které je třeba monitorovat. Tento seznam musí být aktuální a při velkém počtu domén a častých změnách je nezbytná automatizace.
Alertmanager umožňuje na základě labelů nastavených v rámci notifikačních pravidel v Prometheovi zařadit alert do různých kategorií. Jednotlivé kategorie určují komu a jakou metodou či kanálem má být zpráva doručena a jak často se má zpráva opakovat. Alertmanager umožňuje spojování zpráv – což znamená, že čeká definovaný časový interval na podobnou zprávu (stejné labels) a následně se doručuje jako jedna zpráva.
Další možnost je potlačit méně důležité zprávy, pokud je aktivní alert s vyšší prioritou pro stejný objekt, nebo došlo k masivnímu selhání, kdy by se mohly doručit stovky až tisíce zpráv se stejnou chybou pro různé objekty. Alerty lze také dočasně odložit přes webové rozhraní Alertmanagera nebo permanentně vyjmout v rámci notifikačních pravidel – ideální data, která nepotřebujeme, bez scrapování nebo neukládání do databáze.
Interní monitoring
Interní monitoring je architektonicky podobný externímu monitoringu s rozdílem v tom, že konfigurace neobsahují seznam „list“ domén, ale IP:PORT párů stovek exportérů pro různé technologické části infrastruktury, které jsou generovány staticky (admin) nebo dynamicky (Service discovery).
Kromě systému serverů a hardwaru monitorujeme MariaDB, ElasticSearch, Nginx, PHP-FPM, Redis Cluster, Memcached, Gearman, Thumbor, Gitlab, DRBD, Dovecot, Postfix, Pacemaker a Corosync cluster.
Zaznamenáváme téměř 75 000 různých „time series“ každých 10–30 s v závislosti na důležitosti a frekvenci, s jakou se mění. Provádí se nad nimi přes sto notifikačních pravidel. Interní monitoring poskytuje přehled nad stavem infrastruktury, což nám umožňuje rychle jednat v případě problému a předcházet problémům podobně jako při externím monitoringu. Zároveň nám ale slouží jako nezbytný prvek při optimalizaci konfigurace softwaru a hardwaru.
Základní a jeden z nejdůležitějších exportérů je node_exporter vyvíjený v rámci Prometheus systému, který zajišťuje monitorování operačního systému, základní přehled služeb a stavu hardware serveru.
Systémové notifikace zahrnují varování o nedostatku fyzické paměti – „memory pressure“, jehož zvýšená hodnota je znakem nárůstu alokace paměti EDAC, které zaznamenává opravitelné a neopravitelné chyby paměti, vysoké nebo nízké vytížení CPU, čekání CPU na IO (filesystem), dosažení maximální propustnosti síťového připojení nebo ztrátu či opakované posílání paketů.
Notifikace slouží k upozornění o problému ideálně předtím, než nastal, pro optimalizaci a plánování infrastruktury slouží nástroj Grafana, který umožňuje grafické zobrazení metrik a zároveň je pomůckou pro řešení problémů nebo identifikaci podmínek, které problémům předcházely. Grafana se používá i v rámci externího monitoringu, avšak pouze pro historickou analýzu či statistické účely.
I při monitoringu je optimalizace důležitá stejně jako u služeb které monitorujeme.
Monitoring a exportéry mohou mít negativní dopad na výkon, a proto je nezbytné scrapovat jen data, která opravdu potřebujeme. Často lze některá data vydedukovat nebo přímo spočítat na základě jiných dat.
Závěr:
Význam monitorování rostl od prvních počítačových systémů, kde bylo nutné zjistit, zda aplikace plné využívají dostupný hardware, až po současnost, kdy denně používáme nespočet aplikací, které často bez našeho vědomí přistupují ke službám na vzdálených serverech. Jejich funkčnost a rychlost bereme za samozřejmost, ale bez správného monitorování toho nelze dosáhnout.
Monitorovací systém již neslouží jen ke zjištění stavu serverů a sítě, která je propojuje s uživateli, ale stal se nezbytným nástrojem pro budoucí plánování, optimalizace, ale i zdroj informací, které přímo neslouží pouze DevOps týmům, ale lze je použít i pro business a marketingové účely.
