Cloud Insight FAQ

最新のコンテンツが反映されていません。早急にアップデート内容をご提供できるよう努めております。最新のコンテンツ内容は韓国語ページをご参照ください。

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

Cloud Insight FAQでよくある質問への回答を提供します。

以下のよくある質問から答えが得られなかった場合、ご利用ガイドで必要な内容をご確認ください。

Q. Cloud Insightでパフォーマンス指標が確認できるサービスには何がありますか?

A. Cloud Insightでパフォーマンス指標が確認できるサービスは、パフォーマンス指標提供サービスをご参照ください。

Q. Metricと Dimensionの意味は何ですか?

A. Metricはユーザーが扱う値を意味し、Dimensionは Metricのプロパティを意味します。Dimensionで当該 Metricがどのサーバに属しているのか、どんなところに位置しているのか、何の値であるのかなどを定義できます。

Q. データの収集周期と集計周期について

• Metricデータの収集周期は1分です。収集周期は、集計周期と別に対象のリソースから Cloud Insightにデータを送る周期を意味します。
  • データは収集された状態で Cloud Insightに保存され、集計周期(Interval)ごとに複数の集計関数(Aggregation Method)を利用して演算が行われます。
• 集計周期は1分(Min1)、5分(Min5)、30分(Min30)、2時間(Hour2)、1日(Day1)おきに実行されます。

  • 現在集計期間内の AVG(平均値)、MIN(最小値)、MAX(最大値)、COUNT(収集回数)、SUM(合計)などの集計関数をサポートします。

  • 例) 00時01分から00時05分まで次のようなデータが収集されたと仮定した場合、集計期間の1分(Min1)と5分(Min5)に対する期待値は次の表となります。

    00:01:00 - 1
    00:02:00 - 2
    00:03:00 - 3
    00:04:00 - 4
    00:05:00 - 5
    

    集計周期(Interval): 1分(Min1)

    時間	AVG(平均値)	MIN(最小値)	MAX(最大値)	COUNT(収集回数)	SUM(合計)
    00:01	1	1	1	1	1
    00:02	2	2	2	1	2
    00:03	3	3	3	1	3
    00:04	4	4	4	1	4
    00:05	5	5	5	1	5

    集計周期(Interval): 5分(Min5)

    時間	AVG(平均値)	MIN(最小値)	MAX(最大値)	COUNT(収集回数)	SUM(合計)
    00:01	3	1	5	5	15

Q. Custom Schemaを作成して利用するにはどうすればいいですか?

A. Cloud Insightでは様々な Metric Typeと指標をサポートしますが、ユーザーが希望する Metricがサポート対象でない場合があります。この場合、Custom Schemaと SendData APIを利用してユーザーが希望するメトリックを自由に集計・収集することで、Cloud Insightで活用できます。

Custom Schemaと Send Data APIを使用する詳しいシナリオは、次の通りです。

1. Custom Schema作成

Custom Schemaご利用ガイドを参照して Custom Schemaを作成します。
Custom Schema作成後、 [データ転送例] ボタンをクリックして [転送する Sample Data形式] を確認します。

次は、Filesystemの使用量を収集する Custom Schemaの例です(Cloud Insightは Filesystemタイプのメトリックを提供するため、あくまで例としてご参照ください)。

Custom Schema作成時の入力値例

Product Type : CustomFilesystem
  収集対象の設定:
    ID Dimension : instanceName
    Data Type : String
  Metrics :
  - Metric : totalSize
    Data Type : Integer
    AggregationCycle : Min1, Min5, Min30
    Aggregation : AVG
    Unit : MB
  - Metric : usedSize
    Data Type : Integer
    AggregationCycle : Min1, Min5, Min30
    Aggregation : AVG
    Unit : MB
  - Metric : availSize
    Data Type : Integer
    AggregationCycle : Min1, Min5, Min30
    Aggregation : AVG
    Unit : MB
  Dimensions :
  - Dimension : mountPoint
    Data Type : String

Custom Schema作成後の Sample Data形式例

{
	"cw_key": "801142312146182144",
	"data": {
		"instanceName": "fe79g8ahkab",
		"totalSize": 893,
		"availSize": 260,
		"usedSize": 405,
		"mountPoint": "gh1apxl4it9"
	}
}

2. 希望するメトリックを集計

Custom Schemaデータ形式に合ったメトリック値を直接集計します。対象サーバにアクセスして希望する値を導出できるようにスクリプトを作成します。

次は、上記の例に続くスクリプトの作成例です。

#!/bin/bash

MOUNTPOINT="/userDevice"

USAGES=$(df -m | grep " $MOUNTPOINT$")

totalSize=$(echo $USAGES | awk '{print $2}')
usedSize=$(echo $USAGES | awk '{print $3}')
availSize=$(echo $USAGES | awk '{print $4}')

3. SendData APIで Custom Metric Dataを転送

直接集計したメトリック値を Custom Schemaのデータ転送形式に合わせて整理し、SendData APIを利用して Cloud Insightに転送します。

次は、上記の例に続く Custom Schemaデータ転送形式の例です。

{
	"cw_key": "801142312146182144",
	"data": {
		"instanceName": "myServer",
		"totalSize": 1180,
		"availSize": 1150,
		"usedSize": 30,
		"mountPoint": "/userDevice"
	}
}

4. Cloud Insightで収集したデータ確認

このように Cloud Insightに転送された Custom Metricデータは、Cloud Insightコンソールで Dashboardの Widgetを作成したり、Event Ruleまたは Templateを作成するときに確認できます。

5. 1分おきに繰り返し

Cloud Insightで Custom Product Type、ID Dimension、Dimensions、Metricを正常に確認したら、上記の2.~3.の手順を1分おきに繰り返し実行(Crontabなど適切な手段利用)し、Cloud Insightでメトリック値を収集します。

Q. agent_statusメトリックについて

A. agent_statusメトリックとは、Cloud Insight Agentの状態をモニタリングできるメトリックです。
agent_statusメトリックの条件は次の通りです。

• 0 : agentが正常な場合
• 1 : 3分間データは収集されず、pingチェックには成功する場合
• 2 : 3分間データは収集されず、同時に pingチェックにも失敗する場合

agent statusの値は連続的ではなく、分岐で処理されます。もし agentが正常な時にサーバが停止する場合、agent status値が 0から 1 を経て 2に変更されるのではなく、0から 2になります。
ちなみに pingチェックは、別途管理サーバ(ping checkモニタリングサーバ)でお客様のサーバを対象に行います。pingチェックの失敗がサーバ failと同じ意味ではないので、 agent_status 値が 2の場合、Agentとサーバの状態だけでなく、Network部分のチェックも必要です。

Q. Server(VPC)の Processと Plugin Processデータの違いは何ですか?

A. Processはそのサーバの TOP10プロセスに対するデータであり、Plugin Processはユーザーが設定した特定のプロセスに対するデータです。したがって、特定のプロセスをモニタリングするには Plugin Process機能をご利用ください。

Q. Server(VPC)の Plugin(File/Process/Port)機能を使用するにはどうすればいいですか?

A. Plugin機能を使用するには、まず APIで特定の File/Process/Portに対するモニタリングの設定を行います。

Pluginの設定と照会する APIは次をご確認ください。

• File Pluginの登録/照会: AddFilePlugin、RemoveFilePlugin、UpdateFilePlugin、GetFilePlugin、GetAllFilePlugin
• Port Pluginの登録/照会: AddPortPlugin、RemovePortPlugin、UpdatePortPlugin、GetPortPlugin、GetAllPortPlugin
• Process Pluginの登録/照会: AddProcessPlugin、RemoveProcessPlugin、UpdateProcessPlugin、GetProcessPlugin、GetAllProcessPlugin

Plugin(File/Process/Port) Metricは Extendedであるため、そのサーバの詳細モニタリングの設定が必要となります。

詳細な使用例は、次の通りです。

(ここでは Plugin Processを基準に説明します。Plugin File、Plugin Portについても同様に適用されます)

1. サーバに詳細モニタリングが Enableされているか確認します。

2. AddProcessPlugin APIでモニタリングするプロセスを Cloud Insightに登録します。
   Payloadの configListについては、Linuxの場合は ps -ef、Windowsの場合は tasklistをご参照ください。

   Payloadの例

   payload = {
     "configList": [ "*httpd*", "*java*" ],
     "instnaceNo": "1234567",
     "type": "VPCServer"
   }
   

   参考

   asterisk(*)は Plugin Process設定時にのみ使用できます。asterisk(*)が含まれている文字列で process nameを設定する場合、一致するすべてのプロセスの PIDリストが対象になります。

   参考

   AddPluginProcess APIを呼び出すと、一度に1つの instanceNoのみ登録できます。もし、複数の instanceNoを対象にする場合、繰り返して APIを呼び出します。

3. GetAllProcessPluginで Cloud Insightに Plugin Process configListが正常に登録されたか確認します。

4. Plugin Process configListが正常に登録されたら、約2~3分後に Cloud Insight Consoleで登録した process nameを確認できます。Dashboardの Widget設定時、Plugin Processを設定した Target InstanceNameに対して process nameが Dimensionに表示されます。

5. Plugin Processを変更または削除する場合は UpdateProcessPluginや RemoveProcessPluginを使用します。

Q. Metric Dimensionを選択しない場合、デフォルト値は何ですか?

• Metricによって Dimensionの選択有無が異なります。
  例) Metricが Serverである場合: Dimensionが1つだけ存在するため、選択可能な Dimensionが存在しない、Metricが CPUである場合: CPU数に応じて cpu_idx: 0~Nの Dimensionを選択可能

• 選択可能な Dimensionがあるのに選択しなかった場合、選択可能なすべての Dimensionを対象に Aggregation設定に対応する値が出力されます。
  例) 次のような条件で Dimensionを選択しなかった場合

  Metric : CPU/used_rto
  Dimension : cpu_idx: 0, cpu_idx: 1
  Aggregation : AVG
  

  Aggregationの設定に合わせて cpu_idx: 0と cpu_idx: 1の used_rtoの平均値に設定されます。

Q. CPU使用率がイベントルール条件より低いのにイベントが発生しました。なぜイベントが発生したのですか?

A. CPU/used_rto メトリックは、CPU数によって cpu_idx:0~N のディメンションが存在します。
ディメンジョンを選択せずにイベントルールを作成した場合、すべてのディメンジョンのメトリックが対象となり、各ディメンジョンに応じたメトリックのうち1つでも条件に該当するとイベントが発生します。
例) サーバの CPU数が2個で、イベントルールとメトリック値が以下のような場合、CPU/used_rto 値は45ですが、ディメンション cpu_idx: 0 に該当する値が60で条件を満たすため、イベントが発生します。

• 監視項目と条件:

メトリック: CPU/used_rto
ディメンション: 選択しない
条件: >= 50
集約方法: AVG
持続時間: 1minute

• ある時点での Min1データ:

したがって、サーバの平均 CPU使用率に対してイベント設定が必要な場合は、SERVER/avg_cpu_used_rto メトリックをご利用ください。

Q. Event Ruleの監視項目と条件を複数の Metricの Conditionに設定した場合、Eventが発生するにはすべての条件を満たす必要がありますか?

A. Event Ruleに Metricの Conditionを複数に設定した場合、各 Conditionは OR条件で動作します。すなわち、Event Ruleの監視項目と条件に追加された個々の Metricの Conditionを満足すると、Eventが発生します。

Cloud Insightでは、Event Ruleの設定時に監視項目と条件として複数の Metricを選択した場合、実際には選択した Target*Metric数に該当する Event Ruleが作成されます。Event Ruleの作成時または Event Ruleのリストから作成された Event Ruleを選択して [Rules全体を見る] ボタンをクリックすると、実際に作成されたすべての Event Ruleを確認できます。

例) VM 1台に対する Event Ruleに2つの Conditionを設定し、アクションとして Auto Scalingポリシーを設定した場合、実際には以下のような2つの Event Ruleが作成されます。

• VMの avg cpu used_rto > 50%の場合、Auto Scalingポリシーを実行
• VMの mem_usert > 50%の場合、Auto Scalingポリシーを実行

したがって、avg cpu used rto > 50%の場合または(OR) mem usert > 50%の場合は Eventが発生して Auto Scalingポリシーを実行します。

Q. Server(VPC)の mem_usertはどのように収集されますか?

A. mem_usertの値は、全体メモリに対する使用されたメモリの割合であり、計算式は次の通りです。

used_mem_mb = total_mem_mb - free_mem_mb - buffuer_mb - cache_mb - slab_reclaimable_mb
mem_usert = used_mem_mb / total_mem_mb * 100

Q. Filesystem Typeのメトリックはどのように収集されますか?

A. Filesystem Typeのメトリックは以下のような基準に合致する場合、Mountpoint Nameが Dimensionに登録されて収集できます。

• ext3、ext4、xfsのうち1つのファイルシステムでフォーマットされた別のパーティションまたはデバイス(UUIDベース)

  > blkid
  /dev/xvda1: UUID="f95bed0a-11af-4b2c-bfcc-4afb91a68fc1" TYPE="xfs"
  /dev/xvda2: UUID="0692fdb8-bb3c-4094-83f0-fe95a339b8c1" TYPE="xfs"
  

• 実際に Mountされている

  > df -h
  /dev/xvda2       49G  3.6G   46G   8% /
  /dev/xvda1     1014M  183M  832M  18% /boot
  

> cat /etc/fstab
/dev/xvdb    /mnt/vol     vfat      defaults     0   0

Q. Agentをインストールするにはどうすればいいですか?

A. VPCサーバにアクセスした後、OSに応じて方法をご確認ください。

• Linux

  • インストールパッケージをダウンロード: https://nsight.ncloud.com/agent controller linux_ncp.tar.gz
  • /home1/nbpmon/で圧縮展開: tar -zxvf agent controller linux_ncp.tar.gz
  • root権限で Agentを実行: /home1/nbpmon/agent controller linux/install_agent.sh pub

• Linux Bare Metal

  • インストールパッケージをダウンロード: https://nsight.ncloud.com/agent controller linux pub bm.tar.gz
  • /home1/nbpmon/で圧縮展開: tar -zxvf agent controller linux pub bm.tar.gz
  • root権限で Agentを実行: /home1/nbpmon/agent controller linux/bm install agent.sh

• Window

  • インストールパッケージをダウンロード: https://nsight.ncloud.com/agent controller windows_ncp.zip
  • 圧縮展開: unzip agent controller windows_ncp.zip
  • Agent実行: agent controller windows/install_agent.bat pub
  注意

  ダウンロードと圧縮展開後にインストールフォルダは NBP サブフォルダにある必要があります。
  以下は不正なインストール.パスの例です。
  C:\Program Files (x86)\NBP\agent_controller_windows_ncp\agent_controller_windows
  正常なインストールパスは次の通りです。
  C:\Program Files (x86)\NBP\agent_controller_windows

Q. Linux用の Agent scriptファイルはどこからダウンロードできますか?

A. to_stop_start_uninstall_agent.zipをクリックしてダウンロードできます。ダウンロードしたファイルの圧縮を展開し、scriptファイルを Agentディレクトリ(/home1/nbpmon/agent_controller_ linux/)に置きます。当該 scriptを通して Agentを起動/停止/インストール/アンインストールできます。

Q. Server(VPC)データをモニタリングするには、Agentを必ずインストールする必要がありますか?

A. Server(VPC)の場合、パフォーマンス指標を収集するには Agentが必要ですが、サーバ作成時に基本搭載されるため、ユーザーが Agentを別途インストールする必要はありません。ただし、Agentがアンインストールされたり、ユーザーの設定により実行されない場合は、Cloud Insightによるデータの収集ができないのでご注意ください。

Q. Agentの動作状態を確認するにはどうすればいいですか?

A. OSに応じて方法をご確認ください。

• Linux
  ps -ef | grep agentで Agentプロセスが動いているか確認します。agent_updater.pyと agent.pyプロセスが実行中であれば Agentは正常に動作中です。
• Window
  nsight2_agentサービスの状態を確認します。このサービスが起動されたら、Agentは正常に動作中です。

Q. Agentを停止・起動するにはどうすればいいですか?

A. OSに応じて Agentの停止/起動方法をご確認ください。

• Linux

  • Agent停止: /home1/nbpmon/agent controller linux/stop_agent.shを実行します。
  • Agent起動: /home1/nbpmon/agent controller linux/start_agent.shを実行します。
  • Agent再起動: /home1/nbpmon/agent controller linux/restart_agent.shを実行します。

• Window

  • Agent停止: C:\Program Files(x86)\NBP\agent controller windows\agent.bat stopを実行します。
  • Agent起動: C:\Program Files(x86)\NBP\agent controller windows\agent.bat startを実行します。

Q. Agentをアンインストールするにはどうすればいいですか?

A. OSに応じて Agentのアンインストール方法をご確認ください。

• Linux
  Linuxで Agentをアンインストールするには、Agent関連の scriptファイルをダウンロードする必要があります。まず、Q. Linux用の Agent scriptファイルはどこからダウンロードできますか?を参照して scriptファイルをダウンロードし、Q. Agentを停止・起動するにはどうすればいいですか?を参照して Agentを停止した後、/home1/nbpmon/agent controller linux/uninstall_agent.shを実行します。

• Window
  Q. Agentを停止・起動するにはどうすればいいですか?を参照して Agentを停止した後、C:\Program Files (x86)\NBP\agent controller windows\agent.bat uninstallを実行します。

Q. Agentを再インストールするにはどうすればいいですか?

A. インストールが正常に行われなかった場合、以下の方法で Agentを正常に再インストールできます。

• Linux

  1. Agent停止
     /home1/nbpmon/agent_controller_linux/stop_agent.shを実行します。

  2. Agentアンインストール
     /home1/nbpmon/agent_controller_linux/uninstall_agent.shを実行します。

  3. Agentインストールパスの削除
     /home1/nbpmon/agent_controller_linuxを削除します。必要なファイルがある場合、バックアックします。

  4. Agentインストール
     Agentのインストール方法は Q. Agentをインストールするにはどうすればいいですか?をご参照ください。

• Window

  1. Agent停止
     以下のコマンドを実行します。

  C:\Program Files(x86)\NBP\agent_controller_windows\agent_controller_windows\agent.bat stop
  

  2. Agentアンインストール
     以下のコマンドを実行します。

  C:\Program Files (x86)\NBP\agent_controller_windows\agent_controller_windows\agent.bat uninstall
  

  3. Agentインストールパスの削除
     C:\Program Files (x86)\NBP\agent_controller_windowsを削除します。必要なファイルがある場合、バックアックします。

  4. Agentインストール
     Agentのインストール方法は Q. Agentをインストールするにはどうすればいいですか?をご参照ください。

Q. Agentのログを確認するにはどうすればいいですか?

A. OSに応じて次のようにログファイルを確認できます。

• Linux
  /home1/nbpmon/agent controller linux/logsでログファイルを確認できます。

• Window
  C:\Program Files (x86)\NBP\agent controller windows\logsでログファイルを確認できます。

Q. Agentのログサイズとバックアップ数を調整するにはどうすればいいですか?

A. 次のようにログサイズとバックアップ数を調整できます。

1. OSに応じて logger.pyファイルを確認します。

   • Linux
     /home1/nbpmon/agent controller linux/logger.py
   • Window
     C:\Program Files (x86)\NBP\agent controller windows\logger.py

2. logger.pyファイル内容のうち、LOG_SIZE_IN_BYTESと LOG_BACKUP_COUNTを変更します。

   ...
   def get_logger(name, logfile=DEFAULT_LOG, max_bytes=LOG_SIZE_IN_BYTES, backup_count=LOG_BACKUP_COUNT):
       logger = logging.getLogger(name)
       setup_logger(logger, logfile, max_bytes, backup_count)
       return logger
   

3. logger.pyファイルの変更後、Agentを再起動します。

Q. User Createdポリシーを通じてアクション単位で権限を定義するには、アクション間の関係を熟知している必要がありますか?

A. メインアカウントがサブアカウントに付与する詳細アクションを選択する時、関連したアクションも自動で選択される機能を提供します。

Q. Event情報を SMSで受信する場合、SMSにはどのような内容が含まれていますか?

A. Cloud Insightは Event発生、Eventが解消されない状態で維持される場合、Eventが終了する場合、SMSアラーム機能を提供します。
各状況別 Message形式は、次の通りです。

SMSは、メッセージ特性によるメッセージ容量制限により、最小限の情報のみを含めて送信します。
より詳しい情報が必要な場合、Integrationの使用をお勧めします。

Q. Cloud DB系のサービスを使用中です。イベントが発生して自動送信する SMSの内容をどのように解釈すればいいですか?

A. 各 Cloud DB種類別に提供するメトリックが異なるため、詳細はコンソール画面をご確認ください。主に使用するメトリックの内容は、次の通りです。

Q. Widget作成時にメトリックリストに収集されていないメトリックが含まれているようです。表示されるメトリックの基準は何ですか?

A. Widget作成時には選択したサービスで提供するすべてのメトリックリストを表示します。現在収集されないメトリックを Widgetに追加しても、今後収集されると Widgetにメトリックが表示されます。ただし、メトリックを収集するための追加設定が必要な場合(詳細モニタリング、Plugin設定など)、対象リソースに対してサポートしないメトリックの場合、Server(Classic)、Server(VPC)サービスの場合、OSによって提供しないメトリックが表示される場合があります。OSごとに提供するメトリックはメトリックの説明をご参照ください。

Q. イベント発生内容と Eventページで確認したデータが違います。どうしてでしょうか?

A. コンソール Eventページで発生したイベント照会時に表示されるグラフは、イベント開始日時と終了日時によって照会されるデータの集計周期(例: Min5)が異なります。
実際にイベントルールを発生させたデータを確認するには、集計周期が Min1のデータを確認する必要があります。
したがって、別途 Dashboardを構成するか、Event Ruleページで当該イベントルールを照会し、詳細表示で照会期間を1時間以内に設定して照会すると、Min1データを確認できます。

Q. ProcessPluginを収集するプロセス名の基準はどうなっていますか?

A. ProcessPluginの場合、/proc/{pid}/statまたは/proc/{pid}/cmdline基準で一致するプロセス名の情報を収集しています。

Q. 特定の時間帯にイベントルールアクションを停止する方法はありますか?

A. Planned Maintenance機能を活用すると、Event発生によるアクションを停止できます。
無効にしたい event ruleに関連するサービス別ディメンションを設定してください。

Q. Service Dashboardでウィジェットデータ TOP10で照会すると、CPU使用率が高いサーバデータが CPU使用率ウィジェットに表示されません。どうしてでしょうか?

A. Service Dashboard Top10リストを選定する基準は、次の通りです。

• 最近10分間の Min1 metric値を照会してソートした後、上位10個を選定
• 最近10分間の Min1 データがない場合、ランダムに10個を選定

ウィジェットデータが TOP10の場合、表示されるサーバリストを選定する必要があるため、この時選定に使用するデータは(endTime-10分、endTime)期間に照会されたデータです。当該データは実際にダッシュボード上に表記せず、内部的にのみ使用するデータです。
CPU使用率が高いサーバが TOP10に表示されなかった場合、上記の基準により、当該サーバの(endTime-10分、endTime)期間の CPU使用率 Min1 metric値が上位10個に含まれていない可能性があります。
このように、Top10は設定した照会期間の終了時点(endTime)を基準に10分前のデータで比較するため、実際に照会する期間全体で期待するリストとして表示されない場合があります。

Q. イベント発生後、条件を変更しました。変更した条件を満たしていませんが、イベントが発生しました。なぜイベントが発生したのですか?

A. 既存に発生したイベントがある場合、そのイベントの条件を変更すると既存のイベントが終了し、当時設定された条件で終了イベントの通知を送信します。
したがって、条件を変更して発生した終了イベントの当時設定した実際の条件を確認するには、コンソール Eventページで照会して確認する必要があります。

以下の例は、durationなどを考慮していない参考のための単純な例であることをご了承ください。