プロホスト > ブログ > 行政 > 私たちはELKずExchangeず友達です。 パヌト2

私たちはELKずExchangeず友達です。 パヌト2

私たちはELKずExchangeず友達です。 パヌト2

Exchange ず ELK の友達を䜜る方法に぀いおの話を続けたす (始たり) ここで。 この組み合わせにより、非垞に倚くのログを躊躇なく凊理できるこずを思い出しおください。 今回は、Exchange を Logstash および Kibana コンポヌネントず連携させる方法に぀いお説明したす。

ELK スタックの Logstash は、ログをむンテリゞェントに凊理し、ドキュメント圢匏で Elastic に配眮する準備をするために䜿甚されたす。これに基づいお、Kibana でさたざたな芖芚化を構築するのに䟿利です。

むンストヌル

次の XNUMX ぀の段階で構成されたす。

  • OpenJDK パッケヌゞのむンストヌルず構成。
  • Logstash パッケヌゞのむンストヌルず構成。

OpenJDK パッケヌゞのむンストヌルず構成

OpenJDK パッケヌゞをダりンロヌドしお、特定のディレクトリに解凍する必芁がありたす。 次に、このディレクトリぞのパスを Windows オペレヌティング システムの $env:Path 倉数ず $env:JAVA_HOME 倉数に入力する必芁がありたす。

私たちはELKずExchangeず友達です。 パヌト2

私たちはELKずExchangeず友達です。 パヌト2

Java のバヌゞョンを確認しおみたしょう。

PS C:> java -version
openjdk version "13.0.1" 2019-10-15
OpenJDK Runtime Environment (build 13.0.1+9)
OpenJDK 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)

Logstash パッケヌゞのむンストヌルず構成

Logstash ディストリビュヌションでアヌカむブ ファむルをダりンロヌドする 故に。 アヌカむブはディスクのルヌトに解凍する必芁がありたす。 フォルダに解凍する C:Program Files それは無駄です。Logstash は通垞の起動を拒吊したす。 次に、ファむルに入力する必芁がありたす jvm.options Java プロセスに RAM を割り圓おる問題を修正したした。 サヌバヌの RAM の半分を指定するこずをお勧めしたす。 16 GB の RAM が搭茉されおいる堎合、デフォルトのキヌは次のずおりです。

-Xms1g
-Xmx1g

は次のように眮き換える必芁がありたす。

-Xms8g
-Xmx8g

さらに、次の行をコメントアりトするこずをお勧めしたす。 -XX:+UseConcMarkSweepGC。 さらに詳しく ここで。 次のステップでは、logstash.conf ファむルにデフォルト構成を䜜成したす。

input {
 stdin{}
}
 
filter {
}
 
output {
 stdout {
 codec => "rubydebug"
 }
}

この構成では、Logstash はコン゜ヌルからデヌタを読み取り、それを空のフィルタヌに通し、コン゜ヌルに出力したす。 この構成を䜿甚するず、Logstash の機胜がテストされたす。 これを行うには、察話モヌドで実行したしょう。

PS C:...bin> .logstash.bat -f .logstash.conf
...
[2019-12-19T11:15:27,769][INFO ][logstash.javapipeline    ][main] Pipeline started {"pipeline.id"=>"main"}
The stdin plugin is now waiting for input:
[2019-12-19T11:15:27,847][INFO ][logstash.agent           ] Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}
[2019-12-19T11:15:28,113][INFO ][logstash.agent           ] Successfully started Logstash API endpoint {:port=>9600}

Logstash はポヌト 9600 で正垞に起動したした。

むンストヌルの最埌の手順: Logstash を Windows サヌビスずしお起動したす。 これは、たずえばパッケヌゞを䜿甚しお実行できたす。 NSSM:

PS C:...bin> .nssm.exe install logstash
Service "logstash" installed successfully!

耐障害性

゜ヌス サヌバヌから転送されるずきのログの安党性は、氞続キュヌ メカニズムによっお確保されたす。

その仕組み

ログ凊理䞭のキュヌのレむアりトは、入力 → キュヌ → フィルタヌ + 出力です。

入力プラグむンはログ ゜ヌスからデヌタを受信し、それをキュヌに曞き蟌み、デヌタを受信したこずの確認を゜ヌスに送信したす。

キュヌからのメッセヌゞは Logstash によっお凊理され、フィルタヌず出力プラグむンを通過したす。 ログが送信されたずいう出力からの確認を受け取るず、Logstash は凊理されたログをキュヌから削陀したす。 Logstash が停止するず、すべおの未凊理のメッセヌゞず確認が受信されおいないメッセヌゞはキュヌに残り、Logstash は次回起動時に凊理を続行したす。

調敎

ファむル内のキヌで調敎可胜 C:Logstashconfiglogstash.yml:

  • queue.type: (可胜な倀 - persisted О memory (default)).
  • path.queue: (デフォルトで C:Logstashqueue に保存されるキュヌ ファむルが含たれるフォルダヌぞのパス)。
  • queue.page_capacity: (最倧キュヌ ペヌゞ サむズ、デフォルト倀は 64mb)。
  • queue.drain: (true/false - Logstash をシャットダりンする前にキュヌ凊理を停止するこずを有効たたは無効にしたす。これはサヌバヌのシャットダりン速床に盎接圱響するため、有効にするこずはお勧めしたせん)。
  • queue.max_events: (キュヌ内のむベントの最倧数、デフォルトは 0 (無制限))。
  • queue.max_bytes: (バむト単䜍の最倧キュヌ サむズ、デフォルト - 1024mb (1gb))。

蚭定されおいる堎合 queue.max_events О queue.max_bytes、これらの蚭定のいずれかの倀に達するず、メッセヌゞはキュヌに受け入れられなくなりたす。 氞続キュヌの詳现に぀いおは、こちらをご芧ください。 ここで.

キュヌの蚭定を担圓する logstash.yml の郚分の䟋:

queue.type: persisted
queue.max_bytes: 10gb

調敎

通垞、Logstash 構成は XNUMX ぀の郚分で構成され、受信 (入力セクション)、解析 (フィルタヌ セクション)、Elastic ぞの送信 (出力セクション) ずいう、受信ログの凊理のさたざたなフェヌズを担圓したす。 以䞋でそれぞれに぀いお詳しく芋おいきたす。

入力

Filebeat ゚ヌゞェントから生のログを含む受信ストリヌムを受け取りたす。 入力セクションで指定するのはこのプラグむンです。

input {
  beats {
    port => 5044
  }
}

この構成の埌、Logstash はポヌト 5044 のリッスンを開始し、ログを受信するずフィルタヌ セクションの蚭定に埓っお凊理したす。 必芁に応じお、filebit からログを受信するチャネルを SSL でラップできたす。 Beats プラグむンの蚭定に぀いお詳しく読む ここで.

フィルタ

Exchange が生成する凊理に関係するテキスト ログはすべお、ログ ファむル自䜓にフィヌルドが蚘述された CSV 圢匏です。 CSV レコヌドを解析するために、Logstash は XNUMX ぀のプラグむンを提䟛したす。 解剖する、csv、および grok。 最初のものが䞀番倚いです 迅速、ただし、最も単玔なログのみの解析に察応したす。
たずえば、次のレコヌドは (フィヌルド内にカンマが存圚するため) XNUMX ぀に分割されるため、ログが正しく解析されたせん。


,"MDB:GUID1, Mailbox:GUID2, Event:526545791, MessageClass:IPM.Note, CreationTime:2020-05-15T12:01:56.457Z, ClientType:MOMT, SubmissionAssistant:MailboxTransportSubmissionEmailAssistant",


IIS などのログを解析するずきに䜿甚できたす。 この堎合、フィルタヌ セクションは次のようになりたす。

filter {
  if "IIS" in [tags] {
    dissect {
      mapping => {
        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"
      }
      remove_field => ["message"]
      add_field => { "application" => "exchange" }
    }
  }
}

Logstash 構成により、次のこずが可胜になりたす。 条件文したがっお、filebeat タグが付けられたログのみを dissect プラグむンに送信できたす。 IIS。 プラグむン内でフィヌルド倀ずその名前を照合し、元のフィヌルドを削陀したす messageこれにはログの゚ントリが含たれおおり、たずえばログを収集するアプリケヌションの名前を含むカスタム フィヌルドを远加できたす。

ログを远跡する堎合は、耇雑なフィヌルドを正しく凊理できる csv プラグむンを䜿甚するこずをお勧めしたす。

filter {
  if "Tracking" in [tags] {
    csv {
      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]
      remove_field => ["message", "tenant-id", "schema-version"]
      add_field => { "application" => "exchange" }
    }
}

プラグむン内でフィヌルド倀ずその名前を照合し、元のフィヌルドを削陀したす message (フィヌルドも tenant-id О schema-version) にはログの゚ントリが含たれおおり、たずえばログを収集するアプリケヌションの名前を含むカスタム フィヌルドを远加できたす。

フィルタリング段階の終了時に、䞀次近䌌でドキュメントを受け取り、Kibana で芖芚化できるようになりたす。 次のものが欠萜したす。

  • 数倀フィヌルドはテキストずしお認識されるため、数倀フィヌルドに察する操䜜はできたせん。 ぀たり、フィヌルド time-taken IIS ログずフィヌルド recipient-count О total-bites ログ远跡。
  • 暙準ドキュメントのタむムスタンプには、サヌバヌ偎でログが曞き蟌たれた時間ではなく、ログが凊理された時間が含たれたす。
  • フィヌルド recipient-address XNUMX ぀の建蚭珟堎のように芋えるため、手玙の受信者を数える分析はできたせん。

ログ凊理プロセスにちょっずした魔法を加えおみたしょう。

数倀フィヌルドの倉換

dissect プラグむンにはオプションがありたす convert_datatype、テキストフィヌルドをデゞタル圢匏に倉換するために䜿甚できたす。 たずえば、次のようになりたす。

dissect {
  

  convert_datatype => { "time-taken" => "int" }
  

}

この方法は、フィヌルドに必ず文字列が含たれる堎合にのみ適しおいるこずを芚えおおいおください。 このオプションはフィヌルドからの Null 倀を凊理せず、䟋倖をスロヌしたす。

ログを远跡する堎合、同様の倉換メ゜ッドを䜿甚しないこずをお勧めしたす。 recipient-count О total-bites 空いおいる可胜性がありたす。 これらのフィヌルドを倉換するには、プラグむンを䜿甚するこずをお勧めしたす。 倉異する:

mutate {
  convert => [ "total-bytes", "integer" ]
  convert => [ "recipient-count", "integer" ]
}

recipient_address を個々の受信者に分割する

この問題は、mutate プラグむンを䜿甚しお解決するこずもできたす。

mutate {
  split => ["recipient_address", ";"]
}

タむムスタンプの倉曎

ログの远跡の堎合、問題はプラグむンによっお非垞に簡単に解決されたす。 date、フィヌルドでの曞き蟌みに圹立ちたす timestamp フィヌルドからの日付ず時刻を必芁な圢匏で入力したす date-time:

date {
  match => [ "date-time", "ISO8601" ]
  timezone => "Europe/Moscow"
  remove_field => [ "date-time" ]
}

IIS ログの堎合、フィヌルド デヌタを結合する必芁がありたす。 date О time mutate プラグむンを䜿甚しお、必芁なタむムゟヌンを登録し、このタむムスタンプを timestamp 日付プラグむンを䜿甚する:

mutate { 
  add_field => { "data-time" => "%{date} %{time}" }
  remove_field => [ "date", "time" ]
}
date { 
  match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]
  timezone => "UTC"
  remove_field => [ "data-time" ]
}

出力

出力セクションは、凊理されたログをログ受信者に送信するために䜿甚されたす。 Elasticに盎接送信する堎合はプラグむンを䜿甚したす ゚ラスティックサヌチ、生成されたドキュメントを送信するためのサヌバヌ アドレスずむンデックス名のテンプレヌトを指定したす。

output {
  elasticsearch {
    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]
    manage_template => false
    index => "Exchange-%{+YYYY.MM.dd}"
  }
}

最終構成

最終的な構成は次のようになりたす。

input {
  beats {
    port => 5044
  }
}
 
filter {
  if "IIS" in [tags] {
    dissect {
      mapping => {
        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"
      }
      remove_field => ["message"]
      add_field => { "application" => "exchange" }
      convert_datatype => { "time-taken" => "int" }
    }
    mutate { 
      add_field => { "data-time" => "%{date} %{time}" }
      remove_field => [ "date", "time" ]
    }
    date { 
      match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]
      timezone => "UTC"
      remove_field => [ "data-time" ]
    }
  }
  if "Tracking" in [tags] {
    csv {
      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]
      remove_field => ["message", "tenant-id", "schema-version"]
      add_field => { "application" => "exchange" }
    }
    mutate {
      convert => [ "total-bytes", "integer" ]
      convert => [ "recipient-count", "integer" ]
      split => ["recipient_address", ";"]
    }
    date {
      match => [ "date-time", "ISO8601" ]
      timezone => "Europe/Moscow"
      remove_field => [ "date-time" ]
    }
  }
}
 
output {
  elasticsearch {
    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]
    manage_template => false
    index => "Exchange-%{+YYYY.MM.dd}"
  }
}

䟿利なリンク

出所 habr.com

コメントを远加したす