Jak monitorovat zlaté signály SRE

Vlastně získávání metrik z běžných služeb

(Poznámka: Bezplatná elektronická kniha PDF této celé 6dílné série je k dispozici zde)

Technologie spolehlivosti stránek (SRE) a související koncepty jsou v poslední době velmi populární, částečně díky slavné knize Google SRE a dalším, kteří hovoří o „zlatých signálech“, které byste měli sledovat, abyste své systémy udrželi rychlé a spolehlivé, jak se mění.

Zdá se, že každý souhlasí s tím, že tyto signály jsou důležité, ale jak je vlastně sledujete? Zdá se, že o tom nikdo moc nehovoří.

Tyto signály je mnohem těžší získat než tradiční monitorování CPU nebo RAM, protože každá služba a zdroj má různé metriky, definice a zejména potřebné nástroje.

Microservices, Containers a Serverless dělají získání signálů ještě náročnějšími, ale stále stojí za to, protože tyto signály potřebujeme - jak předcházet tradičnímu výstražnému šumu, tak efektivně řešit naše stále složitější distribuované systémy.

Tato řada článků projde signály a praktickými metodami pro řadu běžných služeb. Nejprve si krátce povíme o samotných signálech, pak o tom, jak je můžete použít ve svém monitorovacím systému.

Konečně je zde seznam průvodců specifických pro službu, jak monitorovat signály, pro Load Balancer, Web & App Servers, DB & Cache Servers, General Linux a další. Tento seznam a podrobnosti se mohou časem vyvíjet, protože neustále hledáme zpětnou vazbu a lepší metody pro získání lepších dat.

Za prvé, jaké jsou signály SRE?

Existují tři společné seznamy nebo metodiky:

  • Z knihy Google SRE: latence, provoz, chyby a sytost
  • USE Method (od Brendan Gregg): Využití, sytost a chyby
  • Metoda ČERVENÉ (od Toma Wilkieho): Míra, chyby a doba trvání

Můžete vidět překrývání a jak Baron Schwartz poznamenává ve svém sledování a pozorovatelnosti pomocí blogu USE a RED, každá metoda se liší v zaměření. Navrhuje, aby USE bylo o zdrojích s interním pohledem, zatímco RED se týká požadavků, skutečné práce, a tedy externího pohledu (z pohledu spotřebitele služby). Jsou zjevně propojené a také se vzájemně doplňují, protože každá služba spotřebovává prostředky k práci.

Pro naše účely se zaměříme na jednoduchou superset pěti signálů:

  • Míra - Míra žádosti, v požadavcích / sec
  • Chyby - míra chyb v chybách / sec
  • Latence - doba odezvy, včetně doby fronty / čekání, v milisekundách.
  • Sytost - Jak je něco přetíženo, což souvisí s využíváním, ale přímo měřeno věcmi, jako je hloubka fronty (nebo někdy souběžnost). Jako měření fronty se to stane nenulovým, když jste nasycení, často ne dříve. Obvykle pult.
  • Využití - jak zaneprázdněn zdroj nebo systém. Obvykle vyjádřeno 0–100% a nejužitečnější pro předpovědi (protože saturace je pravděpodobně užitečnější). Upozorňujeme, že k použití tohoto zákona nepoužíváme zákon o využití (~ sazba x doba služby / pracovníci), ale místo toho hledáme známější přímá měření.

Z těchto saturací a využití jsou často nejobtížnější získat a jsou plné předpokladů, námitek a složitosti výpočtu - považujte je za nejlepší. Často jsou však nejcennější pro hledání současných a budoucích problémů, a proto jsme se s nimi naučili milovat.

Všechna tato měření lze rozdělit a / nebo agregovat různými věcmi. HTTP lze například rozdělit na chyby 4xx a 5xx, stejně jako by mohla být latence nebo rychlost rozdělena podle adresy URL.

Kromě toho existují propracovanější způsoby výpočtu věcí. Například chyby mají často nižší latenci než úspěšné požadavky, takže můžete vyloučit chyby z latence, pokud je to možné (často nemůžete).

Protože jsou tyto mezery nebo agregáty užitečné, jsou mimo rozsah tohoto článku, protože se mnohem blíže přibližují metrikám, událostem, analýze velké kardinality atd. Zaměříme se nejprve na získání základních údajů, protože je to dost těžké.

Nyní máme naše signály, co s nimi uděláme?

Pokud chcete, můžete na konci tohoto příspěvku přeskočit na průvodce skutečným sběrem dat, ale jakmile budeme mít tyto signály, měli bychom si povídat o tom, co s těmito signály dělat.

Jedním z klíčových důvodů, proč se jedná o „zlaté“ signály, je to, že se snaží měřit věci, které přímo ovlivňují části systému pro koncového uživatele a produkující práci - jsou přímým měřením věcí, na kterých záleží.

To teoreticky znamená, že jsou lepší a užitečnější než spousta méně přímých měření, jako jsou CPU, RAM, sítě, replikační zpoždění a nekonečné další věci (měli bychom vědět, protože často sledujeme 200+ položek na server; nikdy dobrý čas).

Shromažďujeme zlaté signály z několika důvodů:

  • Upozornění - Řekněte nám, když se něco pokazí
  • Odstraňování problémů - Pomozte nám najít a opravit problém
  • Ladění a plánování kapacit - Pomozte nám v průběhu času vylepšovat věci

Zaměřujeme se zde na varování a na to, jak na tyto signály upozornit. To, co potom uděláte, je mezi vámi a vašimi signály.

Varování tradičně používá statické prahy v našich milovaných (ha!) Nagios, Zabbix, DataDog atd. Systémech. Funguje to, ale je těžké jej správně nastavit a generuje spoustu varovného šumu, protože vy (a kdokoli, s kým žijete) jsou většinou velmi dobře známy.

Začněte však staticky, pokud musíte, na základě vašich zkušeností a osvědčených postupů. Ty často fungují nejlépe, když jsou nastaveny na úrovně, kde jsme si naprosto jistí, že něco není v pořádku, nebo se děje přinejmenším neobvyklé (např. 95% CPU, latence po dobu 10 sekund, fronty skromné ​​velikosti, míra chyb vyšší než několik za sekundu atd.) )

Pokud používáte statické výstrahy, nezapomeňte na výstrahy s nižším limitem, jako jsou například téměř nulové požadavky za sekundu nebo latenci, protože tyto často znamenají, že je něco špatně, dokonce i ve 3:00, když je provoz slabý.

Jste průměrný nebo procentuální?

Tato upozornění obvykle používají průměrné hodnoty, ale udělejte si laskavost a pokuste se použít střední hodnoty, pokud je to možné, protože jsou méně citlivé na velké / malé odlehlé hodnoty.

Průměry mají také jiné problémy, jak Optimizely zdůrazňuje ve svém blogu. Přesto jsou průměry / ​​střední hodnoty snadno srozumitelné, dostupné a docela užitečné jako signál, pokud je vaše měřicí okno krátké (např. 1–5 minut).

Ještě lepší je začít myslet na percentily. Můžete například upozornit na 95. percentilní latenci, což je mnohem lepší míra toho, jak špatné věci jsou pro vaše uživatele.

Nicméně percentily jsou složitější, než se zdá, a Vivid Cortex má samozřejmě blog o tom: Proč Percentily nefungují tak, jak si myslíte, kde například varuje, že váš systém skutečně dělá percentil průměru po dobu měření (např. 1 nebo 5 minut). Ale je to stále užitečné pro upozornění a měli byste to zkusit, pokud můžete (a často budete šokováni, jak špatné jsou vaše percentily).

Jste anomálie nebo jen divný?

V ideálním případě můžete také začít používat moderní detekci anomálií na svých nových lesklých zlatých signálech. Detekce anomálií je zvláště užitečná k zachycení problémů, které se vyskytují mimo špičku nebo které způsobují neobvykle nižší metrické hodnoty. Navíc umožňují mnohem těsnější varovné skupiny, takže problémy najdete mnohem dříve (ale ne tak brzy, že se utopíte ve falešných upozorněních).

Detekce anomálií však může být docela náročná, protože to může udělat jen málo monitorovacích řešení na místě (Zabbix nemůže). Je to také docela nové, stále se vyvíjející a obtížně vyladitelné (zejména s „sezónností“ a trendy tak běžnými v našich zlatých signálech).

Naštěstí to mohou udělat novější řešení pro monitorování SaaS / Cloud, jako jsou DataDog, SignalFX atd., Stejně jako nové lokální systémy jako Prometheus & InfluxDB.

Bez ohledu na vaše anomální nástroje má Baron Schwartz k tomu dobrou knihu, kterou byste si měli přečíst, abyste lépe porozuměli různým možnostem, algoritmům a výzvám: Detekce anomálií pro monitorování.

Mohu tě vidět?

Kromě upozornění byste si měli tyto signály také vizualizovat. Weave Works má pěkný formát se dvěma sloupci grafu a Splunk má pěkný výhled. Na levé straně je skládaný graf požadavků a chyb a na pravé straně grafy latence. Můžete také přidat třetí smíšený graf saturace / využití.

Můžete také obohatit své metriky pomocí značek / událostí, jako jsou nasazení, události v automatickém měřítku, restartování atd. A v ideálním případě zobrazit všechny tyto metriky na mapě systémové architektury jako Netsil.

Opravte mě, opravte vás

Jako poslední poznámku k upozornění jsme zjistili, že je upozornění SRE Golden Signal obtížnější reagovat, protože ve skutečnosti jsou příznaky základního problému, který je varováním zřídka přímo odhalen.

To často znamená, že inženýři musí mít více systémových znalostí a musí být kvalifikovanější při hledání problému, který může snadno spočívat v kterémkoli z tuctu služeb nebo zdrojů

Inženýři vždy museli spojovat všechny tečky a kopat pod (nebo nad) výstrahami, a to i pro základní problémy s vysokým CPU nebo nízkou RAM. Zlaté signály jsou však obvykle ještě abstraktnější a je snadné jich mít spoustu, tj. Jediný problém s vysokou latencí u služby na nízké úrovni může snadno způsobit mnoho zpoždění a upozornění na chyby v celém systému.

Jedním z problémů, které Golden Signals pomáhají vyřešit, je to, že příliš často máme pouze užitečná data o několika službách a problém front-end vytváří dlouhý hon pro viníka. Shromažďování signálů pro každou službu pomáhá přiřadit, která služba je nejpravděpodobnější příčinou (zejména pokud máte informace o závislostech), a tedy kam se zaměřit.

A je to. Bavte se se svými signály, protože jsou náročné a zajímavé, aby je našli, sledovaly a varovaly.

Získání dat z každé služby

Níže jsou uvedeny dodatkové články pro různé populární služby a v průběhu času se snažíme přidávat další. Znovu vítáme zpětnou vazbu k těmto.

Všimněte si, že při získávání těchto údajů použitelným způsobem existuje spousta nuancí a výzev, takže se předem omlouváme za všechny poznámky a námitky, které jsme posypali, protože vyvážíme, když je jasné, že jsme poněkud důkladní.

Nezapomeňte také, že v některých případech musíte provést vlastní zpracování, například provést výpočty delta při vzorkování metrik založených na počítadle (většina systémů to za vás provede automaticky).

Na následujících odkazech naleznete další články o shromažďování dat pro každou službu:

  • Vyvažovače zatížení - AWS ALB / ELB, HAProxy
  • Webové servery - Apache & Nginx
  • Servery aplikací - PHP, FPM, Java, Ruby, Node, Go, Python
  • Databázové servery - MySQL a AWS RDS
  • Databázové servery - AWS Aurora
  • Servery Linux - jako základní zdroje

Protože se jedná o dlouhý a komplexní soubor článků, existují nepochybně odlišné názory a zkušenosti, proto vítáme zpětnou vazbu a další nápady. Upravíme text na základě zpětné vazby a zkušeností ostatních, takže občas zkontrolujte, zda nejsou k dispozici aktualizace vašich oblíbených služeb.

(Poznámka: Bezplatná elektronická kniha PDF této celé řady je k dispozici zde)

Pokud se vám tento článek líbil, pomozte svým přátelům tleskat nebo sdílet.

Steve Mushero je globální technolog se sídlem v Šanghaji a San Franciscu. Je generálním ředitelem společnosti Siglos.io a ChinaNetCloud se zaměřením na rozsáhlé systémové systémové internetové operace. Spojte se s ním na LinkedIn nebo pozdravte na Twitteru.

Připojte se k naší komunitě Slack a přečtěte si naše týdenní témata Faun ⬇

Pokud byl tento příspěvek nápomocný, několikrát klikněte na tlačítko pro tleskání a zobrazte svou podporu autorovi! ⬇