Monitoring vs Observabiltiy

[Mizső]

Sziasztok!

Mi a különbség a Monitoring és Observabiltiy között? Miért nem csak egy Monitoring tool a Dynatrace? Milyen képességek teszik Obeservabiltiy eszközzé? Az alábbi cikkben megtalálod rá a válaszokat.

Monitoring vs. Obszervabilitás - Mi a különbség? | LinkedIn

Üdv:

Mizső

[AndrasKovacs]

Szia @Mizső!

Utólag is áldott karácsonyt mindenkinek és sikerekben gazdag új évet kívánok!

Érdekes a témafelvetésed, ezen már én is sokat gondolkodtam, hasonló válaszokra jutottam, mint ami az idézett cikkben található, de...

akkor mi a helyzet az eseménykezeléssel (event management)? Az meg még a monitorozás előtt született volna?

A BME-s tananyagok a két fogalmat szinonímaként kezelik.

Sőt egy még régebbi anyag szerint (l. csatolmány), az ITIL így definiálja a monitorozást:

„Monitoring refers to the activity of observing a situation to detect changes that happen over time.”

"A monitorozás valamely „helyzet” megfigyelése, mely során az időbeni változásokat kívánjuk érzékelni."

Még ezekben a régi diákban is láthatjuk, hogy az eseménykezelésnek is része volt a korreláció (33. dia) illetve a kiváltó  okok keresése (37. dia).

Egy példával érzékeltetve a helyzetet, kicsit az az érzésem, mintha a mai korszerű autókat nem lehetne autónak hívni, mert már sokkal modernebbek a régi autókhoz képest és többet is tudnak. Egy Trabant az csak kocsi, de a városi terepjáró már autó? 🤔

[grepei]

Szevasztok!

Egy 2016-os PPT-ben vázolt, reaktív / esetleg proaktív CI monitoring nem egyenlő az obszervabilitással.

Monitoring = tudod, hogy baj van

Obszervabilitás = tudod, hogy miért van baj és tudod az impact-ot is

Az obszervabilitás a monitoringgal lefedett területek összessége az egyes területek közti korrelációval megspékelve. Ezért kell középre egy AIOps (pl. Davis) mert a forrásfüggetlen események / metrikák / logok / trace-ek összedolgozása nehézkes AI nélkül. Kézi szabályrendszerrel óriási szívás lenne...

A silószerű IT üzemeltetés (Storage team, Network team, Application team, DB team, Server team, Cloud team, etc.) eleve magában hordozza a blame-game-et. Nálad riaszt, nálam nem, tehát hagyjál békén...

Ezt ki lehet küszöbölni olyan eszközökkel, amik képesek a különböző területek adatait összegyúrni. A Dynatrace eleve tartalmaz ilyet, itt nem kell küzdeni az ernyőrendszer kiépítésével, sőt maga a DT is használható ernyőként.

Figyelem! Véleményem nem feltétlenül tükrözi a többség álláspontját... 🙂

[Mizső]

Szia @grepei 

Szívemből szóltál. Én ezek miatt is szerettem bele ebbe az eszközbe.

Üdv:

Mizső

[Mizső]

Szia András!

Köszi a hozzászólást! @grepei jól összefoglalta hogy mi a rövid válasz a fenti kérdésemre. Teljesen egyetértek vele. Annyival egészíteném ki a Te hozzászólásod, hogy mindkét "megoldást" a helyén kell kezelni minden tekintetben (pl. ne felejtsük el a költségeket sem). A "sima" monitoringnak is meg van a létjogosultsága bizonyos környezetekben, bizonyos komplexitásig. A nagy enterprise komplex környezetekben, ahol exponenciálisan szaporodnak pl. a microservcie-ek ott csak egy modern Observabilty tool segítségével tudod hatékonyan üzemeltetni a rendszereket ezt viszont egy kisebb cég nem biztos hogy megengedheti magának és nem is biztos, hogy szüksége van rá... 😉

Üdv:

Mizső

[grepei]

Az obszervabilitás nem való mindenkinek, érettség kell hozzá. És nem kell feltétlenül sok pénz, open-source alapon is lehet eredményt elérni. Viszont obszervabilitással lehet csökkenteni a terhelést az üzemeltetőkön/fejlesztőkön és javítani az MTTR-t. Ezáltal javul az SLA/SLO is. Az instrumentálás mindig macerás picit de minél komplexebb egy rendszer, annál jobban megéri.

Kell egy obszervabilitás stratégia az IT-n amit mindenki elfogad. Akinek nem tetszik, az meg így járt...

[Mizső]

Február második felére szeretnék szervezni egy sörözést, ott esetleg ütköztethetjük a véleményeket. Köszönöm mindkettőtöknek az aktivitást.

Mizső