შესავალი

სხვა სისტემის განლაგებისას ჩვენ დაგვხვდა დიდი რაოდენობით სხვადასხვა ჟურნალის დამუშავების აუცილებლობა. ინსტრუმენტად აირჩიეს ELK. ეს სტატია განიხილავს ჩვენს გამოცდილებას ამ სტეკის დაყენებაში.

ჩვენ არ დასახული გვაქვს მიზანი, რომ აღვწეროთ მისი მთელი შესაძლებლობები, მაგრამ გვინდა კონცენტრირება კონკრეტულად პრაქტიკული პრობლემების გადაჭრაზე. ეს იმის გამო ხდება, რომ მიუხედავად იმისა, რომ არსებობს საკმაოდ დიდი რაოდენობით დოკუმენტაცია და მზა სურათები, საკმაოდ ბევრი ხარვეზია, ყოველ შემთხვევაში, ჩვენ აღმოვაჩინეთ.

ჩვენ განვათავსეთ სტეკი docker-compose-ის საშუალებით. უფრო მეტიც, ჩვენ გვქონდა კარგად დაწერილი docker-compose.yml, რომელიც გვაძლევდა საშუალებას აგვეღო სტეკი თითქმის უპრობლემოდ. და გვეჩვენებოდა, რომ გამარჯვება უკვე ახლოს იყო, ახლა ჩვენ მას ცოტას შევასწორებთ ჩვენს საჭიროებებზე და ეს არის.

სამწუხაროდ, ჩვენი მცდელობა სისტემის კონფიგურაციისთვის, რომ მიიღოთ და დაამუშავოს ჟურნალები ჩვენი აპლიკაციიდან, მაშინვე წარმატებული არ იყო. ამიტომ, ჩვენ გადავწყვიტეთ, რომ ღირდა თითოეული კომპონენტის ცალ-ცალკე შესწავლა და შემდეგ მათ კავშირებზე დაბრუნება.

ასე რომ, დავიწყეთ logstash-ით.

გარემო, განლაგება, Logstash-ის გაშვება კონტეინერში

განლაგებისთვის ჩვენ ვიყენებთ docker-compose-ს; აქ აღწერილი ექსპერიმენტები ჩატარდა MacOS-ზე და Ubuntu 18.0.4-ზე.

logstash სურათი, რომელიც რეგისტრირებულია ჩვენს ორიგინალურ docker-compose.yml-ში არის docker.elastic.co/logstash/logstash:6.3.2

ჩვენ გამოვიყენებთ მას ექსპერიმენტებისთვის.

ჩვენ დავწერეთ ცალკე docker-compose.yml logstash-ის გასაშვებად. რა თქმა უნდა, შესაძლებელი იყო გამოსახულების გაშვება ბრძანების ხაზიდან, მაგრამ ჩვენ ვაგვარებდით კონკრეტულ პრობლემას, სადაც ყველაფერს ვაწარმოებთ docker-compose-დან.

მოკლედ კონფიგურაციის ფაილების შესახებ

როგორც აღწერიდან ჩანს, logstash შეიძლება გაშვებული იყოს ან ერთი არხისთვის, ამ შემთხვევაში მას სჭირდება *.conf ფაილის გავლა, ან რამდენიმე არხისთვის, ამ შემთხვევაში მას სჭირდება pipelines.yml ფაილის გაშვება, რაც თავის მხრივ , დააკავშირებს ფაილებს .conf თითოეული არხისთვის.
მეორე გზა ავიღეთ. ეს უფრო უნივერსალური და მასშტაბური გვეჩვენებოდა. ამიტომ, ჩვენ შევქმენით pipelines.yml და შევქმენით pipelines დირექტორია, რომელშიც დავდებთ .conf ფაილებს თითოეული არხისთვის.

კონტეინერის შიგნით არის კიდევ ერთი კონფიგურაციის ფაილი - logstash.yml. ჩვენ არ ვეხებით, ვიყენებთ როგორც არის.

ასე რომ, ჩვენი დირექტორია სტრუქტურა:

შეყვანის მონაცემების მისაღებად, ახლა ჩვენ ვივარაუდებთ, რომ ეს არის tcp 5046 პორტზე, ხოლო გამოსასვლელად გამოვიყენებთ stdout.

აქ არის მარტივი კონფიგურაცია პირველი გაშვებისთვის. რადგან თავდაპირველი ამოცანა გაშვებაა.

ასე რომ, ჩვენ გვაქვს ეს 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

რას ვხედავთ აქ?

ქსელები და ტომები აღებულია ორიგინალური docker-compose.yml-დან (ის, სადაც გაშვებულია მთელი სტეკი) და ვფიქრობ, რომ ისინი დიდად არ იმოქმედებენ საერთო სურათზე აქ.
ჩვენ ვქმნით ერთ logstash სერვის(ებს) docker.elastic.co/logstash/logstash:6.3.2 სურათიდან და ვუწოდებთ მას logstash_one_channel.
ჩვენ ვაგზავნით პორტს 5046 კონტეინერის შიგნით, იმავე შიდა პორტში.
ჩვენი მილის კონფიგურაციის ფაილს ./config/pipelines.yml ვაფიქსირებთ ფაილში /usr/share/logstash/config/pipelines.yml კონტეინერის შიგნით, სადაც logstash აიღებს მას და გახდის მხოლოდ წაკითხვადს, ყოველი შემთხვევისთვის.
ჩვენ ვაფიქსირებთ ./config/pipelines დირექტორიას, სადაც გვაქვს ფაილები არხის პარამეტრებით, /usr/share/logstash/config/pipelines დირექტორიაში და ასევე ვაქცევთ მას მხოლოდ წაკითხვად.

Pipelines.yml ფაილი

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

აქ აღწერილია ერთი არხი HABR იდენტიფიკატორით და მისი კონფიგურაციის ფაილის გზა.

და ბოლოს ფაილი "./config/pipelines/habr_pipeline.conf"

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

მოდი, ახლა არ შევიდეთ მის აღწერაში, ვცადოთ მისი გაშვება:

docker-compose up

რას ვხედავთ?

კონტეინერი დაიწყო. ჩვენ შეგვიძლია შევამოწმოთ მისი მოქმედება:

echo '13123123123123123123123213123213' | nc localhost 5046

და ჩვენ ვხედავთ პასუხს კონტეინერის კონსოლში:

მაგრამ ამავე დროს, ჩვენ ასევე ვხედავთ:

logstash_one_channel | [2019-04-29T11:28:59,790][ERROR][logstash.licensechecker.licensereader] შეუძლებელია ლიცენზიის ინფორმაციის მოძიება სალიცენზიო სერვერიდან {:message=>„Elasticsearch მიუწვდომელია: [http://elasticsearch:9200/][Manticore ::ResolutionFailure] elasticsearch", ...

logstash_one_channel | [2019-04-29T11:28:59,894][INFO ][logstash.pipeline ] მილსადენი წარმატებით დაიწყო {:pipeline_id=>".monitoring-logstash", :thread=>"# "}

logstash_one_channel | [2019-04-29T11:28:59,988][INFO ][logstash.agent ] მილსადენები გაშვებული {: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 დაინსტალირებულია Logstash-ზე, მაგრამ არა Elasticsearch-ზე. გთხოვთ, დააინსტალიროთ X-Pack Elasticsearch-ზე, რათა გამოიყენოთ მონიტორინგის ფუნქცია. სხვა ფუნქციები შეიძლება იყოს ხელმისაწვდომი.
logstash_one_channel | [2019-04-29T11:29:00,526][INFO ][logstash.agent ] წარმატებით დაიწყო Logstash API საბოლოო წერტილი {:port=>9600}
logstash_one_channel | [2019-04-29T11:29:04,478][INFO ][logstash.outputs.elasticsearch] მიმდინარეობს ჯანმრთელობის შემოწმება, მუშაობს თუ არა Elasticsearch კავშირი {:healthcheck_url=>http://elasticsearch:9200/, :path=> "/"}
logstash_one_channel | [2019-04-29T11:29:04,487][WARN ][logstash.outputs.elasticsearch] ცდილობდა აღედგინა კავშირი მკვდარი ES ეგზემპლართან, მაგრამ მიიღო შეცდომა. {:url=>“ელასტიური:9200/", :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch მიუწვდომელია: [http://elasticsearch:9200/:][Resoureail:]Resoureail ელასტიური ძიება"}
logstash_one_channel | [2019-04-29T11:29:04,704][INFO ][logstash.licensechecker.licensereader] მიმდინარეობს ჯანმრთელობის შემოწმება, მუშაობს თუ არა Elasticsearch კავშირი {:healthcheck_url=>http://elasticsearch:9200/, :path=> "/"}
logstash_one_channel | [2019-04-29T11:29:04,710][WARN ][logstash.licensechecker.licensereader] ცდილობდა აღედგინა კავშირი მკვდარი ES ეგზემპლართან, მაგრამ მიიღო შეცდომა. {:url=>“ელასტიური:9200/", :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch მიუწვდომელია: [http://elasticsearch:9200/:][Resoureail:]Resoureail ელასტიური ძიება"}

და ჩვენი ჟურნალი მუდმივად ცოცავს.

აქ მე მწვანედ გამოვყავი შეტყობინება, რომ მილსადენი წარმატებით დაიწყო, წითლად შეცდომის შეტყობინება და ყვითლად შეტყობინება დაკავშირების მცდელობის შესახებ. ელასტიური: 9200.
ეს იმიტომ ხდება, რომ logstash.conf, რომელიც შედის სურათში, შეიცავს elasticsearch-ის ხელმისაწვდომობის შემოწმებას. ყოველივე ამის შემდეგ, logstash ვარაუდობს, რომ ის მუშაობს როგორც Elk სტეკის ნაწილი, მაგრამ ჩვენ გამოვყავით იგი.

შესაძლებელია მუშაობა, მაგრამ ეს არ არის მოსახერხებელი.

გამოსავალი არის ამ შემოწმების გამორთვა XPACK_MONITORING_ENABLED გარემოს ცვლადის საშუალებით.

მოდით შევცვალოთ 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
    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

ახლა ყველაფერი კარგადაა. კონტეინერი მზად არის ექსპერიმენტებისთვის.

ჩვენ შეგვიძლია ხელახლა აკრიფოთ შემდეგ კონსოლში:

echo '13123123123123123123123213123213' | nc localhost 5046

და ნახეთ:

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 | }

მუშაობა ერთ არხზე

ასე რომ, ჩვენ დავიწყეთ. ახლა თქვენ შეგიძლიათ რეალურად დაუთმოთ დრო თავად logstash-ის კონფიგურაციას. მოდით, ჯერ არ შევეხოთ pipelines.yml ფაილს, ვნახოთ, რა შეგვიძლია მივიღოთ ერთ არხთან მუშაობისას.

უნდა ითქვას, რომ არხის კონფიგურაციის ფაილთან მუშაობის ზოგადი პრინციპი კარგად არის აღწერილი ოფიციალურ სახელმძღვანელოში, აქ აქ
თუ გსურთ წაიკითხოთ რუსულად, ჩვენ გამოვიყენეთ ეს სტატია(მაგრამ იქ შეკითხვის სინტაქსი ძველია, ეს უნდა გავითვალისწინოთ).

მოდი თანმიმდევრულად გადავიდეთ შეყვანის განყოფილებიდან. ჩვენ უკვე ვნახეთ მუშაობა tcp-ზე. კიდევ რა შეიძლება იყოს აქ საინტერესო?

ტესტი შეტყობინებები გულისცემის გამოყენებით

არსებობს ასეთი საინტერესო შესაძლებლობა ავტომატური სატესტო შეტყობინებების გენერირების.
ამისათვის თქვენ უნდა ჩართოთ heartbean დანამატი შეყვანის განყოფილებაში.

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

ჩართეთ, დაიწყეთ მიღება წუთში ერთხელ

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

თუ გვინდა უფრო ხშირად მივიღოთ, უნდა დავამატოთ ინტერვალის პარამეტრი.
ასე მივიღებთ შეტყობინებას ყოველ 10 წამში.

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

ფაილიდან მონაცემების მოძიება

ჩვენ ასევე გადავწყვიტეთ გადავხედოთ ფაილის რეჟიმში. თუ ის კარგად მუშაობს ფაილთან, მაშინ შესაძლოა არ არის საჭირო აგენტი, ყოველ შემთხვევაში ადგილობრივი გამოყენებისთვის.

აღწერილობის მიხედვით, მუშაობის რეჟიმი უნდა იყოს მსგავსი tail -f, ე.ი. კითხულობს ახალ ხაზებს ან, როგორც ვარიანტი, კითხულობს მთელ ფაილს.

ასე რომ, რისი მიღება გვინდა:

ჩვენ გვინდა მივიღოთ ხაზები, რომლებიც დართულია ერთ ჟურნალის ფაილში.
ჩვენ გვსურს მივიღოთ მონაცემები, რომლებიც ჩაწერილია რამდენიმე ჟურნალის ფაილში, იმავდროულად, შეგვიძლია განვასხვავოთ ის, რაც მიღებულია საიდან.
ჩვენ გვინდა დავრწმუნდეთ, რომ როდესაც logstash გადაიტვირთება, ის აღარ მიიღებს ამ მონაცემებს.
ჩვენ გვინდა შევამოწმოთ, რომ თუ logstash გამორთულია და მონაცემები განაგრძობს ფაილებში ჩაწერას, მაშინ როცა მას გავუშვით, მივიღებთ ამ მონაცემებს.

ექსპერიმენტის ჩასატარებლად დავამატოთ კიდევ ერთი ხაზი 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
    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

და შეცვალეთ შეყვანის განყოფილება habr_pipeline.conf-ში

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

Დავიწყოთ:

docker-compose up

ჟურნალის ფაილების შესაქმნელად და ჩასაწერად ჩვენ გამოვიყენებთ ბრძანებას:

 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 | }

დიახ, მუშაობს!

ამავდროულად, ჩვენ ვხედავთ, რომ ჩვენ ავტომატურად დავამატეთ ბილიკის ველი. ეს ნიშნავს, რომ მომავალში ჩვენ შევძლებთ მის მიერ ჩანაწერების გაფილტვრას.

Კიდევ ვცადოთ:

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 | }

ახლა კი სხვა ფაილზე:

 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 | }

დიდი! ფაილი აიყვანეს, ბილიკი სწორად იყო მითითებული, ყველაფერი კარგადაა.

შეაჩერე logstash და დაიწყე თავიდან. დაველოდოთ. სიჩუმე. იმათ. ჩვენ აღარ მივიღებთ ამ ჩანაწერებს.

ახლა კი ყველაზე გაბედული ექსპერიმენტი.

დააინსტალირეთ logstash და შეასრულეთ:

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

ისევ გაუშვით logstash და ნახეთ:

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 | }

ჰოო! ყველაფერი აიყვანეს.

მაგრამ ჩვენ უნდა გაგაფრთხილოთ შემდეგი. თუ კონტეინერი logstash-ით წაიშლება (docker stop logstash_one_channel && docker rm logstash_one_channel), მაშინ არაფერი არ იქნება აღებული. ფაილის პოზიცია, სადაც ის იკითხებოდა, ინახებოდა კონტეინერში. თუ თქვენ აწარმოებთ მას ნულიდან, ის მიიღებს მხოლოდ ახალ ხაზებს.

არსებული ფაილების კითხვა

ვთქვათ, პირველად ვიწყებთ logstash-ს, მაგრამ უკვე გვაქვს ჟურნალები და გვსურს მათი დამუშავება.
თუ logstash-ს გავუშვით ზემოთ გამოყენებული შეყვანის განყოფილებით, ვერაფერს მივიღებთ. მხოლოდ ახალი ხაზები დამუშავდება logstash-ით.

იმისთვის, რომ არსებული ფაილებიდან ხაზები გაიტანოს, თქვენ უნდა დაამატოთ დამატებითი ხაზი შეყვანის განყოფილებაში:

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

უფრო მეტიც, არსებობს ნიუანსი: ეს ეხება მხოლოდ ახალ ფაილებს, რომლებიც logstash-ს ჯერ არ უნახავს. იგივე ფაილებისთვის, რომლებიც უკვე იყო logstash-ის ხედვის ველში, მას უკვე ახსოვდა მათი ზომა და ახლა მხოლოდ ახალ ჩანაწერებს მიიღებს მათში.

აქ შევჩერდეთ და შევისწავლოთ შეყვანის განყოფილება. ჯერ კიდევ ბევრი ვარიანტია, მაგრამ ეს საკმარისია ჩვენთვის შემდგომი ექსპერიმენტებისთვის.

მარშრუტიზაცია და მონაცემთა ტრანსფორმაცია

შევეცადოთ გადავჭრათ შემდეგი პრობლემა, ვთქვათ, გვაქვს შეტყობინებები ერთი არხიდან, ზოგიერთი მათგანი საინფორმაციოა, ნაწილი კი შეცდომის შესახებ. ისინი განსხვავდებიან ტეგით. ზოგიერთი არის INFO, სხვები არის ERROR.

გასასვლელში უნდა გამოვყოთ ისინი. იმათ. ჩვენ ვწერთ საინფორმაციო შეტყობინებებს ერთ არხზე, ხოლო შეცდომის შეტყობინებებს მეორეში.

ამისათვის გადადით შეყვანის განყოფილებიდან ფილტრზე და გამომავალზე.

ფილტრის განყოფილების გამოყენებით ჩვენ გავაანალიზებთ შემოსულ შეტყობინებას, ვიღებთ მისგან ჰეშის (გასაღები-მნიშვნელობის წყვილებს), რომლებთანაც უკვე შეგვიძლია მუშაობა, ე.ი. დაშლა პირობების მიხედვით. და გამომავალი განყოფილებაში ჩვენ ავირჩევთ შეტყობინებებს და გამოვგზავნით თითოეულს საკუთარ არხზე.

შეტყობინების გარჩევა grok-ით

ტექსტის სტრიქონების გასაანალიზებლად და მათგან ველების ნაკრების მისაღებად, ფილტრის განყოფილებაში არის სპეციალური დანამატი - grok.

მიზნის დასახვის გარეშე მისი დეტალური აღწერა აქ (ამისთვის მე ვგულისხმობ ოფიციალური დოკუმენტაცია), მე მოვიყვან ჩემს მარტივ მაგალითს.

ამისათვის თქვენ უნდა გადაწყვიტოთ შეყვანის სტრიქონების ფორმატი. მე მაქვს ასეთი:

1 საინფორმაციო შეტყობინება1
2 შეცდომის შეტყობინება2

იმათ. ჯერ იდენტიფიკატორი მოდის, შემდეგ INFO/ERROR, შემდეგ რამდენიმე სიტყვა ინტერვალის გარეშე.
ეს არ არის რთული, მაგრამ საკმარისია ოპერაციის პრინციპის გაგება.

ასე რომ, grok მოდულის ფილტრის განყოფილებაში ჩვენ უნდა განვსაზღვროთ ნიმუში ჩვენი სტრიქონების გასაანალიზებლად.

ეს ასე გამოიყურება:

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

არსებითად, ეს ჩვეულებრივი გამოხატულებაა. გამოიყენება მზა შაბლონები, როგორიცაა INT, LOGLEVEL, WORD. მათი აღწერა, ისევე როგორც სხვა ნიმუშები, შეგიძლიათ იხილოთ აქ აქ

ახლა, ამ ფილტრის გავლით, ჩვენი სტრიქონი გადაიქცევა სამი ველის ჰეშად: message_id, message_type, message_text.

ისინი ნაჩვენები იქნება გამომავალი განყოფილებაში.

შეტყობინებების მარშრუტირება გამომავალი განყოფილებაში if ბრძანების გამოყენებით

გამომავალი განყოფილებაში, როგორც გვახსოვს, ვაპირებდით მესიჯების ორ ნაკადად გაყოფას. ზოგიერთი - რომელიც არის iNFO, გამოვა კონსოლში და შეცდომების შემთხვევაში, ჩვენ გამოვატანთ ფაილს.

როგორ განვასხვავოთ ეს შეტყობინებები? პრობლემის მდგომარეობა უკვე გვთავაზობს გამოსავალს - ბოლოს და ბოლოს, ჩვენ უკვე გვაქვს გამოყოფილი message_type ველი, რომელსაც შეუძლია მიიღოს მხოლოდ ორი მნიშვნელობა: INFO და ERROR. სწორედ ამის საფუძველზე გავაკეთებთ არჩევანს if განაცხადის გამოყენებით.

if [message_type] == "ERROR" {
        # Здесь выводим в файл
       } else
     {
      # Здесь выводим в stdout
    }

ველებთან და ოპერატორებთან მუშაობის აღწერა შეგიძლიათ იხილოთ ამ განყოფილებაში ოფიციალური სახელმძღვანელო.

ახლა, რაც შეეხება თავად ფაქტობრივ დასკვნას.

კონსოლის გამომავალი, აქ ყველაფერი ნათელია - stdout {}

მაგრამ გამოსავალი ფაილში - გახსოვდეთ, რომ ამ ყველაფერს კონტეინერიდან ვატარებთ და იმისათვის, რომ ფაილი, რომელშიც ვწერთ შედეგს, ხელმისაწვდომი იყოს გარედან, უნდა გავხსნათ ეს დირექტორია docker-compose.yml-ში.

სულ:

ჩვენი ფაილის გამომავალი განყოფილება ასე გამოიყურება:

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

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
    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

ჩვენ ვიწყებთ მას, ვცდილობთ და ვხედავთ დაყოფას ორ ნაკადად.

წყარო: www.habr.com

ELK-ის პრაქტიკული გამოყენება. logstash-ის დაყენება

შესავალი

გარემო, განლაგება, Logstash-ის გაშვება კონტეინერში

მოკლედ კონფიგურაციის ფაილების შესახებ

მუშაობა ერთ არხზე

ტესტი შეტყობინებები გულისცემის გამოყენებით

ფაილიდან მონაცემების მოძიება

არსებული ფაილების კითხვა

მარშრუტიზაცია და მონაცემთა ტრანსფორმაცია

შეტყობინების გარჩევა grok-ით

შეტყობინებების მარშრუტირება გამომავალი განყოფილებაში if ბრძანების გამოყენებით

ახალი კომენტარის დამატება

ELK-ის პრაქტიკული გამოყენება. logstash-ის დაყენება

შესავალი

გარემო, განლაგება, Logstash-ის გაშვება კონტეინერში

მოკლედ კონფიგურაციის ფაილების შესახებ

მუშაობა ერთ არხზე

ტესტი შეტყობინებები გულისცემის გამოყენებით

ფაილიდან მონაცემების მოძიება

არსებული ფაილების კითხვა

მარშრუტიზაცია და მონაცემთა ტრანსფორმაცია

შეტყობინების გარჩევა grok-ით

შეტყობინებების მარშრუტირება გამომავალი განყოფილებაში if ბრძანების გამოყენებით

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება