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 : AVGAggregationの設定に合わせて
cpu_idx: 0とcpu_idx: 1の 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
もし 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をインストールするにはどうすればいいですか?
Agentのインストールパスは OSバージョンによって異なります。Linuxの場合、 ps -ef | grep agent コマンドで Agentをインストールしたパスを確認できます。インストールしたパスを確認して行ってください。
**A.**VPCサーバにアクセスし、OSによって方法をご確認ください。
インストールドメインは VPCサーバでのみアクセスできます。インターネット環境でアクセスするには NAVERクラウドプラットフォームのオープンソースサイトをご利用ください。
-
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_common_bm.tar.gz
/home1/nbpmon/で圧縮解凍: tar -zxvf agent_controller_linux_pub_common_bm.tar.gz- root権限で Agentを実行: /home1/nbpmon/agent_controller_linux/install_agent.sh vpc
-
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 -
Window Bare Metal
- インストールパッケージをダウンロード: https://repo-nsight.ncloud.com/agent_controller_windows_pub_bm.zip
- 圧縮解凍: unzip agent_controller_windows_pub_bm.zip
- agent実行: agent_controller_windows\install_agent.bat vpc
-
KVM/BM linux環境で GPU insightをインストール
- インストールパッケージをダウンロード: wget --no-cache http://init.ncloud.com/gpu/gpu_insight/install_gpu_insight.sh
- 実行権限を追加: chmod +x install_gpu_insight.sh
- root権限で Agentを実行: ./install_gpu_insight.sh
Q.Classic環境で Agentをインストールするにはどうすればいいですか?
Agentのインストールパスは OSバージョンによって異なります。Linuxの場合、 ps -ef | grep agent コマンドで Agentをインストールしたパスを確認できます。インストールしたパスを確認して行ってください。
**A.**Classicサーバにアクセスし、OSによって方法をご確認ください。
-
Linux
- インストールパッケージをダウンロード: https://repo-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-classic
-
Linux Bare Metal
- インストールパッケージをダウンロード: https://repo-nsight.ncloud.com/agent_controller_linux_pub_common_bm.tar.gz
/home1/nbpmon/で圧縮解凍: tar -zxvf agent_controller_linux_pub_common_bm.tar.gz- root権限で Agentを実行: /home1/nbpmon/agent_controller_linux/install_agent.sh classic
-
Window
- インストールパッケージをダウンロード: https://repo-nsight.ncloud.com/agent_controller_windows_ncp.zip
- 圧縮解凍: unzip agent_controller_windows_ncp.zip
- Agent実行: agent_controller_windows/install_agent.bat pub-classic
注意ダウンロードと圧縮展開後にインストールフォルダは
NBPサブフォルダにある必要があります。
以下は不正なインストールパスの例です。
C:\Program Files (x86)\NBP\agent_controller_windows_ncp\agent_controller_windows正常なインストールパスは次の通りです。
C:\Program Files (x86)\NBP\agent_controller_windows -
Window Bare Metal
- インストールパッケージをダウンロード: https://repo-nsight.ncloud.com/agent_controller_windows_pub_bm.zip
- 圧縮解凍: unzip agent_controller_windows_pub_bm.zip
- agent実行: agent_controller_windows\install_agent.bat classic
Q.Linux用の Agent scriptファイルはどこからダウンロードできますか?
Agentのインストールパスは OSバージョンによって異なります。Linuxの場合、 ps -ef | grep agent コマンドで Agentをインストールしたパスを確認できます。インストールしたパスを確認して行ってください。
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を停止・起動するにはどうすればいいですか?
Agentのインストールパスは OSバージョンによって異なります。Linuxの場合、 ps -ef | grep agent コマンドで 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をアンインストールするにはどうすればいいですか?
Agentのインストールパスは OSバージョンによって異なります。Linuxの場合、 ps -ef | grep agent コマンドで 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を再インストールするにはどうすればいいですか?
Agentのインストールパスは OSバージョンによって異なります。Linuxの場合、 ps -ef | grep agent コマンドで Agentをインストールしたパスを確認できます。インストールしたパスを確認して行ってください。
**A.**インストールが正常に行われなかった場合、以下の方法で Agentを正常に再インストールできます。
-
Linux
-
Agent停止
/home1/nbpmon/agent_controller_linux/stop_agent.shを実行します。 -
Agent削除
/home1/nbpmon/agent_controller_linux/uninstall_agent.shを実行します。 -
Agentインストールパスの削除
/home1/nbpmon/agent_controller_linuxを削除します。必要なファイルがある場合、バックアックします。 -
Agentのインストール
Agentのインストール方法は、Q.Agentをインストールするにはどうすればいいですか?をご参照ください。
-
-
Window
- Agent停止
以下のコマンドを実行します。
C:\Program Files(x86)\NBP\agent_controller_windows\agent.bat stop- Agent削除
以下のコマンドを実行します。
C:\Program Files (x86)\NBP\agent_controller_windows\agent.bat uninstall-
Agentインストールパスの削除
C:\Program Files (x86)\NBP\agent_controller_windowsを削除します。必要なファイルがある場合、バックアックします。 -
Agentのインストール
Agentのインストール方法は、Q.Agentをインストールするにはどうすればいいですか?をご参照ください。
- Agent停止
Q.Agentのログを確認するにはどうすればいいですか?
Agentのインストールパスは OSバージョンによって異なります。Linuxの場合、 ps -ef | grep agent コマンドで 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.イベント発生内容と 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.Cloud Insightでサーバの時刻ズレ(NTP offset)をモニタリングするにはどうすればよいですか?
**A.**時刻ズレのモニタリングが必要な場合、まず Cloud Insightに Custom Schemaを作成した後に OS(Linux、Windows)に適したスクリプトでメトリックを収集します。
Custom Schema作成
収集した NTPメトリックを盛り込む Custom Schemaを作成します。
Custom Schemaで以下の項目を入力します。
Metric (Linux)
| Metric | Data Type |
|---|---|
ntp_system_time |
FLOAT |
ntp_last_offset |
FLOAT |
ntp_rms_offset |
FLOAT |
ntp_root_delay |
FLOAT |
ntp_stratum |
INTEGER |
ntp_leap_status |
INTEGER |
Metric (Windows)
| Metric | Data Type |
|---|---|
ntp_last_offset |
FLOAT |
ntp_root_delay |
FLOAT |
ntp_stratum |
INTEGER |
ntp_leap_status |
INTEGER |
ntp_synced |
INTEGER |
ntp_reachable |
INTEGER |
Linux、Windowsで収集されるメトリックが異なるため、正確な動作のためには各環境に適したメトリックを正確に設定します。
1.Linux環境(chronyベース)
追加のパッケージをインストールすることなく、既に動作中の chronyの同期ステータスを Custom Metricとして収集する方法です。
chrony環境で NTPメトリックを確認する方法は、次の通りです。
$ chronyc tracking
Reference ID : A9FEA97B (169.254.169.123)
Stratum : 3
System time : 0.000012345 seconds slow of NTP time
Last offset : -0.000008721 seconds
RMS offset : 0.000015234 seconds
Root delay : 0.012345678 seconds
Leap status : Normal
主な収集メトリック
| フィールド | 意味 |
|---|---|
ntp_system_time |
ローカル-サーバ間の時刻ズレ(s) |
ntp_last_offset |
直近の補正時に測定された時刻ズレ(s) |
ntp_rms_offset |
offsetの長期平均(s) |
ntp_root_delay |
最上位基準クロックサーバとの往復遅延(s) |
ntp_stratum |
サーバの stratumレベル |
ntp_leap_status |
同期/うるう秒ステータス(Normal=正常、転送値は整数0) |
収集スクリプト (/usr/local/bin/ntp_metric.sh)
#!/bin/bash
set -euo pipefail
CW_KEY="YOUR_CW_KEY" #Custom Schema作成時に発行される19桁の数字キー
ACCESS_KEY="YOUR_NCP_ACCESS_KEY"
SECRET_KEY="YOUR_NCP_SECRET_KEY"
DIM_KEY="YOUR_ID_DIMENSION_KEY" #登録した Custom Schemaの ID Dimension名
DIM_VALUE="$(curl -s --max-time 5 http://169.254.169.254/latest/meta-data/serverName)"
API_HOST="https://cw.apigw.ntruss.com"
URI="/cw_collector/real/data"
METHOD="POST"
TRACKING=$(chronyc tracking) || { echo "chronyc実行失敗(chrony未インストール)"; exit 1; }"
# System time: "X seconds slow/fast" → slowの場合は負の値
read -r ST_VAL ST_DIR < <(awk '/^System time/{print $4, $6}' <<<"$TRACKING") || true
[ "${ST_DIR:-}" = "slow" ] && SYSTEM_TIME="-${ST_VAL}" || SYSTEM_TIME="${ST_VAL:-}"
# 先行「+」を削除(正の値 offsetの場合、JSON数値形式が崩れるのを防止)
LAST_OFFSET=$(awk '/^Last offset/{print $4}' <<<"$TRACKING" | tr -d '+')
RMS_OFFSET=$( awk '/^RMS offset/ {print $4}' <<<"$TRACKING" | tr -d '+')
ROOT_DELAY=$( awk '/^Root delay/ {print $4}' <<<"$TRACKING" | tr -d '+')
STRATUM=$( awk '/^Stratum/ {print $3}' <<<"$TRACKING")
LEAP=$( awk -F': ' '/^Leap status/{print $2}' <<<"$TRACKING")
case "$LEAP" in
"Normal") LEAP_CODE=0 ;;
"Insert second") LEAP_CODE=1 ;;
"Delete second") LEAP_CODE=2 ;;
*) LEAP_CODE=3 ;;
esac
: "${SYSTEM_TIME:=0}" "${LAST_OFFSET:=0}" "${RMS_OFFSET:=0}" "${ROOT_DELAY:=0}" "${STRATUM:=0}"
BODY="{\"cw_key\":\"$CW_KEY\",\"data\":{\"$DIM_KEY\":\"$DIM_VALUE\",\"ntp_system_time\":$SYSTEM_TIME,\"ntp_last_offset\":$LAST_OFFSET,\"ntp_rms_offset\":$RMS_OFFSET,\"ntp_root_delay\":$ROOT_DELAY,\"ntp_stratum\":$STRATUM,\"ntp_leap_status\":$LEAP_CODE}}"
TIMESTAMP=$(date +%s%3N)
SIG_MSG=$(printf '%s %s\n%s\n%s' "$METHOD" "$URI" "$TIMESTAMP" "$ACCESS_KEY")
SIGNATURE=$(printf '%s' "$SIG_MSG" | openssl dgst -sha256 -hmac "$SECRET_KEY" -binary | openssl base64 -A)
curl -sS --max-time 10 -w '\nHTTP %{http_code}\n' -X "$METHOD" "${API_HOST}${URI}" \
-H "Content-Type: application/json" \
-H "x-ncp-apigw-timestamp: $TIMESTAMP" \
-H "x-ncp-iam-access-key: $ACCESS_KEY" \
-H "x-ncp-apigw-signature-v2: $SIGNATURE" \
-d "$BODY"
Cron登録
収集スクリプトを/usr/local/bin/ntp_metric.shに保存してから実行権限を付与し、1分周期で実行されるよう Cronに登録します。
# 1.実行権限付与
chmod +x /usr/local/bin/ntp_metric.sh
# 2.crontab -e実行後に以下の行を追加(1分周期)
* * * * * /usr/local/bin/ntp_metric.sh >/dev/null 2>&1
収集確認
Cronを登録してから約2~3分後、Cloud Insightコンソールでウィジェットを作成してデータが正常に収集されるか確認します。
- コンソールで、Menu > All Services > Management & Governance > Cloud Insight > Dashboardに移動します。
- [ダッシュボード作成] をクリックしてダッシュボード名を入力した後、 [作成] をクリックします。
- 事前に作成しておいた Custom Schemaは Product Typeを、確認するメトリックは Metricを選択します。
- ウィジェットに1分間隔でデータポイントが表示されたら、正常に収集されていることを意味します。
アラームの推奨しきい値
Custom Metricに基づくアラーム設定において、推奨されるしきい値は次の通りです。
| メトリック | Warning | Critical | 説明 |
|---|---|---|---|
ntp_last_offset |
±0.1s超過 | ±1.0s超過 | 直近の測定された時刻ズレ |
ntp_stratum |
4を超過 | 6を超過 | Stratumレベルの過剰 |
ntp_leap_status |
0以外 | - | Leap secondの到来、または同期異常 |
上記の chrony方式の他にも Telegraf入力プラグインを活用したり、Python(ntplibなど)で NTPサーバを直接測定して収集する方法もあります。標準化されたコレクターを運用中、または多重 NTPサーバ交差比較が必要な場合、環境に適した方法を選択します。
2.Windows環境(w32tmベース)
Windowsに内蔵された w32tmコマンドと性能カウンタを活用して NTPメトリックを収集する方法です。
主な収集メトリック
| フィールド | 意味 |
|---|---|
ntp_last_offset |
直近の測定された時刻ズレ(s) |
ntp_root_delay |
最上位基準クロックサーバとの往復遅延(s) |
ntp_stratum |
サーバの stratumレベル |
ntp_leap_status |
同期/うるう秒ステータス(0=正常) |
ntp_synced |
NTP同期有無(1=同期済み、0=失敗) |
ntp_reachable |
基準 NTPサーバ到達可能有無(1=到達、0=失敗) |
収集スクリプト (C:\Scripts\ntp_metric.ps1)
#Requires -Version 5.1
[CmdletBinding()]
param(
[string]$CwEndpoint = 'https://cw.apigw.ntruss.com/cw_collector/real/data',
[string]$CwKey = 'YOUR_CW_KEY', #Custom Schema作成時に発行される19桁の数字キー
[string]$AccessKey = 'YOUR_NCP_ACCESS_KEY',
[string]$SecretKey = 'YOUR_NCP_SECRET_KEY',
[string]$DimKey = 'YOUR_ID_DIMENSION_KEY', #登録した Custom Schemaの ID Dimension名
[string]$LogFile = "$env:ProgramData\ntp_metric\ntp_metric.log",
[switch]$DryRun
)
$ErrorActionPreference = 'Stop'
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
function Write-Log([string]$msg) {
$dir = Split-Path $LogFile
if (-not (Test-Path $dir)) { New-Item -ItemType Directory -Path $dir -Force | Out-Null }
("{0} {1}" -f (Get-Date -Format 'yyyy-MM-dd HH:mm:ss'), $msg) | Add-Content -Path $LogFile
}
# 現在の同期ソース
$source = (& w32tm /query /source).Trim() -replace ',.*',''
if (-not $source -or $source -match 'Local CMOS|Free-running') {
$source = 'time.windows.com'; $synced = 0
} else { $synced = 1 }
# offset—stripchart(数字表示はロケール関係なし)
$offset = $null
try {
foreach ($line in (& w32tm /stripchart /computer:$source /dataonly /samples:1)) {
if ($line -match '([+-]\d+\.\d+)\s*s') { $offset = [double]$Matches[1] }
}
} catch { Write-Log "stripchart failed: $_" }
# fallback: サービス計算 offset(us)
if ($null -eq $offset) {
try {
$us = (Get-Counter '\Windows Time Service\Computed Time Offset' -ErrorAction Stop).CounterSamples[0].CookedValue
$offset = [math]::Round($us / 1e6, 9)
} catch { Write-Log "Computed Time Offset counter failed: $_" }
}
# Stratum/Root Delay/Leap(英語ラベル基準)
$stratum = $null; $rootDelay = $null; $leap = $null
try {
$status = (& w32tm /query /status /verbose) -join "`n"
if ($status -match 'Stratum:\s*(\d+)') { $stratum = [int]$Matches[1] }
if ($status -match 'Root Delay:\s*([\d\.]+)s') { $rootDelay = [double]$Matches[1] }
if ($status -match 'Leap Indicator:\s*(\d+)') { $leap = [int]$Matches[1] }
} catch { Write-Log "query/status failed: $_" }
$data = @{
ntp_last_offset = $offset
ntp_root_delay = $rootDelay
ntp_stratum = $stratum
ntp_leap_status = $leap
ntp_synced = $synced
ntp_reachable = [int]($null -ne $offset)
}
$data[$DimKey] = (Invoke-RestMethod -Uri 'http://169.254.169.254/latest/meta-data/serverName' -TimeoutSec 5).Trim()
$clean = @{}; foreach ($k in $data.Keys) { if ($null -ne $data[$k]) { $clean[$k] = $data[$k] } }
$body = @{ cw_key = $CwKey; data = $clean } | ConvertTo-Json -Depth 5 -Compress
Write-Host "[payload] $body"
if ($DryRun) { Write-Log "DryRun payload=$body"; return }
# IAM署名 v2後に転送
$ts = [string][long]([DateTimeOffset]::UtcNow.ToUnixTimeMilliseconds())
$uriPath = ([Uri]$CwEndpoint).AbsolutePath
$sigMsg = "POST $uriPath`n$ts`n$AccessKey"
$hmac = New-Object System.Security.Cryptography.HMACSHA256
$hmac.Key = [Text.Encoding]::UTF8.GetBytes($SecretKey)
$signature = [Convert]::ToBase64String($hmac.ComputeHash([Text.Encoding]::UTF8.GetBytes($sigMsg)))
$headers = @{
'x-ncp-apigw-timestamp' = $ts
'x-ncp-iam-access-key' = $AccessKey
'x-ncp-apigw-signature-v2' = $signature
}
try {
Invoke-RestMethod -Uri $CwEndpoint -Method Post -Headers $headers -ContentType 'application/json' -Body $body -TimeoutSec 5 | Out-Null
Write-Log "send OK offset=$offset stratum=$stratum leap=$leap synced=$synced"
} catch {
Write-Log "send failed: $_"
exit 1
}
schtasks登録
スクリプトを1分間隔で実行するための schtasks登録方法は、次の通りです。
schtasks /Create /TN "NTP-Metric" /TR "powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\ntp_metric.ps1" /SC MINUTE /MO 1 /RU SYSTEM /RL HIGHEST /F
収集確認
schtasksを登録してから約2~3分後、Cloud Insightコンソールでウィジェットを作成してデータが正常に収集されるか確認します。
- コンソールで、Menu > All Services > Management & Governance > Cloud Insight > Dashboardに移動します。
- [ダッシュボード作成] をクリックしてダッシュボード名を入力した後、 [作成] をクリックします。
- 事前に作成しておいた Custom Schemaは Product Typeを、確認するメトリックは Metricを選択します。
- ウィジェットに1分間隔でデータポイントが表示されたら、正常に収集されていることを意味します。
アラームの推奨しきい値
Custom Metricに基づくアラーム設定において、推奨されるしきい値は次の通りです。
| メトリック | Warning | Critical | 説明 |
|---|---|---|---|
ntp_last_offset |
±0.1s超過 | ±1.0s超過 | 直近の測定された時刻ズレ |
ntp_stratum |
4を超過 | 6を超過 | Stratumレベルの過剰 |
ntp_synced |
- | 0 | 同期失敗 |
ntp_reachable |
- | 0 | NTPサーバ到達不可 |
上記のメトリック例およびしきい値は一般的なウェブサービスに基づくものであり、金融や取引システムなどでは、より厳格な基準が必要となる場合があります。環境に合わせて調整し、ご利用ください。
アラーム設定
上記の方法で送信された値は、Cloud Insightに Custom Schemaとして収集されます。アラームを設定するには、Cloud Insightコンソールで登録されたメトリックに対して上記の推奨しきい値を用いてアラームルールを作成します。
Custom Schemaと SendData APIの詳しい使用方法は、以下のガイドをご参照ください。