Miben különbözik a metrikák aggregációja a naplóaggregációtól? A naplók nem tartalmazhatnak metrikákat? A naplóaggregációs rendszerek nem tudják ugyanazt csinálni, mint a metrikaaggregációs rendszerek?

Ezeket a kérdéseket gyakran hallom. Láttam már olyan gyártókat is, akik a naplóaggregációs rendszerüket az összes megfigyelhetőségi probléma megoldásaként hirdetik. A naplóaggregáció értékes eszköz, de általában nem jó eszköz az idősoros adatokhoz.

Az idősoros metrikai aggregációs rendszer néhány értékes jellemzője a rendszeres intervallum és a kifejezetten az idősoros adatokra szabott tárolási rendszer. A szabályos intervallum lehetővé teszi a felhasználó számára, hogy következetesen valódi matematikai eredményeket származtasson. Ha egy napló aggregációs rendszer rendszeres időközönként gyűjti a metrikákat, akkor potenciálisan ugyanígy működhet. A tárolórendszer azonban nincs optimalizálva a metrika-aggregációs rendszerben jellemző lekérdezések típusaira. Ezeknek a lekérdezéseknek a feldolgozása több erőforrást és időt vesz igénybe a naplóaggregációs eszközökben található tárolórendszerek segítségével.

Azt tudjuk tehát, hogy egy naplóaggregációs rendszer valószínűleg nem alkalmas idősoros adatokra, de mire jó? A naplóaggregációs rendszer kiválóan alkalmas eseményadatok gyűjtésére. Ezek olyan szabálytalan tevékenységek, amelyek jelentősek. Ilyen lehet például egy webes szolgáltatás hozzáférési naplója. Ezek azért jelentősek, mert tudni akarjuk, hogy mi és mikor fér hozzá a rendszereinkhez. Egy másik példa lehet egy alkalmazási hibaállapot – mivel ez nem egy normál működési állapot, értékes lehet a hibaelhárítás során.

Egy maroknyi szabály a naplózásra:

• Ne tartalmazzon időbélyeget
• Ne JSON formátumban
• Ne naplózzon jelentéktelen eseményeket
• Ne naplózzon minden alkalmazási hibát
• MAGYON naplózzon figyelmeztetéseket
• Ne kapcsolja be a naplózást
• Ne írja az üzeneteket emberi nyelven.olvasható formában
• NEM naplózunk információs adatokat a termelésben
• NEM naplózunk semmi olyat, amit egy ember nem tud elolvasni vagy amire nem tud reagálni

Cloud költségek

A naplógyűjtő eszközök vizsgálatakor, a felhő vonzó lehetőségnek tűnhet. Ez azonban jelentős költségekkel járhat. A naplók sok adatot jelentenek, ha több száz vagy több ezer hoszton és alkalmazáson keresztül aggregálják őket. Ezen adatok beemelése, tárolása és visszakeresése költséges a felhőalapú rendszerekben.

Egy valós rendszerből kiindulva, egy körülbelül 500 csomópontból és néhány száz alkalmazásból álló gyűjtemény napi 200 GB naplóadatot eredményez. Ebben a rendszerben valószínűleg van mit javítani, de még ennek felére csökkentése is közel 10 000 dollárba kerül havonta sok SaaS-ajánlatban. Ez gyakran csak 30 napos megőrzést foglal magában, ami nem túl hosszú idő, ha az évről évre változó adatokat szeretnénk megnézni.

Ezzel nem az a célunk, hogy lebeszéljünk az ilyen rendszerek használatáról, mivel nagyon értékesek lehetnek – különösen a kisebb szervezetek számára. A cél az, hogy rámutassunk, hogy jelentős költségek merülhetnek fel, és elkeserítő lehet, amikor ezek realizálódnak. A cikk további részében a nyílt forráskódú és a kereskedelmi megoldásokra összpontosítunk, amelyek saját üzemeltetésűek.

Szerszámlehetőségek

ELK

Az ELK, az Elasticsearch, Logstash és Kibana rövidítése, a legnépszerűbb nyílt forráskódú naplóaggregációs eszköz a piacon. A Netflix, a Facebook, a Microsoft, a LinkedIn és a Cisco használja. A három komponens mindegyikét az Elastic fejleszti és karbantartja. Az Elasticsearch lényegében egy NoSQL, Lucene keresőmotor implementáció. A Logstash egy olyan log pipeline rendszer, amely képes adatokat beemelni, átalakítani és betölteni egy olyan tárolóba, mint az Elasticsearch. A Kibana egy vizualizációs réteg az Elasticsearch tetején.

Pár évvel ezelőtt bevezették a Beats-et. A Beats adatgyűjtők. Ezek leegyszerűsítik az adatok Logstash-be történő szállítását. Ahelyett, hogy a felhasználónak értenie kellene az egyes naplótípusok megfelelő szintaxisát, telepíthet egy Beat-et, amely megfelelően exportálja az NGINX naplóit vagy az Envoy proxy naplóit, így azok hatékonyan használhatók az Elasticsearch-en belül.

A termelési szintű ELK stack telepítésekor néhány más darab is szerepelhet, például a Kafka, a Redis és az NGINX. Szintén gyakori, hogy a Logstash-t Fluentd-re cseréljük, amiről később még beszélünk. Ezt a rendszert bonyolult lehet működtetni, ami a kezdeti időkben sok problémához és panaszhoz vezetett. Ezeket nagyrészt kijavították, de még mindig egy összetett rendszerről van szó, ezért nem biztos, hogy érdemes kipróbálni, ha kisebb vállalkozásról van szó.

Ezzel együtt vannak elérhető szolgáltatások, így emiatt nem kell aggódni. A Logz.io lefuttatja helyetted, de a listaára egy kicsit meredek, ha sok adatod van. Persze te valószínűleg kisebb vagy, és nem biztos, hogy sok adatod van. Ha nem engedheti meg magának a Logz.io-t, megnézheti például az AWS Elasticsearch Service (ES) szolgáltatását. Az ES egy olyan szolgáltatás, amelyet az Amazon Web Services (AWS) kínál, és amely nagyon megkönnyíti az Elasticsearch gyors működésbe hozását. Eszközökkel is rendelkezik ahhoz, hogy az összes AWS-naplót az ES-be juttassa a Lambda és az S3 segítségével. Ez egy sokkal olcsóbb lehetőség, de némi menedzsmentet igényel, és van néhány korlátozása.

A stack anyavállalata, az Elastic egy robusztusabb terméket kínál, amely a nyílt magmodellt használja, amely további lehetőségeket biztosít az analitikai eszközök, és a jelentéskészítés körül. A Google Cloud Platformon vagy az AWS-en is hosztolható. Ez lehet a legjobb megoldás, mivel az eszközök és a tárhelyplatformok ezen kombinációja olcsóbb megoldást kínál, mint a legtöbb SaaS-változat, és még mindig sok értéket nyújt. Ez a rendszer hatékonyan helyettesítheti a biztonsági információ- és eseménykezelő (SIEM) rendszert, vagy adhatja meg annak képességeit.

A Kibana révén az ELK stack is nagyszerű vizualizációs eszközöket kínál, de hiányzik belőle a riasztási funkció. Az Elastic a fizetős X-Pack kiegészítőn belül biztosít riasztási funkciót, de a nyílt forráskódú rendszerbe nincs beépítve semmi. A Yelp létrehozott egy megoldást erre a problémára ElastAlert néven, és valószínűleg vannak mások is. Ez a kiegészítő szoftver meglehetősen robusztus, de növeli az amúgy is összetett rendszer bonyolultságát.

Graylog

A Graylog nemrégiben emelkedett népszerűségre, de a kezdeteket Lennart Koopmann 2010-es létrehozása jelentette. Két évvel később egy cég született ugyanezzel a névvel. A növekvő használata ellenére még mindig messze elmarad az ELK stack mögött. Ez azt is jelenti, hogy kevesebb közösség által fejlesztett funkcióval rendelkezik, de ugyanazokat a Beats-eket tudja használni, mint az ELK stack. A Graylog a Go közösség elismerését a Go nyelven írt Graylog Collector Sidecar bevezetésével nyerte el.

A Graylog Elasticsearch-et, MongoDB-t és a Graylog Server-t használja a motorháztető alatt. Ez ugyanolyan összetetté teszi a futtatását, mint az ELK stack, és talán egy kicsit többé is. A Graylog azonban a nyílt forráskódú verzióba beépített riasztással, valamint számos más figyelemre méltó funkcióval rendelkezik, mint például a streaming, az üzenet újraírás és a földrajzi helymeghatározás.

A streaming funkció lehetővé teszi, hogy az adatokat valós időben, feldolgozásuk közben bizonyos streamekbe irányítsuk. Ezzel a funkcióval a felhasználó az összes adatbázis-hibát egyetlen adatfolyamban, a webkiszolgáló hibáit pedig egy másik adatfolyamban láthatja. A figyelmeztetések akár ezeken a folyamokon is alapulhatnak, amikor új elemek kerülnek hozzáadásra, vagy amikor egy küszöbértéket túllépnek. A késleltetés valószínűleg az egyik legnagyobb probléma a naplógyűjtő rendszereknél, és a Graylogban a streamek kiküszöbölik ezt a problémát. Amint a napló beérkezik, a teljes feldolgozás nélkül továbbítható más rendszerekhez egy Stream-en keresztül.

Az üzenet újraírási funkció a nyílt forráskódú Drools szabálymotort használja. Ez lehetővé teszi, hogy minden bejövő üzenetet kiértékeljenek egy felhasználó által definiált szabályfájl alapján, amely lehetővé teszi egy üzenet elhagyását (úgynevezett feketelistázás), egy mező hozzáadását vagy eltávolítását, vagy az üzenet módosítását.

A legmenőbb funkció talán a Graylog geolokációs képessége, amely támogatja az IP-címek ábrázolását egy térképen. Ez egy meglehetősen gyakori funkció, és a Kibana-ban is elérhető, de rengeteg értéket ad hozzá – különösen, ha SIEM-rendszerként szeretné használni. A geolokációs funkciót a rendszer nyílt forráskódú verziója biztosítja.

A Graylog, a cég, ha igényli, a nyílt forráskódú verzió támogatásáért pénzt kér. Az Enterprise verziójához egy nyílt alapmodellt is kínál, amely archiválást, auditnaplózást és további támogatást kínál. Nincs sok más lehetőség támogatásra vagy tárhelyre, így valószínűleg magadra maradsz, ha nem a Graylogot (a céget) használod.

Fluentd

A Fluentd-et a Treasure Data fejlesztette ki, és a CNCF elfogadta inkubációs projektként. C és Ruby nyelven íródott, és az AWS és a Google Cloud ajánlja. A Fluentd számos telepítésben a Logstash gyakori helyettesítőjévé vált. Helyi aggregátorként működik, amely összegyűjti az összes csomóponti naplót, és elküldi azokat a központi tárolórendszerekbe. Nem egy naplóaggregációs rendszer.

Egy robusztus plugin rendszert használ, hogy gyors és egyszerű integrációkat biztosítson különböző adatforrásokkal és adatkimenetekkel. Mivel több mint 500 bővítmény áll rendelkezésre, a legtöbb felhasználási esetet le kell fednie. Ha mégsem, ez úgy hangzik, mint egy lehetőség a nyílt forráskódú közösséghez való hozzájárulásra.

A Fluentd alacsony memóriaigénye (mindössze néhány tíz megabájt) és nagy áteresztőképessége miatt gyakori választás Kubernetes-környezetekben. Egy olyan környezetben, mint a Kubernetes, ahol minden podhoz tartozik egy Fluentd oldalkocsi, a memóriafogyasztás lineárisan növekszik minden egyes új pod létrehozásával. A Fluentd használata drasztikusan csökkenti a rendszer kihasználtságát. Ez egyre gyakoribb problémává válik a Java nyelven fejlesztett eszközöknél, amelyeket csomópontonként egy-egy futtatásra szántak, ahol a memóriaterhelés eddig nem volt jelentős probléma.