Hlavní navigace

Nástroje a služby využívané při nasazování mikroslužeb

Pavel Tišnovský

V páté části seriálu o mikroslužbách se seznámíme s některými užitečnými nástroji a službami, které se používají při vývoji, nasazování i sledování mikroslužeb. Jedná se například o Apache ZooKeeper, Prometheus, Grafana atd.

Doba čtení: 25 minut

Sdílet

11. Podrobnější informace o konceptech, na kterých je postaven Apache ZooKeeper

12. API ZooKeepera

13. Monitoring mikroslužeb

14. Nástroj Prometheus

15. Dotazovací jazyk PromQL

16. Konfigurace dashboardů s výsledky monitoringu

17. Upozornění v případě, že se detekuje problém

18. Obsah další části seriálu

19. Odkazy na Internetu

1. Nástroje a služby využívané při nasazování mikroslužeb

„Microservices is more than source code and containers.“

V prvních třech částech seriálu o mikroslužbách [1] [2] [3] jsme se seznámili se základními myšlenkami, na nichž je architektura aplikací postavených na mikroslužbách založena. Minule jsme se již začali zabývat konkrétními technikami a nástroji, které se v oblasti mikroslužeb používají. Připomeňme si jen ve stručnosti, že se jednalo o populární nástroj Apache Kafka, jenž umožňuje takzvaný streaming dat – zpráv, událostí, záznamů o změnách v databázi atd. Projektem Apache Kafka se samozřejmě budeme podrobněji zabývat v praktické části seriálu.

Dnes se seznámíme s dalšími vybranými nástroji a službami, které je možné využít při vývoji a nasazení aplikací založených na mikroslužbách. V současnosti totiž pochopitelně není nutné začínat vývoj mikroslužeb zcela „on nuly a na zelené louce“, protože je již k dispozici poměrně velké množství prostředků, které nám mohou v této práci pomoci, například v oblasti monitoringu, jmenné (adresářové) služby, vyhledávání služeb, jejich nasazení apod.

Poznámka: již dopředu je nutné upozornit na to, že ne všechny dnes popisované nástroje a služby spadají do kategorie otevřeného software.

2. Realizace samotných mikroslužeb

Samotné mikroslužby mohou být realizovány relativně snadno (alespoň z hlediska použitých technologií, protože business logika může být někdy hodně složitá). Primárním způsobem komunikace mikroslužeb s okolím je v současnosti protokol HTTP(S) a REST; ovšem nesmíme zapomenout ani na protokoly používané při komunikaci s message brokerem (AMQP, MQTT, STOMP, XMPP). Pro samotnou realizaci je možné použít různé programovací jazyky, například (z těch používanějších jazyků) Javu, Python, Ruby, JavaScript (TypeScript) a v neposlední řadě i programovací jazyk Go. Pro každý z těchto jazyků popř. ekosystémů existují knihovny a frameworky určené (mimo dalších použití) právě pro tvorbu mikroslužeb. V následující tabulce jsou některé z těchto knihoven/frameworků vypsány, ovšem pochopitelně se nejedná o úplný přehled, protože mikroslužbu můžeme v případě potřeby naprogramovat například i v čistém céčku s využitím socketů, knihoven 0MQ, nanomsg atd.:

# Jazyk/ekosystém Knihovna či framework
1 Java Vert.x, Spring Boot, Dropwizard, Ninja
2 Python Django REST framework, FlaskRESTful, restless, Falcon
3 Ruby Rails, Grape, Sinatra, Hanami
4 JavaScript/TypeScript Seneca, Koa, LoopBack
5 Go Goa, standardní balíček net/http
6 Clojure Ring, Liberator, Compojure
Poznámka: pravděpodobně jste si všimli, že se mnohdy jedná o „obyčejné“ knihovny poskytující REST API. To je v pořádku, protože mnohdy nic dalšího než realizaci několika REST API endpointů ani nevyžadujeme (ostatně samotný název „mikroslužby“ evokuje, že si mnohdy vystačíme pouze se základními technologiemi).

3. Realizace a nasazení message brokerů

Poznámka: tato kapitola je do článku zařazena jen kvůli úplnosti, protože message brokerům jsme se poměrně podrobně věnovali ve třetí části tohoto seriálu nazvané příznačně Posílání zpráv v aplikacích založených na mikroslužbách, popř. v samostatném seriálu.

Další částí architektury aplikace založené na mikroslužbách jsou message brokery. V této oblasti sice neexistuje taková shoda, jako u rozhraní mikroslužeb (dnes v naprosté většině případů HTTP, REST, JSON/XML), ovšem skupina používaných protokolů je stále dosti malá:

# Zkratka Protokol
1 AMQP x.y Advanced Message Queuing Protocol verze x.y
2 STOMP Streaming Text Oriented Messaging Protocol
3 MQTT MQTT is a machine-to-machine connectivity protocol
4 NATS protocol protokol systému NATS (podobný STOMPu)

Výběr konkrétního message brokera (pokud se bavíme o použití strategií PUSH-PULL a PUB-SUB) je tak do určité míry omezen vybraným protokolem (a naopak). Z často používaných message brokerů, které lze nasadit na vlastní počítače, se zmíníme o známých projektech:

# Message broker Podporované protokoly
1 RabbitMQ AMQP, STOMP, MQTT
2 Apache ActiveMQ AMQP 1.0, STOMP, MQTT a další
3 ActiveMQ Artemis AMQP, OpenWire, MQTT, STOMP
4 NATS NATS protocol
Poznámka: při samotném nasazování message brokera si musíme uvědomit, že se obecně nejedná o bezstavovou službu, protože message broker typicky používá nějaké datové úložiště pro zajištění persistence zpráv ve strategii PUSH-PULL a v kombinovaných komunikačních strategiích PUSH-PULL+PUB-SUB.

4. Message broker jako služba

V některých případech (a počet těchto případů bude s velkou pravděpodobností stále narůstat) může být výhodnější namísto snahy o nasazení (a administraci, sledování atd.) vlastního message brokera použít službu nabízenou všemi cloud providery, tedy společnostmi, které provozují větší či menší cloudové služby, jež jsou nabízeny a pochopitelně i zpoplatněny. Z cloudových message brokerů se jedná především o:

# Message broker Provozovatel služby
1 Amazon Simple Queue Service (SQS) Amazon (AWS)
2 Microsoft Azure Service Bus Microsoft (Azure)
3 StormMQ StormMQ Limited
4 IBM MQ (dříve MQSeries) IBM

Pro streaming, záznam logů, sledování změn v databázích atd. se v současnosti primárně používá minule představený systém Apache Kafka nebo méně často pak jednodušší NATS Streaming Server.

Ovšem i streamovací platformy jsou nabízeny společnostmi provozujícími cloudové služby. Jedná se například o Amazon MSK (Amazon Managed Streaming for Apache Kafka) v AWS (což je relativní novinka v oblasti celého AWS).

Obrázek 1: Příklad použití ekosystému Kafky (Kafka Streams, konektory pro databáze atd.).

5. Datová úložiště

Víme již, že jednou z nejsložitějších částí aplikace založené na mikroslužbách jsou datová úložiště. V této oblasti je k dispozici téměř nepřeberné množství různých typů databází a výběr konkrétní z nich pak do značné míry závisí na tom, jaká data vlastně potřebujeme uložit, zda se vyžaduje plný ACID (Atomicity, Consistency, Isolation, Durability), jaké jsou požadované možnosti replikace, zda je nutné některé operace provádět v transakcích atd. Použít lze samozřejmě všechny relační databáze, NoSQL databáze, grafové databáze, perzistentní logy. Pro většinu databází existují konektory (connectors) umožňující volání funkcí databáze z různých programovacích jazyků, takže výběr databází je skutečně velký a většinou se nemusíme omezovat podle toho, jaký jazyk byl pro implementaci mikroslužby zvolen:

# Typ Implementace
1 relační databáze PostgreSQL, DB/2, Oracle, MySQL/MariaDB ale i SQLite
2 key-value Amazon DynamoDB, Redis, Memcached
3 dokumentové MongoDB, Apache CouchDB, Amazon SimpleDB
4 objektové Realm, Caché, Zope Object Database a mnoho dalších
5 grafové JanusGraph, Neo4j, Oracle Spatial and Graph, AllegroGraph
Poznámka: v této oblasti skutečně záleží na konkrétních požadavcích, protože například v oblasti relačních databází může pro jednu mikroslužbu plně dostačovat SQLite, zatímco jiná bude vyžadovat „plný“ Oracle.

6. Další prostředky využívané při nasazování a administraci mikroslužeb

Jaké další prostředky (nástroje, knihovny, služby, překladače, …) jsou tedy vlastně potřebné či alespoň užitečné při vývoji a nasazování aplikací založených na mikroslužbách? Mohlo by se zdát, že prostředků bude nutných poměrně malé množství, ostatně již termín „mikroslužby“ naznačuje, že by se nemělo jednat o složité komponenty. Ani při pohledu na obrázek se schématem jednoduché aplikace s architekturou založenou na několika mikroslužbách se nezdá, že by bylo nutné použít velké množství dalších nástrojů:

Obrázek 2: Schéma jednoduché aplikace s architekturou založenou na mikroslužbách.

Ve skutečnosti nepotřebujeme mnoho nástrojů pro vývoj jednotlivých mikroslužeb, ovšem pro jejich nasazení popř. orchestraci či choreografii již ano. Taktéž většinou budeme muset řešit i monitoring mikroslužeb, centralizované zpracování logů a další podobné činnosti.

7. Jednoduchá aplikace s jednotkami mikroslužeb

V předchozí kapitole jsme si uvedli obrázek s velmi jednoduchou aplikací složenou z pouhých pěti mikroslužeb; z toho dvě mikroslužby jsou dokonce bezstavové.

Pokud je aplikace skutečně jednoduchá a skládá se například ze tří až pěti mikroslužeb, může být relativně snadný a přehledný i celý ekosystém postavený okolo těchto pěti mikroslužeb. Pokud každá mikroslužba komunikuje s využitím REST API a používá nějaké datové úložiště (každá mikroslužba ideálně vlastní databázi), je možné takové služby nasadit například takto:

  1. Každá mikroslužba poběží ve vlastním procesu, ať již na společném počítači či na počítači vlastním (nebo virtuálním). Komunikovat s okolím bude pouze přes své REST API, další komunikace bude jen lokální (ve smyslu logiky, ne nutně síťové infrastruktury) a bude probíhat s datovým úložištěm. Technologie nutné k takovému nasazení jsou minimální (a liší se podle použitého programovacího jazyka): nodejs, Flask, Vertx atd.
  2. Můžeme taktéž použít podobný postup, ovšem s tím rozdílem, že jednotlivé mikroslužby poběží v kontejneru, například v Dockeru. Postačuje jen, aby bylo správně nastavené mapování TCP portů, aby byly koncové body REST API viditelné i pro okolí kontejneru.

Partner seriálu o mikroslužbách

V IGNUM mají rádi technologie a staví na nich vlastní mikroslužby, díky kterým je registrace a správa domén, hostingů a e-mailů pro zákazníky hračka. Vymýšlet jednoduchá řešení pro obsluhu složitých systémů a uvádět je v život je výzva. Společnost IGNUM miluje mikroslužby a je proto hrdým partnerem tohoto seriálu.

8. Přednosti a zápory mikroslužeb nasazených bez dalších podpůrných nástrojů

První z naznačených řešení se zdá být skutečně velmi přímočaré (protože vytvořit například demonstrační aplikaci postavenou na frameworku Flask je podle dobrého tutoriálu otázka maximálně několika desítek minut), ovšem skrývá se v něm hned několik úskalí. To se týká jak konfigurace a nasazování aplikace (jak má konfigurace vypadat, jak se aplikace nasazuje a inicializuje, včetně datového úložiště, jak se má nastavit firewall…), tak i například řešení situace, kdy nějaká mikroslužba zhavaruje. Další potenciální problémy se týkají konfigurace load balancingu, sledování logů (každá mikroslužba používá vlastní log) a vůbec sledování činnosti celé aplikace v reálném provozu či při zátěžových testech.

Druhý z naznačených postupů některé z výše naznačených problémů částečně řeší. Především se díky umístění mikroslužby do kontejneru dá poměrně přesně určit a nastavit operační systém a služby, které v něm běží (v ideálním případě je systém v kontejneru minimalizovaný jen na základní používané služby). Dobré je taktéž to, že díky konceptu kontejnerů jsme vlastně „přinuceni“ rozdělit každou mikroslužbu minimálně na dvě části – část neměnnou (immutable), což je většinou vlastní implementace REST API a business logiky a část proměnnou, což je datové úložiště. Toto rozdělení je velmi důležité i při dalších činnostech, například při nastavování load balancingu a taktéž při případném přechodu na řešení naznačená v dalších kapitolách (OpenShift, AWS Lambda atd.).

Představme si ovšem situaci, kdy se vyvíjená aplikace postupně rozroste a namísto pěti mikroslužeb bude používat například několik desítek mikroslužeb (což je v praxi poměrně běžné číslo, ani se nemusíme dívat na Netflix a podobné firmy s obří infrastrukturou), navíc ještě s tím požadavkem, aby některé operace byly řešeny asynchronně. V takovém případě již není ruční správa mikroslužeb možná a je zapotřebí se poohlédnout po dalších podpůrných nástrojích.

Obrázek 3: Hierarchický model aplikace se sdružením těch služeb, které k sobě patří buď logicky, nebo podle toho, jak intenzivně spolu komunikují. Taková architektura může mít desítky, možná i stovku mikroslužeb.

9. Aplikace s desítkami mikroslužeb

U aplikací, které se skládají z desítek či dokonce ze stovek mikroslužeb, si musíme položit následující otázky, protože případná změna může být velmi náročná:

  1. Jak vlastně spolu budou jednotlivé mikroslužby navzájem komunikovat? Bude výhodnější použít přímé volání API (tedy používat spojení typupoint-to-point), sběrnici pro přenos zpráv (enterprise message bus atd.), message broker, sdílenou databázi, streaming platformu pro přenos změn stavu systému či bude vhodnější použít nějakou kombinaci těchto prostředků?
  2. Které protokoly se budou používat pro komunikaci? Bude vše řešeno jediným protokolem (nejpravděpodobněji tedy HTTP + REST), nebo se použije více protokolů (HTTP, AMQP atd.)?
  3. Pokud spolu služby budou přímo komunikovat, jakým způsobem se vůbec naleznou? Pravděpodobně nebude nejlepší řešení, aby každá služba měla seznam s pevnými adresami dalších služeb, s nimiž má komunikovat.
  4. Bude každá služba používat vlastní logování, nebo bude výhodnější použít centralizovaný systém pro zápis logovacích informací? A co se stane ve chvíli, kdy tento centrální systém (což je jen další mikroslužba) z nějakého důvodu zhavaruje?
  5. Dokážeme v případě potřeby automaticky či poloautomaticky celý systém znovu nasadit? Může se to možná zdát divné, ale znám systémy, kde to pravděpodobně už nikdo (od nuly) nedokáže :)
  6. A nakonec samozřejmě velmi důležitá otázka – jak se dá vůbec zajistit, aby administrátoři či DevOps neztratili kontrolu na celou aplikací, tedy aby se jim celý systém „nerozsypal“ pod rukama.

Obrázek 4: Další dělení hierarchického modelu v případě, že se celý systém skládá ze stovek mikroslužeb.

10. Projekt Apache ZooKeeper

Ve světě mikroslužeb se dosti často setkáme s projektem nazvaným Apache ZooKeeper, což je poměrně přiléhavý název, neboť jednou z primárních funkcí tohoto projektu je zajišťovat koordinaci mezi jednotlivými komponentami, z nichž se celá aplikace skládá. Na ZooKeeper se můžeme dívat jako na centralizovanou (mikro)službu obsahující datové úložiště (hierarchické typu key-value, podobá se běžné adresářové struktuře, ovšem s několika vylepšeními), které může obsahovat například konfiguraci celé aplikace, může sloužit jako adresářová služba (naming service) apod. Díky tomu, že je ZooKeeper ústřední komponentou se známými přístupovými body, mohou ho kontaktovat ostatní mikroslužby například ve chvíli, kdy potřebují získat informace o jiné mikroslužbě, o své vlastní konfiguraci, databázi atd. A právě z toho důvodu, že je ZooKeeper navržen jako ústřední a tedy kritická komponenta celé aplikace, podporuje redundanci a HA nasazení. Pro komunikaci mezi jednotlivými uzly se používá protokol ZooKeeper Atomic Broadcast (ZAB).

Obrázek 5: Hierarchický způsob uložení dat v datovém úložišti ZooKeepera. Povšimněte si, že způsob pojmenování uzlů skutečně odpovídá běžné adresářové struktuře, ovšem ve skutečnosti mohou i uzly typu „adresář“ obsahovat data, podobně jako koncové uzly typu „soubor“.

Na předchozím obrázku je ukázán (ve značně zjednodušené podobě) způsob uložení dat do uzlů (znode). Tento způsob uložení se podobá klasické adresářové struktuře, ovšem s tím rozdílem, že jednotlivé uzly mohou obsahovat atributy. Čtení a zápis dat z/do jednotlivých uzlů je proveden atomicky (z pohledu konzumenta těchto dat). Ve skutečnosti existují tři typy uzlů:

  1. Běžné uzly (regular), které klienti vytváří a mažou explicitními operacemi.
  2. Takzvané pomíjivé (ephemeral) uzly, které jsou opět vytvářené klienty. Klienti tyto uzly mohou mazat explicitně nebo se uzly vymažou automaticky po odpojení klientů.
  3. Sekvenční uzly (sequential) u nichž se při jejich vytváření ke jménu automaticky připojí i unikátní číslo generované ze sekvence. Tento typ uzlů umožňuje relativně snadno realizovat složitější struktury, které jsou vlastně simulovány ve stromové struktuře z-uzlů.

Každý uzel navíc obsahuje Access Control List (ACL) umožňující řízení, kdo (jaký klient) z uzlu může data číst a kdo zapisovat.

11. Podrobnější informace o konceptech, na kterých je postaven Apache ZooKeeper

Po přečtení předchozí kapitoly čtenáře možná napadlo, že Apache ZooKeeper je jen reimplementací LDAPu či podobné jmenné služby. Ve skutečnosti jsou však možnosti tohoto projektu větší, protože kromě klasické jmenné (adresářové) služby je možné ZooKeeper použít pro implementaci bariér (koordinace mezi větším množstvím služeb) či dokonce klasické fronty s producenty a konzumenty. Na následujícím obrázku je nakreslena jedna z možných konfigurací tohoto projektu:

Obrázek 6: Jedna z možných konfigurací projektu Apache ZooKeeper s několika servery, z nichž jeden je leaderem. Klienti se mohou připojit na libovolný z těchto serverů.

Služba ZooKeepera je v tomto případě složena z několika serverů, přičemž jeden z těchto serverů byl zvolen do funkce leadera. Jednotlivé servery spolu komunikují a každý server obsahuje obraz se stavem DB, transakčním logem atd. Jednotliví klienti, kteří potřebují využívat služeb ZooKeepera, se mohou připojit k libovolnému serveru. Po provedení připojení se mezi klientem a serverem posílají mj. i takzvané heart beats, tedy krátké zprávy informující druhou stranu, že komunikující uzel stále ještě žije a odpovídá. Pokud dojde k přerušení připojení, může se klient pokusit o připojení k jinému serveru se ZooKeeperem.

Celý koncept databáze ZooKeepera je založen na předpokladu, že čtení dat bude probíhat mnohem častěji, než zápis (což je zcela jistě pravda například pro již několikrát zmíněné adresářové služby, konfigurace služeb atd.). Uvádí se, že poměr čtení:zápis by měl být minimálně 10:1, aby bylo použití ZooKeepera efektivní. Jedním z důvodů, proč je zápis potenciálně „drahou“ operací, je fakt, že každá změna obsahuje mj. i razítko s číslem, které jednoznačně určuje pořadí změny v rámci všech transakcí (ZooKeeper Transaction Id). Nad těmito jednoduchými a nízkoúrovňovými operacemi (zápis s otiskem razítka) je možné vybudovat vysokoúrovňové operace, například synchronizační mechanismy (výše zmíněnou bariéru atd.). Navíc čtení může proběhnout v libovolném serveru ZooKeepera, kdežto zápis je přeposlán leaderovi, který následně bude informovat ostatní servery o této operaci a bude čekat na úspěšný „propis“ změn u minimálně poloviny serverů (aby byl zachován princip většiny, což ale mimochodem znamená, že není zaručena konzistence přečtených dat).

I přesto, že je ZooKeeper velmi rychlý a vlastně i jednoduchý, zajišťuje několik důležitých vlastností:

  1. Změny prováděné klientem budou aplikovány vždy v tom pořadí, v jakém byly klientem poslány.
  2. Všechny změny jsou atomické, tj. buď se kompletně provedou nebo neprovedou. Systém nebude poskytovat jakýkoli mezistav (resp. tento mezistav nebude viditelný při čtení uzlů).
  3. Ve chvíli, kdy je změna provedena, bude zachována až do chvíle, kdy klient provede v daném uzlu novou změnu.

To však zdaleka není vše, protože ZooKeeper není pouhá distribuovaná databáze se zaručeným pořadím operací. Tento systém totiž podporuje i takzvané sledování (watch), což je podobný koncept, jaký známe například z některých debuggerů, v nichž lze sledovat změnu stavu vybraného objektu (proměnné atd.). V případě ZooKeepera se může jakýkoli klient rozhodnout, že bude sledovat určitý uzel. Ve chvíli, kdy se uzel změní, dostane o tom klient informaci a může na ni adekvátně reagovat. Tímto způsobem se u některých služeb řešil takzvaný mailboxing.

12. API ZooKeepera

Jedním z cílů při návrhu ZooKeepera bylo poskytnutí co nejjednoduššího aplikačního programového rozhraní. API je skutečně pojato minimalisticky:

# Operace Význam
1 create vytvoření uzlu ve zvoleném místě stromu
2 delete opak předchozí operace; vymazání uzlu ze zvoleného místa stromu
3 exists dotaz, zda na zvoleném místě ve stromu existuje uzel
4 get data přečtení dat z uzlu
5 set data opak předchozí operace: zápis dat do uzlu
6 get children získání seznamu přímých potomků uzlu
7 sync čekání, až se změny zpropagují
Poznámka: ZooKeeper je vyžadován i minule popsaným systémem Apache Kafka, a to z toho důvodu, aby se zjednodušila správa celého clusteru s brokery.

13. Monitoring mikroslužeb

„Java is 20 years old, mature, and comes with unbeatable tooling and monitoring capabilities. At the very beginning, Java already incorporated microservice concepts with the Jini / JXTA frameworks mixed with no-SQL databases like e.g. JavaSpaces. As often – Java was just 15 years too early. The market was not ready for the technology back then. However, all the design principles from 1999 still do apply today. We don't have re-invent the wheel.“

Zapomenout nesmíme ani na nástroje umožňující provádět monitoring. Těchto nástrojů sice existuje větší množství (například Kibana a Sysdig monitor), ovšem dnes pravděpodobně nejlepším řešením je v současnosti Prometheus, ideálně ve spojení s Grafanou.

14. Nástroj Prometheus

Systém Prometheus používá databázi, do které se ukládají prakticky libovolné (číselné) hodnoty, které jsou opatřeny časovým razítkem, kromě toho i jménem metriky (ta musí být unikátní) a návěštím (label) umožňujícím podrobnější dělení hodnot, například podle toho, v jakém prostředí je měření prováděno. To znamená, že pro zvolenou metriku, popř. pro metriku a návěští je možné získat celou časovou posloupnost s hodnotami, vracet se do minulosti, získat informace pro zvolené časové období apod. Samotné hodnoty jsou interně zpracovávány jako datový typ double/float64 (konkrétní jednotka již záleží na intepretaci dat) a časová razítka mají milisekundovou přesnost, což by mělo být pro účely tohoto nástroje dostačující, už jen z toho důvodu, že samotné pořízení záznamu přes API Promethea má určitou časovou složitost.

15. Dotazovací jazyk PromQL

Důležitou součástí Promethea je i PromQL, což je relativně snadno použitelný dotazovací jazyk používaný pro získání potřebných metrik, agregaci výsledků apod. Můžeme si ostatně uvést příklad jednoduchého dotazu, který vrátí časovou posloupnost hodnot trvání přípravy odpovědi na HTTP požadavky (předpokládejme, že jméno této metriky je „http_requests_total“):

http_requests_total

Celkovou dobu a průměrnou dobu získáme stejně snadno:

sum(http_requests_total)
avg(http_requests_total)

V dotazu ovšem můžeme provést i jemnější dělení, například podle návěští:

http_requests_total{job="prometheus",group="canary"}

V jazyku PromQL lze využívat například i regulární výrazy, což nám umožňuje získat časy odpovědí na HTTP dotazy typu GET, ovšem pouze pro zvolená prostředí:

http_requests_total{environment=~"staging|testing|development",method!="GET"}

Dotazovací jazyk PromQL je primárně určen pro práci s časovými řadami, takže nepřekvapí ani dobrá podpora specifikace časového období, pro které potřebujeme data získat. Výsledky trvání vyřízení HTTP dotazů typu GET za posledních pět minut by se získaly takto:

http_requests_total{job="prometheus"}[5m]

Výsledky za posledních třicet minut, ovšem s rozlišením jedné minuty:

rate(http_requests_total[5m])[30m:1m]

16. Konfigurace dashboardů s výsledky monitoringu

Kromě dotazů zapisovaných v jazyku PromQL je podporován již zmíněný výstup ve formě plně konfigurovatelných grafů, z nichž se posléze vytváří různé dashboardy, které sledují stav celého systému či jeho jednotlivých částí. Pro tento účel se používá Grafana. Pokud chcete vidět, jak může vypadat výstup z kombinace Prometheus+Grafana, můžete se podívat na obrázek na adrese https://prometheus.io/asset­s/grafana_prometheus.png.

Diners Vánoce 2019

Poznámka: screenshoty z našeho produkčního systému nemám zveřejňovat…

17. Upozornění v případě, že se detekuje problém

Možnost zobrazení záznamů (časových řad s hodnotami) je samozřejmě velmi užitečná, ovšem v praxi mnohdy potřebujeme, aby byli administrátoři či devops varováni ve chvíli, kdy dojde k určité události, například když klesne hodnota volné RAM, markantně se zvýší čas odezvy serveru atd. Pro tento účel používá systém Prometheus další komponentu nazvanou příhodně Alertmanager, kterou je možné nakonfigurovat takovým způsobem, aby na naprogramované události (či mnohem častěji na jejich souběh) nějakým vhodným způsobem reagovala. Samozřejmě je možné zvolit například poslání zprávy přes připravená rozhraní (Slack, HipChat, včetně běžného e-mailu) nebo lze nakonfigurovat poslání obecnějšího webhooku do prakticky libovolné služby.

18. Obsah další části seriálu

V další části seriálu se budeme zabývat problematikou FaaS neboli Function as a service. Zaměříme se především na služby dostupné v systému Amazon Web Services (AWS).

19. Odkazy na Internetu

  1. Alertmanager
    https://prometheus.io/doc­s/alerting/alertmanager/
  2. Grafana support for Prometheus
    https://prometheus.io/doc­s/visualization/grafana/
  3. goa
    https://stackshare.io/goa
  4. goa (GitHub)
    https://github.com/goadesign/goa
  5. Grafana support for Prometheus
    https://prometheus.io/doc­s/visualization/grafana/
  6. Useful Tools for Managing Complexity of Microservice Architecture
    https://blog.byndyusoft.com/useful-tools-for-managing-complexity-of-microservice-architecture-109a2289acc
  7. Three pillars of microservice culture
    https://www.oreilly.com/ideas/three-pillars-of-microservice-culture
  8. Prometheus: from metrics to insight
    https://prometheus.io/
  9. Docker Swarm
    https://docs.docker.com/swarm/
  10. Kubernetes: production-Grade Container Orchestration
    https://kubernetes.io/
  11. 29 Top Tools for Building Microservices on All Levels
    https://dzone.com/articles/30top-tools-for-building-microservices-on-all-leve
  12. The 8 best open-source tools for building microservice apps
    https://techbeacon.com/enterprise-it/8-best-open-source-tools-building-microservice-apps
  13. Consul
    https://www.consul.io/
  14. Apache ZooKeeper
    https://zookeeper.apache.org/
  15. ZooKeeper: Because Coordinating Distributed Systems is a Zoo
    http://zookeeper.apache.or­g/doc/current/index.html
  16. ZooKeeper: A Distributed Coordination Service for Distributed Applications
    http://zookeeper.apache.or­g/doc/current/zookeeperOver­.html
  17. Understanding Kafka with Legos (video)
    https://www.youtube.com/wat­ch?v=Q5wOegcVa8E
  18. Apache Kafka Tutorial For Beginners (video)
    https://www.youtube.com/wat­ch?v=U4y2R3v9tlY
  19. Franz Kafka (Wikipedia)
    https://en.wikipedia.org/wi­ki/Franz_Kafka
  20. NATS
    https://nats.io/about/
  21. NATS Streaming Concepts
    https://nats.io/documenta­tion/streaming/nats-streaming-intro/
  22. NATS Streaming Server
    https://nats.io/download/nats-io/nats-streaming-server/
  23. NATS Introduction
    https://nats.io/documentation/
  24. NATS Client Protocol
    https://nats.io/documenta­tion/internals/nats-protocol/
  25. NATS Messaging (Wikipedia)
    https://en.wikipedia.org/wi­ki/NATS_Messaging
  26. Stránka Apache Software Foundation
    http://www.apache.org/
  27. Logstash
    https://www.elastic.co/pro­ducts/logstash
  28. Elasticsearch
    https://www.elastic.co/pro­ducts/elasticsearch
  29. Understanding When to use RabbitMQ or Apache Kafka
    https://content.pivotal.i­o/blog/understanding-when-to-use-rabbitmq-or-apache-kafka
  30. Part 1: Apache Kafka for beginners – What is Apache Kafka?
    https://www.cloudkarafka.com/blog/2016–11–30-part1-kafka-for-beginners-what-is-apache-kafka.html
  31. What are some alternatives to Apache Kafka?
    https://www.quora.com/What-are-some-alternatives-to-Apache-Kafka
  32. What is the best alternative to Kafka?
    https://www.slant.co/opti­ons/961/alternatives/~kaf­ka-alternatives
  33. Apache Flume
    https://flume.apache.org/index.html
  34. Snare
    https://www.snaresolutions.com/
  35. The Log: What every software engineer should know about real-time data's unifying abstraction
    https://engineering.linke­din.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
  36. A super quick comparison between Kafka and Message Queues
    https://hackernoon.com/a-super-quick-comparison-between-kafka-and-message-queues-e69742d855a8?gi=e965191e72d0
  37. Kafka Queuing: Kafka as a Messaging System
    https://dzone.com/articles/kafka-queuing-kafka-as-a-messaging-system
  38. Microservices – Not a free lunch!
    http://highscalability.com/blog/2014/4/8/mi­croservices-not-a-free-lunch.html
  39. Microservices, Monoliths, and NoOps
    http://blog.arungupta.me/microservices-monoliths-noops/
  40. Microservice Design Patterns
    http://blog.arungupta.me/microservice-design-patterns/
  41. Vision of a microservice revolution
    https://www.jolie-lang.org/vision.html
  42. Microservices: a definition of this new architectural term
    https://martinfowler.com/ar­ticles/microservices.html
  43. Mikroslužby
    http://voho.eu/wiki/mikrosluzba/
  44. Microservice Prerequisites
    https://martinfowler.com/bli­ki/MicroservicePrerequisi­tes.html
  45. Microservices in Practice, Part 1: Reality Check and Service Design (vyžaduje registraci)
    https://ieeexplore.ieee.or­g/document/7819415
  46. Microservice Trade-Offs
    https://www.martinfowler.com/ar­ticles/microservice-trade-offs.html
  47. What is a microservice? (from a linguistic point of view)
    http://claudioguidi.blogspot­.com/2017/03/what-microservice-from-linguisitc.html
  48. Microservices (Wikipedia)
    https://en.wikipedia.org/wi­ki/Microservices
  49. Fallacies of distributed computing (Wikipedia)
    https://en.wikipedia.org/wi­ki/Fallacies_of_distributed_com­puting
  50. Service (systems architecture)
    https://en.wikipedia.org/wi­ki/Service_(systems_archi­tecture)
  51. Microservices in a Nutshell
    https://www.thoughtworks.com/in­sights/blog/microservices-nutshell
  52. What is Microservices?
    https://smartbear.com/solu­tions/microservices/
  53. Mastering Chaos – A Netflix Guide to Microservices
    https://www.youtube.com/wat­ch?v=CZ3wIuvmHeM&t=17s
  54. Messaging in Microservice Architecture
    https://www.youtube.com/wat­ch?v=MkQWQ5f-SEY
  55. Pattern: Messaging
    https://microservices.io/pat­terns/communication-style/messaging.html
  56. Microservices Messaging: Why REST Isn’t Always the Best Choice
    https://blog.codeship.com/mi­croservices-messaging-rest-isnt-always-best-choice/
  57. Protocol buffers
    https://developers.google.com/protocol-buffers/
  58. BSON
    http://bsonspec.org/
  59. Apache Avro!
    https://avro.apache.org/
  60. REST vs Messaging for Microservices – Which One is Best?
    https://solace.com/blog/experience-awesomeness-event-driven-microservices/
  61. How did we end up here?
    https://gotocon.com/dl/goto-chicago-2015/slides/MartinThompson_an­d_ToddMontgomery_HowDidWe­EndUpHere.pdf
  62. Scaling microservices with message queues to handle data bursts
    https://read.acloud.guru/scaling-microservices-with-message-queue-2d389be5b139
  63. Microservices: What are smart endpoints and dumb pipes?
    https://stackoverflow.com/qu­estions/26616962/microser­vices-what-are-smart-endpoints-and-dumb-pipes
  64. Common Object Request Broker Architecture
    https://en.wikipedia.org/wi­ki/Common_Object_Request_Bro­ker_Architecture
  65. Enterprise service bus
    https://en.wikipedia.org/wi­ki/Enterprise_service_bus
  66. Microservices vs SOA : What’s the Difference
    https://www.edureka.co/blog/mi­croservices-vs-soa/
  67. Pravda o SOA
    https://businessworld.cz/reseni-a-realizace/pravda-o-soa-2980
  68. Is it a good idea for Microservices to share a common database?
    https://www.quora.com/Is-it-a-good-idea-for-Microservices-to-share-a-common-database
  69. Pattern: Shared database
    https://microservices.io/pat­terns/data/shared-database.html
  70. Is a Shared Database in Microservices Actually an Anti-pattern?
    https://hackernoon.com/is-shared-database-in-microservices-actually-anti-pattern-8cc2536adfe4
  71. Shared database in microservices is a problem, yep
    https://ayende.com/blog/186914-A/shared-database-in-microservices-is-a-problem-yep
  72. Microservices with shared database? using multiple ORM's?
    https://stackoverflow.com/qu­estions/43612866/microser­vices-with-shared-database-using-multiple-orms
  73. Examples of microservice architecture
    https://www.coursera.org/lecture/intro-ibm-microservices/examples-of-microservice-architecture-JXOFj
  74. Microservices: The Rise Of Kafka
    https://movio.co/blog/microservices-rise-kafka/
  75. Building a Microservices Ecosystem with Kafka Streams and KSQL
    https://www.confluent.io/blog/building-a-microservices-ecosystem-with-kafka-streams-and-ksql/
  76. An introduction to Apache Kafka and microservices communication
    https://medium.com/@ulymarins/an-introduction-to-apache-kafka-and-microservices-communication-bf0a0966d63
  77. ACID (computer science)
    https://en.wikipedia.org/wi­ki/ACID_(computer_science)
  78. Distributed transaction
    https://en.wikipedia.org/wi­ki/Distributed_transaction
  79. Two-phase commit protocol
    https://en.wikipedia.org/wiki/Two-phase_commit_protocol
  80. Why is 2-phase commit not suitable for a microservices architecture?
    https://stackoverflow.com/qu­estions/55249656/why-is-2-phase-commit-not-suitable-for-a-microservices-architecture
  81. 4 reasons why microservices resonate
    https://www.oreilly.com/ideas/4-reasons-why-microservices-resonate
  82. Pattern: Microservice Architecture
    https://microservices.io/pat­terns/microservices.html
  83. Pattern: Monolithic Architecture
    https://microservices.io/pat­terns/monolithic.html
  84. Pattern: Saga
    https://microservices.io/pat­terns/data/saga.html
  85. Pattern: Database per service
    https://microservices.io/pat­terns/data/database-per-service.html
  86. Pattern: Access token
    https://microservices.io/pat­terns/security/access-token.html
  87. Databázová integrita
    https://cs.wikipedia.org/wi­ki/Datab%C3%A1zov%C3%A1_in­tegrita
  88. Referenční integrita
    https://cs.wikipedia.org/wi­ki/Referen%C4%8Dn%C3%AD_in­tegrita
  89. Introduction into Microservices
    https://specify.io/concep­ts/microservices
  90. Are Microservices ‘SOA Done Right’?
    https://intellyx.com/2015/07/20/are-microservices-soa-done-right/
  91. The Hardest Part About Microservices: Your Data
    https://blog.christianpos­ta.com/microservices/the-hardest-part-about-microservices-data/
  92. From a monolith to microservices + REST
    https://www.slideshare.net/InfoQ/from-a-monolith-to-microservices-rest-the-evolution-of-linkedins-service-architecture
  93. DevOps and the Myth of Efficiency, Part I
    https://blog.christianpos­ta.com/devops/devops-and-the-myth-of-efficiency-part-i/
  94. DevOps and the Myth of Efficiency, Part II
    https://blog.christianpos­ta.com/devops/devops-and-the-myth-of-efficiency-part-ii/
  95. Standing on Distributed Shoulders of Giants: Farsighted Physicists of Yore Were Danged Smart!
    https://queue.acm.org/deta­il.cfm?id=2953944
  96. Building DistributedLog: High-performance replicated log service
    https://blog.twitter.com/en­gineering/en_us/topics/in­frastructure/2015/building-distributedlog-twitter-s-high-performance-replicated-log-servic.html
  97. Turning the database inside-out with Apache Samza
    https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/
  98. Debezium: Stream changes from your databases.
    https://debezium.io/
  99. Change data capture
    https://en.wikipedia.org/wi­ki/Change_data_capture
  100. Apache Samza (Wikipedia)
    https://en.wikipedia.org/wi­ki/Apache_Samza
  101. Storm (event processor)
    https://en.wikipedia.org/wi­ki/Storm_(event_processor)
  102. kappa-architecture.com
    http://milinda.pathirage.org/kappa-architecture.com/
  103. Questioning the Lambda Architecture
    https://www.oreilly.com/i­deas/questioning-the-lambda-architecture
  104. Lambda architecture
    https://en.wikipedia.org/wi­ki/Lambda_architecture
  105. Event stream processing
    https://en.wikipedia.org/wi­ki/Event_stream_processing
  106. How to beat the CAP theorem
    http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
  107. Kappa Architecture Our Experience
    https://events.static.linux­found.org/sites/events/fi­les/slides/ASPgems%20-%20Kappa%20Architecture.pdf
  108. Messaging Patterns in Event Driven Microservice Architectures
    https://www.youtube.com/wat­ch?v=3×Dc4MEYuHI
  109. Why monolithic apps are often better than microservices
    https://gigaom.com/2015/11/06/why-monolithic-apps-are-often-better-than-microservices/
  110. How Enterprise PaaS Can Add Critical Value to Microservices
    https://apprenda.com/blog/enterprise-paas-microservices/
  111. Common React Mistakes: Monolithic Components and a Lack of Abstraction
    https://www.pmg.com/blog/common-react-mistakes-monolithic-components-lack-abstraction/
  112. From monolith to microservices – to migrate or not to migrate?
    https://altkomsoftware.pl/en/blog/mo­nolith-microservices/
  113. Command–query separation
    https://en.wikipedia.org/wi­ki/Command%E2%80%93query_se­paration
  114. GOTO 2016: Messaging and Microservices (Clemens Vasters)
    https://www.youtube.com/wat­ch?v=rXi5CLjIQ9kx
  115. GOTO Amsterdam 2019
    https://gotoams.nl/
  116. Lesson 2 – Kafka vs. Standard Messaging
    https://www.youtube.com/wat­ch?v=lwMjjTT1Q-Q
  117. CommandQuerySeparation (Martin Fowler)
    https://martinfowler.com/bli­ki/CommandQuerySeparation­.html
  118. Command–query separation
    https://en.wikipedia.org/wi­ki/Command%E2%80%93query_se­paration
  119. CQRS – Martin Fowler
    https://martinfowler.com/bli­ki/CQRS.html
  120. Lesson 12 – CQRS and Microservices
    https://www.youtube.com/wat­ch?v=pUGvXUBfvEE
  121. Message queues - the right way to process and work with realtime data on your servers
    https://www.ably.io/blog/message-queues-the-right-way
  122. Function as a service
    https://en.wikipedia.org/wi­ki/Function_as_a_service
  123. AWS Lambda
    https://en.wikipedia.org/wi­ki/AWS_Lambda