ロギング、モニタリング、およびトラブルシューティングガイド
OpenStack のロギング、モニタリング、およびトラブルシューティングの詳細ガイド
概要
多様性を受け入れるオープンソースの強化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。
ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)
特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。
- Multi-page HTML 形式でドキュメントを表示します。
- ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
- コメントするテキスト部分をハイライト表示します。
- Add Feedback をクリックします。
- Add Feedback フィールドにコメントを入力します。
- オプション: ドキュメントチームが問題の詳細を確認する際に使用できるメールアドレスを記入してください。
- Submit をクリックします。
第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
openstack overcloud deploy \ <existing_overcloud_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/logging-environment-rsyslog.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow <existing_overcloud_environment_files>を既存のデプロイメントに含まれる環境ファイルのリストに置き換えます。
2.3. ロギング機能の設定 リンクのコピーリンクがクリップボードにコピーされました!
ロギング機能を設定するには、logging-environment-rsyslog.yaml ファイルの RsyslogElasticsearchSetting パラメーターを変更します。
手順
-
tripleo-heat-templates/environments/logging-environment-rsyslog.yamlファイルをホームディレクトリーにコピーします。 実際の環境に合わせて
RsyslogElasticsearchSettingパラメーターのエントリーを作成します。RsyslogElasticsearchSettingパラメーターの設定例を以下のスニペットに示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
- 設定可能なパラメーターについての詳細は、「設定可能なロギングパラメーター」 を参照してください。
2.3.1. 設定可能なロギングパラメーター リンクのコピーリンクがクリップボードにコピーされました!
以下の表で、Red Hat OpenStack Platform (RHOSP) のロギング機能の設定に使用するロギングパラメーターについて説明します。これらのパラメーターは tripleo-heat-templates/deployment/logging/rsyslog-container-puppet.yaml ファイルにあります。
| パラメーター | 説明 |
|---|---|
|
|
|
|
| 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.logNovaComputeLoggingSource: tag: openstack.nova.compute file: /some/other/path/nova-compute.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記サービスごとに、
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<service_name>LoggingSource: tag: <service_name>.tag path: <service_name>.path format: <service_name>.formatCopy to Clipboard Copied! Toggle word wrap Toggle overflow より複雑な変換の例を以下のスニペットに示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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]+\\)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]+\\)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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) '
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 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
バックグラウンドデーモンからのアドホックメッセージの例を以下に示します。
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.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 ファイルで定義されているように、デフォルトで以下のメトリックを保存します。
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
# 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'"
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 にはメトリックデータを提供するエージェントが同梱されており、このデータを別のモニタリングインフラストラクチャーおよびアプリケーションで処理することができます。詳細は、監視ツール設定ガイド を参照してください。
3.10.1. 計測値の表示 リンクのコピーリンクがクリップボードにコピーされました!
特定リソースの計測値をすべてリスト表示します。
openstack metric measures show --resource-id UUID METER_NAME
# 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
# 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
# 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
# openstack metric measures aggregation --resource-type instance --groupby project_id -m memory
3.10.4. 既存のアラームの表示 リンクのコピーリンクがクリップボードにコピーされました!
既存の Telemetry アラームをリスト表示するには、aodh コマンドを使用します。以下に例を示します。
リソースに割り当てた計測値をリスト表示するには、リソース (インスタンス、イメージ、ボリューム等) の UUID を指定します。以下に例を示します。
gnocchi resource show 5e3fcbe2-7aab-475d-b42c-a440aa42e5ad
# gnocchi resource show 5e3fcbe2-7aab-475d-b42c-a440aa42e5ad
3.10.5. アラームの作成 リンクのコピーリンクがクリップボードにコピーされました!
aodh を使用して、しきい値に達した時にアクティブになるアラームを作成することができます。以下の例では、個々のインスタンスの平均 CPU 使用率が 80% を超えると、アラームがアクティブになりログエントリーが追加されます。監視目的で、クエリーを使用して特定インスタンスの ID (94619081-abf5-4f1f-81c7-9cedaa872403) を分離します。
既存のアラームのしきい値を編集するには、aodh alarm update コマンドを使用します。たとえば、アラームのしきい値を 75% に増やすには、以下のコマンドを実行します。
aodh alarm update --name cpu_usage_high --threshold 75
# aodh alarm update --name cpu_usage_high --threshold 75
3.10.6. アラームの無効化または削除 リンクのコピーリンクがクリップボードにコピーされました!
アラームを無効にするには、以下のコマンドを実行します。
aodh alarm update --name cpu_usage_high --enabled=false
# aodh alarm update --name cpu_usage_high --enabled=false
アラームを削除するには、以下のコマンドを実行します。
aodh alarm delete --name cpu_usage_high
# aodh alarm delete --name cpu_usage_high
3.10.7. 例: インスタンスのディスク動作のモニタリング リンクのコピーリンクがクリップボードにコピーされました!
aodh アラームを使用して、特定のプロジェクトに含まれるすべてのインスタンスの漸増するディスク動作を監視する方法を、以下の例で説明します。
1. 既存のプロジェクトを確認し、監視するプロジェクトの適切な UUID を選択します。以下の例では、admin プロジェクトを使用します。
2. プロジェクトの UUID を使用して、admin プロジェクト内のインスタンスが生成するすべての読み取りリクエストの sum() を解析するアラームを作成します (--query パラメーターを使用して、クエリーにさらに制限を設けることができます)。
3.10.8. 例: CPU 使用率のモニタリング リンクのコピーリンクがクリップボードにコピーされました!
インスタンスのパフォーマンスを監視する場合、gnocchi データベースを調べ、メモリーや CPU の使用状況などのモニタリング可能なメトリックを特定します。たとえば、インスタンスに対して gnocchi resource show を実行して、モニタリング可能なメトリックを特定します。
特定のインスタンスの UUID に対して利用できるメトリックのクエリーを行います。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力結果の
metricsの値に、Aodh アラームを使用して監視可能なコンポーネントがリスト表示されます (例:cpu_util)。CPU の使用状況を監視するには、
cpu_utilメトリックが必要です。このメトリックの詳細を表示するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
archive_policy:std、count、min、max、sum、meanの値を計算する際の集約間隔を定義します。
-
Aodh を使用して、
cpu_utilをクエリーするモニタリングタスクを作成します。このタスクは、指定した設定に基づいてイベントをトリガーします。たとえば、インスタンスの CPU 使用率が上昇し一定期間 80% を超える場合にログエントリーを生成するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
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 など)。
-
アラームがトリガーされているかどうかを確認するには、アラーム履歴にクエリーを行います。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.10.9. リソース種別の管理 リンクのコピーリンクがクリップボードにコピーされました!
従来ハードコードされていた Telemetry リソース種別が、gnocchi クライアントによって管理できるようになりました。gnocchi クライアントを使用して、リソース種別を作成、表示、削除することができ、gnocchi API を使用して属性を更新または削除することができます。
1. 新しい リソース種別 を作成します。
2. リソース種別 の設定を確認します。
3. リソース種別 を削除します。
gnocchi resource-type delete testResource01
$ gnocchi resource-type delete testResource01
リソースが使用中のリソース種別を削除することはできません。
第4章 トラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
本章では、Red Hat OpenStack Platform デプロイメントのトラブルシューティングに役立つログ記録およびサポート情報について記載します。
4.1. Support リンクのコピーリンクがクリップボードにコピーされました!
クライアントコマンドが失敗したり、他の問題が発生した場合は、発生した問題、完全なコンソール出力、コンソール出力で参照されているすべてのログファイル、問題のある (またはその可能性がある) ノードの 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)
Unable to communicate with identity service: [Errno 113] No route to host. (HTTP 400)
この問題をデバッグするには、以下に挙げる一般的な原因を確認してください。
- Identity サービスが稼働していない
Identity サービスは httpd.service 内で実行されるようになりましたIdentity サービスをホストしているシステム上で、サービスのステータスを確認します。
systemctl status httpd.service
# systemctl status httpd.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスがアクティブでない場合には、root ユーザーとしてログインしてサービスを起動します。
systemctl start httpd.service
# systemctl start httpd.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイアウォールが適切に設定されていない
-
ポート
5000および35357の TCP トラフィックを許可するようにファイアウォールが設定されていない可能性があります。その場合は、オーバークラウドの高度なカスタマイズのオーバークラウドのファイアウォールの管理に記載の手順を参照して、ファイアウォール設定の確認およびカスタムルールの定義を行います。 - サービスエンドポイントが正しく定義されていない
Identity サービスをホストするシステムで、エンドポイントが正しく定義されていることを確認します。
管理トークンを取得します。
grep admin_token /etc/keystone/keystone.conf admin_token = 91f0866234a64fc299db8f26f8729488
# grep admin_token /etc/keystone/keystone.conf admin_token = 91f0866234a64fc299db8f26f8729488Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity サービスの正しい管理エンドポイントを決定します。
http://IP:35357/VERSION
http://IP:35357/VERSIONCopy to Clipboard Copied! Toggle word wrap Toggle overflow IP を、Identity サービスをホストしているシステムの IP アドレスまたはホスト名に置き換えます。VERSION を、使用中の API バージョン (
v2.0またはv3) に置き換えます。事前に定義されている Identity サービス関連の環境変数の設定を解除します。
unset OS_USERNAME OS_TENANT_NAME OS_PASSWORD OS_AUTH_URL
# unset OS_USERNAME OS_TENANT_NAME OS_PASSWORD OS_AUTH_URLCopy to Clipboard Copied! Toggle word wrap Toggle overflow 管理トークンとエンドポイントを使用して、Identity サービスとの認証を行います。Identity サービスのエンドポイントが正しいことを確認してください。以下に例を示します。
openstack endpoint list --os-token=91f0556234a64fc299db8f26f8729488 --os-url=https://osp.lab.local:35357/v3/ --os-identity-api-version 3
# openstack endpoint list --os-token=91f0556234a64fc299db8f26f8729488 --os-url=https://osp.lab.local:35357/v3/ --os-identity-api-version 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow リスト表示された 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
# openstack endpoint delete 2d32fa6feecc49aab5de538bdf7aa018 --os-token=91f0866234a64fc299db8f26f8729488 --os-url=https://osp.lab.local:35357/v3/ --os-identity-api-version 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
# tcpdump -n -i INTERFACE -e -w FILENAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow INTERFACE を、パケットが通過できない箇所を確認するネットワークインターフェイスの名前に置き換えます。このインターフェイス名には、ブリッジまたはホストのイーサネットデバイスの名前を使用することができます。
-eフラグにより、リンクレベルのヘッダー (vlanタグが表示される) がダンプされます。-wフラグはオプションです。このフラグは、出力をファイルに書き込む場合にのみ使用することができます。そうでない場合には、出力は標準出力 (stdout) に書き込まれます。tcpdumpについての詳細は、man tcpdumpコマンドで man ページを開いて参照してください。
- ネットワーク名前空間のデバッグ
-
ip netns listコマンドで、既知のネットワーク名前空間をすべてリスト表示します。 ip netns execコマンドで、特定の名前空間内のルーティングテーブルを表示します。ip netns exec NAMESPACE_ID bash route -n
# ip netns exec NAMESPACE_ID bash # route -nCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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 では、以下の設定を追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 同じファイルで、SESSION_ENGINE を以下に変更します。
SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'
SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'Copy to Clipboard Copied! Toggle word wrap Toggle overflow mysql コマンドを使用してデータベースサービスに接続します。USER は、接続に使用するユーザー名に置き換えます。また、USER は root ユーザー (あるいは、少なくとも正しい権限 create db を持つユーザー) でなければなりません。
mysql -u USER -p
# mysql -u USER -pCopy to Clipboard Copied! Toggle word wrap Toggle overflow Horizon データベースを作成します。
mysql > create database horizondb;
mysql > create database horizondb;Copy to Clipboard Copied! Toggle word wrap Toggle overflow mysql クライアントを終了します。
mysql > exit
mysql > exitCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドで、openstack_dashboard ディレクトリーに移動して、データベースを同期します。
cd /usr/share/openstack-dashboard/openstack_dashboard ./manage.py syncdb
# cd /usr/share/openstack-dashboard/openstack_dashboard $ ./manage.py syncdbCopy to Clipboard Copied! Toggle word wrap Toggle overflow スーパーユーザーを作成する必要はないため、質問には n と回答します。
Apache http サーバーを再起動します。Red Hat Enterprise Linux の場合は以下のコマンドを実行します。
systemctl restart httpd
# systemctl restart httpdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 カスタマーポータルにログインする必要があります。
ログインされていない場合には、以下の手順でログインしてください。
- Log In をクリックします。
- Red Hat のログイン情報を入力します。
- Red Hat パスワードを入力します。
- Sign in をクリックします。
フォームは以下のとおりです。
図4.2 Red Hat カスタマーポータルへのログイン
この時点でログインしないと、認証が必要な機能の 1 つを使用する際に Red Hat ログインとパスワードが要求されます。
4.6.1.1. 検索 リンクのコピーリンクがクリップボードにコピーされました!
1 つまたは複数の検索キーワードを入力して、Red Hat カスタマーポータルからの記事やソリューションを検索できます。関連の記事やソリューションのタイトルが表示されます。タイトルをクリックして、指定の記事またはソリューションを表示します。
図4.3 Red Hat Access タブの検索結果の例
4.6.1.2. ログ リンクのコピーリンクがクリップボードにコピーされました!
ここから、OpenStack インスタンスからのログを確認することができます。
図4.4 Red Hat Access タブでのインスタンスのログ
表で必要なインスタンスを探します。インスタンスが多数ある場合は、名前、ステータス、イメージ ID、またはフレーバー ID で絞り込むことができます。確認するインスタンスの Actions 欄で、View Log をクリックします。
インスタンスのログが表示されたら、Red Hat Diagnose をクリックして、コンテンツに関連した提案ソリューションを取得することができます。
図4.5 Red Hat Access タブでのインスタンスのログ
提案されたソリューションで役に立つものがない場合や、問題が正しくロギングされている場合には、サポートケースを新規作成 をクリックして、問題を Red Hat サポートに報告してください。
4.6.1.3. サポート リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Access タブの最後のオプションでは、Red Hat カスタマーポータルのサポートケースを検索することができます。
図4.6 サポートケースの検索
また、適切なボタンをクリックして、以下のページでフォームに入力して新規サポートケースを開くことも可能です。
図4.7 サポートケースの新規作成