第15章 ログレコードのフィールド
ロギングによってエクスポートされたログレコードには、以下のフィールドが表示される場合があります。ログレコードは通常 JSON オブジェクトとしてフォーマットされますが、同じデータモデルは他のエンコーディングに適用できます。
Elasticsearch および Kibana からこれらのフィールドを検索するには、検索時に点線の全フィールド名を使用します。たとえば、Elasticsearch /_search URL の場合、Kubernetes Pod 名を検索するには、/_search/q=kubernetes.pod_name:name-of-my-pod を使用します。
最上位フィールドはすべてのレコードに存在する可能性があります。
message
元のログエントリーテキスト (UTF-8 エンコード)。このフィールドが存在しないか、空でない 構造化 フィールドが存在する可能性があります。詳細は、structured の説明を参照してください。
| データのタイプ | text |
| 値の例 |
|
structured
構造化されたオブジェクトとしての元のログエントリー。このフィールドは、フォワーダーが構造化された JSON ログを解析するように設定されている場合に存在する可能性があります。元のログエントリーの構造化ログが有効である場合に、このフィールドには同等の JSON 構造が含まれます。それ以外の場合は、このフィールドは空または存在しないため、message フィールドに元のログメッセージが含まれます。構造化された フィールドには、ログメッセージに含まれるサブフィールドがあるので、ここでは制約が定義されていません。
| データのタイプ | group |
| 値の例 | map[message:starting fluentd worker pid=21631 ppid=21618 worker=0 pid:21631 ppid:21618 worker:0] |
@timestamp
ログペイロードが作成された時点か、作成時間が不明な場合は、ログペイロードが最初に収集された時点の UTC 値のマーキング。“@” 接頭辞は、特定の用途で使用できるように予約されているフィールドを表します。ElasticSearch の場合、ほとんどのツールはデフォルトで “@timestamp" を検索します。
| データのタイプ | 日付 |
| 値の例 |
|
hostname
このログメッセージの発信元のホスト名。Kubernetes クラスターでは、これは kubernetes.host と同じです。
| データのタイプ | キーワード |
ipaddr4
ソースサーバーの IPv4 アドレス。配列を指定できます。
| データのタイプ | ip |
ipaddr6
ソースサーバーの IPv6 アドレス (ある場合)。配列を指定できます。
| データのタイプ | ip |
level
rsyslog(severitytext property)、Python のロギングモジュールなどのさまざまなソースのロギングレベル。
以下の値は syslog.h から取得されます。値の前には 同等の数値 が追加されます。
-
0=emerg、システムが使用できない。 -
1=alert。アクションをすぐに実行する必要がある。 -
2=crit、致命的な状況。 -
3=err、エラーのある状況。 -
4=warn、警告のある状況。 -
5=notice、通常ではあるが、影響が大きい状況。 -
6=info、情報提供。 -
7=debug、デバッグレベルのメッセージ。
以下の 2 つの値は syslog.h の一部ではありませんが、広く使用されています。
-
8=trace、トレースレベルメッセージ。これは、debugメッセージよりも詳細にわたります。 -
9=unknown、ロギングシステムで認識できない値を取得した場合。
他のロギングシステムのログレベルまたは優先度を前述のリストで最も近い一致にマップします。たとえば python logging では、CRITICAL と crit、ERROR と err が同じです。
| データのタイプ | キーワード |
| 値の例 |
|
pid
ロギングエンティティーのプロセス ID です (ある場合)。
| データのタイプ | キーワード |
サービス
ロギングエンティティーに関連付けられたサービスの名前です (ある場合)。たとえば、syslog の APP-NAME および rsyslog の programname プロパティーはサービスフィールドにマップされます。
| データのタイプ | キーワード |
