監視ツール設定ガイド

Red Hat OpenStack Platform 16.1

OpenStack のロギングおよび監視ツールについてのガイド

OpenStack Documentation Team

概要

このガイドでは、Red Hat OpenStack Platform 環境でのロギングと監視の設定方法について説明します。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)

特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。

  1. Multi-page HTML 形式でドキュメントを表示します。
  2. ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
  3. コメントするテキスト部分をハイライト表示します。
  4. Add Feedback をクリックします。
  5. Add Feedback フィールドにコメントを入力します。
  6. オプション: ドキュメントチームが問題の詳細を確認する際に使用できるメールアドレスを記入してください。
  7. Submit をクリックします。

第1章 Red Hat OpenStack Platform 監視ツールの概要

監視ツールは、オペレーターが OpenStack 環境を維持管理するのに役立つオプションのツールセットです。これらのツールは、以下の機能を果たします。

  • 集中ロギング: OpenStack 環境の全コンポーネントからのログを 1 つの場所に収集します。すべてのノードとサービスにわたって問題を特定することができます。また、オプションで Red Hat にログデータをエクスポートして、問題を診断するサポートを受けることもできます。
  • 可用性監視: OpenStack 環境内の全コンポーネントを監視して、いずれかのコンポーネントが現在停止中または機能していない状態かどうかを判断します。また、問題が確認された時にシステムがアラートを送信するように設定することも可能です。

1.1. 監視コンポーネントのサポート状況

以下の表に、Red Hat OpenStack Platform (RHOSP) の監視用コンポーネントに対するサポート状況を示します。

表1.1 サポート状況

コンポーネント  以降でフルサポート非推奨化以降で削除注記

Aodh

RHOSP 9

RHOSP 15

 

自動スケーリングのユースケースでサポートされています。

Ceilometer

RHOSP 4

  

自動スケーリングおよびサービステレメトリーフレームワーク (STF) のユースケースで RHOSP のメトリクスとイベントの収集がサポートされています。

Collectd

RHOSP 11

RHOSP 17.1

 

STF のインフラストラクチャーメトリクスの収集がサポートされています。

Gnocchi

RHOSP 9

RHOSP 15

 

自動スケーリングのユースケースのメトリックのストレージがサポートされています。

Panko

RHOSP 11

RHOSP 12、RHOSP 14 以降、デフォルトではインストールされていません

RHOSP 17.0

 

QDR

RHOSP 13

RHOSP 17.1

 

RHOSP から STF へのメトリクスおよびイベントデータの送信がサポートされています。

第2章 監視アーキテクチャー

監視ツールは、Red Hat OpenStack Platform オーバークラウドノードにクラウドがデプロイされているクライアント/サーバーモデルを使用します。Rsyslog サービスは、クライアント側の集中ロギング (CL) を提供し、有効な collectd-sensubility プラグインは、クライアント側の可用性監視 (AM) を提供します。

2.1. 集中ロギング

Red Hat OpenStack 環境では、一元的な場所に全サービスからログを収集すると、デバッグと管理が容易になります。これらのログは、syslog や audit ログファイルなどのオペレーティングシステム、RabbitMQ や MariaDB などのインフラストラクチャーコンポーネント、Identity や Compute などの OpenStack サービスから収集されます。

集中ロギングのツールチェーンは、以下のコンポーネントで設定されます。

  • ログ収集エージェント (Rsyslog)
  • データストア (Elasticsearch)
  • API/プレゼンテーション層 (Kibana)
注記

Red Hat OpenStack Platform director は、集中ロギング向けのサーバー側のコンポーネントはデプロイしません。Red Hat は、Elasticsearch データベースおよび Kibana を含むサーバー側のコンポーネントはサポートしません。

2.2. 可用性監視

可用性監視により、OpenStack 環境全体にわたる全コンポーネントのハイレベルな機能性を一元的に監視できます。

可用性監視のツールチェーンは、複数のコンポーネントで設定されます。

  • 監視エージェント (sensubility プラグインが有効な collectd)
  • 監視リレー/プロキシー (RabbitMQ)
  • 監視コントローラー/サーバー (Sensu サーバー)
  • API/プレゼンテーション層 (Uchiwa)
注記

Red Hat OpenStack Platform director は、サーバー側の可用性監視のコンポーネントはデプロイしません。Red Hat では、Uchiwa、Sensu Server、Sensu API plus、RabbitMQ、監視ノードで実行する Redis インスタンスなどのサーバー側のコンポーネントはサポートしていません。

以下の図は、可用性監視のコンポーネントとそれらの対話を示しています。

注記

青で示した項目は Red Hat のサポート対象コンポーネントです。

図2.1 ハイレベルでの可用性監視のアーキテクチャー

ハイレベルでの可用性監視のアーキテクチャー

図2.2 Red Hat OpenStack Platform の単一ノードデプロイメント

Red Hat OpenStack Platform の単一ノードデプロイメント

図2.3 Red Hat OpenStack Platform の HA デプロイメント

Red Hat OpenStack Platform の高可用性デプロイメント

第3章 クライアント側のツールのインストール

オーバークラウドをデプロイする前に、各クライアントに適用する設定を決定する必要があります。Heat テンプレートコレクションからサンプルの環境ファイルをコピーし、使用している環境に応じてファイルを変更します。

3.1. 集中ロギングのクライアントパラメーターの設定

詳細は、ロギング、監視、トラブルシューティング ガイドの Elasticsearch を使用した集中ロギングの有効化 を参照してください。

3.2. 監視クライアントパラメーターの設定

監視ソリューションは、定期的にシステム情報を収集し、データ収集エージェントを使用してさまざまな方法で値を保管し、監視するメカニズムを提供します。Red Hat は、collectd をコレクションエージェントとしてサポートします。collectd-sensubility は collectd の機能拡張であり、RabbitMQ を介して Sensu サーバー側と通信します。Service Telemetry Framework (STF) を使用してデータを保存し、続いてシステムの監視、パフォーマンスのボトルネックの特定、将来のシステム負荷の予測を行うことができます。Service Telemetry Framework についての詳細は、Service Telemetry Framework 1.3 を参照してください。

collectd および collectd-sensubility を設定するには、以下の手順を実行します。

  1. ホームディレクトリーに /home/templates/custom などの config.yaml を作成し、MetricsQdrConnectors パラメーター が STF サーバー側をポイントするように設定します。

    MetricsQdrConnectors:
        - host: qdr-normal-sa-telemetry.apps.remote.tld
          port: 443
          role: inter-router
          sslProfile: sslProfile
          verifyHostname: false
    MetricsQdrSSLProfiles:
        - name: sslProfile
  2. config.yaml ファイルで、CollectdExtraPlugins の下に使用するプラグインをリスト表示します。ExtraConfig セクションにパラメーターを指定することもできます。デフォルトでは、collectd のプラグインには cpudfdiskhugepagesinterfaceloadmemoryprocessestcpconnsunixsock、および uptime があります。追加のプラグインは、CollectdExtraPlugins パラメーターを使用して追加できます。また、ExtraConfig オプションを使用して、CollectdExtraPlugins の設定情報を追加することもできます。たとえば、virt プラグインを有効にし、接続文字列とホスト名の形式を設定するには、以下の構文を使用します。

    parameter_defaults:
      CollectdExtraPlugins:
        - disk
        - df
        - virt
    
      ExtraConfig:
        collectd::plugin::virt::connection: "qemu:///system"
        collectd::plugin::virt::hostname_format: "hostname uuid"
    注記

    unixsock プラグインは削除しないでください。削除すると、collectd コンテナーは正常ではないと永続的に指定されます。

  3. オプション: AMQ Interconnect でメトリックおよびイベントデータを収集するには、MetricsQdrExternalEndpoint: true 行を config.yaml ファイルに追加します。

    parameter_defaults:
        MetricsQdrExternalEndpoint: true
  4. collectd-sensubility を有効にするには、以下の環境設定を config.yaml ファイルに追加します。

    parameter_defaults:
      CollectdEnableSensubility: true
    
      # Use this if there is restricted access for your checks by using the sudo command.
      # The rule will be created in /etc/sudoers.d for sensubility to enable it calling restricted commands via sensubility executor.
      CollectdSensubilityExecSudoRule: "collectd ALL = NOPASSWD: <some command or ALL for all commands>"
    
      # Connection URL to Sensu server side for reporting check results.
      CollectdSensubilityConnection: "amqp://sensu:sensu@<sensu server side IP>:5672//sensu"
    
      # Interval in seconds for sending keepalive messages to Sensu server side.
      CollectdSensubilityKeepaliveInterval: 20
    
      # Path to temporary directory where the check scripts are created.
      CollectdSensubilityTmpDir: /var/tmp/collectd-sensubility-checks
    
      # Path to shell used for executing check scripts.
      CollectdSensubilityShellPath: /usr/bin/sh
    
      # To improve check execution rate use this parameter and value to change the number of goroutines spawned for executing check  scripts.
      CollectdSensubilityWorkerCount: 2
    
      # JSON-formatted definition of standalone checks to be scheduled on client side. If you need to schedule checks
      # on overcloud nodes instead of Sensu server, use this parameter. Configuration is compatible with Sensu check definition.
      # For more information, see https://docs.sensu.io/sensu-core/1.7/reference/checks/#check-definition-specification
      # There are some configuration options which sensubility ignores such as: extension, publish, cron, stdin, hooks.
      CollectdSensubilityChecks:
        example:
          command: "ping -c1 -W1 8.8.8.8"
          interval: 30
    
      # The following parameters are used to modify standard, standalone checks for monitoring container health on overcloud nodes.
      # Do not modify these parameters.
      # CollectdEnableContainerHealthCheck: true
      # CollectdContainerHealthCheckCommand: <snip>
      # CollectdContainerHealthCheckInterval: 10
      # The Sensu server side event handler to use for events created by the container health check.
      # CollectdContainerHealthCheckHandlers:
      #   - handle-container-health-check
      # CollectdContainerHealthCheckOccurrences: 3
      # CollectdContainerHealthCheckRefresh: 90
  5. オーバークラウドをデプロイする。overcloud deploy コマンドに、config.yamlcollectd-write-qdr.yaml のほか、qdr-*.yaml ファイルのいずれかを含めます。

    $ openstack overcloud deploy
    -e  /home/templates/custom/config.yaml
    -e tripleo-heat-templates/environments/metrics/collectd-write-qdr.yaml
    -e tripleo-heat-templates/environments/metrics/qdr-form-controller-mesh.yaml
  6. オプション: オーバークラウドの RabbitMQ 監視を有効にするには、overcloud deploy コマンドに collectd-read-rabbitmq.yaml ファイルを追加します。

関連情報

3.3. AMQ Interconnect を使用したデータの収集

メトリックおよびイベントデータ消費のために利用可能な AMQ Interconnect アドレスにサブスクライブするには、クライアント接続用に AMQ Interconnect を公開する環境ファイルを作成し、オーバークラウドをデプロイします。

注記

Service Telemetry Operator は、単一クラウドデプロイメント用の全データ取得およびデータストレージコンポーネントのデプロイメントを単純化します。データストレージドメインを複数のクラウドと共有するには、Service Telemetry Framework 1.3Configuring multiple clouds を参照してください。

警告

なお、Service Telemetry Framework (STF) で採用されている QDR メッシュモードと QDR エッジモードの切り替えはできません。また、STF のデータ収集を有効にした場合は、QDR のメッシュモードを使用することはできません。

手順

  1. Red Hat OpenStack Platform アンダークラウドに stack ユーザーとしてログオンします。
  2. /home/stack ディレクトリーに data-collection.yaml という名前の設定ファイルを作成します。
  3. 外部エンドポイントを有効にするには、MetricsQdrExternalEndpoint: true パラメーターを data-collection.yaml ファイルに追加します。

    parameter_defaults:
        MetricsQdrExternalEndpoint: true
  4. collectd および AMQ Interconnect を有効にするには、以下のファイルを Red Hat OpenStack Platform director デプロイメントに追加します。

    • data-collection.yaml 環境ファイル
    • クライアント側の AMQ Interconnect が外部エンドポイントに接続できるようにする qdr-form-controller-mesh.yaml ファイル

      openstack overcloud deploy <other arguments>
        --templates /usr/share/openstack-tripleo-heat-templates \
        --environment-file <...other-environment-files...> \
        --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-form-controller-mesh.yaml \
        --environment-file /home/stack/data-collection.yaml
  5. オプション: Ceilometer および collectd イベントを収集するには、overcloud deploy コマンドに ceilometer-write-qdr.yaml および collectd-write-qdr.yaml ファイルを含めます。
  6. オーバークラウドをデプロイする。

関連情報

3.4. collectd プラグインの設定

Red Hat OpenStack Platform director には、多くの設定の可能性があります。お使いの環境に応じて複数の collectd プラグインを設定できます。文書化された各プラグインには、説明と設定例があります。一部のプラグインには、Grafana または Prometheus からクエリーできるメトリックのテーブルと、設定可能なオプションのリスト (利用可能な場合) があります。

関連情報

  • collectd プラグインオプションの完全な一覧を表示するには、Service Telemetry Frameworkcollectd plugins を参照してください。

3.5. YAML ファイル

collectd を設定する際に、overcloud deploy コマンドに以下の YAML ファイルを追加することができます。

  • collectd-read-rabbitmq.yaml: python-collect-rabbitmq を有効にし、オーバークラウドの RabbitMQ インスタンスを監視するように設定します。
  • collectd-write-qdr.yaml: collectd が AMQ Interconnect を使用して Telemetry および通知データを送信できるようにします。
  • qdr-edge-only.yaml: AMQ Interconnect のデプロイメントを有効にします。各オーバークラウドノードでは、エッジモードで 1 つのローカルの qdrouterd サービスが実行および操作されます。たとえば、受信したデータを直接定義された MetricsQdrConnectors に送信し ます。
  • qdr-form-controller-mesh.yaml: AMQ Interconnect のデプロイメントを有効にします。各オーバークラウドノードでは、1 つのローカルの qdrouterd サービスが実行され、メッシュトポロジーを形成します。たとえば、コントローラー上の AMQ Interconnect ルーターは、定義された MetricsQdrConnectors に接続して内部ルーターモードで動作し、他のノードタイプ上の AMQ Interconnect ルーターは、エッジモードでコントローラー上で実行される内部ルーターに接続されます。

関連情報

collectd の設定に関する詳細は、「監視クライアントパラメーターの設定」 を参照してください。

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.