ロギング、モニタリング、およびトラブルシューティングガイド
OpenStack のロギング、モニタリング、およびトラブルシューティングの詳細ガイド
概要
第1章 本ガイドについて リンクのコピーリンクがクリップボードにコピーされました!
現在 Red Hat では、本リリース用の本ガイドに記載されている情報および手順の見直しを行っています。
本書は、製品ドキュメント から利用可能な Red Hat OpenStack Platform 12 のドキュメントをベースにしています。
現在の Red Hat OpenStack Platform リリース用にサポートが必要な場合は、Red Hat サポートにお問い合わせください。
本書では、Red Hat OpenStack Platform 環境で利用可能なロギングおよびモニタリング機能の概要、ならびに発生する可能性のある問題のトラブルシューティング方法について説明します。
第2章 ロギング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform は、情報メッセージを特定のログファイルに書き込みます。これらのメッセージをトラブルシューティングおよびシステムイベントの監視に使用できます。
個々のログファイルをサポートケースに手動で添付する必要はありません。必要な情報はすべて、sosreport ユーティリティーにより自動的に収集されます。これは、5章トラブルシューティング で説明されています。
2.1. OpenStack サービスのログファイル リンクのコピーリンクがクリップボードにコピーされました!
それぞれの OpenStack コンポーネントには、実行中のサービス固有のファイルが含まれる個別のログディレクトリーがあります。
2.1.1. Bare Metal Provisioning (ironic) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| 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.1.2. Block Storage (cinder) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| 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.1.3. Compute (nova) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| 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.1.4. Dashboard (horizon) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| 特定ユーザーの対話のログ | 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 |
また、/var/log/containers/httpd/default_error.log も用意されています。これは、同じホストで実行している他の Web サービスが報告するエラーを保存します。
2.1.5. Database as a Service (trove) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| OpenStack Trove API サービス | openstack-trove-api.service | /var/log/containers/trove/trove-api.log |
| OpenStack Trove Conductor サービス | openstack-trove-conductor.service | /var/log/containers/trove/trove-conductor.log |
| OpenStack Trove ゲストエージェントサービス | openstack-trove-guestagent.service | /var/log/containers/trove/logfile.txt |
| OpenStack Trove タスクマネージャーサービス | openstack-trove-taskmanager.service | /var/log/containers/trove/trove-taskmanager.log |
2.1.6. Identity サービス (keystone) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| OpenStack Identity サービス | openstack-keystone.service | /var/log/containers/keystone/keystone.log |
2.1.7. Image サービス (glance) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| 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.1.8. Networking (neutron) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| 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.1.9. 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.1.10. Orchestration (heat) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| 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.1.12. Telemetry (ceilometer) のログファイル リンクのコピーリンクがクリップボードにコピーされました!
| Service | サービス名 | ログのパス |
|---|---|---|
| OpenStack ceilometer 通知エージェント | openstack-ceilometer-notification.service | /var/log/containers/ceilometer/agent-notification.log |
| OpenStack ceilometer アラーム評価 | openstack-ceilometer-alarm-evaluator.service | /var/log/containers/ceilometer/alarm-evaluator.log |
| OpenStack ceilometer アラーム通知 | openstack-ceilometer-alarm-notifier.service | /var/log/containers/ceilometer/alarm-notifier.log |
| OpenStack ceilometer API | httpd.service | /var/log/containers/ceilometer/api.log |
| 情報メッセージ | MongoDB インテグレーション | /var/log/containers/ceilometer/ceilometer-dbsync.log |
| OpenStack ceilometer 中央エージェント | openstack-ceilometer-central.service | /var/log/containers/ceilometer/central.log |
| OpenStack ceilometer コレクション | openstack-ceilometer-collector.service | /var/log/containers/ceilometer/collector.log |
| OpenStack ceilometer コンピュートエージェント | openstack-ceilometer-compute.service | /var/log/containers/ceilometer/compute.log |
2.1.13. サポートサービスのログファイル リンクのコピーリンクがクリップボードにコピーされました!
以下のサービスは OpenStack のコアコンポーネントにより使用され、独自のログディレクトリーおよびファイルを持ちます。
| Service | サービス名 | ログのパス |
|---|---|---|
| メッセージブローカー (RabbitMQ) | rabbitmq-server.service |
/var/log/rabbitmq/rabbit@short_hostname.log |
| データベースサーバー (MariaDB) | mariadb.service | /var/log/mariadb/mariadb.log |
| ドキュメント指向データベース (MongoDB) | mongod.service | /var/log/mongodb/mongodb.log |
| 仮想ネットワークスイッチ (Open vSwitch) | openvswitch-nonetwork.service |
/var/log/openvswitch/ovsdb-server.log |
2.2. デプロイメント時の集中ロギングの有効化 リンクのコピーリンクがクリップボードにコピーされました!
集中ロギングを有効にするには、OS::TripleO::Services::Rsyslog コンポーザブルサービスの実装を指定します。以下の例のように、ロギング環境ファイルのファイルパスをオーバークラウドデプロイメントコマンドに追加します。
openstack overcloud deploy <other arguments> -e /usr/share/openstack-tripleo-heat-templates/environments/logging-environment-rsyslog.yaml
openstack overcloud deploy <other arguments>
-e /usr/share/openstack-tripleo-heat-templates/environments/logging-environment-rsyslog.yaml
2.3. ロギング機能の設定 リンクのコピーリンクがクリップボードにコピーされました!
ロギング機能を設定するには、logging-environment-rsyslog.yaml ファイルの RsyslogElasticsearchSetting パラメーターを変更します。
-
tripleo-heat-templates/environments/logging-environment-rsyslog.yamlファイルをホームディレクトリーにコピーします。 -
実際の環境に合わせて
RsyslogElasticsearchSettingパラメーターのエントリーを作成します。RsyslogElasticsearchSettingパラメーターの設定例を以下のスニペットに示します。
parameter_defaults:
RsyslogElasticsearchSetting:
server: "exampleip:9200"
usehttps: "on"
parameter_defaults:
RsyslogElasticsearchSetting:
server: "exampleip:9200"
usehttps: "on"
RsyslogElasticsearchTls パラメーターを設定して、セキュアなデータ転送を有効にすることができます。詳細は、「「設定可能なパラメーター」」を参照してください。
2.3.1. 設定可能なパラメーター リンクのコピーリンクがクリップボードにコピーされました!
設定可能なパラメーターの説明を以下の表にまとめます。これらのパラメーターは 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.log
NovaComputeLoggingSource:
tag: openstack.nova.compute
file: /some/other/path/nova-compute.log
tag および path 属性は、<service_name>LoggingSource パラメーターの必須の要素です。それぞれのサービスで tag および path が定義され、残りの値はデフォルトで派生されます。以下のスニペットは、デフォルトのログファイルパスを上書きする別の例です。
ServiceLoggingSource:
tag: openstack.Service
file: /another/path/service/service.log
startmsg.regex: "^[a-zA-Z]{3} [0-9]{2} [:0-9]{8}"
ServiceLoggingSource:
tag: openstack.Service
file: /another/path/service/service.log
startmsg.regex: "^[a-zA-Z]{3} [0-9]{2} [:0-9]{8}"
2.5. ロギングオプションの設定 リンクのコピーリンクがクリップボードにコピーされました!
各コンポーネントは、コンポーネントの設定ファイルに個別のロギング設定を維持します。たとえば、Compute では、以下のオプションは /etc/nova/nova.conf で設定されます。
情報ロギングのレベルを増やすには、デバッグを有効にします。このオプションはキャプチャーされた情報の量を増やすため、一時的に使用する場合や、最初にログローテーションの設定を確認することを検討してください。
debug=True
debug=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細ロギングを有効化します。
verbose=True
verbose=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow ログファイルのパスを変更します。
log_dir=/var/log/containers/nova
log_dir=/var/log/containers/novaCopy to Clipboard Copied! Toggle word wrap Toggle overflow ログを中央の syslog サーバーに送信します。
use_syslog=True syslog_log_facility=LOG_USER
use_syslog=True syslog_log_facility=LOG_USERCopy to Clipboard Copied! Toggle word wrap Toggle overflow
ログのタイムスタンプおよび形式を設定することもできます。追加のロギングオプションについては、コンポーネントの設定ファイルを確認してください。
2.6. 接続のテスト リンクのコピーリンクがクリップボードにコピーされました!
クライアント側で 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 を変更する必要があります。
第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'"
第4章 Telemetry サービスを使用した容量のメータリング リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Telemetry サービスには、請求、チャージバック、およびショウバックの目的に使用できる使用状況のメトリックが用意されています。このようなメトリックデータをサードパーティーアプリケーションで処理してクラスター容量の計画を作成したり、OpenStack heat を使用した仮想インスタンスの自動スケーリングに活用したりすることもできます。詳細は、「 Auto Scaling for Instances 」を参照してください。
モニタリングおよびアラーム用に、ceilometer と gnocchi の組み合わせを使用することができます。この構成は小規模のクラスターでサポートされ、既知の制限が存在します。リアルタイムモニタリング用に、Red Hat OpenStack Platform にはメトリックデータを提供するエージェントが同梱されており、このデータを別のモニタリングインフラストラクチャーおよびアプリケーションで処理することができます。詳細は、「 監視ツールの設定 」を参照してください。
4.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 です。
4.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
4.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
4.4. 例: L3 キャッシュの使用状況の表示 リンクのコピーリンクがクリップボードにコピーされました!
お使いの Intel ハードウェアおよび libvirt のバージョンが Cache Monitoring Technology (CMT)に対応している場合は、cpu_l3_cache メーターを使用して、インスタンスが使用する L3 キャッシュの量を監視することができます。
L3 キャッシュを監視するには、以下の項目が必要です。
-
LibvirtEnabledPerfEventsパラメーターのcmt。 -
gnocchi_resources.yamlファイルのcpu_l3_cache。 -
Ceilometer
polling.yamlファイルのcpu_l3_cache。
L3 キャッシュモニタリングの有効化
L3 キャッシュのモニタリングを有効にするには、以下の手順を実施します。
Telemetry の YAML ファイルを作成し(
ceilometer-environment.yamlなど)、LibvirtEnabledPerfEventsパラメーターにcmtを追加します。parameter_defaults: LibvirtEnabledPerfEvents: cmtparameter_defaults: LibvirtEnabledPerfEvents: cmtCopy to Clipboard Copied! Toggle word wrap Toggle overflow この YAML ファイルを使用してオーバークラウドをデプロイします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンピュートノード上の gnocchi で
cpu_l3_cacheが有効になっていることを確認します。sudo -i podman exec -ti ceilometer_agent_compute cat /etc/ceilometer/gnocchi_resources.yaml | grep cpu_l3_cache
$ sudo -i # podman exec -ti ceilometer_agent_compute cat /etc/ceilometer/gnocchi_resources.yaml | grep cpu_l3_cacheCopy to Clipboard Copied! Toggle word wrap Toggle overflow Telemetry のポーリングについて
cpu_l3_cacheが有効になっていることを確認します。podman exec -ti ceilometer_agent_compute cat /etc/ceilometer/polling.yaml | grep cpu_l3_cache
# podman exec -ti ceilometer_agent_compute cat /etc/ceilometer/polling.yaml | grep cpu_l3_cacheCopy to Clipboard Copied! Toggle word wrap Toggle overflow cpu_l3_cacheが Telemetry に対して有効にされていない場合は、これを有効にしてサービスを再起動します。podman exec -ti ceilometer_agent_compute echo " - cpu_l3_cache" >> /etc/ceilometer/polling.yaml podman exec -ti ceilometer_agent_compute pkill -HUP -f "ceilometer.*master process"
# podman exec -ti ceilometer_agent_compute echo " - cpu_l3_cache" >> /etc/ceilometer/polling.yaml # podman exec -ti ceilometer_agent_compute pkill -HUP -f "ceilometer.*master process"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この podman の変更は、リブート後に維持されません。
このコンピュートノードでゲストインスタンスを起動したら、gnocchi measures show コマンドを使用して CMT メトリックを監視することができます。
4.5. 既存のアラームの表示 リンクのコピーリンクがクリップボードにコピーされました!
既存の Telemetry アラームを一覧表示するには、aodh コマンドを使用します。以下に例を示します。
リソースに割り当てた計測値を一覧表示するには、リソース (インスタンス、イメージ、ボリューム等) の UUID を指定します。以下に例を示します。
gnocchi resource show 5e3fcbe2-7aab-475d-b42c-a440aa42e5ad
# gnocchi resource show 5e3fcbe2-7aab-475d-b42c-a440aa42e5ad
4.6. アラームの作成 リンクのコピーリンクがクリップボードにコピーされました!
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
4.7. アラームの無効化または削除 リンクのコピーリンクがクリップボードにコピーされました!
アラームを無効にするには、以下のコマンドを実行します。
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
4.8. 例: インスタンスのディスク動作のモニタリング リンクのコピーリンクがクリップボードにコピーされました!
aodh アラームを使用して、特定のプロジェクトに含まれるすべてのインスタンスの漸増するディスク動作を監視する方法を、以下の例で説明します。
1. 既存のプロジェクトを確認し、監視するプロジェクトの適切な UUID を選択します。以下の例では、admin プロジェクトを使用します。
2. プロジェクトの UUID を使用して、admin プロジェクト内のインスタンスが生成するすべての読み取りリクエストの sum() を解析するアラームを作成します(--queryパラメーターを使用して、クエリーにさらに制限を設けることができます)。
4.9. 例: 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
4.10. リソース種別の管理 リンクのコピーリンクがクリップボードにコピーされました!
従来ハードコードされていた Telemetry リソース種別が、gnocchi クライアントによって管理できるようになりました。gnocchi クライアントを使用して、リソース種別を作成、表示、削除することができ、gnocchi API を使用して属性を更新または削除することができます。
1. 新しい リソース種別 を作成します。
2. リソース種別 の設定を確認します。
3. リソース種別 を削除します。
gnocchi resource-type delete testResource01
$ gnocchi resource-type delete testResource01
リソースが使用中のリソース種別を削除することはできません。
第5章 トラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
本章では、Red Hat OpenStack Platform デプロイメントのトラブルシューティングに役立つログ記録およびサポート情報について記載します。
5.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 ファイルでヒントがないか確認もしてください。
5.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に置き換えます。
5.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コマンドを実行しなくても呼び出されるようにします。
-
5.4. ダッシュボードのネットワークまたはルータータブの表示に関する問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Networking を使用するように環境が設定されている場合にのみ、Dashboard に ネットワーク および ルーター タブが表示されます。現在、デフォルトでは、Packstack ユーティリティーによって nova ネットワークがデプロイされるため、この方法でデプロイされた環境には、これらのタブは表示されない点に特に注意してください。
OpenStack Networking が環境にデプロイされているにもかかわらずタブが表示されない場合には、Identity サービスでサービスエンドポイントが正しく定義されて、ファイアウォールがそのエンドポイントへのアクセスを許可し、サービスが稼働していることを確認してください。
5.5. Dashboard でのインスタンス起動エラーに関するトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
ダッシュボードを使用してインスタンスを起動する際、操作が失敗すると、一般的な ERROR メッセージが表示されます。実際の原因を究明するには、コマンドラインツールを使用する必要があります。
nova list コマンドを使用して、インスタンスの一意識別子を確認します。続いて、この識別子を nova show コマンドの引数として使用します。返される項目のいずれかがエラー条件になります。もっとも一般的な値は NoValidHost です。
このエラーは、インスタンスをホストするのに十分なリソースが利用できる有効なホストがないことを示しています。この問題を回避するには、より小さなインスタンスサイズを選択するか、その環境のオーバーコミットの上限を高くする方法を検討してください。
インスタンスをホストするには、コンピュートノードで CPU および RAM リソースが使用可能なだけでなく、インスタンスに関連付けられる一時ストレージ用に十分なディスク領域を持つ必要もあります。
5.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
5.7. OpenStack Dashboard: Red Hat Access タブ リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Access タブ (OpenStack Dashboard の一部) では、Red Hat カスタマーポータルの記事やソリューションの検索、表示、インスタンスからのログの表示や診断、カスタマーサポートケースの操作を行うことができます。
図5.1 Red Hat Access タブ
Red Hat Acesss タブの機能を使用するには、ブラウザーで Red Hat カスタマーポータルにログインする必要があります。
ログインされていない場合には、以下の手順でログインしてください。
- ログイン をクリックします。
- Red Hat のログイン情報を入力します。
- Red Hat パスワードを入力します。
- サインイン をクリックします。
フォームは以下のとおりです。
図5.2 Red Hat カスタマーポータルへのログイン
この時点でログインしないと、認証が必要な機能の 1 つを使用する際に Red Hat ログインとパスワードが要求されます。
5.7.1. 検索 リンクのコピーリンクがクリップボードにコピーされました!
1 つまたは複数の検索キーワードを入力して、Red Hat カスタマーポータルからの記事やソリューションを検索できます。関連の記事やソリューションのタイトルが表示されます。タイトルをクリックして、指定の記事またはソリューションを表示します。
図5.3 Red Hat Access タブの検索結果の例
5.7.2. ログ リンクのコピーリンクがクリップボードにコピーされました!
ここから、OpenStack インスタンスからのログを確認することができます。
図5.4 Red Hat Access タブでのインスタンスのログ
表で必要なインスタンスを探します。インスタンスが多数ある場合は、名前、ステータス、イメージ ID、またはフレーバー ID で絞り込むことができます。確認するインスタンスの アクション 欄で、ログの参照 をクリックします。
インスタンスのログが表示されたら、Red Hat 診断 をクリックして、コンテンツに関連した提案ソリューションを取得することができます。
図5.5 Red Hat Access タブでのインスタンスのログ
提案されたソリューションで役に立つものがない場合や、問題が正しくロギングされている場合には、サポートケースを新規作成 をクリックして、問題を Red Hat サポートに報告してください。
5.7.3. サポート リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Access タブの最後のオプションでは、Red Hat カスタマーポータルのサポートケースを検索することができます。
図5.6 サポートケースの検索
また、適切なボタンをクリックして、以下のページでフォームに入力して新規サポートケースを開くことも可能です。
図5.7 サポートケースの新規作成