BeatsとLogstashを使用してElasticSearchにログを送信する

BeatsとLogstashを使用してElasticSearchにログを送信する

  • ITOps・DevOps
5分で読めます 更新日 Jul 5, 2019

ポイント: BeatsとLogstashを使用してElasticSearchにログを送信する手順が提供されており、nginxウェブサーバーログの解析に焦点を当てています。BeatsはログをJSONに変換し、Logstashは解析を処理し、データをElasticSearchに送信します。

  • Beatsはログファイルを監視し、解析のためにLogstashに送信します。
  • LogstashはBeatsをリッスンし、ログをフォーマットしてからElasticSearchに送信します。

ここでは、Beats(別名File Beats)とLogstashを使用してElasticSearchにログを送信する方法を説明します。nginxウェブサーバーログを解析し、最も簡単なユースケースの1つです。また、ElasticCloudを使用しており、ElasticSearchの独自のローカルインストールの代わりに使用しています。ただし、スタンドアロンインストールの指示は同じであり、ほとんどの場合、スタンドアロンインストールにはユーザーIDとパスワードを必要としません。

以前、LogstashなしでBeatsを使用してnginxログを解析する方法について書きました。なぜ両方が必要なのか疑問に思うかもしれません。答えは、BeatsがログをElasticSearchに必要なJSON形式に変換しますが、GETまたはPOSTメッセージフィールドをウェブサーバーに解析してURL、操作、位置などを引き出すことはできません。Logstashを使用すると、すべての作業ができます。

  • Beatsは/var/logs/nginx*.logsに書き込まれた新しいログエントリを監視するように構成されています。
  • LogstashはBeatsをリッスンして、これらのログを解析し、ElasticSearchに送信します。

Beatsをダウンロードしてインストールする:

    wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.1.1-amd64.deb
sudo dpkg -i filebeat-7.1.1-amd64.deb

nginx Beatsモジュールを有効にする必要はありません。Logstashに解析を任せます。

/etc/filebeat/filebeat設定ファイルを編集してください:

ファイルの上部と下部のセクションを変更する必要があります。以下に、これを2つの別々のセクションで示します。最初は上部:

重要な項目は:

 enabled: true

さもなければ何も行いません。

 - /var/log/nginx/*.log

ここで監視するフォルダを一覧表示できます。各行を個別に記入してください。この場合、nginxのみを一覧表示します。

    #=========================== Filebeat inputs =============================

filebeat.inputs:

# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.

- type: log

  # Change to true to enable this input configuration.
  enabled: true

  # Paths that should be crawled and fetched. Glob based paths.
  paths:
    - /var/log/nginx/*.log

ここでは:

  • ElasticSearch出力をコメントアウトします。Logstashを使用して書き込む予定です。
  • Logstash行のコメントを解除します。
  • BeatsにLogStashの場所を指定します。
  • 行##output.elasticsearchもコメントアウトすることを確認してください。
    #-------------------------- Elasticsearch output ------------------------------
##output.elasticsearch:
  # Array of hosts to connect to.
  # hosts: ["localhost:9200"]

  # Enabled ilm (beta) to use index lifecycle management instead daily indices.
  #ilm.enabled: false

  # Optional protocol and basic auth credentials.
  #protocol: "https"
  #username: "elastic"
  #password: "changeme"

#----------------------------- Logstash output --------------------------------
output.logstash:
  # The Logstash hosts
  hosts: ["localhost:5044"]

今、Beatsを起動します。-eはstdoutにログを書き込むように指示します。これにより、機能していることを確認し、エラーをチェックできます。

    sudo /usr/share/filebeat/bin/filebeat -e -c /etc/filebeat/filebeat.yml

LogStashをインストールする

    cd /usr/share
sudo mkdir logstash
sudo wget https://artifacts.elastic.co/downloads/logstash/logstash-7.1.1.tar.gz
sudo tar xvfz logstash-7.1.1.tar.gz

/usr/share/logstash/logstash-7.1.1/config/nginx.confを編集してください。

注目すべき項目は:

input logstashにポート5044でBeatsをリッスンするよう指示する

filter {

grok {

これを理解するためにはGrokを理解する必要があります。まだ試さないでください。それはファイルパーサーツールです。基本的に異なるファイル形式を理解し、さらに拡張可能です。以下の例を使用してください。ElasticSearchのドキュメント内の例は機能しません。そのため、技術ライターは皆同じ作業例を使用します。

output {

elasticsearch {

hosts => ["https://58571402f5464923883e7be42a037917.eu-central-1.aws.cloud.es.io:9243"]

user => "elastic"

password => "xxxxxxxx"

index => "logstash-%{+YYYY.MM.dd}"

}

stdout { codec => rubydebug }

}

この部分は失望です。ElasticSearchはBeatsのように<強>cloud.idと<強>cloud.authを使用してElasticSearchに接続することを許可していません。そのため、URLとユーザーIDおよびパスワードを指定する必要があります。cloud.elastic.comにログインするために使用するのと同じユーザーIDとパスワードを使用してください。

別のユーザーを作成することもできますが、その場合はそのユーザーにインデックスを作成する権限を与える必要があります。そのため、elasticユーザーを使用することは、短いログとしてスーパーユーザーを使用することになります。

index行は、インデックスをlogstashと日付の組み合わせにすることを可能にします。目標は、意味のある名前を付けることです。おそらくnginx*の方が良いでしょう。なぜなら、Logstashを使用してさまざまなログやアプリケーションを扱うからです。

codec = rubydebugは出力をstdoutに書き込むため、機能していることを確認できます。

    input {
  beats {
    port => 5044
    host => "0.0.0.0"
  }
}

filter {
 grok {
   match => [ "message" , "%{COMBINEDAPACHELOG}+%{GREEDYDATA:extra_fields}"]
   overwrite => [ "message" ]
 }
 mutate {
   convert => ["response", "integer"]
   convert => ["bytes", "integer"]
   convert => ["responsetime", "float"]
 }
 geoip {
   source => "clientip"
   target => "geoip"
   add_tag => [ "nginx-geoip" ]
 }
 date {
   match => [ "timestamp" , "dd/MMM/YYYY:HH:mm:ss Z" ]
   remove_field => [ "timestamp" ]
 }
 useragent {
   source => "agent"
 }
}

output {
  elasticsearch {
    hosts => ["https://58571402f5464923883e7be42a037917.eu-central-1.aws.cloud.es.io:9243"]
    user => "elastic"
    password => "xxxxxxxx"
    index => "logstash-%{+YYYY.MM.dd}"
  }
 stdout { codec => rubydebug }
}

今、Logstashをフォアグラウンドで起動して、何が起こっているのかを確認できます。

    sudo /usr/share/logstash/logstash-7.1.1/bin/logstash -f /usr/share/logstash/logstash-7.1.1/config/nginx.conf

nginxウェブサーバーがあり、/var/log/nginxにいくつかのログが書き込まれていると仮定すると、1分ほどでElasticSearchにログが書き込まれ始めるはずです。または、サンプルエントリを与えるためにhttps://raw.githubusercontent.com/respondcreate/nginx-access-log-frequency/master/example-access.logをダウンロードできます。

パスワードとElasticSearchのユーザーIDを環境変数にエクスポートしてください:

    export pwd="elastic:xxxxx"

その後、ElasticSearchをクエリすると、logstash*インデックスが作成されているのが確認できます。

    curl --user $pwd -XGET https://58571402f5464923883e7be42a037917.eu-central-1.aws.cloud.es.io:9243/logstash-2019.06.19-000001/_search?pretty

これで、そのElasticSearchインデックスをクエリし、1つのレコードを確認できます。以下に、メッセージログエントリを個別のフィールドに解析したことを示すためにレコードを短縮しています。これをクエリすることができます。例えば、request(URL)やverb(GET、PUTなど)です。

    curl --user $pwd -X GET 'https://58571402f5464923883e7be42a037917.eu-central-1.aws.cloud.es.io:9243/logstash-2019.06.19-000001?pretty'
    {
        "_index" : "logstash-2019.06.19-000001",
        "_type" : "_doc",
        "_id" : "9RZDcWsBDzKZEQI4C4Qu",
        
…

          "verb" : "GET",
          "input" : {
            "type" : "log"
          },
          "auth" : "-",
          "source" : "/var/log/nginx/another.log",
          "device" : "Other",
        

….

          "geoip" : {
            "timezone" : "Europe/Moscow",
            "latitude" : 55.7386,
            "location" : {
              "lon" : 37.6068,
              "lat" : 55.7386
            },
            "longitude" : 37.6068,
            "country_code2" : "RU",
            "ip" : "46.160.190.178",
            "continent_code" : "EU",
            "country_code3" : "RU",
            "country_name" : "Russia"
          },
          


…


          "response" : 200,
          "os_name" : "Windows",
          "major" : "52",
          "agent" : "\"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36\"",
          "build" : "",
          "clientip" : "46.160.190.178",
          "@version" : "1",
          "message" : "46.160.190.178 - - [19/Jun/2019:12:39:52 +0000] \"GET / HTTP/1.1\" 200 481 \"-\" \"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36\"",
          

…

          "request" : "/",

Kibanaでは次のように表示されます:

展開時はこのようになります:

これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも代表するものではありません。

ITOps・DevOpsの関連記事

The Briefを購読する

このオファーに登録することで、あなたはBMCのプライバシーポリシーを読み、同意したことを確認します。

ありがとう

あなたはThe Briefに登録されました
The Briefはメインフレームとエンタープライズオーケストレーション—BMC AMIとControl-M—および、両者に関するアナリストの研究、顧客の展開、イベントをカバーしています。