Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第12章 モニタリングツールの設定

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

  • 集中ロギング: OpenStack 環境の全コンポーネントからのログを 1 つの場所に収集することができます。すべてのノードとサービスにわたって問題を特定することができます。また、オプションでログデータをエクスポートして、問題を診断するサポートを受けることもできます。
  • 可用性監視: OpenStack 環境内の全コンポーネントをモニタリングして、いずれかのコンポーネントが現在停止中または機能していない状態かどうかを判断します。応答時間を最適化するために、問題の発生時に通知を受信することもできます。

12.1. アーキテクチャー

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

12.1.1. 集中ロギング

集中ロギングにより、OpenStack 環境全体にわたるログを一箇所で確認することができます。これらのログは、syslog や audit ログファイルなどのオペレーティングシステム、RabbitMQ や MariaDB などのインフラストラクチャーコンポーネント、Identity や Compute などの OpenStack サービスから収集されます。

集中ロギングのツールチェーンは、以下のような複数のコンポーネントで構成されます。

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

director は、集中ロギング向けのサーバー側のコンポーネントはデプロイしません。Red Hat では、ログアグリゲーターとして実行するプラグインを使用する Elasticsearch データベース、Kibana、Fluentd などのサーバー側のコンポーネントはサポートしていません。

以下の図は、集中ロギングのコンポーネントとそれらの対話を示しています。

注記

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

図12.1 集中ロギングのハイレベルアーキテクチャー

centralised logging arch

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

centralised logging single node fluentd

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

centralised logging ha fluentd

12.1.2. 可用性監視

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

可用性監視のツールチェーンは、以下を含む複数のコンポーネントで構成されます。

  • 監視エージェント (Sensu クライアント)
  • 監視リレー/プロキシー (RabbitMQ)
  • 監視コントローラー/サーバー (Sensu サーバー)
  • API/プレゼンテーション層 (Uchiwa)
注記

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

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

注記

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

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

availability monitoring arch

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

availability monitoring single node sensu

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

availability monitoring ha sensu

12.2. クライアント側のツールのインストール

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

12.2.1. 集中ロギングのパラメーターの設定

Fluentd の構成設定には、/usr/share/openstack-tripleo-heat-templates/environments/logging-environment.yaml をコピーし、ご使用の環境に応じて変更します。 以下に例を示します。

簡易設定

resource_registry:
  OS::TripleO::Services::FluentdClient: ../puppet/services/logging/fluentd-client.yaml

parameter_defaults:
  LoggingServers:
    - host: log0.example.com
      port: 24224
    - host: log1.example.com
      port: 24224

SSL の設定例

## (note the use of port 24284 for ssl connections)

resource_registry:
  OS::TripleO::Services::FluentdClient: ../puppet/services/logging/fluentd-client.yaml

parameter_defaults:
  LoggingServers:
    - host: 192.0.2.11
      port: 24284
  LoggingUsesSSL: true
  LoggingSharedKey: secret
  LoggingSSLCertificate: |
    -----BEGIN CERTIFICATE-----
    ...certificate data here...
    -----END CERTIFICATE-----

  • LoggingServers: Fluentd ログメッセージの受信先のシステム
  • LoggingUsesSSL: ログメッセージの送信時にsecure_forward を使用するかどうかを決定する設定
  • LoggingSharedKey: secure_forward が使用する共有シークレット
  • LoggingSSLCertificate: PEM エンコードされた SSL CA 証明書の内容

12.2.2. 可用性監視クライアントのパラメーターの設定

Sensu クライアントの構成設定には、/usr/share/openstack-tripleo-heat-templates/environments/monitoring-environment.yaml をコピーし、ご使用の環境に応じて変更します。以下に例を示します。

resource_registry:
  OS::TripleO::Services::SensuClient: ../puppet/services/monitoring/sensu-client.yaml

parameter_defaults:
  MonitoringRabbitHost: 10.10.10.10
  MonitoringRabbitPort: 5672
  MonitoringRabbitUserName: sensu
  MonitoringRabbitPassword: sensu
  MonitoringRabbitUseSSL: false
  MonitoringRabbitVhost: "/sensu"
  SensuClientCustomConfig:
    api:
      warning: 10
      critical: 20
  • MonitoringRabbit*: これらのパラメーターは、監視サーバーで実行する RabbitMQ インスタンスに Sensu クライアントサービスを接続します。
  • MonitoringRabbitUseSSL: このパラメーターは、現在可用性監視には利用できません。
  • SensuClientCustomConfig: Sensu クライアントの追加の設定を指定します。ユーザー名/パスワード、auth_url、テナント、リージョンを含む OpenStack の認証情報を定義します。

12.2.3. オーバークラウドノードへの運用ツールのインストール

openstack overcloud deploy コマンドで変更した YAML ファイルを指定して、Sensu クライアントと Fluentd ツールを全オーバークラウドノードにインストールします。以下に例を示します。

$ openstack overcloud deploy --templates  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e network-environment.yaml -e ~/templates/monitoring-environment.yaml -e ~/templates/logging-environment.yaml --control-scale 3 --compute-scale 1 --ntp-server 192.168.122.10

12.3. サーバー側のコンポーネントのインストール

注記

Red Hat では、サーバー側のコンポーネントおよびそれらのデプロイメントプロセスはサポートしていません。

opstools-ansible プレイブックを使用してサーバー側のコンポーネントを Red Hat Enterprise Linux 7 にインストールすることができます。これらのサーバー側のコンポーネントには、Red Hat がサポートするクライアント側のコンポーネントを補完する可用性監視や集中ロギングのサービスが含まれます。最も多く検証される opstools-ansible のシナリオは、サーバー側のコンポーネントを CentOS 7 にデプロイするシナリオです。詳しい手順については、https://github.com/centos-opstools/opstools-ansibleREADME.md を参照してください。

12.4. OpenStack Platform の監視

Sensu のスタックインフラストラクチャーについては、https://sensuapp.org/docs/latest/overview/architecture.html の Sensu のドキュメントを参照してください。

Red Hat は、osops-tools-monitoring-oschecks パッケージで、check スクリプトのセットを提供しています。check スクリプトの大半は、OpenStack コンポーネントの API 接続のみをチェックしますが、特定のスクリプトは、OpenStack Compute (nova)、OpenStack Block Storage (cinder)、OpenStack Image (glance)、OpenStack Networking (neutron) を対象とする追加の OpenStack リソースのテストも実行します。たとえば、OpenStack Identity (keystone) API check は、keystone の実行時には以下のような結果を提示します。

OK: Got a token, Keystone API is working.

12.5. Sensu クライアントインストールの検証

  1. オーバークラウドノードで sensu-client のステータスを確認します。

    # systemctl status sensu-client
  2. エラーログ (/var/log/sensu/sensu-client.log) で問題があるかどうかを確認します。
  3. 各オーバークラウドノードに、監視サーバーの IP アドレスを設定する /etc/sensu/conf.d/rabbitmq.json ファイルがあることを確認します。

12.6. ノードの状態の確認

Uchiwa ダッシュボードがデプロイされている場合には、そのダッシュボードを Sensu サーバーと共に使用して、ノードの状態を確認することができます。

  1. Uchiwa ダッシュボードにログインして、Data Center タブをクリックし、データセンターが稼働中であることを確認します。

    http://<SERVER_IP_ADDRESS>:3000
  2. 全オーバークラウドノードが Connected の状態であることを確認します。
  3. オーバークラウドノードの 1 台を適時に再起動し、そのノードの状態を Uchiwa ダッシュボードで確認します。再起動の完了後には、ノードが Sense サーバーに正常に再接続されて check の実行を開始するかどうかを確認します。

12.7. OpenStack サービスの状態の確認

以下の例では、openstack-ceilometer-central サービスの監視をテストします。

  1. openstack-ceilometer-central サービスが実行中であることを確認します。

    systemctl status openstack-ceilometer-central.service
  2. Uchiwa ダッシュボードに接続して、正常な ceilometer check があり、ceilometer JSON ファイルで定義されているとおりに実行されていることを確認します。
  3. openstack-ceilometer-central サービスを停止します。

    注記

    これにより、サービスが中断される場合があるので、このテストは適切な時間に実行してください。

    systemctl stop openstack-ceilometer-central.service
  4. Uchiwa ダッシュボードにログインして、ceilometer check が失敗したことが報告されていることを確認します。
  5. openstack-ceilometer-central サービスを起動します。

    systemctl start openstack-ceilometer-central.service
  6. Uchiwa ダッシュボードにログインして ceilometer check レポートの間隔を確認し、ceilometer JSON ファイルで定義されている間隔で check が実行されていることを確認します。