Sissejuhatus

Teise süsteemi käivitamisel seisime silmitsi vajadusega töödelda suures koguses erinevaid logisid. Tööriistaks valisime ELK. Selles artiklis käsitleme oma kogemust selle stacki seadistamisel.

Me ei püüa kirja panna kõiki selle võimalusi, vaid soovime keskenduda praktiliste probleemide lahendamisele. Seda tingis see, et kuigi dokumentatsiooni ja valmis pilte on küllalt, esines palju takistusi, vähemalt meie kogemusel.

Me käivitasime stacki läbi docker-compose'i. Veelgi enam, meil oli hästi kirjutatud docker-compose.yml, mis võimaldas meil praktiliselt probleemideta stacki üles tõsta. Meil tundus, et võit on juba lähedal, nüüd veidi kohandame seda oma vajadustele ja kõik ongi.

Kahjuks ei kroonitud meie katse süsteemi seadistamisel logide vastuvõtmiseks ja töötlemiseks meie rakenduselt kohe edu. Seetõttu otsustasime uurida iga komponenti eraldi, enne kui naaseme nende ühenduste juurde.

Nii et alustasime logstash'iga.

Keskkond, Logstashi käivitamine konteineris

Käivitamiseks kasutame docker-compose'i, siin tehtud katsed viidi läbi MacOS-il ja Ubuntu 18.0.4-l.

Logstashi pilt, mis oli meie algses docker-compose.yml-is määratletud, on docker.elastic.co/logstash/logstash:6.3.2

Seda kasutame katseteks.

Logstashi käivitamiseks kirjutasime eraldi docker-compose.yml faili. Loomulikult oleks võinud ka käsurealt pilti käivitada, kuid me lahendasime spetsiifilise ülesande, kus kõik käivitatakse docker-compose'i kaudu.

Lühidalt konfigureerimisfailidest

Kuna kirjeldus viitab sellele, et logstash'i saab käivitada nii ühe kanalina, juhul kui sellele tuleb anda *.conf fail, kui ka mitme kanali jaoks, genereerides pipelines.yml faili, mis omakorda viitab .conf failidele iga kanali jaoks.
Valisime teise viisi. See tundus meile universaalsem ja skaleeritavam. Seega lõime pipelines.yml ja tegsime kaustas pipelines, kuhu paigutame .conf failid iga kanali jaoks.

Konteineris on veel üks konfigureerimisfail - logstash.yml. Me ei puutu sellesse, kasutame seda sellisena, nagu see on.

Nii et meie kataloogide struktuur on:

Käivitavate andmete jaoks arvame esialgu, et see on tcp sadamas 5046, ja väljundi jaoks kasutame stdout.

Siin on lihtne konfiguratsioon esmakordseks käivitamiseks. Lõppude lõpuks on esmane ülesanne käivitada.

Nüüd on meil selline docker-compose.yml

version: '3'

networks:
  elk:

volumes:
  elasticsearch:
    driver: local

services:

  logstash:
    container_name: logstash_one_channel
    image: docker.elastic.co/logstash/logstash:6.3.2
    networks:
      	- elk
    ports:
      	- 5046:5046
    volumes:
      	- ./config/pipelines.yml:/usr/share/logstash/config/pipelines.yml:ro
	- ./config/pipelines:/usr/share/logstash/config/pipelines:ro

Mida me siin näeme?

1. Networks ja volumes on võetud algsest docker-compose.yml (see, kus kogu stakk käivitub), ja ma arvan, et need ei mõjuta suurt üldpilti.
2. Loome ühe teenuse (services) logstash, kasutades pilti docker.elastic.co/logstash/logstash:6.3.2 ja anname sellele nimeks logstash_one_channel.
3. Edastame konteinerisse pordi 5046, mis vastab sellele samale siseportile.
4. Me kuvame oma kanali seadistusfaili ./config/pipelines.yml faili /usr/share/logstash/config/pipelines.yml konteineri sees, kust logstash selle üles leiab, ning teeme selle lugemisõigusega ainult, lihtsalt igaks juhuks.
5. Me kuvame katalooge ./config/pipelines, kus meie kanalite seadistuse failid asuvad, katalooge /usr/share/logstash/config/pipelines ja teeme selle samuti lugemisõigusega.

Fail pipelines.yml

- pipeline.id: HABR
  pipeline.workers: 1
  pipeline.batch.size: 1
  path.config: "./config/pipelines/habr_pipeline.conf"

Siin on kirjeldatud üks kanal identifikaatoriga HABR ja tee selle konfiguratsioonifailini.

Ja lõpuks fail "./config/pipelines/habr_pipeline.conf"

input {
  tcp {
    port => "5046"
   }
  }
filter {
  mutate {
    add_field => [ "habra_field", "Hello Habr" ]
    }
  }
output {
  stdout {
      
    }
  }

Ärme hetkel süvene selle kirjelduse detailidesse, proovime käivitada:

docker-compose up

Mida me näeme?

Konteiner käivitus. Saame kontrollida selle tööd:

echo '13123123123123123123123213123213' | nc localhost 5046

Ja näeme konteineri konsoolis vastust:

Aga samas näeme ka:

logstash_one_channel | [2019-04-29T11:28:59,790][ERROR][logstash.licensechecker.licensereader] Unable to retrieve license information from license server {:message=>"Elasticsearch Unreachable: [http://elasticsearch:9200/][Manticore::ResolutionFailure] elasticsearch", …

logstash_one_channel | [2019-04-29T11:28:59,894][INFO ][logstash.pipeline ] Pipeline started successfully {:pipeline_id=>".monitoring-logstash", :thread=>"#"}

logstash_one_channel | [2019-04-29T11:28:59,988][INFO ][logstash.agent ] Pipelines running {:count=>2, :running_pipelines=>[:HABR, :".monitoring-logstash"], :non_running_pipelines=>[]}
logstash_one_channel | [2019-04-29T11:29:00,015][ERROR][logstash.inputs.metrics ] X-Pack is installed on Logstash but not on Elasticsearch. Please install X-Pack on Elasticsearch to use the monitoring feature. Other features may be available.
logstash_one_channel | [2019-04-29T11:29:00,526][INFO ][logstash.agent ] Successfully started Logstash API endpoint {:port=>9600}
logstash_one_channel | [2019-04-29T11:29:04,478][INFO ][logstash.outputs.elasticsearch] Käivitan tervisekontrolli, et näha, kas Elasticsearchi ühendus töötab {:healthcheck_url=http://elasticsearch:9200/, :path="/"}
logstash_one_channel | [2019-04-29T11:29:04,487][WARN ][logstash.outputs.elasticsearch] Üritati parandada surnud ES näite ühendust, kuid tekkis viga. {:url=«elasticsearch:9200/, :error_type=LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=«Elasticsearch ei ole kätte saadav: [http://elasticsearch:9200/][Manticore::ResolutionFailure] elasticsearch»}
logstash_one_channel | [2019-04-29T11:29:04,704][INFO ][logstash.licensechecker.licensereader] Käivitan tervisekontrolli, et näha, kas Elasticsearchi ühendus töötab {:healthcheck_url=http://elasticsearch:9200/, :path="/"}
logstash_one_channel | [2019-04-29T11:29:04,710][WARN ][logstash.licensechecker.licensereader] Üritati parandada surnud ES näite ühendust, kuid tekkis viga. {:url=«elasticsearch:9200/, :error_type=LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=«Elasticsearch ei ole kätte saadav: [http://elasticsearch:9200/][Manticore::ResolutionFailure] elasticsearch»}

Ja meie logi tõuseb pidevalt ülespoole.

Siin olen ma rohelise värviga esile tõstnud sõnumi, et pipeline käivitus edukalt, punasega — vea sõnumi ja kollasega — sõnumi ühenduse loomise katse kohta elasticsearch:9200.
See juhtub seetõttu, et logstash.conf, mis kuulub pildi koosseisu, kontrollib elasticsearchi kätte saamist. Logstash eeldab, et töötab ELK stacki osana, aga me oleme ta eraldanud.

Töötamine on võimalik, kuid ebamugav.

Lahenduseks on see kontroll välja lülitada keskkonnamuutuja XPACK_MONITORING_ENABLED kaudu.

Teeme muudatus docker-compose.yml-is ja käivitame uuesti:

version: '3'

networks:
  elk:

volumes:
  elasticsearch:
    driver: local

services:

  logstash:
    container_name: logstash_one_channel
    image: docker.elastic.co/logstash/logstash:6.3.2
    networks:
      - elk
    environment:
      XPACK_MONITORING_ENABLED: "false"
    ports:
      - 5046:5046
   volumes:
      - ./config/pipelines.yml:/usr/share/logstash/config/pipelines.yml:ro
      - ./config/pipelines:/usr/share/logstash/config/pipelines:ro

Nüüd on kõik korras. Konteiner on katsetamiseks valmis.

Saame jälle naabruses asuvas konsoolis kirjutada:

echo '13123123123123123123123213123213' | nc localhost 5046

Ja näha:

logstash_one_channel | {
logstash_one_channel |         "message" => "13123123123123123123123213123213",
logstash_one_channel |      "@timestamp" => 2019-04-29T11:43:44.582Z,
logstash_one_channel |        "@version" => "1",
logstash_one_channel |     "habra_field" => "Hello Habr",
logstash_one_channel |            "host" => "gateway",
logstash_one_channel |            "port" => 49418
logstash_one_channel | }

Töötamine ühe kanali raames

Nii et me alustasime. Nüüd võib tegelikult pühendada aega logstashi seadistamisele. Ärgem puudutagem veel pipelines.yml faili, vaatame, mida saame saavutada töötades ühe kanaliga.

Pean ütlema, et kanalikonfiguratsiooni faili tööpõhimõte on hästi kirjeldatud ametlikus juhendis, siin siin
Kui soovite lugeda vene keeles, kasutasime siin seda artiklit(aga päringute süntaks on seal vana, seda tuleb arvesse võtta).

Liigume järjekindlalt Input sektsioonist edasi. TCP töötlemist oleme juba näinud. Mis siin veel huvitavat võiks olla?

Testspordialad, kasutades heartbeat'i

On selline huvitav võimalus genereerida automaatseid testspordialasid.
Selleks tuleb input sektsiooni lisada heartbean plugin.

input {
  heartbeat {
    message => "HeartBeat!"
   }
  } 

Lükkame sisse, hakkame kord minutis saama

logstash_one_channel | {
logstash_one_channel |      "@timestamp" => 2019-04-29T13:52:04.567Z,
logstash_one_channel |     "habra_field" => "Tere Habr",
logstash_one_channel |         "message" => "HeartBeat!",
logstash_one_channel |        "@version" => "1",
logstash_one_channel |            "host" => "a0667e5c57ec"
logstash_one_channel | }

Tahame sagedamini, peame lisama parameetri interval.
Nii saame iga 10 sekundi tagant teate.

input {
  heartbeat {
    message => "HeartBeat!"
    interval => 10
   }
  }

Andmete saamine failist

Oleme ka otsustanud vaadata faili režiimi. Kui failiga töötab normaalselt, siis võib-olla ei ole agenti vaja, vähemalt kohalikuks kasutamiseks.

Kirjelduse kohaselt peaks töörežiim olema sarnane tail -f, st loeb uusi ridu või, nagu valik, loeb kogu faili.

Nii et mida me tahame saada:

1. Tahame saada ridu, mis lisatakse ühte logifaili.
2. Tahame saada andmeid, mis kirjutatakse mitmesse logifaili, samas soovides eristada, kust miski saadud on.
3. Tahame kontrollida, et kui logstash'i taaskäivitame, siis ei saada neid andmeid uuesti.
4. Tahame kontrollida, et kui logstash välja lülitada, ja andmeid kirjutatakse failidesse edasi, siis kui me selle käivitame, saame need andmed.

Eksperimendi läbiviimiseks lisame docker-compose.yml faili veel ühe rida, avades kausta, kuhu me failid asetame.

version: '3'

networks:
  elk:

volumes:
  elasticsearch:
    driver: local

services:

  logstash:
    container_name: logstash_one_channel
    image: docker.elastic.co/logstash/logstash:6.3.2
    networks:
      - elk
    environment:
      XPACK_MONITORING_ENABLED: "false"
    ports:
      - 5046:5046
   volumes:
      - ./config/pipelines.yml:/usr/share/logstash/config/pipelines.yml:ro
      - ./config/pipelines:/usr/share/logstash/config/pipelines:ro
      - ./logs:/usr/share/logstash/input

Ja muudame input sektsiooni habr_pipeline.conf'is

input {
  file {
    path => "/usr/share/logstash/input/*.log"
   }
  }

Käivitame:

docker-compose up

Logifailide loomise ja kirjutamise jaoks kasutame käsku:

echo '1' >> logs/number1.log

{
logstash_one_channel |            "host" => "ac2d4e3ef70f",
logstash_one_channel |     "habra_field" => "Hello Habr",
logstash_one_channel |      "@timestamp" => 2019-04-29T14:28:53.876Z,
logstash_one_channel |        "@version" => "1",
logstash_one_channel |         "message" => "1",
logstash_one_channel |            "path" => "/usr/share/logstash/input/number1.log"
logstash_one_channel | }

Jah, see töötab!

Samuti näeme, et meil on automaatselt lisandunud väli path. See tähendab, et edaspidi saame selle alusel kirjeid filtreerida.

Proovime veel:

echo '2' >> logs/number1.log

{
logstash_one_channel |            "host" => "ac2d4e3ef70f",
logstash_one_channel |     "habra_field" => "Hello Habr",
logstash_one_channel |      "@timestamp" => 2019-04-29T14:28:59.906Z,
logstash_one_channel |        "@version" => "1",
logstash_one_channel |         "message" => "2",
logstash_one_channel |            "path" => "/usr/share/logstash/input/number1.log"
logstash_one_channel | }

Nüüd teise faili:

 echo '1' >> logs/number2.log

{
logstash_one_channel |            "host" => "ac2d4e3ef70f",
logstash_one_channel |     "habra_field" => "Hello Habr",
logstash_one_channel |      "@timestamp" => 2019-04-29T14:29:26.061Z,
logstash_one_channel |        "@version" => "1",
logstash_one_channel |         "message" => "1",
logstash_one_channel |            "path" => "/usr/share/logstash/input/number2.log"
logstash_one_channel | }

Suurepärane! Fail tuvastati, path määrati õigesti, kõik on hästi.

TÕSTAME logstashi ja käivita uuesti. Ootame. Vaikus. See tähendab, et me ei saa neid kirjeid uuesti.

Ja nüüd kõige julgem eksperiment.

Paneme logstashi seisma ja teeme:

echo '3' >> logs/number2.log
echo '4' >> logs/number1.log

Käivitame logstashi uuesti ja näeme:

logstash_one_channel | {
logstash_one_channel |            "host" => "ac2d4e3ef70f",
logstash_one_channel |     "habra_field" => "Hello Habr",
logstash_one_channel |         "message" => "3",
logstash_one_channel |        "@version" => "1",
logstash_one_channel |            "path" => "/usr/share/logstash/input/number2.log",
logstash_one_channel |      "@timestamp" => 2019-04-29T14:48:50.589Z
logstash_one_channel | }
logstash_one_channel | {
logstash_one_channel |            "host" => "ac2d4e3ef70f",
logstash_one_channel |     "habra_field" => "Hello Habr",
logstash_one_channel |         "message" => "4",
logstash_one_channel |        "@version" => "1",
logstash_one_channel |            "path" => "/usr/share/logstash/input/number1.log",
logstash_one_channel |      "@timestamp" => 2019-04-29T14:48:50.856Z
logstash_one_channel | }

Hurraa! Kõik tuvastati.

Aga, peame hoiatama järgmise üle. Kui logstashi konteiner kustutatakse (docker stop logstash_one_channel && docker rm logstash_one_channel), siis ei midagi tuvastata. Konteineri sees oli salvestatud faili positsioon, kuhu seda oli loetud. Kui käivitada „nullist”, siis aktsepteeritakse ainult uusi ridu.

Olemasolevate failide lugemine

Oletame, et käivitame logstashi esmakordselt, kuid meil on juba logid ja soovime neid töötlema hakata.
Kui me käivitame logstashi eelmises osas kasutatud input sektsiooniga, siis me ei saa midagi. Ainult uusi rea kirjutatakse logstashi.

Selleks, et olemasolevatest failidest read üles haarata, tuleb input sektsiooni lisada täiendav rida:

input {
  file {
    start_position => "beginning"
    path => "/usr/share/logstash/input/*.log"
   }
  }

Oluline on märkida, et see kehtib ainult uute failide kohta, mida logstash pole veel näinud. Juba logstashi nähtud failid on selle suuruse meelde jätnud ja nüüd võetakse nendest ainult uued kirjed.

Peatume sellel, et uurime input sektsiooni. Seal on veel palju variante, kuid meie edasiste eksperimentide jaoks piisab praegu sellest.

Andmete marsruutimine ja töötlemine

Proovime lahendada järgmise ülesande: oletame, et meil on ühiselt sõnumid ühest kanalist, millest osa on informatiivsed ja osa on veateated. Need erinevad sildiga. Ühed INFO, teised ERROR.

Me peame need väljundis eraldi jagama. St. informatiivsed sõnumid kirjutame ühte kanalis ja veateated teise.

Selleks liigume input sektsioonist filter ja väljundisse.

Filter sektsiooni abil analüüsime sisenevat sõnumit, saades sellest hash (võti-väärtus paarid), millega juba töötada, st. jagame tingimuste järgi. Ja väljundis valime sõnumid ja saadame igaühe oma kanalisse.

Sõnumi analüüs groki abil

Tekstiread analüüsimiseks ja väli kogumi saamiseks on filter sektsioonis spetsiaalne pistik. — grok.

Ilma, et mul oleks eesmärk anda siin selle detailne kirjeldus (selle jaoks suunan teid ametlikust dokumentatsioonist), annan ma oma lihtsa näite.

Selleks tuleb määratleda sisenemise ridade formaat. Minu omad on sellised:

1 INFO message1
2 ERROR message2

St. identifikaator esimesel kohal, seejärel INFO/ERROR, seejärel mõni sõna ilma tühikuta.
Ei midagi keerulist, kuid tööpõhimõtte mõistmiseks piisab.

Nii et filter sektsioonis grok pistikus peame määrama mustri, et analüüsida meie ridu.

See näeb välja selline:

filter {
  grok {
    match => { "message" => ["%{INT:message_id} %{LOGLEVEL:message_type} %{WORD:message_text}"] }
   }
  } 

Tegelikult on see regulaarne avaldis. Kasutatakse juba valmis mustreid, nagu INT, LOGLEVEL, WORD. Nende kirjeldust ja muid mustreid võib vaadata siit siin

Nüüd, minnes läbi selle filtri, muudetakse meie rida hash'iks kolmelt väljade: message_id, message_type, message_text.

Just need väljad kuvatakse väljundis.

Sõnumite suunamine väljundsektsioonis if-käsu abil

Väljundsektsioonis, nagu me mäletame, kavatsesime jagada sõnumid kaheks vooks. Ühed, mis on INFO, kuvame konsoolile, ja vead, kirjutame faili.

Kuidas saame neid sõnumeid eraldada? Ülesande tingimus annab meile lahenduse — meil on juba eraldi väli message_type, mis võib võtta ainult kaks väärtust: INFO ja ERROR. Just selle alusel teeme valiku if-operaatoriga.

if [message_type] == "ERROR" {
        # Siin kirjutame faili
       } else
     {
      # Siin kirjutame stdout'i
    }

Andmete ja operaatorite töö kirjeldust saab vaadata siin sektsioonis ametlikust manuaalist.

Nüüd, mis puudutab väljundit.

Väljund konsoolile, siin on kõik selge — stdout {}

Aga väljund faili — meenutame, et me käivitame kõik konteinerist ja et fail, kuhu me kirjutame tulemuse, oleks väljastpoolt ligipääsetav, peame avatama selle katalooge docker-compose.yml-is.

Kokkuvõtteks:

Meie faili väljundsektsioon näeb välja selline:

output {
  if [message_type] == "ERROR" {
    file {
          path => "/usr/share/logstash/output/test.log"
          codec => line { format => "custom format: %{message}"}
         }
    } else
     {stdout {
             }
     }
  }

docker-compose.yml-le lisame veel ühe mahu, väljundiks:

version: '3'

networks:
  elk:

volumes:
  elasticsearch:
    driver: local

services:

  logstash:
    container_name: logstash_one_channel
    image: docker.elastic.co/logstash/logstash:6.3.2
    networks:
      - elk
    environment:
      XPACK_MONITORING_ENABLED: "false"
    ports:
      - 5046:5046
   volumes:
      - ./config/pipelines.yml:/usr/share/logstash/config/pipelines.yml:ro
      - ./config/pipelines:/usr/share/logstash/config/pipelines:ro
      - ./logs:/usr/share/logstash/input
      - ./output:/usr/share/logstash/output

Käivitame, proovime, näeme jagunemist kaheks vooks.

Allikas: habr.com