Menu Close
ロギング、モニタリング、およびトラブルシューティングガイド
OpenStack のロギング、モニタリング、およびトラブルシューティングの詳細ガイド
概要
前書き
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ)
弊社ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。
ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)
特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。
- Multi-page HTML 形式でドキュメントを表示します。
- ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
- コメントするテキスト部分をハイライト表示します。
- Add Feedback をクリックします。
- Add Feedback フィールドにコメントを入力します。
- (オプション) ドキュメントチームが連絡を取り問題についてお伺いできるように、ご自分のメールアドレスを追加します。
- 送信 をクリックします。
第1章 本ガイドについて
現在 Red Hat では、本リリース用の本ガイドに記載されている情報および手順の見直しを行っています。
本書は、製品ドキュメント から利用可能な Red Hat OpenStack Platform 12 のドキュメントをベースにしています。
現在の Red Hat OpenStack Platform リリース用にサポートが必要な場合は、Red Hat サポートにお問い合わせください。
第2章 ログサービスのインストールおよび設定
Red Hat OpenStack Platform (RHOSP) は、情報メッセージを特定のログファイルに書き込みます。これらのメッセージを、トラブルシューティングおよびシステムイベントのモニタリングに使用することができます。ログ収集エージェント Rsyslog はクライアント側のログを収集し、それらのログをサーバー側で実行されている Rsyslog インスタンスに送信します。サーバー側の Rsyslog インスタンスは、保管のためにログの記録を Elasticsearch にリダイレクトします。
個々のログファイルをサポートケースに手動で添付する必要はありません。sosreport
ユーティリティーは、必要なログを自動的に収集します。
2.1. 集中ログシステムのアーキテクチャーおよびコンポーネント
モニタリングツールは、クライアントが Red Hat OpenStack Platform (RHOSP) オーバークラウドノードにデプロイされる、クライアント/サーバーモデルを使用します。Rsyslog サービスは、クライアント側の集中ロギング (CL) を提供します。
すべての RHOSP サービスはログファイルを生成および更新します。これらのログファイルは、アクション、エラー、アラート、およびその他のイベントを記録します。OpenStack のような分散環境では、これらのログを一元的な場所に収集することで、デバッグおよび管理が簡素化されます。
集中ロギングの場合、RHOSP 環境全体にわたるログを 1 カ所で確認することができます。これらのログは、syslog や監査ログファイル等のオペレーティングシステム、RabbitMQ や MariaDB 等のインフラストラクチャーコンポーネント、および Identity や Compute 等の OpenStack サービスから収集されます。集中ロギングのツールチェーンは、以下のコンポーネントで構成されます。
- ログ収集エージェント (Rsyslog)
- データストア (ElasticSearch)
- API/プレゼンテーション層 (Grafana)
Red Hat OpenStack Platform director は、集中ロギング向けのサーバー側のコンポーネントをデプロイしません。Red Hat は、Elasticsearch データベースおよび Grafana を含むサーバー側のコンポーネントはサポートしません。
2.2. Elasticsearch を使用した集中ロギングの有効化
集中ロギングを有効にするには、OS::TripleO::Services::Rsyslog
コンポーザブルサービスの実装を指定する必要があります。
Rsyslog サービスは、集中ロギングのデータストアとして Elasticsearch だけを使用します。
前提条件
- Elasticsearch がサーバー側にインストールされている。
手順
以下の例に示すように、ご自分の環境およびデプロイに該当するその他の環境ファイルと共に、ロギング環境ファイルのファイルパスを
overcloud deployment
コマンドに追加します。openstack overcloud deploy \ <existing_overcloud_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/logging-environment-rsyslog.yaml
<existing_overcloud_environment_files>
を既存のデプロイメントに含まれる環境ファイルの一覧に置き換えます。
2.3. ロギング機能の設定
ロギング機能を設定するには、logging-environment-rsyslog.yaml
ファイルの RsyslogElasticsearchSetting
パラメーターを変更します。
手順
-
tripleo-heat-templates/environments/logging-environment-rsyslog.yaml
ファイルをホームディレクトリーにコピーします。 実際の環境に合わせて
RsyslogElasticsearchSetting
パラメーターのエントリーを作成します。RsyslogElasticsearchSetting
パラメーターの設定例を以下のスニペットに示します。parameter_defaults: RsyslogElasticsearchSetting: uid: "elastic" pwd: "yourownpassword" skipverifyhost: "on" allowunsignedcerts: "on" server: "https://log-store-service-telemetry.apps.stfcloudops1.lab.upshift.rdu2.redhat.com" serverport: 443
関連資料
- 設定可能なパラメーターについての詳細は、「設定可能なロギングパラメーター」を参照してください。
2.3.1. 設定可能なロギングパラメーター
以下の表で、Red Hat OpenStack Platform (RHOSP) のロギング機能の設定に使用するロギングパラメーターについて説明します。これらのパラメーターは tripleo-heat-templates/deployment/logging/rsyslog-container-puppet.yaml
ファイルにあります。
表2.1 設定可能なロギングパラメーター
パラメーター | 説明 |
---|---|
|
|
| Elasticsearch サーバーの証明書を発行した CA の CA 証明書の内容が含まれます。 |
| Elasticsearch に対してクライアント証明書の認可を行うためのクライアント証明書の内容が含まれます。 |
|
証明書 |
2.4. デフォルトのログファイルパスのオーバーライド
デフォルトのコンテナーを変更し、変更箇所にサービスログファイルへのパスが含まれる場合は、デフォルトのログファイルパスも変更する必要があります。すべてのコンポーザブルサービスには <service_name>LoggingSource
パラメーターがあります。たとえば、nova-compute サービスの場合、このパラメーターは NovaComputeLoggingSource
です。
手順
nova-compute サービスのデフォルトパスをオーバーライドするには、設定ファイルの
NovaComputeLoggingSource
パラメーターにパスを追加します。NovaComputeLoggingSource: tag: openstack.nova.compute file: /some/other/path/nova-compute.log
注記サービスごとに、
tag
およびfile
を定義します。他の値にはデフォルト値が反映されます。特定のサービスの形式を変更することができます。これは Rsyslog 設定に直接渡します。
LoggingDefaultFormat
パラメーターのデフォルト形式は、/(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d+) (?<pid>\d+) (?<priority>\S+) (?<message>.*)$/ です。以下の構文を使用します。<service_name>LoggingSource: tag: <service_name>.tag path: <service_name>.path format: <service_name>.format
より複雑な変換の例を以下のスニペットに示します。
ServiceLoggingSource: tag: openstack.Service path: /var/log/containers/service/service.log format: multiline format_firstline: '/^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3} \d+ \S+ \S+ \[(req-\S+ \S+ \S+ \S+ \S+ \S+|-)\]/' format1: '/^(?<Timestamp>\S+ \S+) (?<Pid>\d+) (?<log_level>\S+) (?<python_module>\S+) (\[(req-(?<request_id>\S+) (?<user_id>\S+) (?<tenant_id>\S+) (?<domain_id>\S+) (?<user_domain>\S+) (?<project_domain>\S+)|-)\])? (?<Payload>.*)?$/'
2.5. ログレコードの形式の変更
特定のサービスについて、ログレコードの開始の形式を変更することができます。これは Rsyslog 設定に直接渡します。
Red Hat OpenStack Platform (RHOSP) のログレコードのデフォルト形式は ('^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}(.[0-9]+ [0-9]+)?(DEBUG|INFO|WARNING|ERROR) ') です。
手順
ログレコード開始の解析に異なる正規表現を追加するには、設定に
startmsg.regex
を追加します。NovaComputeLoggingSource: tag: openstack.nova.compute file: /some/other/path/nova-compute.log startmsg.regex: "^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}(.[0-9]+ \\+[0-9]+)? [A-Z]+ \\([a-z]+\\)
2.6. Rsyslog と Elasticsearch 間の接続のテスト
クライアント側で、Rsyslog と Elasticsearch 間の通信を確認することができます。
手順
-
Elasticsearch 接続ログファイル(Rsyslog コンテナーの
/var/log/rsyslog/omelasticsearch.log
)またはホスト上の/var/log/containers/rsyslog/omelasticsearch.log
に移動します。このログファイルが存在しない場合や、ログファイルは存在するがログが含まれていない場合、接続の問題はありません。ログファイルが存在しログが含まれている場合は、Rsyslog は正常に接続されていません。
サーバー側から接続をテストするには、Elasticsearch ログを表示して接続に問題を確認します。
2.7. サーバー側のロギング
Elasticsearch クラスターが動作中の場合、logging-environment-rsyslog.yaml
ファイルの RsyslogElasticsearchSetting
パラメーターを設定して、オーバークラウドノードで実行している Rsyslog を接続する必要があります。RsyslogElasticsearchSetting
パラメーターを設定するには、https://www.rsyslog.com/doc/v8-stable/configuration/modules/omelasticsearch.html を参照してください。
2.8. トレースバック
問題が発生してトラブルシューティングを開始する場合、トレースバックログを使用して問題の診断を行うことができます。ログファイル中、通常トレースバックとしてすべて同じ問題に関連する複数の情報行が表示されます。
Rsyslog は、ログレコードの開始を定義する正規表現を提供します。通常、各ログレコードはタイムスタンプで始まります。トレースバックの最初の行は、この情報だけが含まれる行です。Rsyslog は最初の行と共に該当するレコードをバンドルし、1 つのログレコードとして送信します。
この動作設定オプションには、<Service>LoggingSource の startmsg.regex
が使用されます。以下の正規表現が、director のすべての <service>LoggingSource パラメーターのデフォルト値です。
startmsg.regex='^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}(.[0-9]+ [0-9]+)? (DEBUG|INFO|WARNING|ERROR) '
このデフォルトが追加または変更した LoggingSource
のログレコードと一致しない場合は、それに応じて startmsg.regex
を変更する必要があります。
2.9. OpenStack サービスのログファイルの場所
それぞれの OpenStack コンポーネントには、実行中のサービス固有のファイルが含まれる個別のログディレクトリーがあります。
2.9.1. Bare Metal Provisioning (ironic) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
OpenStack Ironic API | openstack-ironic-api.service | /var/log/containers/ironic/ironic-api.log |
OpenStack Ironic Conductor | openstack-ironic-conductor.service | /var/log/containers/ironic/ironic-conductor.log |
2.9.2. Block Storage (cinder) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
Block Storage API | openstack-cinder-api.service | /var/log/containers/cinder-api.log |
Block Storage Backup | openstack-cinder-backup.service | /var/log/containers/cinder/backup.log |
情報メッセージ | cinder-manage コマンド | /var/log/containers/cinder/cinder-manage.log |
Block Storage Scheduler | openstack-cinder-scheduler.service | /var/log/containers/cinder/scheduler.log |
Block Storage Volume | openstack-cinder-volume.service | /var/log/containers/cinder/volume.log |
2.9.3. Compute (nova) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
OpenStack Compute API サービス | openstack-nova-api.service | /var/log/containers/nova/nova-api.log |
OpenStack Compute 証明書サーバー | openstack-nova-cert.service | /var/log/containers/nova/nova-cert.log |
OpenStack Compute サービス | openstack-nova-compute.service | /var/log/containers/nova/nova-compute.log |
OpenStack Compute Conductor サービス | openstack-nova-conductor.service | /var/log/containers/nova/nova-conductor.log |
OpenStack Compute VNC コンソール認証サーバー | openstack-nova-consoleauth.service | /var/log/containers/nova/nova-consoleauth.log |
情報メッセージ | nova-manage コマンド | /var/log/containers/nova/nova-manage.log |
OpenStack Compute NoVNC Proxy サービス | openstack-nova-novncproxy.service | /var/log/containers/nova/nova-novncproxy.log |
OpenStack Compute Scheduler サービス | openstack-nova-scheduler.service | /var/log/containers/nova/nova-scheduler.log |
2.9.4. Dashboard (horizon) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
特定ユーザーの対話のログ | Dashboard インターフェース | /var/log/containers/horizon/horizon.log |
Apache HTTP サーバーは、Dashboard Web インターフェース用にさまざまな追加ログファイルを使用します。このログファイルには、Web ブラウザーまたは keystone および nova 等のコマンドラインクライアントを使用してアクセスすることができます。以下の表のログファイルは、Dashboard の使用状況のトラッキングおよび障害の診断に役立ちます。
目的 | ログのパス |
---|---|
すべての処理された HTTP リクエスト | /var/log/containers/httpd/horizon_access.log |
HTTP エラー | /var/log/containers/httpd/horizon_error.log |
管理者ロールの API リクエスト | /var/log/containers/httpd/keystone_wsgi_admin_access.log |
管理者ロールの API エラー | /var/log/containers/httpd/keystone_wsgi_admin_error.log |
メンバーロールの API リクエスト | /var/log/containers/httpd/keystone_wsgi_main_access.log |
メンバーロールの API エラー | /var/log/containers/httpd/keystone_wsgi_main_error.log |
同じホストで実行中の他の Web サービスが報告するエラーを保管するログファイル /var/log/containers/httpd/default_error.log
もあります。
2.9.5. Identity サービス (keystone) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
OpenStack Identity サービス | openstack-keystone.service | /var/log/containers/keystone/keystone.log |
2.9.6. Image サービス (glance) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
OpenStack Image サービス API サーバー | openstack-glance-api.service | /var/log/containers/glance/api.log |
OpenStack Image サービスレジストリーサーバー | openstack-glance-registry.service | /var/log/containers/glance/registry.log |
2.9.7. Networking (neutron) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
OpenStack Neutron DHCP エージェント | neutron-dhcp-agent.service | /var/log/containers/neutron/dhcp-agent.log |
OpenStack Networking レイヤー 3 エージェント | neutron-l3-agent.service | /var/log/containers/neutron/l3-agent.log |
メタデータエージェントサービス | neutron-metadata-agent.service | /var/log/containers/neutron/metadata-agent.log |
メタデータ名前空間プロキシー | 該当なし | /var/log/containers/neutron/neutron-ns-metadata-proxy-UUID.log |
Open vSwitch エージェント | neutron-openvswitch-agent.service | /var/log/containers/neutron/openvswitch-agent.log |
OpenStack Networking サービス | neutron-server.service | /var/log/containers/neutron/server.log |
2.9.8. Object Storage (swift) のログファイル
OpenStack Object Storage は、システムのロギング機能にのみ、ログを送信します。
デフォルトでは、すべての Object Storage ログファイルは、local0、local1、および local2 syslog ファシリティーを使用して /var/log/containers/swift/swift.log
に保存されます。
Object Storage のログメッセージは、REST API サービスによるものとバックグラウンドデーモンによるものの 2 つのカテゴリーに大別されます。API サービスのメッセージには、一般的な HTTP サーバーと同様に、API リクエストごとに 1 つの行が含まれます。フロントエンド (プロキシー) とバックエンド (アカウント、コンテナー、オブジェクト) サービスの両方がこのメッセージの POST を行います。デーモンメッセージは構造化されておらず、通常、定期的なタスクを実行するデーモンに関する人間が判読できる情報が含まれます。ただし、メッセージを生成する Object Storage の部分に関係なく、ソースの ID は常に行の先頭に置かれます。
プロキシーメッセージの例を以下に示します。
Apr 20 15:20:34 rhev-a24c-01 proxy-server: 127.0.0.1 127.0.0.1 20/Apr/2015/19/20/34 GET /v1/AUTH_zaitcev%3Fformat%3Djson%26marker%3Dtestcont HTTP/1.0 200 - python-swiftclient-2.1.0 AUTH_tk737d6... - 2 - txc454fa8ea4844d909820a-0055355182 - 0.0162 - - 1429557634.806570053 1429557634.822791100
バックグラウンドデーモンからのアドホックメッセージの例を以下に示します。
Apr 27 17:08:15 rhev-a24c-02 object-auditor: Object audit (ZBF). Since Mon Apr 27 21:08:15 2015: Locally: 1 passed, 0 quarantined, 0 errors files/sec: 4.34 , bytes/sec: 0.00, Total time: 0.23, Auditing time: 0.00, Rate: 0.00 Apr 27 17:08:16 rhev-a24c-02 object-auditor: Object audit (ZBF) "forever" mode completed: 0.56s. Total quarantined: 0, Total errors: 0, Total files/sec: 14.31, Total bytes/sec: 0.00, Auditing time: 0.02, Rate: 0.04 Apr 27 17:08:16 rhev-a24c-02 account-replicator: Beginning replication run Apr 27 17:08:16 rhev-a24c-02 account-replicator: Replication run OVER Apr 27 17:08:16 rhev-a24c-02 account-replicator: Attempted to replicate 5 dbs in 0.12589 seconds (39.71876/s) Apr 27 17:08:16 rhev-a24c-02 account-replicator: Removed 0 dbs Apr 27 17:08:16 rhev-a24c-02 account-replicator: 10 successes, 0 failures
2.9.9. Orchestration (heat) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
OpenStack Heat API サービス | openstack-heat-api.service | /var/log/containers/heat/heat-api.log |
OpenStack Heat エンジンサービス | openstack-heat-engine.service | /var/log/containers/heat/heat-engine.log |
Orchestration サービスイベント | 該当なし | /var/log/containers/heat/heat-manage.log |
2.9.10. Shared File Systems サービス (manila) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
OpenStack Manila API サーバー | openstack-manila-api.service | /var/log/containers/manila/api.log |
OpenStack Manila Scheduler | openstack-manila-scheduler.service | /var/log/containers/manila/scheduler.log |
OpenStack Manila ファイル共有サービス | openstack-manila-share.service | /var/log/containers/manila/share.log |
Manila Python ライブラリーの一部の情報は、/var/log/containers/manila/manila-manage.log
に記録することもできます。
2.9.11. Telemetry (ceilometer) のログファイル
サービス | サービス名 | ログのパス |
---|---|---|
OpenStack ceilometer 通知エージェント | ceilometer_agent_notification | /var/log/containers/ceilometer/agent-notification.log |
OpenStack ceilometer 中央エージェント | ceilometer_agent_central | /var/log/containers/ceilometer/central.log |
OpenStack ceilometer コレクション | openstack-ceilometer-collector.service | /var/log/containers/ceilometer/collector.log |
OpenStack ceilometer コンピュートエージェント | ceilometer_agent_compute | /var/log/containers/ceilometer/compute.log |
2.9.12. サポートサービスのログファイル
以下のサービスは OpenStack のコアコンポーネントにより使用され、独自のログディレクトリーおよびファイルを持ちます。
サービス | サービス名 | ログのパス |
---|---|---|
メッセージブローカー (RabbitMQ) | rabbitmq-server.service |
/var/log/rabbitmq/rabbit@short_hostname.log |
データベースサーバー (MariaDB) | mariadb.service | /var/log/mariadb/mariadb.log |
仮想ネットワークスイッチ (Open vSwitch) | openvswitch-nonetwork.service |
/var/log/openvswitch/ovsdb-server.log |
2.9.13. aodh (アラームサービス) のログファイル
サービス | コンテナー名 | ログのパス |
---|---|---|
アラーム用 API | aodh_api | /var/log/containers/httpd/aodh-api/aodh_wsgi_access.log |
アラームエバリュエーターログ | aodh_evaluator | /var/log/containers/aodh/aodh-evaluator.log |
アラームリスナー | aodh_listener | /var/log/containers/aodh/aodh-listener.log |
アラーム通知 | aodh_notifier | /var/log/containers/aodh/aodh-notifier.log |
2.9.14. gnocchi (メトリックストレージ) のログファイル
サービス | コンテナー名 | ログのパス |
---|---|---|
gnocchi API | gnocchi_api | /var/log/containers/httpd/gnocchi-api/gnocchi_wsgi_access.log |
gnocchi metricd | gnocchi_metricd | /var/log/containers/gnocchi/gnocchi-metricd.log |
gnocchi statsd | gnocchi_statsd | /var/log/containers/gnocchi/gnocchi-statsd.log |
第3章 Telemetry 用時系列データベース (gnocchi) の設定
時系列データベース (gnocchi) は、マルチプロジェクトのメトリックおよびリソースデータベースです。大規模なメトリックを保管する一方で、オペレーターやユーザーにメトリックおよびリソースの情報へのアクセスを提供します。
3.1. 時系列データベースについて
本セクションでは、時系列データベース (gnocchi) の機能に関して一般的に使用される用語を定義します。
- 集約メソッド
-
複数の計測値から 1 つの集約値を生成するのに使用される関数。たとえば、
min
集約メソッドは、さまざまな計測値を、特定期間内の全計測値の最小値に集約します。 - 集約値 (Aggregate)
- アーカイブポリシーに従って複数の計測値から生成されたデータポイントタプル。集約値はタイムスタンプおよび値で構成されます。
- アーカイブポリシー
- メトリックに割り当てられた集約値の保管ポリシー。アーカイブポリシーにより、集約値がメトリックに保持される期間および集約値の生成方法 (集約メソッド) が決定されます。
- 粒度 (Granularity)
- メトリックの集約時系列における 2 つの集約値の時間間隔
- 計測値 (Measure)
- API によって時系列データベースに送信される受信データポイントタプル。計測値はタイムスタンプおよび値で構成されます。
- メトリック
- UUID で識別される集約値を保管するエンティティー。名前を使用して、メトリックをリソースに割り当てることができます。メトリックがその集約値をどのように保管するかは、メトリックが関連付けられたアーカイブポリシーで定義されます。
- リソース
- メトリックを関連付ける、インフラストラクチャー内の任意の項目を表すエンティティー。リソースは一意の ID で識別され、属性を含めることができます。
- 時系列 (Time series)
- 集約値を時刻順に並べた一覧
- タイムスパン
- メトリックがその集約値を保持する期間。アーカイブポリシーを定義する際に使用されます。
3.2. メトリック
時系列データベース (gnocchi) は Telemetry からの メトリック を保管します。これには、サーバーの CPU 使用状況、部屋の温度、ネットワークインターフェースによって送信されるバイト数など、計測することのできる任意の項目が含まれます。
メトリックには以下の属性が含まれます。
- メトリックを識別するための UUID
- メトリック名
- 計測値を保管および集約するのに使用されるアーカイブポリシー
時系列データベースは、etc/ceilometer/polling.yaml
ファイルで定義されているように、デフォルトで以下のメトリックを保存します。
[root@controller-0 ~]# podman exec -ti ceilometer_agent_central cat /etc/ceilometer/polling.yaml --- sources: - name: some_pollsters interval: 300 meters: - cpu - memory.usage - network.incoming.bytes - network.incoming.packets - network.outgoing.bytes - network.outgoing.packets - disk.read.bytes - disk.read.requests - disk.write.bytes - disk.write.requests - hardware.cpu.util - hardware.memory.used - hardware.memory.total - hardware.memory.buffer - hardware.memory.cached - hardware.memory.swap.avail - hardware.memory.swap.total - hardware.system_stats.io.outgoing.blocks - hardware.system_stats.io.incoming.blocks - hardware.network.ip.incoming.datagrams - hardware.network.ip.outgoing.datagrams
polling.yaml
ファイルでは、デフォルトのポーリング間隔 300 秒(5 分)も指定します。
3.3. 時系列データベースのコンポーネント
現在、gnocchi は認証に Identity サービスを、受信測定値のストレージに Redis を、それぞれ使用します。集約した計測値を保管するのに、gnocchi は Swift または Ceph (オブジェクトストレージ) のいずれかに依存します。gnocchi は MySQL も活用して、リソースおよびメトリックのインデックスを保管します。
時系列データベースは、statsd
プロトコルと互換性のある statsd
デーモン(gnocchi-statsd
)を提供し、ネットワークに送信されるメトリックをリッスンできます。Gnocchi で statsd
のサポートを有効にするには、設定ファイルで [statsd]
オプションを設定します。リソース ID パラメーターは、全メトリックがアタッチされる主要な一般リソース、リソースとメトリックに関連付けられるユーザーとプロジェクト ID、メトリックの作成に使用するアーカイブポリシー名として使用されます。
メトリックはgnocchi-statsd
に送信され、指定した名前で設定したリソース ID にアタッチされるので、すべてのメトリックは動的に作成されます。
3.4. 時系列データベースの実行
HTTP サーバーおよびメトリックデーモンを実行して、時系列データベースを実行します。
# gnocchi-api # gnocchi-metricd
3.5. WSGI アプリケーションとしての実行
mod_wsgi
などの WSGI サービスや他の WSGI アプリケーションを使用して Gnocchi を実行することができます。Gnocchi で提供される gnocchi/rest/app.wsgi
ファイルを使用して、Gnocchi を WSGI アプリケーションとして有効にできます。
gnocchi API 層は、WSGI を使用して実行します。つまり、Apache httpd
および mod_wsgi
や uwsgi
などの別の HTTP デーモンを使用して実行できます。所有している CPU の数に応じて、プロセスおよびスレッドの数を設定します(通常はおよそ CPU の数の1.5 倍
です)。1 台のサーバーで十分ではない場合、必要なだけ新規 API サーバーを増設し、異なるマシン上にでも gnocchi をスケールアウトすることができます。
3.6. metricd ワーカー
メトリックの集約を処理する際、デフォルトでは gnocchi-metricd
デーモンは、CPU の使用率を最大化するために CPU の全能力を活用します。gnocchi status
コマンドを使用して HTTP API にクエリーを行い、メトリック処理のクラスターステータスを取得することができます。このコマンドにより、gnocchi-metricd
の処理のバックログである処理するメトリックの数が表示されます。このバックログが継続的に増加していない限り、gnocchi-metricd
が送信されるメトリックの量に対応できることを意味します。処理する計測値の数が継続的に増加している場合は、gnocchi-metricd
デーモンの数を一時的に増やさなければならない場合があります。任意の数のサーバー上で、metricd デーモンをいくつでも実行することができます。
director ベースのデプロイメントの場合、環境ファイルで特定のメトリック処理パラメーターを調整することができます。
-
MetricProcessingDelay
: メトリック処理の反復間の遅延時間を調整します。 -
GnocchiMetricdWorkers
:metricd
ワーカーの数を設定します。
3.7. 時系列データベースのモニタリング
HTTP API の /v1/status
エンドポイントは、処理する計測値の数(計測値のバックログ)など、さまざまな情報を返すので、簡単に監視することができます。システム全体の正常性を検証するには、HTTP サーバーおよび gnocchi-metricd
デーモンが動作中で、ログファイルにエラーを書き込んでいないことを確認します。
3.8. 時系列データベースのバックアップおよびリストア
問題のある状況から回復するために、インデックスとストレージの両方をバックアップします。データベースのダンプを作成し (PostgreSQL または MySQL)、データストレージのスナップショットまたはコピーを作成する (Ceph、Swift、またはファイルシステム) 必要があります。復元の手順としては、インデックスおよびストレージのバックアップを復元し、必要に応じて gnocchi を再インストールし、再起動します。
3.9. gnocchi からの古いリソースのバッチ削除
古い計測値を削除するには、要件に合ったアーカイブポリシーを作成します。リソース、メトリック、および計測値をバッチで削除するには、CLI または REST API を使用します。たとえば、30 日経過したリソースおよび関連するすべてのメトリックを削除するには、以下のコマンドを実行します。
openstack metric resource batch delete "ended_at < '-30days'"
3.10. Telemetry サービスを使用した容量のメータリング
OpenStack Telemetry サービスには、請求、チャージバック、およびショウバックの目的に使用できる使用状況のメトリックが用意されています。このようなメトリックデータをサードパーティーアプリケーションで処理してクラスター容量の計画を作成したり、OpenStack heat を使用した仮想インスタンスの自動スケーリングに活用したりすることもできます。詳細は、『Auto Scaling for Instances』を参照してください。
モニタリングおよびアラーム用に、ceilometer と gnocchi の組み合わせを使用することができます。この構成は小規模のクラスターでサポートされ、既知の制限が存在します。リアルタイムモニタリング用に、Red Hat OpenStack Platform にはメトリックデータを提供するエージェントが同梱されており、このデータを別のモニタリングインフラストラクチャーおよびアプリケーションで処理することができます。詳細は、『Monitoring Tools Configuration』を参照してください。
3.10.1. 計測値の表示
特定リソースの計測値をすべて一覧表示します。
# openstack metric measures show --resource-id UUID METER_NAME
タイムスタンプの範囲内の特定リソースの計測値だけを一覧表示します。
# openstack metric measures show --aggregation mean --start <START_TIME> --stop <STOP_TIME> --resource-id UUID METER_NAME
タイムスタンプの変数 <START_TIME> および <STOP_TIME> の形式は、iso-dateThh:mm:ss です。
3.10.2. 新規計測値の作成
計測値を使用して、Telemetry サービスにデータを送信することができます。以前に定義した計測値と一致する必要はありません。以下は例になります。
# openstack metrics measures add -m 2015-01-12T17:56:23@42 --resource-id UUID METER_NAME
3.10.3. 例: クラウドの使用状況に関する計測値の表示
以下の例では、各プロジェクトの全インスタンスの平均メモリー使用量を表示します。
# openstack metric measures aggregation --resource-type instance --groupby project_id -m memory
3.10.4. 既存のアラームの表示
既存の Telemetry アラームを一覧表示するには、aodh
コマンドを使用します。以下は例になります。
# aodh alarm list +--------------------------------------+--------------------------------------------+----------------------------+-------------------+----------+---------+ | alarm_id | type | name | state | severity | enabled | +--------------------------------------+--------------------------------------------+----------------------------+-------------------+----------+---------+ | 922f899c-27c8-4c7d-a2cf-107be51ca90a | gnocchi_aggregation_by_resources_threshold | iops-monitor-read-requests | insufficient data | low | True | +--------------------------------------+--------------------------------------------+----------------------------+-------------------+----------+---------+
リソースに割り当てた計測値を一覧表示するには、リソース (インスタンス、イメージ、ボリューム等) の UUID を指定します。以下は例になります。
# gnocchi resource show 5e3fcbe2-7aab-475d-b42c-a440aa42e5ad
3.10.5. アラームの作成
aodh
を使用して、しきい値に達した時にアクティブになるアラームを作成することができます。以下の例では、個々のインスタンスの平均 CPU 使用率が 80% を超えると、アラームがアクティブになりログエントリーが追加されます。監視目的で、クエリーを使用して特定インスタンスの ID(94619081-abf5-4f1f-81c7-9cedaa872403
)を分離します。
# aodh alarm create --type gnocchi_aggregation_by_resources_threshold --name cpu_usage_high --metric cpu_util --threshold 80 --aggregation-method sum --resource-type instance --query '{"=": {"id": "94619081-abf5-4f1f-81c7-9cedaa872403"}}' --alarm-action 'log://' +---------------------------+-------------------------------------------------------+ | Field | Value | +---------------------------+-------------------------------------------------------+ | aggregation_method | sum | | alarm_actions | [u'log://'] | | alarm_id | b794adc7-ed4f-4edb-ace4-88cbe4674a94 | | comparison_operator | eq | | description | gnocchi_aggregation_by_resources_threshold alarm rule | | enabled | True | | evaluation_periods | 1 | | granularity | 60 | | insufficient_data_actions | [] | | metric | cpu_util | | name | cpu_usage_high | | ok_actions | [] | | project_id | 13c52c41e0e543d9841a3e761f981c20 | | query | {"=": {"id": "94619081-abf5-4f1f-81c7-9cedaa872403"}} | | repeat_actions | False | | resource_type | instance | | severity | low | | state | insufficient data | | state_timestamp | 2016-12-09T05:18:53.326000 | | threshold | 80.0 | | time_constraints | [] | | timestamp | 2016-12-09T05:18:53.326000 | | type | gnocchi_aggregation_by_resources_threshold | | user_id | 32d3f2c9a234423cb52fb69d3741dbbc | +---------------------------+-------------------------------------------------------+
既存のアラームのしきい値を編集するには、aodh alarm update
コマンドを使用します。たとえば、アラームのしきい値を 75% に増やすには、以下のコマンドを実行します。
# aodh alarm update --name cpu_usage_high --threshold 75
3.10.6. アラームの無効化または削除
アラームを無効にするには、以下のコマンドを実行します。
# aodh alarm update --name cpu_usage_high --enabled=false
アラームを削除するには、以下のコマンドを実行します。
# aodh alarm delete --name cpu_usage_high
3.10.7. 例: インスタンスのディスク動作のモニタリング
aodh アラームを使用して、特定のプロジェクトに含まれるすべてのインスタンスの漸増するディスク動作を監視する方法を、以下の例で説明します。
1. 既存のプロジェクトを確認し、監視するプロジェクトの適切な UUID を選択します。以下の例では、admin
プロジェクトを使用します。
$ openstack project list +----------------------------------+----------+ | ID | Name | +----------------------------------+----------+ | 745d33000ac74d30a77539f8920555e7 | admin | | 983739bb834a42ddb48124a38def8538 | services | | be9e767afd4c4b7ead1417c6dfedde2b | demo | +----------------------------------+----------+
2. プロジェクトの UUID を使用して、admin
プロジェクト内のインスタンスが生成するすべての読み取りリクエストの sum()
を解析するアラームを作成します(--query
パラメーターを使用して、クエリーにさらに制限を設けることができます)。
# aodh alarm create --type gnocchi_aggregation_by_resources_threshold --name iops-monitor-read-requests --metric disk.read.requests.rate --threshold 42000 --aggregation-method sum --resource-type instance --query '{"=": {"project_id": "745d33000ac74d30a77539f8920555e7"}}' +---------------------------+-----------------------------------------------------------+ | Field | Value | +---------------------------+-----------------------------------------------------------+ | aggregation_method | sum | | alarm_actions | [] | | alarm_id | 192aba27-d823-4ede-a404-7f6b3cc12469 | | comparison_operator | eq | | description | gnocchi_aggregation_by_resources_threshold alarm rule | | enabled | True | | evaluation_periods | 1 | | granularity | 60 | | insufficient_data_actions | [] | | metric | disk.read.requests.rate | | name | iops-monitor-read-requests | | ok_actions | [] | | project_id | 745d33000ac74d30a77539f8920555e7 | | query | {"=": {"project_id": "745d33000ac74d30a77539f8920555e7"}} | | repeat_actions | False | | resource_type | instance | | severity | low | | state | insufficient data | | state_timestamp | 2016-11-08T23:41:22.919000 | | threshold | 42000.0 | | time_constraints | [] | | timestamp | 2016-11-08T23:41:22.919000 | | type | gnocchi_aggregation_by_resources_threshold | | user_id | 8c4aea738d774967b4ef388eb41fef5e | +---------------------------+-----------------------------------------------------------+
3.10.8. 例: CPU 使用率のモニタリング
インスタンスのパフォーマンスを監視する場合、gnocchi データベースを調べ、メモリーや CPU の使用状況などのモニタリング可能なメトリックを特定します。たとえば、インスタンスに対して gnocchi resource show
を実行して、モニタリング可能なメトリックを特定します。
特定のインスタンスの UUID に対して利用できるメトリックのクエリーを行います。
$ gnocchi resource show --type instance d71cdf9a-51dc-4bba-8170-9cd95edd3f66
-----------------------
---------------------------------------------------------------------+ | Field | Value |-----------------------
---------------------------------------------------------------------+ | created_by_project_id | 44adccdc32614688ae765ed4e484f389 | | created_by_user_id | c24fa60e46d14f8d847fca90531b43db | | creator | c24fa60e46d14f8d847fca90531b43db:44adccdc32614688ae765ed4e484f389 | | display_name | test-instance | | ended_at | None | | flavor_id | 14c7c918-df24-481c-b498-0d3ec57d2e51 | | flavor_name | m1.tiny | | host | overcloud-compute-0 | | id | d71cdf9a-51dc-4bba-8170-9cd95edd3f66 | | image_ref | e75dff7b-3408-45c2-9a02-61fbfbf054d7 | | metrics | compute.instance.booting.time: c739a70d-2d1e-45c1-8c1b-4d28ff2403ac | | | cpu.delta: 700ceb7c-4cff-4d92-be2f-6526321548d6 | | | cpu: 716d6128-1ea6-430d-aa9c-ceaff2a6bf32 | | | cpu_l3_cache: 3410955e-c724-48a5-ab77-c3050b8cbe6e | | | cpu_util: b148c392-37d6-4c8f-8609-e15fc15a4728 | | | disk.allocation: 9dd464a3-acf8-40fe-bd7e-3cb5fb12d7cc | | | disk.capacity: c183d0da-e5eb-4223-a42e-855675dd1ec6 | | | disk.ephemeral.size: 15d1d828-fbb4-4448-b0f2-2392dcfed5b6 | | | disk.iops: b8009e70-daee-403f-94ed-73853359a087 | | | disk.latency: 1c648176-18a6-4198-ac7f-33ee628b82a9 | | | disk.read.bytes.rate: eb35828f-312f-41ce-b0bc-cb6505e14ab7 | | | disk.read.bytes: de463be7-769b-433d-9f22-f3265e146ec8 | | | disk.read.requests.rate: 588ca440-bd73-4fa9-a00c-8af67262f4fd | | | disk.read.requests: 53e5d599-6cad-47de-b814-5cb23e8aaf24 | | | disk.root.size: cee9d8b1-181e-4974-9427-aa7adb3b96d9 | | | disk.usage: 4d724c99-7947-4c6d-9816-abbbc166f6f3 | | | disk.write.bytes.rate: 45b8da6e-0c89-4a6c-9cce-c95d49d9cc8b | | | disk.write.bytes: c7734f1b-b43a-48ee-8fe4-8a31b641b565 | | | disk.write.requests.rate: 96ba2f22-8dd6-4b89-b313-1e0882c4d0d6 | | | disk.write.requests: 553b7254-be2d-481b-9d31-b04c93dbb168 | | | memory.bandwidth.local: 187f29d4-7c70-4ae2-86d1-191d11490aad | | | memory.bandwidth.total: eb09a4fc-c202-4bc3-8c94-aa2076df7e39 | | | memory.resident: 97cfb849-2316-45a6-9545-21b1d48b0052 | | | memory.swap.in: f0378d8f-6927-4b76-8d34-a5931799a301 | | | memory.swap.out: c5fba193-1a1b-44c8-82e3-9fdc9ef21f69 | | | memory.usage: 7958d06d-7894-4ca1-8c7e-72ba572c1260 | | | memory: a35c7eab-f714-4582-aa6f-48c92d4b79cd | | | perf.cache.misses: da69636d-d210-4b7b-bea5-18d4959e95c1 | | | perf.cache.references: e1955a37-d7e4-4b12-8a2a-51de4ec59efd | | | perf.cpu.cycles: 5d325d44-b297-407a-b7db-cc9105549193 | | | perf.instructions: 973d6c6b-bbeb-4a13-96c2-390a63596bfc | | | vcpus: 646b53d0-0168-4851-b297-05d96cc03ab2 | | original_resource_id | d71cdf9a-51dc-4bba-8170-9cd95edd3f66 | | project_id | 3cee262b907b4040b26b678d7180566b | | revision_end | None | | revision_start | 2017-11-16T04:00:27.081865+00:00 | | server_group | None | | started_at | 2017-11-16T01:09:20.668344+00:00 | | type | instance | | user_id | 1dbf5787b2ee46cf9fa6a1dfea9c9996 |-----------------------
---------------------------------------------------------------------+この出力結果の
metrics
の値に、Aodh アラームを使用して監視可能なコンポーネントが一覧表示されます (例:cpu_util
)。CPU の使用状況を監視するには、
cpu_util
メトリックが必要です。このメトリックの詳細を表示するには、以下のコマンドを実行します。$ gnocchi metric show --resource d71cdf9a-51dc-4bba-8170-9cd95edd3f66 cpu_util
------------------------------------
-------------------------------------------------------------------+ | Field | Value |------------------------------------
-------------------------------------------------------------------+ | archive_policy/aggregation_methods | std, count, min, max, sum, mean | | archive_policy/back_window | 0 | | archive_policy/definition | - points: 8640, granularity: 0:05:00, timespan: 30 days, 0:00:00 | | archive_policy/name | low | | created_by_project_id | 44adccdc32614688ae765ed4e484f389 | | created_by_user_id | c24fa60e46d14f8d847fca90531b43db | | creator | c24fa60e46d14f8d847fca90531b43db:44adccdc32614688ae765ed4e484f389 | | id | b148c392-37d6-4c8f-8609-e15fc15a4728 | | name | cpu_util | | resource/created_by_project_id | 44adccdc32614688ae765ed4e484f389 | | resource/created_by_user_id | c24fa60e46d14f8d847fca90531b43db | | resource/creator | c24fa60e46d14f8d847fca90531b43db:44adccdc32614688ae765ed4e484f389 | | resource/ended_at | None | | resource/id | d71cdf9a-51dc-4bba-8170-9cd95edd3f66 | | resource/original_resource_id | d71cdf9a-51dc-4bba-8170-9cd95edd3f66 | | resource/project_id | 3cee262b907b4040b26b678d7180566b | | resource/revision_end | None | | resource/revision_start | 2017-11-17T00:05:27.516421+00:00 | | resource/started_at | 2017-11-16T01:09:20.668344+00:00 | | resource/type | instance | | resource/user_id | 1dbf5787b2ee46cf9fa6a1dfea9c9996 | | unit | None |------------------------------------
-------------------------------------------------------------------+-
archive_policy
:std、count、min、max、sum、mean
の値を計算する際の集約間隔を定義します。
-
Aodh を使用して、
cpu_util
をクエリーするモニタリングタスクを作成します。このタスクは、指定した設定に基づいてイベントをトリガーします。たとえば、インスタンスの CPU 使用率が上昇し一定期間 80% を超える場合にログエントリーを生成するには、以下のコマンドを実行します。aodh alarm create \ --project-id 3cee262b907b4040b26b678d7180566b \ --name high-cpu \ --type gnocchi_resources_threshold \ --description 'High CPU usage' \ --metric cpu_util \ --threshold 80.0 \ --comparison-operator ge \ --aggregation-method mean \ --granularity 300 \ --evaluation-periods 1 \ --alarm-action 'log://' \ --ok-action 'log://' \ --resource-type instance \ --resource-id d71cdf9a-51dc-4bba-8170-9cd95edd3f66 +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | aggregation_method | mean | | alarm_actions | [u'log://'] | | alarm_id | 1625015c-49b8-4e3f-9427-3c312a8615dd | | comparison_operator | ge | | description | High CPU usage | | enabled | True | | evaluation_periods | 1 | | granularity | 300 | | insufficient_data_actions | [] | | metric | cpu_util | | name | high-cpu | | ok_actions | [u'log://'] | | project_id | 3cee262b907b4040b26b678d7180566b | | repeat_actions | False | | resource_id | d71cdf9a-51dc-4bba-8170-9cd95edd3f66 | | resource_type | instance | | severity | low | | state | insufficient data | | state_reason | Not evaluated yet | | state_timestamp | 2017-11-16T05:20:48.891365 | | threshold | 80.0 | | time_constraints | [] | | timestamp | 2017-11-16T05:20:48.891365 | | type | gnocchi_resources_threshold | | user_id | 1dbf5787b2ee46cf9fa6a1dfea9c9996 | +---------------------------+--------------------------------------+
-
comparison-operator
:ge
演算子は、CPU 使用率が 80% 以上の場合にアラームがトリガーされることを定義します。 -
granularity
:メトリックにはアーカイブポリシーが関連付けられます。ポリシーには、さまざまな粒度を設定することができます(例:5 分間隔の集約を 1 時間、および 1 時間間隔の集約を 1 カ月)。granularity
の値は、アーカイブポリシーで指定された期間と一致する必要があります。 -
evaluation-periods
: アラームがトリガーされる前に満たさなければならないgranularity
期間の数。たとえば、この値を2
に設定すると、アラームがトリガーされる前に、2 つのポーリング期間において CPU の使用率が 80% を超える必要があります。 [u'log://']
: この値に設定すると、イベントが aodh のログファイルに記録されます。注記アラームがトリガーされた時(
alarm_actions
)と通常の状態に戻る時(ok_actions
)で、異なるアクションが実行されるように設定できます(Webhook URL など)。
-
アラームがトリガーされているかどうかを確認するには、アラーム履歴にクエリーを行います。
aodh alarm-history show 1625015c-49b8-4e3f-9427-3c312a8615dd --fit-width +----------------------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------+ | timestamp | type | detail | event_id | +----------------------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------+ | 2017-11-16T05:21:47.850094 | state transition | {"transition_reason": "Transition to ok due to 1 samples inside threshold, most recent: 0.0366665763", "state": "ok"} | 3b51f09d-ded1-4807-b6bb-65fdc87669e4 | +----------------------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------+
3.10.9. リソース種別の管理
従来ハードコードされていた Telemetry リソース種別が、gnocchi クライアントによって管理できるようになりました。gnocchi クライアントを使用して、リソース種別を作成、表示、削除することができ、gnocchi API を使用して属性を更新または削除することができます。
1. 新しい リソース種別 を作成します。
$ gnocchi resource-type create testResource01 -a bla:string:True:min_length=123 +----------------+------------------------------------------------------------+ | Field | Value | +----------------+------------------------------------------------------------+ | attributes/bla | max_length=255, min_length=123, required=True, type=string | | name | testResource01 | | state | active | +----------------+------------------------------------------------------------+
2. リソース種別 の設定を確認します。
$ gnocchi resource-type show testResource01 +----------------+------------------------------------------------------------+ | Field | Value | +----------------+------------------------------------------------------------+ | attributes/bla | max_length=255, min_length=123, required=True, type=string | | name | testResource01 | | state | active | +----------------+------------------------------------------------------------+
3. リソース種別 を削除します。
$ gnocchi resource-type delete testResource01
リソースが使用中のリソース種別を削除することはできません。
第4章 トラブルシューティング
本章では、Red Hat OpenStack Platform デプロイメントのトラブルシューティングに役立つログ記録およびサポート情報について記載します。
4.1. サポート
クライアントコマンドが失敗したり、他の問題が発生した場合は、発生した問題、完全なコンソール出力、コンソール出力で参照されているすべてのログファイル、問題のある(またはその可能性がある)ノードの sosreport
と共に、Red Hat テクニカルサポートまでお問い合わせください。たとえば、コンピュートレベルで問題が発生した場合、Nova ノードで sosreport
を実行します。また、ネットワークの問題の場合は、Neutron ノードでユーティリティーを実行します。一般的なデプロイメントの問題については、クラウドコントローラー上で sosreport
を実行すると良いでしょう。
sosreport
コマンド (sos
パッケージ) の詳細は、「What is a sosreport and how to create one in Red Hat Enterprise Linux 4.6 and later」を参照してください。
/var/log/messages
ファイルでヒントがないか確認もしてください。
4.2. Identity クライアント (keystone) の接続性に関する問題のトラブルシューティング
Identity クライアント (keystone
) が Identity サービスにコンタクトできない場合には、次のようなエラーが返されます。
Unable to communicate with identity service: [Errno 113] No route to host. (HTTP 400)
この問題をデバッグするには、以下に挙げる一般的な原因を確認してください。
- Identity サービスが稼働していない
Identity サービスは httpd.service 内で実行されるようになりましたIdentity サービスをホストしているシステム上で、サービスのステータスを確認します。
# systemctl status httpd.service
サービスがアクティブでない場合には、root ユーザーとしてログインしてサービスを起動します。
# systemctl start httpd.service
- ファイアウォールが適切に設定されていない
-
ポート
5000
および35357
の TCP トラフィックを許可するようにファイアウォールが設定されていない可能性があります。その場合は、『オーバークラウドの高度なカスタマイズ』の「オーバークラウドのファイアウォールの管理」に記載の手順を参照して、ファイアウォール設定の確認およびカスタムルールの定義を行います。 - サービスエンドポイントが正しく定義されていない
Identity サービスをホストするシステムで、エンドポイントが正しく定義されていることを確認します。
管理トークンを取得します。
# grep admin_token /etc/keystone/keystone.conf admin_token = 91f0866234a64fc299db8f26f8729488
Identity サービスの正しい管理エンドポイントを決定します。
http://IP:35357/VERSION
IP を、Identity サービスをホストしているシステムの IP アドレスまたはホスト名に置き換えます。VERSION を、使用中の API バージョン(
v2.0
またはv3
)に置き換えます。事前に定義されている Identity サービス関連の環境変数の設定を解除します。
# unset OS_USERNAME OS_TENANT_NAME OS_PASSWORD OS_AUTH_URL
管理トークンとエンドポイントを使用して、Identity サービスとの認証を行います。Identity サービスのエンドポイントが正しいことを確認してください。以下は例になります。
# openstack endpoint list --os-token=91f0556234a64fc299db8f26f8729488 --os-url=https://osp.lab.local:35357/v3/ --os-identity-api-version 3
一覧表示された Identity サービスの
publicurl
、internalurl
、およびadminurl
が正しいことを確認してください。特に、各エンドポイント内にリストされている IP アドレスとポート番号が正しく、ネットワーク上で到達可能であるようにしてください。これらの値が正しくない場合は、正しいエンドポイントを追加し、
openstack
コマンドのendpoint delete
アクションを使用して正しくないエンドポイントを削除します。以下は例になります。# openstack endpoint delete 2d32fa6feecc49aab5de538bdf7aa018 --os-token=91f0866234a64fc299db8f26f8729488 --os-url=https://osp.lab.local:35357/v3/ --os-identity-api-version 3
TOKEN および ENDPOINT を前のステップで特定した値に置き換えます。ID を、
endpoint-list
アクションで一覧表示される削除するエンドポイントのIDに置き換えます。
4.3. OpenStack Networking に関する問題のトラブルシューティング
本項では、OpenStack Networking サービスに関する問題のトラブルシューティングに使用することができるさまざまなコマンドと手順について説明します。
- ネットワークデバイスのデバッグ
-
ip a
コマンドで、すべての物理デバイスおよび仮想デバイスを表示します。 -
ovs-vsctl show
コマンドで、仮想スイッチ内のインターフェースとブリッジを表示します。 -
ovs-dpctl show
コマンドで、スイッチ上のデータパスを表示します。
-
- ネットワークパケットのトラッキング
tcpdump
コマンドで、パケットが通過しない場所を確認します。# tcpdump -n -i INTERFACE -e -w FILENAME
INTERFACE を、パケットが通過できない箇所を確認するネットワークインターフェースの名前に置き換えます。このインターフェース名には、ブリッジまたはホストのイーサネットデバイスの名前を使用することができます。
-e
フラグにより、リンクレベルのヘッダー(vlan
タグが表示される)がダンプされます。-w
フラグはオプションです。このフラグは、出力をファイルに書き込む場合にのみ使用することができます。そうでない場合には、出力は標準出力(stdout
)に書き込まれます。tcpdump
についての詳細は、man tcpdump
コマンドで man ページを開いて参照してください。
- ネットワーク名前空間のデバッグ
-
ip netns list
コマンドで、既知のネットワーク名前空間をすべて一覧表示します。 ip netns exec
コマンドで、特定の名前空間内のルーティングテーブルを表示します。# ip netns exec NAMESPACE_ID bash # route -n
bash シェルで
ip netns exec
コマンドを起動し、それ以降に実行するコマンドがip netns exec
コマンドを実行しなくても呼び出されるようにします。
-
4.4. ダッシュボードのネットワークまたはルータータブの表示に関する問題のトラブルシューティング
OpenStack Networking を使用するように環境が設定されている場合にのみ、Dashboard に ネットワーク および ルーター タブが表示されます。現在、デフォルトでは、Packstack ユーティリティーによって nova ネットワークがデプロイされるため、この方法でデプロイされた環境には、これらのタブは表示されない点に特に注意してください。
OpenStack Networking が環境にデプロイされているにもかかわらずタブが表示されない場合には、Identity サービスでサービスエンドポイントが正しく定義されて、ファイアウォールがそのエンドポイントへのアクセスを許可し、サービスが稼働していることを確認してください。
4.5. Dashboard でのインスタンス起動エラーに関するトラブルシューティング
ダッシュボードを使用してインスタンスを起動する際、操作が失敗すると、一般的な ERROR
メッセージが表示されます。実際の原因を究明するには、コマンドラインツールを使用する必要があります。
nova list
コマンドを使用して、インスタンスの一意識別子を確認します。続いて、この識別子を nova show
コマンドの引数として使用します。返される項目のいずれかがエラー条件になります。もっとも一般的な値は NoValidHost
です。
このエラーは、インスタンスをホストするのに十分なリソースが利用できる有効なホストがないことを示しています。この問題を回避するには、より小さなインスタンスサイズを選択するか、その環境のオーバーコミットの上限を高くする方法を検討してください。
インスタンスをホストするには、コンピュートノードで CPU および RAM リソースが使用可能なだけでなく、インスタンスに関連付けられる一時ストレージ用に十分なディスク領域を持つ必要もあります。
4.6. Dashboard の Keystone v3 認証に関するトラブルシューティング
django_openstack_auth は、Django の contrib.auth フレームワークと連携する、プラグ可能な Django 認証バックエンドで、OpenStack Identity サービス API に対してユーザー認証を行います。Django_openstack_auth は、トークンオブジェクトを使用して、ユーザーおよび Keystone 関連の情報をカプセル化します。Dashboard は、トークンオブジェクトを使用して Django ユーザーオブジェクトを再構築します。
現在、トークンオブジェクトは以下を保管します。
- keystone トークン
- ユーザー情報
- スコープ
- ロール
- サービスカタログ
Dashboard は、ユーザーセッションデータの処理に Django のセッションフレームワークを使用します。以下は、利用可能な各種セッションバックエンド一覧です。これらは、local_settings.py ファイルの SESSION_ENGINE 設定で制御されます。
- ローカルメモリーキャッシュ
- Memcached
- データベース
- キャッシュされたデータベース
- クッキー
特に署名付きクッキーのセッションバックエンドが使用されている場合、多数またはすべてのサービスが一度に有効化された場合など、クッキーのサイズが制限に到達して、Dashboard へのログインに失敗する可能性があります。クッキーサイズが増加する理由の 1 つとして、サービスカタログが挙げられます。多くのサービスが登録されるにつれ、サービスカタログのサイズも増加します。
このようなシナリオでは (特に keystone v3 認証を使用している場合)、セッショントークン管理を向上させるため、Dashboard へログインするための以下の設定を含めてください。
/usr/share/openstack-dashboard/openstack_dashboard/settings.py では、以下の設定を追加します。
DATABASES = { default: { ENGINE: django.db.backends.mysql, NAME: horizondb, USER: User Name, PASSWORD: Password, HOST: localhost, } }
同じファイルで、SESSION_ENGINE を以下に変更します。
SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'
mysql コマンドを使用してデータベースサービスに接続します。USER は、接続に使用するユーザー名に置き換えます。また、USER は root ユーザー (あるいは、少なくとも正しい権限「create db」を持つユーザー) でなければなりません。
# mysql -u USER -p
Horizon データベースを作成します。
mysql > create database horizondb;
mysql クライアントを終了します。
mysql > exit
以下のコマンドで、openstack_dashboard ディレクトリーに移動して、データベースを同期します。
# cd /usr/share/openstack-dashboard/openstack_dashboard $ ./manage.py syncdb
スーパーユーザーを作成する必要はないため、質問には n と回答します。
Apache http サーバーを再起動します。Red Hat Enterprise Linux の場合は以下のコマンドを実行します。
# systemctl restart httpd
4.6.1. OpenStack Dashboard: Red Hat Access タブ
Red Hat Access タブ (OpenStack Dashboard の一部) では、Red Hat カスタマーポータルの記事やソリューションの検索、表示、インスタンスからのログの表示や診断、カスタマーサポートケースの操作を行うことができます。
図4.1 Red Hat Access タブ

Red Hat Acesss タブの機能を使用するには、ブラウザーで Red Hat カスタマーポータルにログインする必要があります。
ログインされていない場合には、以下の手順でログインしてください。
- ログイン をクリックします。
- Red Hat のログイン情報を入力します。
- Red Hat パスワードを入力します。
- サインイン をクリックします。
フォームは以下のとおりです。
図4.2 Red Hat カスタマーポータルへのログイン

この時点でログインしないと、認証が必要な機能の 1 つを使用する際に Red Hat ログインとパスワードが要求されます。
4.6.1.1. Search
1 つまたは複数の検索キーワードを入力して、Red Hat カスタマーポータルからの記事やソリューションを検索できます。関連の記事やソリューションのタイトルが表示されます。タイトルをクリックして、指定の記事またはソリューションを表示します。
図4.3 Red Hat Access タブの検索結果の例

4.6.1.2. ログ
ここから、OpenStack インスタンスからのログを確認することができます。
図4.4 Red Hat Access タブでのインスタンスのログ

表で必要なインスタンスを探します。インスタンスが多数ある場合は、名前、ステータス、イメージ ID、またはフレーバー ID で絞り込むことができます。確認するインスタンスの アクション 欄で、ログの参照 をクリックします。
インスタンスのログが表示されたら、Red Hat 診断 をクリックして、コンテンツに関連した提案ソリューションを取得することができます。
図4.5 Red Hat Access タブでのインスタンスのログ

提案されたソリューションで役に立つものがない場合や、問題が正しくロギングされている場合には、サポートケースを新規作成 をクリックして、問題を Red Hat サポートに報告してください。
4.6.1.3. サポート
Red Hat Access タブの最後のオプションでは、Red Hat カスタマーポータルのサポートケースを検索することができます。
図4.6 サポートケースの検索

また、適切なボタンをクリックして、以下のページでフォームに入力して新規サポートケースを開くことも可能です。
図4.7 サポートケースの新規作成
