10 nyílt forráskódú naplógyűjtő a központosított naplózáshoz

A közepes és a nagyszerű termékek közötti különbség a fakitermelés. Tudja meg, miért van így, és hogyan köti össze mindezt.


Csakúgy, mint a biztonság, a naplózás a webes alkalmazások (vagy általában az alkalmazások) egy másik kulcseleme, amely a régi szokások és az előre láthatatlanság miatt elkerülhető. Amit sokan használhatatlannak tartanak a digitális szalag rengetegének, az hatékony eszköz az alkalmazások belsejébe történő betekintéshez, a hibák javításához, a gyenge területek javításához és az ügyfelek öröméhez.

Mielőtt elkezdenénk a központosított fakitermelést, először vizsgáljuk meg, miért olyan nagy a fakitermelés.

A naplózás két típusa (szintje)

A számítógépek determinisztikus rendszerek, kivéve, ha nem.

Mint a profi fejlesztő, Sok esetben találkoztam olyan esetekben, amikor az alkalmazás megfigyelt viselkedése napok óta zavart mindenkit, de a kulcs mindig a naplókban volt. Minden szoftver, amelyet futtatunk, naplókat állít elő (vagy legalább generálnia kell), amelyek megmutatják, hogy mi ment át a problémás helyzet felmerülésekor..

Most, hogy látom, a naplózás kétféle: automatikusan generált naplók és programozó által generált naplók. Felhívjuk figyelmét, hogy ez nem különbözik a tankönyvektől, és idézve ezt a terminológiát, bajba kerülsz. ��

A fenti kép azt mutatja, hogy mit lehet úgynevezni automatikusan generált napló.

Ebben az esetben a WordPress rendszer váratlan körülményeket (közleményt) naplóz, amikor valamilyen PHP kódot futtat. Az ilyen naplókat fáradhatatlanul generálják állandóan – adatbázis-eszközök, mint például a MySQL, webszerverek, például Apache, programozási nyelvek és környezetek, mobil eszközök és még operációs rendszerek.

Ezek ritkán tartalmaznak nagy értéket, és a programozók még csak nem is törődnek azzal, hogy bemutassák őket, kivéve, ha valami rosszul fordul elő. Ilyen pillanatban mélyen ásnak a naplókba, és megpróbálják megérteni, mi történt rosszul.

De az automatikusan generált naplók csak annyit segíthetnek. Ha több embernek például adminisztrátori hozzáférése van egy webhelyhez, és egyikük véletlenül töröl egy alapvető információt, lehetetlen az automatikusan létrehozott naplók használatával felismerni a bűnösöt. Az alkalmazásként megkötött rendszerek szempontjából ez csak egy újabb nap volt a munkában – valakinek megvan a szükséges jogosultsága a feladat végrehajtásához, és így a rendszer elvégezte azt..

Itt szükség van egy explicit, kiterjedt naplózás további rétegére, amely nyomvonalakat teremt a dolgok emberi oldalához. Ezekre gondolok programozó által generált naplók, és képezik az olyan érzékeny iparágak gerincét, mint a banki szolgáltatások. Íme egy példa arra, hogyan nézhet ki egy ilyen naplózási séma:

Forrás: joomlatools.com

A fakitermelés hatalom

Tehát, figyelembe véve a rendszer két naplófajtáját, a következőképpen állíthatja be őket és növelheti az ütéseket.

Maradjon az ügyfél előtt

Az „ügyfelek örömét” haszontalan marketing trükknek nevezték, de a naplózásnak köszönhetően ez nagyon valódi lehet. Ismerek olyan digitális termékeket, amelyek úgy figyelik a naplóikat, mint egy sólyom, és amint az ügyfél megtöri valamit az oldalon, felhívhatják az ügyfelet és felajánlhatnak segítséget.

Gondolj csak bele – néhány csúnya hiba észlelése után néhány másodpercen belül felhívást kap a cégtől, amely azt mondja: „Hé, megértem, hogy ezt a tételt próbálta hozzáadni a kosárba, de ez tovább haldoklik. Nem megfelelő, ha hozzáadom ezt az időt, és teljesítem a megrendelést?

Örömmel vásárló? Fogadsz!

Csapat morál és termelékenység

Mint már korábban mondtam, amikor a hibákat sokáig nem találják meg, a csapata fejlesztői frusztráltak és egyre több időt veszítenek a farkuk üldözésében. És itt van a hibakeresés – a kezdetektől kezdve friss, kíváncsi elme szükséges. Ha egy WTF annyira gondolkodik, hogy belép az agyába, akkor az egész folyamat dobálásra vezet.

És mi megnehezíti a hibakeresést? Tapasztalataim szerint a fakitermelés hiánya vagy a fakitermelés ismeretének hiánya. Kezdetnek: nem biztos, hogy észreveszi, hogy a kedvenc adatbázis egy újabb szoftver, amely naplókat generál, vagy nem jelentkezik jelentősen az alkalmazásban (lásd fent a programozó által generált naplókat)..

Különösen emlékszem egy olyan esetre, amikor az alkalmazás nem reagált, és senki sem tudta, miért. Néhány nappal később a tettes volt a lemez I / O korlátja, amelyet a túlzott forgalom miatt elértek. Mivel senki sem zavarta odanézni, senki sem tudta kitalálni, miért.

Ellenőrzési nyomvonalak

Mi lenne, ha két év elteltével az ügyfél azt állítja, hogy az összes megrendelést nem ők tették, hanem valami hackert?

Milyen érv lenne a kérés kielégítése vagy elutasítása érdekében? Ha kiterjedt naplózással rendelkezik (IP-cím, dátum és idő, hitelkártya stb.), Akkor mindezt elemezheti és döntést hozhat. Jó vagy rossz, ennek legalább lesz valamilyen objektív alapja, ahelyett, hogy egy sötét lövésre emlékeztetne.

Forrás: aláírás-.com

Ugyanez igaz akkor is, ha valamilyen szabályozási lencse alá tartozik, vagy egy új, fontos projekt részeként harmadik fél általi ellenőrzést kell elvégezni. Ha nincs robusztus naplózási rendszer, akkor rossz fényben fog megjelenni.

A meglévő rendszerek fejlesztése

Hogyan lehet továbbfejleszteni a jelenlegi rendszert??

Ha csak több RAM-ot és CPU-szálat dobna rá? Mi lenne, ha az alkalmazás elég erőforrások ellenére lassú? Hol van a szűk keresztmetszet? Gyakrabban a válasz a naplózás.

Például az összes főbb adatbázis-rendszer rendelkezik naplózási funkcióval lassú lekérdezések.

Forrás: speedawarenessmonth.com

Ha rendszeresen meglátogatja a lassú lekérdezési naplót, megismerheti, hogy mely műveletekkel és a legtöbb időt vesz igénybe, így felfedezheti azokat a kicsi, de fontos területeket, amelyek munkát igényelnek. Gyakran egy ilyen apró változtatás jobban működik, mint a hardver kapacitás megduplázása.

Nem számít arra, hogy egy jó naplózási rendszer mennyire segít Önnek. Talán a legjobb érv az, hogy egy automatizált tevékenység, amely egyszer beállítva, nem igényel semmilyen figyelést, és egy nap megment a tönkremeneteltől.

Ha nem akarja, nézzük meg néhány csodálatos nyílt forráskódú naplógyűjtőt (egységes naplózási eszköz). Csak arra az esetre, ha kíváncsi lenne, egy korábbi bejegyzésben kiterjesztettük a kereskedelmi felhőalapú naplózási eszközöket.

Graylog

Graylog az iparág egyik vezető neve, amikor az iparági naplózási és megjelenítési képességekről van szó. Az is egyedülálló, hogy ellenőrizte az összegyűjtött naplókat a biztonsági rések jeleire, és azonnal értesít.

Noha a Graylog egy központosított naplózási rendszer, rendelkezik a szükséges rugalmassággal, lehetővé téve a riasztások, az irányítópultok és egyebek testreszabását..

Greylog van nyílt forráskód, de van egy vállalati terv, ha az Ön igényei összetettek.

Az olyan ügyfelekkel, mint például az SAP, a Cisco és a LinkedIn, a Graylog olyan eszköz, amelyben csukott szemmel megbízhat..

Logstash

Ha ön a Elastic verem rajongója vagy felhasználója, Logstash érdemes megnézni (az ELK verem máris dolog, ha nem tudtad). A listán szereplő többi naplózási eszközhöz hasonlóan a Logstash is teljes mértékben nyílt forráskód, lehetővé téve a szabadon a telepítést és a felhasználást, ahogy szeretné.

De ne tévesszen meg: a Logstash olyan anyahajó, amelynek képességei messze meghaladják az alázatos naplózási eszközöket. Képes hatalmas mennyiségű adatot gyűjteni több platformon, lehetővé teszi a saját adatvezetékek meghatározását és végrehajtását, a strukturálatlan naplólerakók értelmét és még sok minden mást.

Természetesen az egyetlen korlátozás az, hogy csak az Elastic termékcsaláddal működik, de ha elkezdi és hamarosan skálázni szeretne, akkor a Logstash az út!

Fluentd

A központosított naplózási eszközök között, amelyek középső rétegként szolgálnak az adatok begyűjtéséhez, Flutend az első az egyenlők között. Kiváló plug-inek könyvtárával a Fluentd képes adatok gyűjtésére gyakorlatilag bármilyen termelési rendszerből, beillesztheti azokat a kívánt struktúrába, létrehozhat egy egyedi csővezetéket és továbbíthatja kedvenc elemző platformjára, legyen az MongoDB vagy Elasticsearch.

A Fluentd a Rubyra épül, teljesen nyílt forráskód, és rugalmassága és modularitása miatt rendkívül népszerű.

A platformot használó nagyvállalatokkal, mint például a Microsoft, az Atlassian és a Twilio, a Fluentdnek nincs semmi bizonyítéka. ��

Flume

Ha igazán, akkor a nagy adatkészletek jelentik a kihívást, és végül azt akarja, hogy mindent olyanra adagoljon, mint a Hadoop, Flume az egyik legjobb választás. Ez egy „tiszta” nyílt forráskódú projekt abban az értelemben, hogy azt szeretett Apache Alapítvány fenntartja, ami azt jelenti, hogy nincs vállalati terv.

Lehet, hogy nem az, amit pontosan keres. ��

Forrás :yondcoder.com

A Java nyelven írva (amely továbbra is meglep, amikor az úttörő technológiáról van szó), a Flume forráskódja teljes nyisd ki. A Flume akkor az Ön számára legjobb, ha elosztott, hibatűrő adatgyűjtő platformot keres nehéz tehergépjárművekhez.

Octopussy

Tízből adok nullát a termék elnevezéséhez, de Octopussy jó választás lehet, ha az Ön igényei egyszerűek, és azon gondolkozik, hogy mi a helyzet minden, a csővezetékekkel, a lenyeléssel, az aggregálással stb..

Véleményem szerint az Octopussy a legtöbb termék igényeit kielégíti (a becsült statisztikák haszontalanok, de ha kellett kitalálnom, azt mondanám, hogy a valós világban a felhasználási esetek 80% -áért felelősek)..

Az Octopussy-nak nincs nagy felhasználói felülete (lásd itt) egyáltalán, de pótolja ezt a sebesség és a duzzanat hiánya miatt. A forrás itt érhető el GitHub, a vártnál, és azt hiszem, érdemes egy komoly pillantást vetni.

LOGalyze

LOGalyze egy olyan kereskedelmi termék, amelyet nemrég nyílt forrásúvá tettek. Bár nem tudtam elindítani a projektet a GitHubon, a Windows telepítőjét és az összes forráskódot letölthetővé teszik.

Ha szándékában áll egy közösség, akkor megtalálhatja a levelezési lista részleteit itt.

A LOGalyze egy viszonylag rugalmas és nagy teljesítményű ajánlat, amely szépen működik az egyrendszeres telepítéseknél, amelyek célja az ismert forrásokból (például Postfix, Apache stb.) Származó naplózás kombinálása, és a kimenetet CSV, PDF, HTML vagy hasonló formátumban állítják elő. Igen, nem mindent tesz, de mivel egyszerre kereskedelmi termék volt, meglehetősen jól csinálja.

LogPacker

A munkaeszköz kiválasztásakor két kritérium van: fókuszálni kell, és aktív üzleti modellt kell támogatnia. A nyílt forráskódú szoftverek problémája általában az, hogy néhány hónappal / évvel az úton nagy a stagnálás vagy halál esélye. Nincs szám, hogy hány naplózási eszközt indítottak el gusto-val, csak most találhatók meg a GitHub temetőben.

Ezt a mérőszámot mérve, LogPacker a kedvencem számomra.

Amint a képernyőképről meg lehet mondani, a LogPacker a naplókról szól, és semmi másra. Felfogásuk határozottan a felhőajánlatok felé irányul, ám örömmel várjuk, hogy töltse le és telepítse a szerverekre (GitHub oldal itt).

A fürtözés és az összesítés elérhető azok számára, akik nem triviális méretekben szeretnék használni, és rendelkezésre állnak vállalati tervek, akik az API-val dolgozni akarnak, vagy nagyobb telepítésekre szorulnak. Véleményem szerint egy frissítően minimalista (fókuszált, bár nem jellemzőire gyenge) vállalja a naplózást!

Logwatch

Biztos vagyok benne, hogy köztük vannak olyanok, akik nem akarják, hogy az ünnepség az „egységes”, „központosított” naplózási rendszerhez kapcsolódjon. Üzletük egyetlen szerverről származik, és valami gyors és hatékony megoldást keresnek a naplófájlok megfigyelésére. Nos, köszönj Logwatch.

A telepítés után a LogWatch átvizsgálhatja a rendszernaplókat, és létrehozhat egy jelentést a kívánt típustól. Ez egy kissé elavult szoftver (olvasható „megbízhatónak”), Perl-ben írta. Szóval, a Perl 5.6 vagy újabb verzióra lesz szüksége a szerverén annak futtatásához. Nincs olyan képernyőképem, amelyet megoszthatnék, mivel ez tisztán parancssori, deemonizált folyamat.

Ha CLI drogos vagy, és szereti a régi iskola működési módját, akkor a Logwatch!

Syslog-ng

Az Syslog-ng az eszközt fejlesztették ki, mint a syslog (a rendszer naplózására létrehozott kliens-szerver protokoll) adatfájlok valós időben történő feldolgozási módját. Idővel azonban más adatformátumokat is támogatott: strukturálatlan, SQL és NoSQL. A syslog protokoll működését az alábbiakban nagyjából összefoglaljuk.

syslog-ng egy termelési szintű, megbízható naplógyűjtő és -osztályozó eszköz, amelyet C-ben írtak, és az iparágban már régóta bevált név. A legjobb rész a kiterjeszthetősége, amely lehetővé teszi plug-inek írását C, Python, Java, Lua vagy Perl formátumban.

lnav

Rövid: (Naplónavigátor), lnav egy tiszta terminál eszköz, amely egyetlen gépen, egyetlen könyvtárban működik. Azok számára készült, akiknek naplózása egyetlen könyvtárba van egyesítve, vagy egyetlen forrásból szeretnék szűrni és megjeleníteni a valós idejű naplókat.

Ha azt gondoltad, hogy az lnav nem más, mint a dicsõített farok | grep, akkor tévedsz. Számos olyan szolgáltatás teszi lehetővé, hogy beleszeret: idősoros nézet, szép nyomtatás (JSON és más formátumok esetén), színkódú naplóforrások, hatékony szűrők, több naplózási protokoll megértésének képessége és még sok más.

Csak az, hogy néha nulla probléma, nulla beállítás, esetleg ideiglenes naplózási rétegre van szükség, és az lnav tökéletesen illeszkedik a számlához.!

Következtetés

És megvan neked!

Nehéz lista volt összeállítani, őszinte legyek, mivel a naplózás nem olyan népszerű, mint mondjuk a tartalomkezelés, és úgy tűnik, hogy az összes elme-megosztást három vagy négy eszköz fogta meg. Ennek ellenére mindenki igényei eltérőek, és igyekeztem ezeket széles körben fedezni.

A buta parancssorból, a telepítés nélküli eszközöktől a teljes körű adatgyűjtőktől kezdve itt minden! Kihagytam valamit? Persze, hogy én voltam! Kérem, tudassa velem a megjegyzésekben, és örömmel adom hozzá ide (természetesen kredittel!).

CÍMKÉK:

  • Nyílt forráskód

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map