第9章 ロギングおよびアグリゲーション
ロギングは、詳細なログをサードパーティーの外部ログアグリゲーションサービスに送信する機能を提供します。このデータフィードに接続されたサービスは、Automation Controller の使用や技術の傾向に関する洞察を得るための手段として機能します。このデータを使用して、インフラストラクチャー内のイベントを分析し、異常を監視し、あるサービスのイベントを別のサービスのイベントと関連付けることができます。
Automation Controller に最も役立つデータのタイプは、ジョブファクトデータ、ジョブイベントまたはジョブ実行、アクティビティーストリームデータ、およびログメッセージです。JSON 形式のデータを HTTP 接続経由で送信できます。カスタムハンドラーやインポートしたライブラリーで設計したサービス固有の調整を使用することはほとんどありません。
Automation Controller によってインストールされる rsyslog のバージョンは、次の rsyslog モジュールを含みません。
- rsyslog-udpspoof.x86_64
- rsyslog-libdbi.x86_64
Automation Controller 外部のロギングは、以前は RHEL 提供の rsyslog パッケージを使用して実行していた可能性がありますが、Automation Controller をインストールした後は、Automation Controller 提供の rsyslog パッケージのみを使用する必要があります。
Automation Controller インスタンスでのシステムログの記録にすでに rsyslog を使用している場合は、別の rsyslog プロセス (Automation Controller が使用するのと同じバージョンの rsyslog を使用) を実行し、別の /etc/rsyslog.conf ファイルを指定することで、引き続き rsyslog を使用して Automation Controller の外部からのログを処理できます。
外部ロガーがオフラインになった場合に Automation Controller の rsyslog プロセスで未送信のメッセージを処理する方法を、/api/v2/settings/logging/ エンドポイントを使用して設定します。
LOG_AGGREGATOR_ACTION_MAX_DISK_USAGE_GB: rsyslogd アクションキューの最大ディスク永続性 (GB 単位)。外部ログアグリゲーターの停止時に保存するデータの量 (ギガバイト単位) を指定します (デフォルトは 1)。
rsyslogd queue.maxDiskSpace設定に相当します。LOG_AGGREGATOR_ACTION_QUEUE_SIZE: ログアクションキューに保存できるメッセージの最大数。保存されるメッセージの数に応じて、rsyslog アクションキューをどれだけ大きくするかを定義します。これはメモリー使用量に影響を及ぼす可能性があります。キューがこの数の 75% に達すると、キューはディスクへの書き込みを開始します (
rsyslogのqueue.highWatermark)。90% に達すると、NOTICE、INFO、DEBUGメッセージが破棄され始めます (queue.discardMarkと 'queue.discardSeverity=5`)。アクションの
rsyslogd queue.size設定に相当します。
これは、LOG_AGGREGATOR_MAX_DISK_USAGE_PATH で指定されたディレクトリーにファイルを保存します。
-
LOG_AGGREGATOR_MAX_DISK_USAGE_PATH: 外部ログアグリゲーターの停止後に再試行する必要があるログを保存する場所を指定します (デフォルトは/var/lib/awx)。rsyslogd queue.spoolDirectory設定に相当します。
たとえば、Splunk がオフラインになった場合、rsyslogd は Splunk がオンラインに戻るまでディスクにキューを保存します。デフォルトでは、(Splunk がオフラインの間) 最大 1 GB のイベントが保存されますが、必要に応じて 1 GB 超に増やすことも、キューを保存するパスを変更することもできます。
9.1. ロガー リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller は、分析と監視のために構造化されたログデータを配信するように設定できる複数のロガーを提供します。
以下は、予測可能な構造化形式または半構造化形式で大量の情報を提供する特別なロガー (汎用的なサーバーログを構成する awx は除く) です。これらは、API からデータを取得するときと同じ構造を使用します。
-
job_events: Ansible コールバックモジュールから返されるデータを渡します。 -
job_lifecycle: ジョブの作成、開始、終了時など、ジョブのライフサイクルに関するデータを提供します。 -
broadcast_websocket: クライアントに送信されるブロードキャスト Websocket メッセージに関するデータを提供します。 -
activity_stream: アプリケーション内のオブジェクトに対する変更の記録を表示します。 -
system_tracking: Ansiblesetupモジュールによって収集されたファクトデータを提供します。つまり、Enable Fact Cache を選択した状態でジョブテンプレートを実行する場合は、gather_facts: trueになります。 -
awx: 通常はファイルに書き込まれるログを含む、汎用的なサーバーログを提供します。これには、すべてのログが有する標準メタデータが含まれます。ただし、含まれるのはログステートメントからのメッセージのみです。
これらのロガーは、INFO のログレベルのみを使用します。例外は awx ロガーで、これはどのレベルでも使用できます。
さらに、標準の Automation Controller ログも、同じメカニズムで配信できます。ローカルの設定ファイルで複雑なディクショナリーを操作せずに、これら 5 つのデータソースをそれぞれ有効または無効にする方法や、標準の Automation Controller ログから使用するログレベルを調整する方法は明らかです。
ナビゲーションパネルから、
9.1.1. ログメッセージスキーマ リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、さまざまな Automation Controller コンポーネントによって生成されるログメッセージの共通スキーマについて説明します。ログメッセージスキーマを理解すると、システムを効果的に監視およびトラブルシューティングするのに役立ちます。
全ロガーに対する共通のスキーマ
-
cluster_host_id: Automation Controller クラスター内のホストの一意識別子。 -
level: イベントの重要性をほぼ反映する、標準の Python ログレベル。すべてのデータロガーは 'レベル' の一部としてINFOレベルを使用しますが、他の Automation Controller ログは必要に応じて異なるレベルを使用します。 -
logger_name: 設定で使用するロガー名 (たとえば "activity_stream")。 -
@timestamp: ログの時刻。 -
path: ログが生成されたコードのファイルパス。
9.1.2. アクティビティーストリームスキーマ リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller には、ジョブテンプレート、インベントリー、認証情報など、システム内のオブジェクトの変更を記録する activity_stream ロガーが組み込まれています。
これは、ログメッセージスキーマ にリストされているすべてのロガーに共通するフィールドを使用します。
次の追加フィールドがあります。
-
actor: ログに記述されたアクションを行ったユーザーのユーザー名。 -
changes: 変更されたフィールド、および古い値または新しい値の概要 (JSON)。 -
operation: アクティビティーストリームに記録された変更のカテゴリー (例: "associate")。 -
object1: 操作対象のオブジェクトに関する情報。アクティビティーストリームに表示される内容と一致します。 -
object2: 該当する場合には、アクションに関連する 2 つ目のオブジェクト。
このロガーは、ジョブイベントに保存されているデータを反映します。ただし、ロガーの予期される標準フィールドと競合する場合を除きます (この場合、フィールドはネストされます)。job_event モデルのフィールド host は、event_host として指定されることに注意してください。ペイロード内にはサブディクショナリーフィールド event_data もあります。このフィールドには、Ansible イベントの詳細に応じて異なるフィールドが含まれます。
このロガーには ログメッセージスキーマ の共通フィールドも含まれています。
9.1.3. スキャン/ファクト/システム追跡データスキーマ リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Automation Controller のスキャン/ファクト/システム追跡ロガーによって生成されるログメッセージのスキーマについて説明します。
これらには、サービス、パッケージまたはファイルの詳細なディクショナリータイプのフィールドが含まれます。
services: サービススキャンの場合、このフィールドが含まれ、サービスの名前に基づいたキーを含みます。注記名前の Elastic Search ではピリオドは使用できず、ログフォーマッターによって "_" に置き換えられます。
-
package: パッケージスキャンからのログメッセージに含まれます。 -
files: ファイルスキャンからのログメッセージに含まれます。 -
host: スキャンを適用するホストの名前です。 -
inventory_id: ホストが含まれるインベントリー ID です。
このロガーには、ログメッセージスキーマ の共通フィールドも含まれます。
9.1.4. ジョブステータスの変更 リンクのコピーリンクがクリップボードにコピーされました!
ジョブステータス変更ロガーは、ジョブのステータス変更が発生した際にそれをキャプチャーします。
この情報ソースは、ジョブイベントと比較してジョブ状態の変化に関する情報は少量とし、ジョブテンプレートをベースとするジョブ以外で、統合されたジョブタイプに対する変更を取得します。
このロガーには、ログメッセージスキーマ の共通フィールドと、ジョブモデルに存在するフィールドも含まれます。
9.1.5. Automation Controller のログ リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller は標準の Python ロギングモジュールを使用して、システムのさまざまな部分からのメッセージをログに記録します。
このロガーには、ログメッセージスキーマ の共通フィールドも含まれます。
さらに、ログメッセージを含む msg フィールドが含まれます。エラーには別の traceback フィールドが含まれます。ナビゲーションパネルから、
9.1.6. ログアグリゲーターサービス リンクのコピーリンクがクリップボードにコピーされました!
ロギングアグリゲーターサービスは、以下の監視またはデータ分析システムと連携します。
9.1.6.1. Splunk リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller の Splunk ロギング統合では、Splunk HTTP Collector を使用します。
SPLUNK ログアグリゲーターを設定する場合は、次の例のように、完全な URL を HTTP Event Collector ホストに追加します。
Splunk HTTP Event Collector はデフォルトでポート 8088 をリッスンするため、受信要求が正常に処理されるように、LOG_AGGREGATOR_HOST に完全な HEC イベント URL (ポート番号を含む) を指定する必要があります。
一般的な値を次の例に示します。
HTTP Event Collector の設定の詳細は、Splunk のドキュメント を参照してください。
9.1.6.2. Loggly リンクのコピーリンクがクリップボードにコピーされました!
Loggly ロギングアグリゲーター統合により、Loggly の HTTP エンドポイントを使用して、コントローラーから Loggly アカウントにログを送信できます。
Loggly の HTTP エンドポイントを介したログ送信の詳細は、Loggly のドキュメント を参照してください。
Loggly は、次の例の Logging Aggregator フィールドに示す URL 規則を使用します。
9.1.6.3. Sumologic リンクのコピーリンクがクリップボードにコピーされました!
Sumologic では、JSON ファイルに含まれる検索基準を作成します。JSON ファイルには、必要なデータを収集するのに使用するパラメーターが指定されています。
9.1.6.4. Elastic stack (以前の ELK stack) リンクのコピーリンクがクリップボードにコピーされました!
エラスティックスタックは、ログデータをリアルタイムで検索、分析、視覚化するためのオープンソース製品のコレクションです。
独自のバージョンの Elastic Stack をセットアップしている場合、必要な変更は、logstash logstash.conf ファイルに次の行を追加するだけです。
filter {
json {
source => "message"
}
}
filter {
json {
source => "message"
}
}
Elastic 5.0.0 で後方互換性のない変更が導入され、使用するバージョンによっては、異なる設定が必要になる可能性があります。