filebeatはnginxの各リクエストに要する時間を記録しkibana内に表示する

filebeatバージョン:7.4.2

elasticsearchバージョン:7.4.2

Kibana 7.4.2

nginxログ新規request_timeとupstream_response_time 2フィールド

1.nginx構成

http {
	## main  log         
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" $request_time $upstream_response_time';
    access_log  logs/access.log  main;
}

2.カスタムgrok正則

ここでfilebeatsのnginx moduleを開いたと仮定すると、$(filebeats )/module/nginx/access/default.jsonというファイルを直接構成することができます.

もしあなたがfiletbeatにいたら.ymlファイルに配置するinputであれば、kibanaが持参するdevツールhttp://xxxx/app/kibana#/dev_tools/console?_g=()を使用してpipelineの配置情報PUTをelastcisearchに、下図のように、配置情報は上記のdefaultを使用することができる.jsonの内容は、inputがpipelineの属性を指定することを覚えています.

grokの正規構成は、grokが持参したpattern(github上のlogstashのソースファイル)

を参照することができる.

以下では正規のprocessorの他にconvertのprocessorも用いられており、主な目的はrequest_timeとresponse_timeのデータ型がfloatに変換され、nginxのログからこの2つの値が出力された場合、request_timeの場合、-という文字が直接印刷され、grokでNUMBERマッチングを使用するとマッチングに失敗するので、ここではNOTSPACEマッチングを使用し、convertでデータ型変換を行います.

{
    "processors": [
        {
            "grok": {
                "field": "message",
                "patterns": [
                    "\"?(?:%{IP_LIST:nginx.access.remote_ip_list}|%{DATA:source.address}) - %{DATA:user.name} \\[%{HTTPDATE:nginx.access.time}\\] \"%{DATA:nginx.access.info}\" %{NUMBER:http.response.status_code:long} %{NUMBER:http.response.body.bytes:long} \"%{DATA:http.request.referrer}\" \"%{DATA:user_agent.original}\" %{NOTSPACE:http.request_time} %{NOTSPACE:http.upstream.response_time}"
                ],
                "pattern_definitions": {
                    "IP_LIST": "%{IP}(\"?,?\\s*%{IP})*"
                },
                "ignore_missing": true
            }
        },
        {
            "convert": {
                "field": "http.request_time",
				"type": "float",
				"ignore_missing": true,
				"on_failure": [
					{
						"set": {
							"field": "http.request_time",
							"value": -1.0
						}
					}
				]
            }
        },
        {
            "convert": {
                "field": "http.upstream.response_time",
				"type": "float",
				"ignore_missing": true,
				"on_failure": [
					{
						"set": {
							"field": "http.upstream.response_time",
							"value": -1.0
						}
					}
				]
            }
        }   
}   

4.elasticsearchのpipelineキャッシュを削除する
ここではkibanaが持参したdevツールhttp://xxxx/app/kibana#/dev_tools/console?_g=()を使用できます

DELETE _ingest/pipeline/xxxxxxx

5.filebeatsを再起動する
filebeatsのプライマリプロファイルに構成再ロード構成がある場合は、filebeatsプロセスをオフにする必要がなく、再ロード構成を待つだけでよい.

filebeats.yml自動ロードプロファイルの変化するプロファイル(ここで自動ロードはmodules.d/フォルダ内のプロファイルのみであることに注意)

filebeat.config.modules:
  # Glob pattern for configuration loading
  path: ${path.config}/modules.d/*.yml

  # Set to true to enable config reloading
  reload.enabled: true

  # Period on which files under path should be checked for changes
  #reload.period: 10s

構成情報の変化をリアルタイムで見るために、filebeatsを起動するときにパラメータを指定してdebug情報をコンソールfilebeats.exe -e -d "publish"

に出力することができる.
発生する可能性のある問題

nginxのログが変更されると、kibanaインタフェースにログフォーマットが一致しないことが表示されます.ステップ4でpipelineを削除したり、PUTでpipelineの内容を変更したり、nginx moduleを使用している場合は、pipelineの名前はfilebeat-{filebeat.version}-nginx-access-defaultであるべきです.

ログ解析は正常で、pipelineの内容は変更され(devツールでGET _ingest/pipeline/を使用して表示できます)、kibanaのmanagment-index pattern(http://xxxx/kibana#/management/kibana/index_patterns?_g=())に入り、対応するindexを選択してリフレッシュします.