- 印刷する
- PDF
Cloud Insight FAQ
- 印刷する
- PDF
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と SendData APIの詳しい使用方法は、以下のリンクをご参照ください。
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はそのサーバの TOP 10プロセスに対するデータであり、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についても同様に適用されます)
サーバに詳細モニタリングが Enableされているか確認します。
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を呼び出します。GetAllProcessPluginで Cloud Insightに Plugin Process configListが正常に登録されているか確認します。
Plugin Process configListが正常に登録されたら、約2~3分経過後に Cloud Insight Consoleで登録した process nameを確認できます。Dashboardの Widgetを設定すると、Plugin Processを設定した Target InstanceNameに対して process nameが Dimensionに表示されます。
Plugin Processを変更または削除する場合は UpdateProcessPluginや RemoveProcessPluginを使用します。
Plugin Processは削除しても、すぐには Dimensionから消えません。詳細は、Cloud Insight のトラブルシューティングをご参照ください。
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
持続時間: 1 minute
- ある時点での Min1データ:
時間 | CPU/used_rto (cpu_idx: 0) | CPU/used_rto (cpu_idx: 1) | CPU/used_rto |
---|---|---|---|
00:01 | 60 | 30 | 45 |
したがって、サーバの平均 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などのファイルシステムでフォーマットされた別のパーティションまたはデバイス(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
もし Filesystemが ext3、ext4、xfsの中の1つにフォーマットされない場合、/etc/fstabに登録してから Mountすると収集できます。
> cat /etc/fstab
/dev/xvdb /mnt/vol vfat defaults 0 0
/etc/fstabに記録された mountpointは実際の df -hコマンドの結果で得られる mountpointと一致する必要があります。
例)
/logs/ != /logs
Q. Agentをインストールするにはどうすればいいですか?
A. VPCサーバにアクセスし、OSに応じて方法をご確認ください。
インストールドメインは VPCサーバでのみアクセスできます。インターネット環境でアクセスするには NAVERクラウドプラットフォームのオープンソースサイトをご利用ください。
Linux
- インストールパッケージをダウンロード: https://nsight.ncloud.com/agent controller linux_pub.tar.gz
/home1/nbpmon/
で圧縮を展開: tar -zxvf agent controller linux_pub.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_pub.zip
- 圧縮を展開: unzip agent controller windows_pub.zip
- Agentを実行: agent controller windows/agent.bat install
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. OSに応じて次のようにログファイルを確認できます。
Linux
/home1/nbpmon/agent controller linux/logsでログファイルを確認できます。Window
C:\Program Files (x86)\NBP\agent controller windows\logsでログファイルを確認できます。
Q. Agentのログサイズとバックアップ数を調整するにはどうすればいいですか?
A. 次のようにログサイズとバックアップ数を調整できます。
OSに応じて logger.pyファイルを確認します。
- Linux
/home1/nbpmon/agent controller linux/logger.py - Window
C:\Program Files (x86)\NBP\agent controller windows\logger.py
- Linux
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
logger.pyファイルを修正した後、Agentを再起動します。
Q. User Createdポリシーを介してアクション単位で権限を定義するには、アクション間の関係を熟知している必要がありますか?
A. メインアカウントがサブアカウントに与える詳細アクションを選択する際、関連したアクションも自動で選択される機能を提供しています。
Q. Event情報を SMSで受信する場合、SMSにはどのような内容が含まれていますか?
A. Cloud Insightは Event発生、Eventが解消されない状態で維持される場合、Eventが終了する場合についての SMSアラーム機能をサポートします。
各状況別 Message形式は、次の通りです。
送信状況 | SMS Format |
---|---|
Event発生 | [Ncloud] ${RuleName} ${Level} ${InstanceName} ${Condition} |
Eventリマインド | [Ncloud][Remind] ${RuleName} ${Level} ${InstanceName} ${Condition} |
Event終了 | [Ncloud][Resolve] ${RuleName} ${InstanceName} ${Condition} |
SMSは、メッセージ特性によるメッセージ容量制限により、最小限の情報のみを含めて送信しています。
より詳しい情報が必要な場合、Integrationの使用をお勧めします。
Q. Cloud DB系のサービスを使用中です。イベントが発生して自動で転送される SMSの内容をどのように解釈すればいいですか?
A. 各 Cloud DB種類別に提供するメトリックが異なるため、詳細はコンソール画面をご確認ください。主に使用するメトリックの内容は、次の通りです。
Product | Metric | SMS Sample | Description |
---|---|---|---|
Cloud DB for MySQL(VPC) | mysql_active | [Ncloud] DB Down:0, Threshold:== 0, Duration:1min WARNING test mysql_active=0 | test DBサーバがダウンする |
Cloud DB for MySQL(VPC) | mysql_slavedelay | [Ncloud] DB Down:0, Threshold:== 0, Duration:1min WARNING test mysql_slavedelay | Masterから Slaveへの最新データコピーが遅延(1分前のデータまで反映済み) |
Cloud DB for MySQL(VPC) | mysql_slaverun | [Ncloud] DB Down:0, Threshold:== 0, Duration:1min WARNING test mysql_slaverun=0 | test DBの Slaveサーバが同期されていない |
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でウィジェットデータ TOP 10で照会すると、CPU使用率が高いサーバデータが CPU使用率ウィジェットに表示されません。どうしてでしょうか?
A. Service Dashboard Top10リストを選定する基準は、次の通りです。
- 最近10分間の
Min1
metric値を照会してソートした後、上位10個を選定 - 最近10分間の
Min1
データがない場合、ランダムに10個を選定
ウィジェットデータが TOP 10の場合、表示されるサーバリストを選定する必要があるため、この時選定に使用するデータは(endTime - 10分、endTime)期間に照会されたデータです。当該データは実際にダッシュボード上に表記せず、内部的にのみ使用するデータです。
CPU使用率が高いサーバが TOP 10に表示されなかった場合、上記の基準により、当該サーバの(endTime - 10分、endTime)期間の CPU使用率 Min1
metric値が上位10個に含まれていない可能性があります。
このように、Top10は設定した照会期間の終了時点(endTime)を基準に10分前のデータで比較するため、実際に照会する全体の期間で期待するリストとして表示されない場合があります。
Q. イベント発生後、条件を変更しました。変更した条件を満たしていませんが、イベントが発生しました。なぜイベントが発生したのですか?
A. 既存に発生したイベントがある場合、そのイベントの条件を変更すると既存のイベントが終了し、当時設定された条件で終了イベントの通知を送信します。
したがって、条件を変更して発生した終了イベントの当時設定した実際の条件を確認するには、コンソール Eventページで照会して確認する必要があります。
以下の例は、durationなどを考慮していない参考のための単純な例であることをご了承ください。
時間 | process_count | 条件 | イベント発生と内容 |
---|---|---|---|
00:00 | 0 | process_count = 1 | イベント未発生 |
00:01 | 1 | process_count = 1 | process_count = 1内容のイベントアラーム発生 |
00:02 | 1 | process_count = 0 | process_count = 0内容の終了(Resolve)イベントアラーム発生 |
00:03 | 0 | process_count = 0 | process_count = 0内容のイベントアラーム発生 |