Figyelje meg a szolgáltatást és a felhasználóit

Induljon ki a kérdésből

A monitoring ismert feltételeket ellenőriz. Az observability a rendszer működésének vizsgálatát segíti, az előre nem látott hibákat is beleértve. Több dashboard nem jelent automatikusan jobb válaszokat.

Egy fiktív exportszolgáltatásnál kezdjen felhasználói kérdéssel: megkapja-e a jogosult felhasználó a helyes exportot a megállapodott időn belül? Ezután válasszon olyan jelzéseket, amelyek támogatják ezt a kérdést, és segítenek megmagyarázni a hibákat.

Az OpenTelemetry instrumentációt és telemetriai szabványokat biztosít. Jelzéseket küldhet kompatibilis backendeknek. Tárolásra, lekérdezésekre, hozzáférés-szabályozásra, megőrzési szabályokra és a bizonyíték alapján cselekvő emberekre továbbra is szükség van. Az observability alapjai.

Kapcsolja össze a bizonyíték különböző formáit

A metrika egy mennyiséget mér időben. A napló egy eseményt rögzít. A trace összekapcsolja a kapcsolódó műveleteket, miközben a kérés végighalad a rendszeren. A span egy műveletet jelöl a trace-en belül.

Aszinkron munkánál őrizzen meg biztonságos összerendelést a beküldött feladat és a worker végrehajtása között. A HTTP 202 válasz jelentheti a munka elfogadását. Nem bizonyítja, hogy az export elkészült.

Akkor riasszon, amikor beavatkozás kell

Az SLO beállítása előtt határozza meg az SLI-t és annak nevezőjét. A példában a megállapodott időn belül helyesen elkészült, jogosult exportokat számolja. Határozza meg, hogyan kerülnek a mérésbe a hosszú ideig futó és a félbehagyott feladatok.

Az error budget az SLO időablakán belüli megengedett hibamennyiséget írja le. A burn rate azt mutatja, milyen gyorsan fogyasztják el a hibák ezt a keretet. A Google útmutatója több időablakkal egyensúlyoz az időben történő észlelés és a riasztási zaj között. SLO-alapú riasztás.

Akkor küldjön közvetlen ügyeleti riasztást, amikor időben történő beavatkozás szükséges. A kevésbé sürgős munkát tegye feladatsorba. Minden riasztáshoz kell felelős, hatásleírás, vizsgálati hivatkozás és reagálási utasítás. Vizsgálja felül azokat a riasztásokat, amelyek ismételten semmilyen beavatkozáshoz nem vezetnek.

Ne használjon egyetlen általános küszöbértéket minden szolgáltatáshoz. A döntést a felhasználói hatás, a forgalom, az üzleti időszakok és a reagálási kapacitás befolyásolják.

Védje a telemetriai pipeline-t

A telemetria tartalmazhat személyes adatokat, tokeneket, kérésparamétereket és bizalmas dokumentumokat. Gyűjtés előtt határozza meg az engedélyezett mezőket. Korlátozza a hozzáférést és a megőrzést. Külső backendbe történő export előtt távolítsa el a titkos értékeket. Érzékeny telemetria.

Ne használjon ügyfél-e-mail-címet vagy egyedi feladatazonosítót metrikacímkeként. A korlátlan értékkészletű címkék növelik az idősorok számát, és azonosítókat fedhetnek fel. A metrikákhoz szabályozott dimenziókat használjon. A jóváhagyott korrelációs azonosítókat hozzáférés-szabályozott naplókba vagy trace-ekbe helyezze.

Mérje magát a pipeline-t is. Ellenőrizze a beérkeztetési hibákat, az eldobott adatokat és a legutóbbi megfigyelés korát. A lapos hibagrafikon jelenthet hibamentességet, de a beérkező telemetria hiányát is. Mutassa meg a különbséget.

Vizsgáljon meg egy konkrét hibát

A fiktív szolgáltatás minden kérésre HTTP 202-t ad. A sorban várakozás ideje néhány másodpercről 15 percre nő. A worker naplói ismétlődő adatbázis-időtúllépéseket mutatnak. A mintavételezett trace-ek szerint a worker idejének nagy része adatbázishívásokkal telik.

Ez a bizonyíték célzott vizsgálatot támogat. Nem dönti el, hogy az ok lekérdezésváltozás, a kapcsolatok kimerülése vagy az adatbázis kapacitása. Vesse össze ezeket a hipotéziseket a hibakeresési módszerrel.

A Taiga Monitoring a termék állapotát mutató nézetet biztosít rendelkezésre állási és böngészős felhasználóiélmény-jelzésekkel. Kiegészíti az infrastruktúra és az alkalmazás observability-rendszereit; nem helyettesíti őket. Monitoring.