第8章 ロギングおよびアグリゲーション
ロギングは、詳細なログをサードパーティーの外部ログアグリゲーションサービスに送信する機能を提供します。このデータフィードに接続されたサービスは、Automation Controller の使用や技術の傾向に関する洞察を得るための手段として機能します。このデータを使用して、インフラストラクチャー内のイベントを分析し、異常を監視し、あるサービスのイベントを別のサービスのイベントと関連付けることができます。
Automation Controller に最も役立つデータのタイプは、ジョブファクトデータ、ジョブイベントまたはジョブ実行、アクティビティーストリームデータ、およびログメッセージです。データは、カスタムハンドラーで、またはインポートされたライブラリーを介して設計された最小限のサービス固有の調整を使用して、HTTP 接続を介して JSON 形式で送信されます。
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 超に増やすことも、キューを保存するパスを変更することもできます。
8.1. ロガー
以下は、予測可能な構造化形式または半構造化形式で大量の情報を提供する特別なロガー (汎用的なサーバーログを構成する awx
は除く) です。これらは、API からデータを取得するときと同じ構造を使用します。
-
job_events
: Ansible コールバックモジュールから返されるデータを渡します。 -
activity_stream
: アプリケーション内のオブジェクトに対する変更の記録を表示します。 -
system_tracking
: Ansiblesetup
モジュールによって収集されたファクトデータを提供します。つまり、Enable Fact Cache を選択した状態でジョブテンプレートを実行する場合は、gather_facts: true
になります。 -
awx
: 通常はファイルに書き込まれるログを含む、汎用的なサーバーログを提供します。これには、すべてのログが有する標準メタデータが含まれます。ただし、含まれるのはログステートメントからのメッセージのみです。
これらのロガーは、INFO
のログレベルのみを使用します。例外は awx
ロガーで、これはどのレベルでも使用できます。
さらに、標準の Automation Controller ログも、同じメカニズムで配信できます。ローカルの設定ファイルで複雑なディクショナリーを操作せずに、これら 5 つのデータソースをそれぞれ有効または無効にする方法や、標準の Automation Controller ログから使用するログレベルを調整する方法は明らかです。
ナビゲーションパネルから
8.1.1. ログメッセージスキーマ
全ロガーに対する共通のスキーマ
-
cluster_host_id
: Automation Controller クラスター内のホストの一意識別子。 -
level
: イベントの重要性をほぼ反映する、標準の Python ログレベル。すべてのデータロガーは「レベル」の一部としてINFO
レベルを使用しますが、他の Automation Controller ログは必要に応じて異なるレベルを使用します。 -
logger_name
: 設定で使用するロガー名 (たとえば "activity_stream")。 -
@timestamp
: ログの時刻。 -
path
: ログが生成されたコードのファイルパス。
8.1.2. アクティビティーストリームスキーマ
これは、ログメッセージスキーマ にリストされているすべてのロガーに共通するフィールドを使用します。
次の追加フィールドがあります。
-
actor
: ログに記述されたアクションを行ったユーザーのユーザー名。 -
changes
: 変更されたフィールド、および古い値または新しい値の概要 (JSON)。 -
operation
: "associate" など、アクティビティーストリームにログ記録された変更の基本カテゴリー。 -
object1
: 操作を行うプライマリーオブジェクトに関する情報。アクティビティーストリームに表示する内容と一貫性があります。 -
object2
: 該当する場合には、アクションに関連する 2 つ目のオブジェクト。
このロガーは、ジョブイベントに保存されているデータを反映します。ただし、ロガーの予期される標準フィールドと競合する場合を除きます (この場合、フィールドはネストされます)。特に、job_event
モデルのフィールド host は、event_host
として指定されます。ペイロード内にはサブディクショナリーフィールド event_data
もあり、これには Ansible イベントの詳細に応じて異なるフィールドが含まれます。
このロガーには、ログメッセージスキーマ の共通フィールドも含まれます。
8.1.3. スキャン/ファクト/システム追跡データスキーマ
これらには、サービス、パッケージまたはファイルの詳細なディクショナリータイプのフィールドが含まれます。
services
: サービススキャンの場合、このフィールドが含まれ、サービスの名前に基づいたキーを含みます。注記名前の Elastic Search ではピリオドは使用できず、ログフォーマッターによって "_" に置き換えられます。
-
package
: パッケージスキャンからのログメッセージに含まれます。 -
files
: ファイルスキャンからのログメッセージに含まれます。 -
host
: スキャンを適用するホストの名前です。 -
inventory_id
: ホストが含まれるインベントリー ID です。
このロガーには、ログメッセージスキーマ の共通フィールドも含まれます。
8.1.4. ジョブステータスの変更
この情報ソースは、ジョブイベントと比較してジョブ状態の変化に関する情報は少量とし、ジョブテンプレートをベースとするジョブ以外で、統合されたジョブタイプに対する変更を取得します。
このロガーには、ログメッセージスキーマ の共通フィールドと、ジョブモデルに存在するフィールドも含まれます。
8.1.5. Automation Controller のログ
このロガーには、ログメッセージスキーマ の共通フィールドも含まれます。
さらに、ログメッセージを含む msg
フィールドが含まれます。エラーには別の traceback
フィールドが含まれます。ナビゲーションパネルから
8.1.6. ログアグリゲーターサービス
ログアグリゲーターサービスは、以下の監視またはデータ分析システムと連携します。
8.1.6.1. Splunk
Automation Controller の Splunk ロギング統合では、Splunk HTTP Collector を使用します。SPLUNK ログアグリゲーターを設定する場合は、次の例のように、完全な URL を HTTP Event Collector ホストに追加します。
https://<yourcontrollerfqdn>/api/v2/settings/logging { "LOG_AGGREGATOR_HOST": "https://<yoursplunk>:8088/services/collector/event", "LOG_AGGREGATOR_PORT": null, "LOG_AGGREGATOR_TYPE": "splunk", "LOG_AGGREGATOR_USERNAME": "", "LOG_AGGREGATOR_PASSWORD": "$encrypted$", "LOG_AGGREGATOR_LOGGERS": [ "awx", "activity_stream", "job_events", "system_tracking" ], "LOG_AGGREGATOR_INDIVIDUAL_FACTS": false, "LOG_AGGREGATOR_ENABLED": true, "LOG_AGGREGATOR_CONTROLLER_UUID": "" }
Splunk HTTP Event Collector はデフォルトでポート 8088 をリッスンするため、受信要求が正常に処理されるように、LOG_AGGREGATOR_HOST
に完全な HEC イベント URL (ポート番号を含む) を指定する必要があります。
一般的な値を次の例に示します。
HTTP Event Collector の設定の詳細は、Splunk のドキュメント を参照してください。
8.1.6.2. Loggly
Loggly の HTTP エンドポイントを介したログ送信の詳細は、Loggly のドキュメント を参照してください。
Loggly は、次の例の Logging Aggregator フィールドに示す URL 規則を使用します。
8.1.6.3. Sumologic
Sumologic では、JSON ファイルに含まれる検索基準を作成します。JSON ファイルには、必要なデータを収集するのに使用するパラメーターが指定されています。
8.1.6.4. Elastic stack (以前の ELK stack)
独自のバージョンの Elastic Stack をセットアップしている場合、必要な変更は、logstash logstash.conf
ファイルに次の行を追加するだけです。
filter { json { source => "message" } }
Elastic 5.0.0 で後方互換性のない変更が導入され、使用するバージョンによっては、異なる設定が必要になる可能性があります。