تعارف

ایک اور نظام کی تعیناتی کے دوران، ہمیں مختلف لاگز کی ایک بڑی تعداد پر کارروائی کرنے کی ضرورت کا سامنا کرنا پڑا۔ ELK کو آلے کے طور پر منتخب کیا گیا تھا۔ یہ مضمون اس اسٹیک کو ترتیب دینے میں ہمارے تجربے پر بحث کرے گا۔

ہم اس کی تمام صلاحیتوں کو بیان کرنے کے لیے کوئی ہدف مقرر نہیں کرتے، لیکن ہم عملی مسائل کو حل کرنے پر خصوصی توجہ مرکوز کرنا چاہتے ہیں۔ یہ اس حقیقت کی وجہ سے ہے کہ اگرچہ کافی بڑی مقدار میں دستاویزات اور تیار شدہ تصاویر موجود ہیں، وہاں بہت سارے نقصانات ہیں، کم از کم ہم نے انہیں پایا۔

ہم نے اسٹیک کو docker-compose کے ذریعے تعینات کیا۔ مزید یہ کہ، ہمارے پاس ایک اچھی طرح سے لکھا ہوا docker-compose.yml تھا، جس نے ہمیں بغیر کسی پریشانی کے اسٹیک کو بڑھانے کی اجازت دی۔ اور ہمیں ایسا لگ رہا تھا کہ فتح پہلے ہی قریب ہے، اب ہم اسے اپنی ضروریات کے مطابق تھوڑا سا موافقت کریں گے اور بس۔

بدقسمتی سے، ہماری درخواست سے لاگ وصول کرنے اور ان پر کارروائی کرنے کے لیے سسٹم کو ترتیب دینے کی کوشش فوری طور پر کامیاب نہیں ہو سکی۔ لہذا، ہم نے فیصلہ کیا کہ یہ ہر ایک جزو کا الگ الگ مطالعہ کرنے کے قابل ہے، اور پھر ان کے کنکشن پر واپس جانا۔

لہذا، ہم نے logstash کے ساتھ شروع کیا.

ماحولیات، تعیناتی، کنٹینر میں لاگ سٹیش چلانا

تعیناتی کے لیے ہم docker-compose استعمال کرتے ہیں؛ یہاں بیان کردہ تجربات MacOS اور Ubuntu 18.0.4 پر کیے گئے تھے۔

logstash امیج جو ہمارے اصل docker-compose.yml میں رجسٹرڈ تھی وہ ہے docker.elastic.co/logstash/logstash:6.3.2

ہم اسے تجربات کے لیے استعمال کریں گے۔

ہم نے logstash چلانے کے لیے ایک علیحدہ docker-compose.yml لکھا۔ بلاشبہ، کمانڈ لائن سے تصویر کو لانچ کرنا ممکن تھا، لیکن ہم ایک مخصوص مسئلہ حل کر رہے تھے، جہاں ہم ہر چیز کو docker-compose سے چلاتے ہیں۔

کنفیگریشن فائلوں کے بارے میں مختصراً

جیسا کہ تفصیل سے درج ذیل ہے، logstash یا تو ایک چینل کے لیے چلایا جا سکتا ہے، اس صورت میں اسے *.conf فائل پاس کرنے کی ضرورت ہے، یا کئی چینلز کے لیے، ایسی صورت میں اسے pipelines.yml فائل پاس کرنے کی ضرورت ہے، جس کے نتیجے میں , ہر چینل کے لیے فائلوں .conf سے لنک کرے گا۔
ہم نے دوسرا راستہ اختیار کیا۔ یہ ہمیں زیادہ آفاقی اور توسیع پذیر لگ رہا تھا۔ لہذا، ہم نے pipelines.yml بنایا، اور ایک پائپ لائن ڈائرکٹری بنائی جس میں ہم ہر چینل کے لیے .conf فائلیں ڈالیں گے۔

کنٹینر کے اندر ایک اور کنفیگریشن فائل ہے - logstash.yml۔ ہم اسے ہاتھ نہیں لگاتے، ہم اسے ویسے ہی استعمال کرتے ہیں۔

تو، ہماری ڈائریکٹری ڈھانچہ:

ان پٹ ڈیٹا حاصل کرنے کے لیے، فی الحال ہم فرض کرتے ہیں کہ یہ پورٹ 5046 پر tcp ہے، اور آؤٹ پٹ کے لیے ہم 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 سے لیے گئے تھے (وہ جہاں پورا اسٹیک لانچ کیا گیا ہے) اور مجھے لگتا ہے کہ وہ یہاں کی مجموعی تصویر کو زیادہ متاثر نہیں کرتے ہیں۔
ہم docker.elastic.co/logstash/logstash:6.3.2 امیج سے ایک logstash سروس(s) بناتے ہیں اور اسے 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 ] پائپ لائن کامیابی سے شروع ہو گئی "}

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 پر نہیں۔ مانیٹرنگ فیچر استعمال کرنے کے لیے براہ کرم Elasticsearch پر X-Pack انسٹال کریں۔ دیگر خصوصیات دستیاب ہوسکتی ہیں۔
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/][Manticore::ResolutionFail] لچکدار تلاش"}
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/][Manticore::ResolutionFail] لچکدار تلاش"}

اور ہمارا لاگ ہر وقت رینگتا رہتا ہے۔

یہاں میں نے سبز رنگ میں اس پیغام کو نمایاں کیا ہے کہ پائپ لائن کامیابی کے ساتھ شروع ہوئی ہے، سرخ رنگ میں ایرر میسج اور پیلے رنگ میں رابطہ کرنے کی کوشش کا پیغام لچکدار تلاش: 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 | }

ایک چینل کے اندر کام کرنا

تو ہم نے لانچ کیا۔ اب آپ اصل میں لاگ سٹیش کو ترتیب دینے میں وقت نکال سکتے ہیں۔ آئیے ابھی کے لیے pipelines.yml فائل کو ہاتھ نہ لگائیں، آئیے دیکھتے ہیں کہ ہم ایک چینل کے ساتھ کام کر کے کیا حاصل کر سکتے ہیں۔

مجھے یہ کہنا ضروری ہے کہ چینل کنفیگریشن فائل کے ساتھ کام کرنے کے عمومی اصول کو یہاں سرکاری دستی میں اچھی طرح سے بیان کیا گیا ہے۔ یہاں
اگر آپ روسی میں پڑھنا چاہتے ہیں تو ہم نے اسے استعمال کیا۔ مضمون(لیکن استفسار کا نحو پرانا ہے، ہمیں اسے مدنظر رکھنا ہوگا)۔

آئیے ان پٹ سیکشن سے ترتیب وار چلتے ہیں۔ ہم پہلے ہی TCP پر کام دیکھ چکے ہیں۔ یہاں اور کیا دلچسپ ہو سکتا ہے؟

دل کی دھڑکن کا استعمال کرتے ہوئے پیغامات کی جانچ کریں۔

خودکار ٹیسٹ پیغامات تیار کرنے کا ایک دلچسپ موقع ہے۔
ایسا کرنے کے لیے، آپ کو ان پٹ سیکشن میں ہارٹ بین پلگ ان کو فعال کرنے کی ضرورت ہے۔

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 دوبارہ شروع ہوتا ہے، تو اسے یہ ڈیٹا دوبارہ موصول نہیں ہوتا ہے۔
ہم یہ دیکھنا چاہتے ہیں کہ اگر لاگ اسٹیش آف ہے، اور ڈیٹا فائلوں میں لکھنا جاری ہے، تو جب ہم اسے چلاتے ہیں، تو ہمیں یہ ڈیٹا موصول ہوگا۔

تجربہ کرنے کے لیے، آئیے 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 چلاتے ہیں، تو ہمیں کچھ نہیں ملے گا۔ لاگ سٹیش کے ذریعے صرف نئی لائنوں پر کارروائی کی جائے گی۔

موجودہ فائلوں سے لائنوں کو کھینچنے کے لیے، آپ کو ان پٹ سیکشن میں ایک اضافی لائن شامل کرنی چاہیے:

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

مزید یہ کہ، ایک نزاکت ہے: یہ صرف نئی فائلوں پر اثر انداز ہوتا ہے جو لاگ اسٹاش نے ابھی تک نہیں دیکھی ہیں۔ انہی فائلوں کے لیے جو پہلے سے لاگ اسٹیش کے منظر کے میدان میں تھیں، اس نے ان کا سائز پہلے ہی یاد کر لیا ہے اور اب وہ ان میں صرف نئی اندراجات لے گی۔

آئیے یہاں رکیں اور ان پٹ سیکشن کا مطالعہ کریں۔ ابھی بھی بہت سارے اختیارات موجود ہیں، لیکن ہمارے لیے ابھی مزید تجربات کے لیے یہی کافی ہے۔

روٹنگ اور ڈیٹا ٹرانسفارمیشن

آئیے درج ذیل مسئلے کو حل کرنے کی کوشش کرتے ہیں، ہم کہتے ہیں کہ ہمارے پاس ایک چینل کے پیغامات ہیں، ان میں سے کچھ معلوماتی ہیں، اور کچھ غلطی کے پیغامات ہیں۔ وہ ٹیگ کے لحاظ سے مختلف ہیں۔ کچھ 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 ہیں، کنسول میں آؤٹ پٹ ہوں گے، اور غلطیوں کے ساتھ، ہم فائل میں آؤٹ پٹ کریں گے۔

ہم ان پیغامات کو کیسے الگ کرتے ہیں؟ مسئلہ کی حالت پہلے سے ہی ایک حل تجویز کرتی ہے - آخر کار، ہمارے پاس پہلے سے ہی ایک وقف شدہ میسج_ٹائپ فیلڈ ہے، جو صرف دو قدریں لے سکتی ہے: 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 ترتیب دے رہا ہے۔