- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
デフォルトでは、Datadog の Intake API がログを受信すると、INFO
ステータスが生成され、status
属性として自身を追加します。
このデフォルトの status
は、ログ自体に含まれる実際のステータスを必ずしも反映しているとは限りません。このガイドでは、実際のステータスでデフォルト値をオーバーライドする方法を説明します。
Datadog で生ログが正しいステータスを表示していない場合、生ログから正しいログステータスを抽出して、それを正しいステータスにリマップします。
Grok パーサーを利用して、word()
マッチャーでルールを定義し、実際のログのステータスを抽出します。
word()
マッチャーを使用してステータスを抽出し、それをカスタムの log_status
属性に渡します。例えば、ログは次のようになります。
WARNING: John disconnected on 09/26/2017
以下のようなルールを追加します。
MyParsingRule %{word:log_status}: %{word:user.name} %{word:action}.*
MyParsingRule
の抽出の出力:
{
"action": "disconnected",
"log_status": "WARNING",
"user": {
"name": "John"
}
}
log_status
属性は正しいステータスを含んでいます。ログステータスリマッパーを追加して、log_status
属性のステータス値がデフォルトのログステータスをオーバーライドすることを確認します。
パイプラインの修正は、すべての処理が取り込みプロセスで行われるため、新しいログにのみ影響します。
JSON ログは Datadog で自動的にパースされます。ログの status
属性は予約属性なので、JSON ログのための前処理操作を通過します。
この例では、ログの実際のステータスは、デフォルトの INFO
ログステータスではなく、logger_severity
属性の値です。
logger_severity
属性の値がデフォルトのログステータスをオーバーライドするようにするには、logger_severity
をステータス属性のリストに追加します。
logger_severity
を追加します。ステータスリマッパーは予約されたすべての属性をリストの順番に探します。ステータスが logger_severity
属性に由来していることを確認するために、リストの最初に置きます。パイプラインの修正は、すべての処理が取り込みプロセスで行われるため、新しいログにのみ影響します。新しいログは logger_severity
属性値で正しく構成されます。
リマップが機能するためには、プロセッサードキュメントで指定されているステータスフォーマットを遵守する必要があります。