11. ロギングおよびアグリゲーション¶

11.1.1. ログメッセージスキーマ¶

全ロガーに対する共通のスキーマ

• cluster_host_id: コントローラークラスターにあるホストの一意識別子

• level: 標準の Python ログレベル。イベントの重大度をほぼ反映します。この機能に含まれるデータロガーはすべて INFO レベルを使用しますが、コントローラーログは随時、異なるレベルを使用します。

• logger_name: "activity_stream" など、設定で使用するロガー名

• @timestamp: ログの時間

• path: ログが生成されたコードのファイルパス

11.1.2. アクティビティーストリームスキーマ¶

• (common): これは、上記の全ロガーに共通するフィールドすべてを使用します。

• actor: ログに記述されたアクションを行ったユーザーのユーザー名

• changes: 変更されたフィールド、以前/新規の概要 (JSON)

• operation: "associate" など、アクティビティーストリームにログ記録された変更の基本カテゴリー

• object1: 操作を行うプライマリーオブジェクトに関する情報。アクティビティーストリームに表示する内容と一貫性があります。

• object2: 該当する場合には、アクションに関連する 2 つ目のオブジェクト

11.1.3. ジョブイベントのスキーマ¶

このロガーは、想定されるロガーからの標準フィールドと矛盾してしまう場合 (このような場合はこれらのフィールドはネス化されます) を除き、ジョブイベントに保存されるデータを反映します。特に、job_event モデルのフィールドホストは、event_host とされます。プレイロード内には event_data というサブディクショナリーフィールドもあり、これには、Ansible イベントの内容によっては含まれるフィールドが異なります。

このロガーには、以下の共通のフィールドが含まれます。

11.1.4. スキャン/ファクト/システム追跡データスキーマ¶

これらには、サービス、パッケージまたはファイルの詳細ディクショナリータイプフィールドが含まれます。

• (common): これは、上記の全ロガーに共通するフィールドすべてを使用します。

• services: サービススキャンの場合は、このフィールドが含まれ、このフィールドにはサービス名をもとにしたキーがあります。注記: 名前の Elastic Search ではピリオドは使用できず、ログフォーマッターにより "_" に置き換えられます

• package: パッケージスキャンからのログメッセージに含まれます

• files: ファイルスキャンからのログメッセージに含まれます

• host: 適用されるホストスキャン名

• inventory_id: 含まれるインベントリー id ホスト

11.1.5. ジョブステータスの変更¶

これは、ジョブイベントに比べ、ジョブの状態の変更に関する情報源は少量とし、ジョブテンプレートをベースとするジョブ以外で、統合されたジョブタイプに対する変更を取得することが目的です。

共通のフィールドに加え、これらのログには、ジョブモデルに表示されるフィールドも含まれます。

11.1.6. コントローラーのログ¶

一般的なフィールドのほかに、これにはログメッセージを含む msg フィールドが含まれます。エラーには別の traceback フィールドが含まれます。これらのログは、ロギング設定ページから ENABLE EXTERNAL LOGGING オプションで有効または無効にできます。

11.1.7. ログアグリゲーターサービス¶

ログアグリゲーターサービスは、以下の監視またはデータ分析システムと連携します。

11.1.7.1. Splunk¶

Automation controller の Splunk ロギング統合では、Splunk HTTP Collector を使用します。SPLUNK ログアグリゲーターを設定する場合は、以下のように、HTTP Event Collector ホストに完全 URL を追加します。

https://yourcontrollerfqdn.com/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 をリッスンし、受信要求を適切に処理するために完全 HEC イベント URL (ポートを使用) を提供する必要があります。この値は、以下の例に入力されます。

HTTP Event Collector の設定方法は Splunk documentation を参照してください。

11.1.7.2. Loggly¶

Loggly の HTTP エンドポイント経由でのログの送信を設定するには、https://www.loggly.com/docs/http-endpoint/ を参照してください。Loggly は、http://logs-01.loggly.com/inputs/TOKEN/tag/http/ に記載の URL 規則を使用します。これは、以下の例の ログアグリゲーター フィールドに入力して紹介しています。

11.1.7.3. Sumologic¶

Sumologic では、json ファイルに含まれる検索基準を作成します。json ファイルには、必要なデータを収集するのに使用するパラメーターが指定されています。

filter {
  json {
    source => "message"
  }
}

11.2.1. ログアグリゲーション¶

いずれかのアグリゲータータイプにロギングを設定する方法:

1. 左側のナビゲーションバーで 設定 をクリックします。

2. システムオプションの一覧で、ロギング設定 を選択します。

3. ロギング設定画面下部で、編集 をクリックします。

4. 表示されたフィールドで設定可能なオプションを設定します。

• 外部ログの有効化: 外部のログアグリゲーターにログを送信するには、切り替えボタンをクリックして ON にします。

• ログアグリゲーター: ログを送信するホスト名または IP アドレスを入力します。

• ログアグリゲーターポート: 必要な場合には、アグリゲーターポートを指定します。

注釈

接続タイプが HTTPS の場合は、URL にポート番号が付いたホスト名を入力します。そのため、再度ポートを入力する必要はありません。ただし、TCP や UDP 接続は、URL ではなく、ホスト名とポート番号の組み合わせで判断されるため、TCP/UDP 接続の場合は、指定のフィールドにポートを入力してください。URL がホストフィールド (ログアグリゲーター フィールド) に入力された場合には、実際のホスト名としてホスト名の部分が抽出されます。

• ログアグリゲータータイプ: クリックして、ドロップダウンメニューからアグリゲーターサービスを選択します。

• ログアグリゲーターユーザー名: 必要な場合には、ログアグリゲーターのユーザー名を入力します。

• ログアグリゲーターパスワード/トークン: 必要な場合にはログアグリゲーターのパスワードを入力します。

• ログシステムによるファクトの個別トラッキング: オンに切り替えるか、デフォルトのままオフにしておくかなど、追加情報を確認するにはヒント アイコンをクリックします。

• ログアグリゲーターのプロトコル: ログアグリゲーターと通信する接続タイプ (プロトコル) を選択するにはこれをクリックします。今後表示されるオプションは、選択したオプションにより異なります。

• ログアグリゲーターレベルのしきい値: ログハンドラーがレポートする重大度レベルを選択します。

• TCP 接続のタイムアウト: 接続のタイムアウトを秒単位で指定します。このオプションは、HTTP と TCP ログアグリゲータープロトコルにのみ適用されます。

• HTTPS 証明書の検証を有効化/無効化: デフォルトでは、HTTPS ログプロトコルに対する証明書の検証は有効です。接続の確立前に、外部ログアグリゲーターが送信した HTTPS 証明書をログハンドラーに検証させないようにするには、ボタンを OFF に切り替えます。

• ログアグリゲーターフォームにデータを送信するロガー: デフォルトでは、データ 4 種類すべてが事前投入されています。各データタイプに関する追加情報は、フィールドの横にあるヒント アイコンをクリックします。必要がなくなればデータタイプを削除してください。

• API 4XX エラーのログ形式: 特定のエラーメッセージを設定します。詳細は、API 4XX エラー設定 を参照してください。

5. 選択したログアグリゲーションの内容を確認します。以下は、Splunk 用に設定した一例です。

7. 完了したら、保存 をクリックして設定を適用するか、キャンセル をクリックして変更を破棄します。

8. 設定が正しく設定されていることを確認するには、まず Save をクリックしてから Test をクリックします。これにより、automation controller における現在のロギング設定を使用してテストログメッセージがログアグリゲーターに送信されます。このテストメッセージを外部ログアグリゲーターが確実に受け取っていることを確認してください。

注釈

Test ボタンが無効になっている場合は、フィールドが初期値とは異なることを示しています。したがって、最初に変更を保存して Enable External Logging トグルボタンを ON に設定してください。

11.2.2. API 4XX エラー設定¶

API でリクエストの問題が発生すると、通常、エラーとともに 400 の範囲の HTTP エラーコードが返されます。これが発生すると、以下のパターンに従うエラーメッセージがログに生成されます。

` status {status_code} received by user {user_name} attempting to access {url_path} from {remote_addr} `

これらのメッセージは、必要に応じて設定できます。デフォルトの API 4XX エラーログメッセージ形式を変更するには、以下を実行します。

1. 左側のナビゲーションバーで 設定 をクリックします。

2. システムオプションの一覧で、ロギング設定 を選択します。

3. ロギング設定画面下部で、編集 をクリックします。

4. API 4XX エラーのログ形式 フィールドを変更します。

{} で囲まれた項目が、ログエラー発生時に置き換えられます。以下の変数が使用可能です。

• status_code: API が返す HTTP ステータスコード

• user_name: API リクエストを行うときに認証されたユーザーの名前

• url_path: 呼び出される URL のパス部分 (別名 API エンドポイント)

• remote_addr: コントローラーが受信したリモートアドレス

• error: API によって返されるエラーメッセージ。エラーが指定されていない場合は、HTTP ステータスをテキストで返します。

11.3.1. ロギングアグリゲーション¶

テストボタンのあるメッセージを http/https で設定したロギングサービスに送信し、メッセージを受信しなかった場合は、/var/log/tower/rsyslog.err ログファイルを確認してください。これは、rsyslog を http/https の外部ロギングサービスで認証する際に発生した場合にエラーが保存されます。エラーがない場合には、このファイルが存在しないことに注意してください。

11.3.2. API 4XX エラー¶

これらのメッセージのログ形式を変更することにより、4XX エラーの API エラーメッセージを含めることができます。詳細は、API 4XX エラー設定 を参照してください。

11.3.3. LDAP¶

LDAP アダプターのロギングメッセージを有効にすることができます。詳細は、LDAP のロギングの有効化 を参照してください。

11.3.4. SAML¶

LDAP のロギングを有効にするのと同じ方法で、SAML アダプターのロギングメッセージを有効にすることができます。詳細は、LDAP のロギングの有効化 を参照してください。