Cloud Insight のトラブルシューティング

Classic/VPC環境で利用できます。

Cloud Insightのトラブルシューティングでは、Cloud Insightを使用する際にユーザーが遭遇しかねない問題状況と解決方法を説明します。

Cloud Insightのトラブルシューティングで説明できなかった場合や、当該ガイドを熟知しても解決が難しい場合は次の方法で問題を確認するか、解決方法をお問い合わせください。

• よくある質問
• お問い合わせ

Q. サーバの Hangが発生して Metricが収集できず、通知も届きません。

A. サーバの Hangが発生すると、Agentが CPUの割り当てを受けられなくなるため、動作しません。Hangの発生原因のプロセスが Hang状態を自ら解除するか、そのプロセスを強制終了させるまで問題が続くことがあります。もしサーバに何も入力できない場合、サーバを強制的に再起動することもご検討ください。サーバが Hang、Agent、ネットワークイシューなどで正常に動作しない場合、Server(Classic)または Server(VPC)の agent_status Metricを使用してご確認ください。

Q. Server(VPC)の is_process_upでモニタリング中ですが、異常がないのに Eventが発生します。

A. Plugin Processの is_process_upデータは、ユーザーが登録した process nameの PIDが新規作成するときに収集されます。asterisk(*)を含めて process nameを登録すると、一致するすべてのプロセスの PIDリストが対象になります。

is_process_upが変動する条件は次の通りです。

• is_process_up = 1: PIDリストが維持されるか新しい PIDが追加される場合
• is_process_up = 0: PIDリストのうち、一部または全体がなくなる場合

そのため、以下のような場合は Mainプロセスが正常であっても is_process_upが0になる場合があります。

• Mainプロセスの Subプロセスが一時的に作成された後、削除された場合
• Mainプロセスの Subプロセスが一時的に削除された後、作成された場合
• Mainプロセスの Subプロセスが減った場合

例) process nameで *httpd*を登録した場合、時間による PIDの変化と is_process_up / process_countのメトリック値

一般的に*httpd*のような process nameをモニタリングする理由は、apacheサービスの正常性を判断するためです。
このような場合、is_process_upでモニタリングすると正常にモニタリングができない場合があるため、process_count == 0のような条件でモニタリングする方が有利です(apacheサービスが終了したら *httpd*の process_countは0になるため)。

Q. Event Ruleの作成時に削除した File/Process/Port Pluginの Dimensionがずっと表示されています。

A. 削除した File/Process/Port Pluginの Dimensionは削除後、Event Ruleの作成画面で最大2日間表示されることがあります。File/Process/Port Pluginを削除すると収集された情報はすぐに削除されますが、Dimension情報は、当該 Dimensionを持つ Metricを収集しない状態が2日間持続する場合に削除されます。

Q. Event Ruleを作成したにもかかわらず、Total Rule Count値が監視対象および監視項目の値と一致しません。

A. Event Ruleの Total Rule Countは、実際に作成された Ruleを基準に算定されます。この時、実際 Ruleの作成有無は、設定した監視対象が監視項目に対して Metricを収集しているかによって決定されます。

例) 監視対象が3つで、そのうち2つに対してのみ実際に監視項目の Metricを収集している場合、Total Rule Countは3ではなく2と表記されます。

監視対象のうち、一部に対して監視項目の Metricが収集されない場合は次の通りです。

• 監視対象のサーバのうち、一部が監視項目の Metricに設定された Dimensionについて収集していない場合
• 監視項目の Metric Typeが Extendedであるため詳細モニタリングの設定が必要だが、監視対象のサーバのうち、一部が詳細モニタリングを設定していない場合
• 監視対象のサーバのうち、一部が停止状態に変更されたため、Metric収集が停止された場合
• 監視対象のサーバのうち、一部が内部ファイアウォールやファイアウォールソリューションなどにより、Metric収集が正常に行われない場合
• 監視対象のサーバのうち、一部が Agent動作のイシューにより、Metric収集が正常に行われない場合
• Event Ruleの設定時点に実際に Metricが収集されなかったため Total Rule Countから外された監視対象に対し、その後に Metricが収集される場合(この場合は、自動的に Total Rule Countに追加されます)。

Q. Serverの proc_mem_usertが Memoryの mem_usertより高いです。

A. 各 Metricに関する説明は、次の通りです。

• SERVER/proc_mem_usert: サーバ内の全プロセスのメモリ使用率
• MEMORY/mem_usert: サーバ全体のメモリ使用率

一般的に、プロセスの他にもいろいろな要素がサーバメモリを使用するため、MEMORY/mem_usertが SERVER/proc_mem_usertより大きい傾向があります。

SERVER/proc_mem_usertが MEMORY/mem_usertより大きい場合は以下の2つです。

• SERVER/proc_mem_usertは、すべてのプロセスが使用している RSS(プロセスが占めている Local Memory+プロセスが参照している Shared Memory)の合計を意味します。多くのプロセスが同じ Shared Memory pageを参照する場合、RSSに重複して合算されるため、理屈の上では RSSの合計が実際のメモリ使用率より大きく集計される可能性があります。

• RSSはプロセスが CPUを使用する場合にのみ、その値がアップデートされます。CPU負荷が非常に高い状況では、プロセス別に CPUの割り当てを受けられないこともあり、そのため RSS値のアップデートが正常に行われない場合があります。そのため、全体 RSS値の合計が実際のメモリ使用率より大きい場合があります。

正確なメモリ使用率を確認するには、SERVER/proc_mem_usertより MEMORY/mem_userttを使用することをお勧めします。

Q. CPUの used_rtoが Serverの avg_cpu_used_rtoより高いか低いです。

A. 各 Metricに関する説明は、次の通りです。

• CPU/used_rto: 各 vCPUの使用率
  • 例) vCPUが4つの場合、cpu_idx: 0~3のうち1つの使用率
• SERVER/avg_cpu_used_rto: サーバ全体の平均 CPU使用率

Linuxアーキテクチャの特性上、特定のプロセスはすべての CPUを均等に使用せず、特定の CPUをより多く使用する場合があります。この場合、CPU/used_rtoは SERVER/avg_cpu_used_rtoより高いか低いです。

サーバの正確な CPU使用率を確認するには、CPU/used_rtoより SERVER/avg_cpu_used_rtoを使用することをお勧めします。

Q. Eventが発生した後に Conditionを調整すると、これに伴う Eventが発生しません。

A. 既に発生した Eventが終了しないと、Conditionを調整しても新しい Conditionに伴う Eventは発生しません。

Eventが終了していない状況で Conditionを調整し、これをもとに新たに Eventを発生させたい場合は Rule無効化機能を利用できます。Ruleを無効化して Eventを強制終了させた後、Conditionを調整して再度無効化を解除すると、条件が満たされた時点で新しい Eventが発生します。

Ruleの無効化に関する詳細は、Rule詳細照会または Event Rule修正をご参照ください。

Q. Agentが正常に実行中なのに、Cloud Insightにデータが収集されません。

A. Agentが正常に実行中でもサーバ内部ファイアウォールの設定、セキュリティソリューションのインストールなどにより Agentから Cloud Insightへの Outbound通信が遮断されている可能性があります。次の Portリストを確認してから、ファイアウォールの解除有無をご確認ください。

Classic環境

VPC環境

Q. NAVERクラウドプラットフォームサービスのデータがダッシュボードで照会できません。

A. NAVERクラウドプラットフォームの各サービスで基本的に提供する Basic Metricは、Cloud Insightで別の設定なしに照会できます。追加で提供される Extended Metricは各サービスのコンソールで設定します(Server(VPC)の場合、詳細モニタリング設定で設定できます)。各サービスで提供する Basic/Extended Metricは APIガイドのサービスリストで確認できます。また、Extended Metricは設定時点から収集されるため、Cloud Insightで照会するには照会期間を確認します。

Q. ASGポリシーをアクションとして登録すると、サーバが持続的に作成または削除されます。

A. Event Ruleの作成時にアクションとして ASGポリシーを設定した場合、Eventが発生すると ASGポリシーを実行します。この際、ASGポリシーのクールダウンタイムを置いて持続的にポリシーが実行され、Eventが終了すると当該ポリシーの実行が終了します。そのため、当該 Eventが終了するまではサーバが持続的に作成または削除されることがあります。

Q. Custom Schemaを作成しましたが、コンソールで照会できません。

A. 作成された Custom Schemaでデータが収集されてからコンソールで確認できます。データの転送は、SendData APIをご参照ください。データ収集が開始した後、Custom Schemaの作成時に設定した集計周期(Interval)に応じて一定時間が経過してからデータを照会できます。

Q. APIでデータを送りましたが、コンソールで照会できません。

Q. Cloud Insightでデータを照会する際にデフォルトとして設定されている期間は照会時点から1時間前です。APIにデータを送った時点が含まれるように期間を設定してからご照会ください。

Q. APIに送ったデータとダッシュボードで照会される結果が異なります。

A. Cloud Insightでは、収集されたデータを一定周期ごとに複数の集計関数を利用して演算を行います。演算した結果が照会されるため、APIに送ったデータとは異なって表示されることがあります。Cloud Insightでデータを照会する際に集計周期(Interval)をご確認ください。集計周期と集計関数は、Custom Schema作成時に設定できます。

Q. 特に何もしていないのに、ある時点からメトリックが収集されなくなりました。

A. root(/)パスのディスク使用率が99%以上の時点以降は、Cloud Insight Agentが正常に動作しない場合があります。
そのため、当該パスのディスク容量の確保と点検が必要です。容量確保および点検後、agentを再起動して正常に収集されるか確認します。