OpenStack のコンポーネントごとに、実行サービス固有のファイルを含む個別のロギングディレクトリーがあります。

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

コンポーネントごとに、別のロギング設定が適切な設定ファイルに保管されています。たとえば、Compute ではこれらのオプションは /etc/nova/nova.conf に設定されます。

既存の 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

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

アラームを無効にするには、以下のコマンドを使用します。

# aodh alarm update --name cpu_usage_high --enabled=false

アラームを削除するには、以下のコマンドを使用します。

# aodh alarm delete --name cpu_usage_high

特定のリソースの測定をすべて表示するには、以下のコマンドを使用します。

# gnocchi measures show --resource-id UUID METER_NAME

タイムスタンプの範囲内における特定のリソースの測定のみを表示するには以下のコマンドを使用します。

# gnocchi measures show --aggregation mean --start START_TIME --end STOP_TIME --resource-id UUID METER_NAME

START_TIME および END_TIME は iso-dateThh:mm:ss の形式で指定してください。

測定を使用して、Telemetry サービスにデータを送信することができます。以前に定義した計測と一致する必要はありません。以下に例を示します。

# gnocchi measures add -m 2015-01-12T17:56:23@42 --resource-id UUID METER_NAME

以下の例では、各プロジェクトの全インスタンスの平均メモリー使用状況を表示します。

gnocchi measures aggregation --resource-type instance --groupby project_id -m memory

Intel ハードウェアと libvirt バージョンが キャッシュモニタリングテクノロジー (CMT) をサポートする場合には、cpu_l3_cache の計測を使用して、インスタンスが使用する L3 キャッシュの量を監視することができます。

以下の例では、aodm アラームを使用して、特定のプロジェクトに含まれる全インスタンスの累積ディスクアクティビティーを監視する方法を紹介します。

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                          |
+---------------------------+-----------------------------------------------------------+

以前にハードコードされている Telemetry リソースタイプは、gnocchi クライアントで管理することができます。gnocchi クライアントを使用して、リソースタイプを作成、表示、削除することができ、gnocchi API を使用して属性を更新または削除することができます。

1. 新しい resource-type を作成します。

$ 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. resource-type の設定をレビューします。

$ gnocchi resource-type show testResource01
+----------------+------------------------------------------------------------+
| Field          | Value                                                      |
+----------------+------------------------------------------------------------+
| attributes/bla | max_length=255, min_length=123, required=True, type=string |
| name           | testResource01                                             |
| state          | active                                                     |
+----------------+------------------------------------------------------------+

3. resource-type を削除します。

$ gnocchi resource-type delete testResource01

Time-Series-Database-as-a-Service (gnocchi) はマルチテナントのメトリックおよびリソースのデータベースです。大規模なメトリックを格納する一方でオペレーターやユーザーにメトリックおよびリソースの情報へのアクセスを提供します。

現在、TSDaaS は認証に Identity サービスを、データの保存に Ceph と Object Storage を使用します。

TDSaaS は statsd プロトコルと互換性のある statsd デーモンを提供し、gnocchi-statsd と呼ばれるネットワークで送信されるメトリックをリッスンすることができます。TDSaaS での statsd サポートを有効化するには、設定ファイルで [statsd] オプションを設定する必要があります。リソース ID パラメーターは、全メトリックがアタッチされる主要な一般リソース、リソースとメトリックに関連付けられるユーザーとプロジェクト ID、メトリックの作成に使用するアーカイブポリシー名として使用されます。

メトリックは gnocchi-statsd に送信されるため、すべてのメトリックは動的に作成され、指定の名前を設定したリソース ID にアタッチします。TSDaaS のインストールおよび設定に関する詳しい情報は、https://access.redhat.com/documentation/ja/red-hat-enterprise-linux-openstack-platform/ から『手動インストール手順』の「Time-Series-Database-as-a-サービスのインストール」の章を参照してください。

# gnocchi-api
# gnocchi-metricd

クライアントコマンドが失敗した場合には、Red Hat テクニカルサポートまでご連絡ください。その際には、発生した問題についての状況説明、コンソールの全出力、およびコンソールの出力で参照されているすべてのログファイル、問題のある (可能性のある) ノードからの sosreport を提供してください。たとえば、コンピュートレベルで問題が発生した場合には Nova ノードで sosreport を実行します。ネットワークの問題の場合は、Neutron ノードでユーティリティーを実行します。一般的なデプロイメントの問題の場合は、クラウドコントローラー上で sosreport を実行するのがベストです。

sosreport コマンド (sos パッケージ) についての情報は、「Red Hat Enterprise Linux 4.6 以降における sosreport の役割と取得方法」の記事を参照してください。

ヒントについては /var/log/messages ファイルも確認します。

Identity クライアント (keystone) が Identity サービスにコンタクトできない場合には、次のようなエラーが返されます。

Unable to communicate with identity service: [Errno 113] No route to host. (HTTP 400)

この問題をデバッグするには、以下にあげる一般的な原因を確認してください。

本項では、OpenStack Networking サービスに関する問題のトラブルシューティングに使用することができるさまざまなコマンドと手順について説明します。

Networks および Routers のタブは、OpenStack Networking を使用するように環境が設定されている場合にのみ表示されます。現在、デフォルトでは、Packstack ユーティリティーによって Nova ネットワークがデプロイされるため、この方法でデプロイされた環境には、これらのタブは表示されない点に特に注意してください。

OpenStack Networking が環境にデプロイされているにもかかわらずタブが表示されない場合には、Identity サービスでサービスエンドポイントが正しく定義されて、ファイアウォールがそのエンドポイントへのアクセスを許可し、サービスが稼働していることを確認してください。

ダッシュボードを使用したインスタンス起動時に操作が失敗した場合には、汎用の ERROR メッセージが表示されます。実際の原因を究明するには、コマンドラインツールを使用する必要があります。

nova list でインスタンスの一意識別子を確認します。次にその識別子を nova show コマンドの引数として使用します。返される項目の 1 つがエラー条件となります。最も一般的な値は NoValidHost です。

このエラーは、インスタンスをホストするのに十分なリソースが利用できる有効なホストがないことを示しています。この問題を回避するには、より小さなインスタンスサイズを選択するか、その環境のオーバーコミットの上限を高くする方法を検討してください。

django_openstack_auth は、Django の contrib.auth フレームワークと連携する、プラグ可能な Django 認証バックエンドで、OpenStack Identity サービス API に対してユーザー認証を行います。Django_openstack_auth は、トークンオブジェクトを使用して、ユーザーおよび Keystone 関連の情報をカプセル化し、Dashboard は、トークンオブジェクトを使用して Django ユーザーオブジェクトを再構築します。

現在、トークンオブジェクトは以下を格納します。

Dashboard は、ユーザーセッションデータの処理に Django のセッションフレームワークを使用します。以下は、利用可能な各種セッションバックエンド一覧です。これらは、local_settings.py ファイルの SESSION_ENGINE 設定で制御されます。

特に署名付きクッキーのセッションバックエンドが使用されている場合、多数またはすべてのサービスが一度に有効化された場合など、クッキーのサイズが制限に到達して、Dashboard へのログインに失敗する可能性があります。クッキーサイズが増加する理由の 1 つとして、サービスカタログが挙げられます。多くのサービスが登録されるにつれ、サービスカタログのサイズも増加します。

このようなシナリオでは (特に keystone v3 認証を使用している場合)、セッショントークン管理を向上するため、Dashboard へログインするための以下の設定を含めてください。

Red Hat Access タブ (OpenStack Dashboard の一部) では、Red Hat カスタマーポータルから記事やソリューションの検索、確認、インスタンスからのログ表示や診断、カスタマーサポートケースの対応ができます。

図4.1 Red Hat Access タブ

ログインされていない場合には、以下の手順でログインしてください。

フォームは以下のとおりです。

図4.2 Red Hat カスタマーポータルへのログイン

この時点でログインしないと、認証が必要な機能の 1 つを使用する際に Red Hat ログインとパスワードが要求されます。

4.7.1. 検索

1 つまたは複数の検索キーワードを入力して、Red Hat カスタマーポータルからの記事やソリューションを検索できます。関連の記事やソリューションのタイトルが表示されます。タイトルをクリックして、指定の記事またはソリューションを表示します。

図4.3 Red Hat Access タブの検索結果の例

4.7.2. ログ

ここから、OpenStack インスタンスからのログを確認することができます。

図4.4 Red Hat Access タブでのインスタンスのログ

表から希望のインスタンスを検索します。多数のインスタンスがある場合には、名前、状態、イメージ ID、フレーバー ID 別にフィルタリングすることができます。チェックするインスタンスの アクション の欄で ログの表示 をクリックします。

インスタンスのログが表示されたら、Red Hat 診断 をクリックして、コンテンツに関連した提案ソリューションを取得することができます。

図4.5 Red Hat Access タブでのインスタンスのログ

提案されたソリューションで役に立つものがない場合や、問題が正しくロギングされていない場合には、サポートケースを新規作成 をクリックして、問題を Red Hat サポートに報告してください。

4.7.3. サポート

Red Hat Access タブの最後のオプションでは、Red Hat カスタマーポータルのサポートケースを検索することができます。

図4.6 サポートケースの検索

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

図4.7 サポートケースの新規作成