Miten metriikoiden aggregointi eroaa lokien aggregoinnista? Eivätkö lokit voi sisältää metriikoita? Eivätkö lokien aggregointijärjestelmät voi tehdä samoja asioita kuin metriikoiden aggregointijärjestelmät?

Nämä ovat kysymyksiä, joita kuulen usein. Olen myös nähnyt myyjien mainostavan lokien aggregointijärjestelmiään ratkaisuna kaikkiin havaittavuusongelmiin. Lokien aggregointi on arvokas työkalu, mutta se ei yleensä ole hyvä työkalu aikasarjadataa varten.

Pari arvokasta ominaisuutta aikasarjan metriikan aggregointijärjestelmässä ovat säännöllinen aikaväli ja erityisesti aikasarjadataa varten räätälöity tallennusjärjestelmä. Säännöllinen aikaväli antaa käyttäjälle mahdollisuuden johtaa todellisia matemaattisia tuloksia johdonmukaisesti. Jos lokien aggregointijärjestelmä kerää metriikoita säännöllisin väliajoin, se voi mahdollisesti toimia samalla tavalla. Tallennusjärjestelmää ei kuitenkaan ole optimoitu sellaisille kyselyille, jotka ovat tyypillisiä metriikoiden aggregointijärjestelmässä. Näiden kyselyiden käsittely lokien aggregointityökaluissa esiintyvien tallennusjärjestelmien avulla vie enemmän resursseja ja aikaa.

Tiedämme siis, että lokien aggregointijärjestelmä ei todennäköisesti sovellu aikasarjadatalle, mutta mihin se soveltuu? Lokien aggregointijärjestelmä on hyvä paikka tapahtumatietojen keräämiseen. Nämä ovat epäsäännöllisiä toimintoja, jotka ovat merkittäviä. Esimerkkinä voisivat olla verkkopalvelun käyttölokit. Nämä ovat merkittäviä, koska haluamme tietää, mikä käyttää järjestelmiämme ja milloin. Toinen esimerkki olisi sovelluksen virhetilanne – koska se ei ole normaali toimintatilanne, se voi olla arvokas vianmäärityksessä.

Kourallinen sääntöjä kirjaamista varten:

• Osaa sisällyttää aikaleima
• Osaa muotoilla JSON-muotoon
• Osaa lokata merkityksettömiä tapahtumia
• Osaa lokata kaikki sovelluksen virheet
• Osaa mahdollisesti lokata varoitukset
• Osaa kytkeä loggauksen päälle
• Osaa kirjoittaa viestejä inhimillisellä-luettavassa muodossa
• ÄLÄ kirjaa tietoteknistä dataa tuotannossa
• ÄLÄ kirjaa mitään sellaista, mitä ihminen ei voi lukea tai mihin hän ei voi reagoida

Pilvipalvelun kustannukset

Tutkittaessa lokien yhdistämistyökaluja, pilvi saattaa vaikuttaa houkuttelevalta vaihtoehdolta. Siihen voi kuitenkin liittyä merkittäviä kustannuksia. Lokit edustavat paljon dataa, kun ne yhdistetään satoihin tai tuhansiin isäntäkoneisiin ja sovelluksiin. Näiden tietojen kerääminen, tallentaminen ja hakeminen ovat kalliita pilvipohjaisissa järjestelmissä.

Viittauksena todellisesta järjestelmästä voidaan todeta, että noin 500 solmun ja muutaman sadan sovelluksen kokoelma tuottaa 200 Gt lokidataa päivässä. Tuossa järjestelmässä on todennäköisesti parantamisen varaa, mutta jopa sen vähentäminen puoleen maksaa monissa SaaS-tarjouksissa lähes 10 000 dollaria kuukaudessa. Tähän sisältyy usein vain 30 päivän säilytysaika, mikä ei ole kovin pitkä aika, jos halutaan tarkastella trenditietoja vuodesta toiseen.

Tämän tarkoituksena ei ole estää näiden järjestelmien käyttöä, sillä ne voivat olla erittäin arvokkaita – erityisesti pienille organisaatioille. Tarkoituksena on huomauttaa, että kustannukset voivat olla merkittäviä, ja niiden toteutuminen voi olla lannistavaa. Tämän artikkelin loppuosassa keskitytään avoimen lähdekoodin ja kaupallisiin ratkaisuihin, jotka ovat itse isännöityjä.

Työkaluvaihtoehdot

ELK

ELK, joka on lyhenne sanoista Elasticsearch, Logstash ja Kibana, on suosituin avoimen lähdekoodin lokien aggregointityökalu markkinoilla. Sitä käyttävät Netflix, Facebook, Microsoft, LinkedIn ja Cisco. Kaikki kolme komponenttia ovat Elasticin kehittämiä ja ylläpitämiä. Elasticsearch on pohjimmiltaan NoSQL, Lucene-hakukoneen toteutus. Logstash on lokiputkijärjestelmä, joka voi imuroida dataa, muuntaa sitä ja ladata sen Elasticsearchin kaltaiseen kauppaan. Kibana on visualisointikerros Elasticsearchin päällä.

Muutama vuosi sitten esiteltiin Beats. Beatsit ovat tiedonkerääjiä. Ne yksinkertaistavat tietojen lähettämistä Logstashiin. Sen sijaan, että käyttäjän tarvitsisi ymmärtää kunkin lokityypin oikea syntaksi, hän voi asentaa Beatin, joka vie NGINX-lokit tai Envoy-proxylokit oikein, jotta niitä voidaan käyttää tehokkaasti Elasticsearchissa.

Tuotantotason ELK-pinon asentamisen yhteydessä saatetaan ottaa mukaan muutama muukin osa, kuten Kafka, Redis ja NGINX. Lisäksi on yleistä korvata Logstash Fluentdillä, josta puhutaan myöhemmin. Tämä järjestelmä voi olla monimutkainen käyttää, mikä sen alkuaikoina johti moniin ongelmiin ja valituksiin. Nämä on suurelta osin korjattu, mutta se on silti monimutkainen järjestelmä, joten et ehkä halua kokeilla sitä, jos olet pienempi operaatio.

Sen sanottuasi, saatavilla on palveluita, joten sinun ei tarvitse huolehtia siitä. Logz.io pyörittää sitä puolestasi, mutta sen listahinnoittelu on hieman kova, jos sinulla on paljon dataa. Toki olet luultavasti pienempi ja sinulla ei välttämättä ole paljon dataa. Jos sinulla ei ole varaa Logz.ioon, voit tarkastella esimerkiksi AWS Elasticsearch Service (ES) -palvelua. ES on Amazon Web Servicesin (AWS) tarjoama palvelu, jonka avulla Elasticsearch on erittäin helppo saada nopeasti toimimaan. Sillä on myös työkaluja, joilla kaikki AWS-lokit saadaan ES:ään Lambdan ja S3:n avulla. Tämä on paljon halvempi vaihtoehto, mutta se vaatii jonkin verran hallintaa ja siinä on muutamia rajoituksia.

Elastic, pinon emoyhtiö, tarjoaa vankemman tuotteen, joka käyttää avoimen ytimen mallia, joka tarjoaa lisävaihtoehtoja analytiikkatyökaluihin ja raportointiin. Sitä voidaan myös isännöidä Google Cloud Platformissa tai AWS:ssä. Tämä saattaa olla paras vaihtoehto, sillä tämä työkalujen ja hosting-alustojen yhdistelmä tarjoaa halvemman ratkaisun kuin useimmat SaaS-vaihtoehdot ja tarjoaa silti paljon arvoa. Tämä järjestelmä voi tehokkaasti korvata tietoturvatietojen ja tapahtumien hallintajärjestelmän (SIEM) tai antaa siihen valmiudet.

ELK-pino tarjoaa myös loistavia visualisointityökaluja Kibanan kautta, mutta siitä puuttuu hälytystoiminto. Elastic tarjoaa hälytystoiminnon maksullisessa X-Pack-lisäosassa, mutta avoimen lähdekoodin järjestelmään ei ole sisäänrakennettu mitään. Yelp on luonut tähän ongelmaan ratkaisun nimeltä ElastAlert, ja todennäköisesti muitakin on olemassa. Tämä lisäohjelmisto on melko vankka, mutta se lisää jo valmiiksi monimutkaisen järjestelmän monimutkaisuutta.

Graylog

Graylog on viime aikoina kasvattanut suosiotaan, mutta se sai alkunsa, kun Lennart Koopmann loi sen vuonna 2010. Samanniminen yritys syntyi kaksi vuotta myöhemmin. Kasvavasta käytöstään huolimatta se on edelleen kaukana ELK-pinosta. Tämä tarkoittaa myös sitä, että sillä on vähemmän yhteisön kehittämiä ominaisuuksia, mutta se voi käyttää samoja Beatteja kuin ELK-pino. Graylog on saanut kiitosta Go-yhteisössä Go-kielellä kirjoitetun Graylog Collector Sidecarin myötä.

Graylog käyttää konepellin alla Elasticsearchia, MongoDB:tä ja Graylog Serveriä. Tämä tekee siitä yhtä monimutkaisen käyttää kuin ELK-pino ja ehkä hieman enemmänkin. Avoimen lähdekoodin versiossa Graylogissa on kuitenkin sisäänrakennettu hälytysjärjestelmä sekä useita muita merkittäviä ominaisuuksia, kuten suoratoisto, viestien uudelleenkirjoitus ja maantieteellinen paikannus.

Suoratoisto-ominaisuuden avulla tiedot voidaan ohjata tiettyihin streameihin reaaliaikaisesti niiden käsittelyn aikana. Tämän ominaisuuden avulla käyttäjä voi nähdä kaikki tietokantavirheet yhdessä virrassa ja verkkopalvelimen virheet toisessa virrassa. Näihin Streameihin voidaan jopa perustaa hälytyksiä, kun uusia kohteita lisätään tai kun jokin kynnysarvo ylittyy. Viive on luultavasti yksi suurimmista ongelmista lokien yhdistämisjärjestelmissä, ja Graylogissa tämä ongelma poistuu Streamien avulla. Heti kun loki saapuu, se voidaan ohjata Streamin kautta muihin järjestelmiin käsittelemättä sitä kokonaan.

Sanomien uudelleenkirjoitusominaisuus käyttää avoimen lähdekoodin Drools-sääntömoottoria. Sen avulla kaikki saapuvat viestit voidaan arvioida käyttäjän määrittelemää sääntötiedostoa vasten, jolloin viesti voidaan jättää pois (ns. musta lista), kenttä voidaan lisätä tai poistaa tai viestiä voidaan muuttaa.

Viilein ominaisuus lienee Graylogin maantieteellinen paikannusominaisuus, joka tukee IP-osoitteiden piirtämistä kartalle. Tämä on melko yleinen ominaisuus, ja se on saatavilla myös Kibanassa, mutta se tuo paljon lisäarvoa – etenkin jos haluat käyttää tätä SIEM-järjestelmänäsi. Geopaikannustoiminto on tarjolla järjestelmän avoimen lähdekoodin versiossa.

Yritys Graylog veloittaa avoimen lähdekoodin version tuesta, jos haluat sitä. Se tarjoaa myös avoimen ydinmallin Enterprise-versiolleen, joka tarjoaa arkistointia, audit-lokitusta ja lisätukea. Muita tuki- tai hosting-vaihtoehtoja ei juuri ole, joten olet todennäköisesti omillasi, jos et käytä Graylogia (yritystä).

Fluentd

Fluentd kehitettiin Treasure Datassa, ja CNCF on hyväksynyt sen hautomoprojektiksi. Se on kirjoitettu C:llä ja Rubylla, ja AWS ja Google Cloud suosittelevat sitä. Fluentdistä on tullut yleinen Logstashin korvaaja monissa asennuksissa. Se toimii paikallisena aggregaattorina, joka kerää kaikki solmujen lokit ja lähettää ne keskitettyihin tallennusjärjestelmiin. Se ei ole lokien aggregointijärjestelmä.

Se käyttää vankkaa liitännäisjärjestelmää tarjotakseen nopeita ja helppoja integraatioita erilaisiin tietolähteisiin ja tietolähteisiin. Koska saatavilla on yli 500 liitännäistä, useimpien käyttötapausten pitäisi olla katettu. Jos ne eivät ole, tämä kuulostaa mahdollisuudelta antaa panos takaisin avoimen lähdekoodin yhteisölle.

Fluentd on yleinen valinta Kubernetes-ympäristöissä sen vähäisten muistivaatimusten (vain kymmeniä megatavuja) ja suuren läpimenon vuoksi. Kubernetesin kaltaisessa ympäristössä, jossa jokaisella podilla on Fluentd-sivuvaunu, muistin kulutus kasvaa lineaarisesti jokaisen uuden luotavan podin myötä. Fluentdin käyttö vähentää järjestelmän käyttöastetta huomattavasti. Tästä on tulossa yleinen ongelma Javalla kehitetyissä työkaluissa, jotka on tarkoitettu ajettavaksi yksi per solmu, jossa muistin ylikuormitus ei ole ollut merkittävä ongelma.