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はそのサーバの 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についても同様に適用されます)

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.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_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をインストールするにはどうすればいいですか?

**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ファイルはどこからダウンロードできますか?

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.bat stop
  

  2. Agent削除
     以下のコマンドを実行します。

  C:\Program Files (x86)\NBP\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.イベント発生内容と 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.**時刻ズレのモニタリングが必要な場合は、環境に適した方法を選択して構成してください。

方法1: chronyc、ntpq 結果を Custom Metricとして収集

追加のパッケージをインストールすることなく、既に動作中の chronyまたは ntpdの同期ステータスを Custom Metricとして収集する方法です。

chrony環境(Ubuntu 20.04+、RHEL 8+、Rocky Linux 8+など)

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

主な収集メトリック

• 収集スクリプト(/usr/local/bin/ntp_metric.sh)

  #!/bin/bash
  # chronyベースの NTPメトリックの収集および Cloud Insightへの送信
  TRACKING=$(chronyc tracking)
  
  SYSTEM_TIME=$(echo "$TRACKING" | grep "^System time" | awk '{print $4}')
  LAST_OFFSET=$(echo "$TRACKING" | grep "^Last offset" | awk '{print $4}')
  RMS_OFFSET=$(echo "$TRACKING"  | grep "^RMS offset"  | awk '{print $4}')
  ROOT_DELAY=$(echo "$TRACKING"  | grep "^Root delay"  | awk '{print $4}')
  STRATUM=$(echo    "$TRACKING"  | grep "^Stratum"     | awk '{print $3}')
  LEAP=$(echo       "$TRACKING"  | grep "^Leap status" | awk '{print $4}')
  
  case "$LEAP" in
    "Normal") LEAP_CODE=0 ;;
    "Insert") LEAP_CODE=1 ;;
    "Delete") LEAP_CODE=2 ;;
    *)        LEAP_CODE=3 ;;
  esac
  
  curl -X POST "https://cw.apigw.ntruss.com/cw_collector/real/data" \
    -H "Content-Type: application/json" \
    -d "{
      \"cw_key\": \"YOUR_CW_KEY\",
      \"data\": {
        \"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
      }
    }"
  

ntpd環境(旧バージョンシステム)

ntpd環境で NTPメトリックを収集する方法は、次の通りです。

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*169.254.169.123 10.71.8.61       2 u   42   64  377    0.234   -0.012   0.023
+169.254.169.124 10.71.8.62       2 u   38   64  377    0.241   -0.015   0.029

• 現在、同期済みのサーバーは * と表示されており、offset(9番目)と jitter(10番目)が主要指標

NTPQ_OUTPUT=$(ntpq -pn | grep "^\*")
OFFSET=$(echo "$NTPQ_OUTPUT" | awk '{print $9}')
JITTER=$(echo "$NTPQ_OUTPUT" | awk '{print $10}')
DELAY=$(echo  "$NTPQ_OUTPUT" | awk '{print $8}')

Cron登録

収集スクリプトを1分間隔で実行するための Cron登録方法は、次の通りです。

# crontab -e
* * * * * /usr/local/bin/ntp_metric.sh >/dev/null 2>&1

方法2: Telegraf Input Pluginを活用した収集

既に Telegrafベースのモニタリングを運用している場合や、標準化されたコレクターを導入する場合に推奨される方法です。

インストール(Ubuntu、Debian)

Ubuntuおよび Debian環境で Telegrafをインストールする方法は、次の通りです。

wget -qO- https://repos.influxdata.com/influxdata-archive_compat.key | sudo apt-key add -
echo "deb https://repos.influxdata.com/ubuntu focal stable" | sudo tee /etc/apt/sources.list.d/influxdata.list
sudo apt update && sudo apt install telegraf

• 上記の Telegraf repoは予告なく変更される可能性があるため、直接確認が必要

設定(/etc/telegraf/telegraf.conf)

NTPメトリックを収集するための Telegrafの設定方法は、次の通りです。

[[inputs.ntpq]]
  dns_lookup = false

# chrony input plugin(NCPインスタンスには chronyが標準実装されているため、推奨)
[[inputs.chrony]]
  metrics = ["tracking", "activity", "serverstats", "sources", "sourcestats"]

[[outputs.http]]
  url    = "https://cw.apigw.ntruss.com/cw_collector/real/data"
  method = "POST"
  data_format = "json"
  [outputs.http.headers]
    Content-Type        = "application/json"
    x-ncp-apigw-api-key = "YOUR_API_KEY"

主な収集メトリック

Telegrafを通じて収集される主なメトリックは、次の通りです。

実行と確認

Telegrafサービスの実行およびメトリックの収集を確認する方法は、次の通りです。

sudo systemctl enable --now telegraf
sudo telegraf --test --input-filter ntpq
sudo telegraf --test --input-filter chrony

方法3: Pythonで複数の NTPサーバを直接測定して収集

NTPクライアントデーモンとは独立して動作し、複数の NTPサーバを同時に比較して異常値を検知できる方法です。モニタリングの精度と可用性が最も重要な環境に適しています。

インストール(Python)

Pythonパッケージのインストール方法は、次の通りです。

pip3 install ntplib requests

スクリプト(/usr/local/bin/ntp_offset_monitor.py)

複数の NTPサーバの測定および Cloud Insightへの送信を行うスクリプトは、次の通りです。

#!/usr/bin/env python3
import ntplib, requests, socket
from datetime import datetime

NTP_SERVERS = ["time.google.com", "time.cloudflare.com", "kr.pool.ntp.org", "time.bora.net"]
CW_ENDPOINT = "https://cw.apigw.ntruss.com/cw_collector/real/data"
CW_KEY = "YOUR_CW_KEY"

def measure_ntp(server, timeout=3):
    client = ntplib.NTPClient()
    try:
        r = client.request(server, version=3, timeout=timeout)
        return {"server": server, "offset_ms": r.offset*1000, "delay_ms": r.delay*1000,
                "stratum": r.stratum, "success": 1}
    except (ntplib.NTPException, socket.gaierror, socket.timeout) as e:
        return {"server": server, "success": 0, "error": str(e)}

def send_to_cloud_insight(metrics):
    try:
        requests.post(CW_ENDPOINT, json={"cw_key": CW_KEY, "data": metrics}, timeout=5).raise_for_status()
    except requests.RequestException as e:
        print(f"[ERROR] Cloud Insight送信失敗: {e}")

def main():
    results = [measure_ntp(s) for s in NTP_SERVERS]
    ok = [r for r in results if r["success"] == 1]
    if ok:
        offsets = [r["offset_ms"] for r in ok]; delays = [r["delay_ms"] for r in ok]
        metrics = {
            "ntp_offset_avg_ms": sum(offsets)/len(offsets),
            "ntp_offset_max_ms": max(offsets, key=abs),
            "ntp_offset_spread_ms": max(offsets)-min(offsets),
            "ntp_delay_avg_ms": sum(delays)/len(delays),
            "ntp_servers_available": len(ok),
            "ntp_servers_total": len(NTP_SERVERS),
        }
        for r in ok:
            label = r["server"].replace(".", "_")
            metrics[f"ntp_offset_{label}_ms"] = r["offset_ms"]
            metrics[f"ntp_delay_{label}_ms"] = r["delay_ms"]
        send_to_cloud_insight(metrics)
        print(f"[OK] {datetime.now()} 送信完了")
    else:
        send_to_cloud_insight({"ntp_servers_available": 0, "ntp_servers_total": len(NTP_SERVERS)})
        print("[CRITICAL] すべての NTPサーバからのレスポンスに失敗")

if __name__ == "__main__":
    main()

Cron登録

スクリプトを1分間隔で実行するための Cron登録方法は、次の通りです。

# 1分間隔(NTPサーバの負荷を考慮)
* * * * * /usr/bin/python3 /usr/local/bin/ntp_offset_monitor.py >> /var/log/ntp_monitor.log 2>&1

アラームの推奨しきい値

Custom Metricに基づくアラーム設定において、推奨されるしきい値は次の通りです。

アラーム設定

上記の方法で送信された値は、Cloud Insightに Custom Schemaとして収集されます。アラームを設定するには、まず Cloud Insightコンソールで該当する Custom Schemaを登録し、登録されたメトリックに対して上記の推奨しきい値を用いてアラームルールを作成します。