第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% に達すると、キューはディスクへの書き込みを開始します (rsyslogqueue.highWatermark)。90% に達すると、NOTICEINFODEBUG メッセージが破棄され始めます (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 がオフラインになった場合、rsyslogdSplunk がオンラインに戻るまでディスクにキューを保存します。デフォルトでは、(Splunk がオフラインの間) 最大 1 GB のイベントが保存されますが、必要に応じて 1 GB 超に増やすことも、キューを保存するパスを変更することもできます。

8.1. ロガー

以下は、予測可能な構造化形式または半構造化形式で大量の情報を提供する特別なロガー (汎用的なサーバーログを構成する awx は除く) です。これらは、API からデータを取得するときと同じ構造を使用します。

  • job_events: Ansible コールバックモジュールから返されるデータを渡します。
  • activity_stream: アプリケーション内のオブジェクトに対する変更の記録を表示します。
  • system_tracking: Ansible setup モジュールによって収集されたファクトデータを提供します。つまり、Enable Fact Cache を選択した状態でジョブテンプレートを実行する場合は、gather_facts: true になります。
  • awx: 通常はファイルに書き込まれるログを含む、汎用的なサーバーログを提供します。これには、すべてのログが有する標準メタデータが含まれます。ただし、含まれるのはログステートメントからのメッセージのみです。

これらのロガーは、INFO のログレベルのみを使用します。例外は awx ロガーで、これはどのレベルでも使用できます。

さらに、標準の Automation Controller ログも、同じメカニズムで配信できます。ローカルの設定ファイルで複雑なディクショナリーを操作せずに、これら 5 つのデータソースをそれぞれ有効または無効にする方法や、標準の Automation Controller ログから使用するログレベルを調整する方法は明らかです。

ナビゲーションパネルから Settings Logging を選択して、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 フィールドが含まれます。ナビゲーションパネルから Settings Logging を選択します。Logging Settings ページで Edit をクリックし、ENABLE EXTERNAL LOGGING オプションを使用して、ロギングコンポーネントを有効または無効にします。

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 (ポート番号を含む) を指定する必要があります。

一般的な値を次の例に示します。

Splunk logging example

HTTP Event Collector の設定の詳細は、Splunk のドキュメント を参照してください。

8.1.6.2. Loggly

Loggly の HTTP エンドポイントを介したログ送信の詳細は、Loggly のドキュメント を参照してください。

Loggly は、次の例の Logging Aggregator フィールドに示す URL 規則を使用します。

Loggly example

8.1.6.3. Sumologic

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

Sumologic logging

8.1.6.4. Elastic stack (以前の ELK stack)

独自のバージョンの Elastic Stack をセットアップしている場合、必要な変更は、logstash logstash.conf ファイルに次の行を追加するだけです。

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

Elastic 5.0.0 で後方互換性のない変更が導入され、使用するバージョンによっては、異なる設定が必要になる可能性があります。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.