--- title: "Cloud Insight FAQ" slug: "cloudinsight-faq" tags: ["Cloud Insight", "FAQ"] updated: 2026-10-08T07:17:19Z published: 2026-10-08T07:17:19Z canonical: "guide.ncloud-docs.com/cloudinsight-faq" --- > ## Documentation Index > Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt > Use this file to discover all available pages before exploring further. # Cloud Insight FAQ Available in Classic and VPC You can find answers to FAQs about Cloud Insight. If you can't find the answer you're looking for in the following FAQs, check out the user guides. ## Q. What services allow me to view performance metrics using Cloud Insight? **A.** For more information about services that allow you to view performance metrics using Cloud Insight, see [Services that provide performance metrics](/docs/en/cloudinsight-spec#%EC%84%B1%EB%8A%A5%EC%A7%80%ED%91%9C%EC%A0%9C%EA%B3%B5%EC%84%9C%EB%B9%84%EC%8A%A4). ## Q. What are the meanings of Metric and Dimension? **A.** Metric means a value that you want to handle, while a Dimension means properties of a Metric. You can use Dimensions to define which server a Metric belongs to, where it is located, or what the value represents. ## Q. How long do the data collection cycle and the data aggregation interval take? - The data collection cycle of the Metric is 1 minute. The collection cycle refers to a cycle in which the target resource sends data to Cloud Insight, independent of the aggregation interval. - The data is saved as collected in Cloud Insight, and is computed using various types of aggregation methods at each aggregation interval. - Aggregation intervals are executed in intervals of 1 minute (Min1), 5 minutes (Min5), 30 minutes (Min30), 2 hours (Hour2), and 1 day (Day1). - Aggregation functions such as AVG (average value), MIN (minimum value), MAX (maximum value), COUNT (number of collections), and SUM (total) of the current aggregation interval are supported. - Example: Assuming the following data has been collected between 00:01 and 00:05, the following table shows the expected values of the 1-minute (Min1) and 5-minute (Min5) aggregation periods: ``` 00:01:00 - 1 00:02:00 - 2 00:03:00 - 3 00:04:00 - 4 00:05:00 - 5 ``` **Aggregation interval: 1 minute (Min1)** | Time | AVG (average value) | MIN (minimum value) | MAX (maximum value) | COUNT (number of collections) | SUM (total) | | --- | --- | --- | --- | --- | --- | | 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 | **Aggregation interval: 5 minutes (Min5)** | Time | AVG (average value) | MIN (minimum value) | MAX (maximum value) | COUNT (number of collections) | SUM (total) | | --- | --- | --- | --- | --- | --- | | 00:01 | 3 | 1 | 5 | 5 | 15 | ## Q. How can I create and use Custom Schema? **A.** Cloud Insight supports various Metric types and indicators, but the Metric you want may not be supported. In this case, you can use Custom Schema and SendData APIs to freely aggregate and collect the metrics you want, and use them in Cloud Insight. Note For more information about Custom Schema and SendData APIs, see the following guides: - [Custom Schema user guide](https://guide.ncloud-docs.com/docs/en/cloudinsight-use-customschema) - [SendData API guide](https://api.ncloud-docs.com/docs/en/management-cloudinsight-senddata) The detailed quickstart for using Custom Schema and Send Data APIs is as follows: #### 1. Create Custom Schema See the [Custom Schema user guide](https://guide.ncloud-docs.com/docs/en/cloudinsight-use-customschema) to create Custom Schema. After creating Custom Schema, click **[Examples of data transfer]** to check the **[Sample Data format to be transferred]**. The following are examples of Custom Schema for collecting the usage of Filesystem: (As Cloud Insight provides the Filesystem-type metrics, note that this is for illustrative purposes only.) **Example of the input value when Custom Schema is created** ``` Product Type: CustomFilesystem   Set collection target:     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 ``` **Example of the Sample Data format after Custom Schema is created** ``` { "cw_key": "801142312146182144", "data": { "instanceName": "fe79g8ahkab", "totalSize": 893, "availSize": 260, "usedSize": 405, "mountPoint": "gh1apxl4it9" } } ``` #### 2. Aggregate the metrics you want Directly aggregate metric values that fit the Custom Schema data format. Create a script to access the target server and derive the desired value. The following is an example of writing a script that follows the example above: ``` #!/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. Transfer Custom Metric Data through the SendData APIs Organize the metric values you have aggregated directly according to the data transfer format of Custom Schema, and transfer them to Cloud Insight using [SendData APIs](https://api.ncloud-docs.com/docs/en/management-cloudinsight-senddata). The following is an example of the Custom Schema data transfer format that follows the example above: ``` { "cw_key": "801142312146182144", "data": { "instanceName": "myServer", "totalSize": 1180, "availSize": 1150, "usedSize": 30, "mountPoint": "/userDevice" } } ``` #### 4. Check the data collected in Cloud Insight You can check Custom Metric Data transferred to Cloud Insight when creating a Dashboard Widget, Event Rule, or Template in the Cloud Insight console. #### 5. Repeat it at a 1-minute interval Once you have verified that the Custom Product Type, ID Dimension, Dimensions, and Metric are displayed correctly in Cloud Insight, repeat steps 2 and 3 above every minute using an appropriate method, such as Crontab, to collect metric values in Cloud Insight. ## Q. What is agent_status metric? **A.** The agent_status metric is a metric that can monitor the status of Cloud Insight Agent. The conditions for the agent_status metric are as follows: - `0`: When the Agent is normal. - `1`: When data is not collected for 3 minutes but the ping check succeeds. - `2`: When data is not collected for 3 minutes and the ping check fails. The agent_status values are processed as branches rather than consecutively. If the server is stopped while the Agent is operating normally, the agent_status value changes from `0` to `2` rather than from `0` through `1` to `2`. Note that the ping check is performed against your server by a separate management server (ping check monitoring server). As ping check failure is not the same as a server failure, if the `agent_status` value is `2`, you need to check the Network as well as the Agent and server status. ## Q. What is the difference in data between Process data and Plugin Process data in Server (VPC)? **A.** Process refers to the data related to the server's TOP 10 processes. Plugin process refers to the data related to the specific processes set by the user. Accordingly, we recommend that you use the Plugin Process feature to monitor specific processes. ## Q. How can I use the Server (VPC)'s Plugin (File/Process/Port) features? **A.** To use the Plugin feature, you must set up monitoring for specific files, processes, or ports through APIs first. See the following APIs for Plugin configuration and viewing: - Register/view File Plugin: [AddFilePlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-addfileplugin), [RemoveFilePlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-removefileplugin), [UpdateFilePlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-updatefileplugin), [GetFilePlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-getfileplugin), and [GetAllFilePlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-getallfileplugin) - Register/view Port Plugin: [AddPortPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-addportplugin), [RemovePortPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-removeportplugin), [UpdatePortPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-updateportplugin), [GetPortPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-getportplugin), and [GetAllPortPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-getallportplugin) - Register/view Process Plugin: [AddProcessPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-addprocessplugin), [RemoveProcessPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-removeprocessplugin), [UpdateProcessPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-updateprocessplugin), [GetProcessPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-getprocessplugin), and [GetAllProcessPlugin](https://api.ncloud-docs.com/docs/en/management-cloudinsight-getallprocessplugin) Plugin (File/Process/Port) Metric is Extended and requires detailed monitoring settings of the server. #### See the detailed examples as follows: (It is described based on the Plugin Process. It is similarly applied to Plugin File and Plugin Port.) 1. Check if detailed monitoring is enabled on the server. 2. Register the desired process for monitoring to Cloud Insight through AddProcessPlugin APIs. For configList of Payload, see ps -ef on Linux or tasklist on Windows. **Payload examples** ``` payload = { "configList": [ "*httpd*", "*java*" ], "instnaceNo": "1234567", "type": "VPCServer" } ``` Note An asterisk (*) can only be used while setting Plugin Processes. When a process name is set with a string containing an asterisk (*), the PID list of all matching processes becomes the target. Note When calling the AddPluginProcess APIs, only 1 instanceNo can be registered at a time. If multiple instanceNo values are targeted, APIs are called multiple times. 3. Check if the Plugin Process configList is normally registered in Cloud Insight through GetAllProcessPlugin. 4. If the Plugin Process configList is normally registered, you can check the registered process name in the Cloud Insight Console after about 2 to 3 minutes. When setting the Dashboard's Widget, the process name for the Target InstanceName to set Plugin Process is exposed as Dimensions. 5. If you need to change or delete the Plugin Process, use UpdateProcessPlugin or RemoveProcessPlugin. Note If you delete Plugin Process, it does not disappear from Dimension right away. For details, see [Cloud Insight troubleshooting](/docs/en/cloudinsight-troubleshoot-event#EventRule%EC%83%9D%EC%84%B1%EC%8B%9C%EC%82%AD%EC%A0%9C%ED%95%9CFileProcessPortPlugin%EC%9D%98%EB%94%94%EB%A9%98%EC%85%98%EB%85%B8%EC%B6%9C). ## Q. What is the default value if I don't select the Metric Dimension? - The Dimension selection differs according to the Metric. Example: When the Metric is Server, there is only 1 Dimension, so there is no optional Dimension. When the Metric is CPU, you can select the Dimension of `cpu_idx: 0~N` according to the number of CPUs. - If selectable Dimensions are available but none are selected, values corresponding to the Aggregation settings are displayed for all selectable Dimensions. Example: If no Dimension was selected under the following conditions ``` Metric: CPU/used_rto Dimension: cpu_idx: 0, cpu_idx: 1 Aggregation: AVG ``` It is set as the average used_rto of `cpu_idx: 0` and `cpu_idx: 1` according to the Aggregation settings. ## Q. If I have set the monitoring items and conditions of the Event Rule as Conditions of multiple Metrics, do all the conditions need to be met for the event to occur? **A.** If multiple Conditions of multiple Metrics are set in the Event Rule, each Condition operates under the OR condition. In other words, if the Condition for an individual Metric added to the monitoring items and conditions is met, the event occurs. In Cloud Insight, if multiple Metrics are selected as the monitoring items and conditions when configuring Event Rules, then Event Rules that correspond to the number of selected Target*Metrics are actually created. If you click **[View all rules]** when creating Event Rules, or after selecting a created Event Rule, you can view all the Event Rules that were actually created. Example: If 2 Conditions are configured to the Event Rule for 1 VM, and the Auto Scaling Policy is set as the action, then 2 Event Rules are actually created as follows: - Execute the Auto Scaling Policy when avg_cpu_used_rto for the VM exceeds 50%. - Execute the Auto Scaling Policy when mem_usert for the VM exceeds 50%. Thus, if either avg_cpu_used_rto or mem_usert exceeds 50%, an event is triggered and the Auto Scaling Policy is executed. ## Q. How is mem_usert of the Server (VPC) collected? **A.** The mem_usert value refers to the percentage of memory used compared to the total memory, and the calculation formula is as follows: ``` 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. How is the Filesystem Type metric collected? **A.** Metrics in the Filesystem Type are registered with Mountpoint Name as a Dimension and can be collected when the following criteria are met: - A separate partition or device formatted with 1 of the following file systems: ext3, ext4, or xfs (based on UUID) ``` > blkid /dev/xvda1: UUID="f95bed0a-11af-4b2c-bfcc-4afb91a68fc1" TYPE="xfs" /dev/xvda2: UUID="0692fdb8-bb3c-4094-83f0-fe95a339b8c1" TYPE="xfs" ``` - Actually mounted ``` > df -h /dev/xvda2 49G 3.6G 46G 8% / /dev/xvda1 1014M 183M 832M 18% /boot ``` Note If the Filesystem is not formatted with ext3, ext4, or xfs, you can register it in /etc/fstab and mount it to collect the metrics. ``` > cat /etc/fstab /dev/xvdb /mnt/vol vfat defaults 0 0 ``` The mountpoint recorded in /etc/fstab must exactly match the mountpoint resulting from the actual df -h command. Example: /logs/ != /logs ## Q. How do I install the Agent? Note The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the `ps -ef | grep agent` command. Proceed according to the installed path. **A.** Access your VPC server and check the method for your OS. Note Installation domains are only accessible from VPC servers. To access it from the Internet environment, use the NAVER Cloud Platform open source site. - Linux - Download installation package: https://nsight.ncloud.com/agent_controller_linux_ncp.tar.gz - Unzip in `/home1/nbpmon/`: tar -zxvf agent_controller_linux_ncp.tar.gz - Run the Agent with root permissions: /home1/nbpmon/agent_controller_linux/install_agent.sh pub - Linux Bare Metal - Download installation package: https://nsight.ncloud.com/agent_controller_linux_pub_common_bm.tar.gz - Unzip in `/home1/nbpmon/`: tar -zxvf agent_controller_linux_pub_common_bm.tar.gz - Run the Agent with root permissions: /home1/nbpmon/agent_controller_linux/install_agent.sh vpc - Window Caution After downloading or unzipping, the installation folder must be under the `NBP` folder. The following is an example of a wrong installation path: `C:\Program Files (x86)\NBP\agent_controller_windows_ncp\agent_controller_windows` The following is the correct installation path: `C:\Program Files (x86)\NBP\agent_controller_windows` - Download installation package: https://nsight.ncloud.com/agent_controller_windows_ncp.zip - Unzip: unzip agent_controller_windows_ncp.zip - Run the Agent: agent_controller_windows/install_agent.bat pub - Window Bare Metal - Download installation package: https://repo-nsight.ncloud.com/agent_controller_windows_pub_bm.zip - Unzip: unzip agent_controller_windows_pub_bm.zip - Run the Agent: agent_controller_windows\install_agent.bat vpc - Install GPU insight in the KVM/BM Linux environment - Download installation package: wget --no-cache http://init.ncloud.com/gpu/gpu_insight/install_gpu_insight.sh - Add run permissions: chmod +x install_gpu_insight.sh - Run the Agent with root permissions: ./install_gpu_insight.sh ## Q. How do I install the Agent in the Classic environment? Note The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the `ps -ef | grep agent` command. Proceed according to the installed path. **A.** Access your Classic server and see the method for your OS. - Linux - Download installation package: https://repo-nsight.ncloud.com/agent_controller_linux_ncp.tar.gz - Unzip in `/home1/nbpmon/`: tar -zxvf agent_controller_linux_ncp.tar.gz - Run the Agent with root permissions: /home1/nbpmon/agent_controller_linux/install_agent.sh pub-classic - Linux Bare Metal - Download installation package: https://repo-nsight.ncloud.com/agent_controller_linux_pub_common_bm.tar.gz - Unzip in `/home1/nbpmon/`: tar -zxvf agent_controller_linux_pub_common_bm.tar.gz - Run the Agent with root permissions: /home1/nbpmon/agent_controller_linux/install_agent.sh classic - Window Caution After downloading or unzipping, the installation folder must be under the `NBP` folder. The following is an example of a wrong installation path: `C:\Program Files (x86)\NBP\agent_controller_windows_ncp\agent_controller_windows` The following is the correct installation path: `C:\Program Files (x86)\NBP\agent_controller_windows` - Download installation package: https://repo-nsight.ncloud.com/agent_controller_windows_ncp.zip - Unzip: unzip agent_controller_windows_ncp.zip - Run the Agent: agent_controller_windows/install_agent.bat pub-classic - Window Bare Metal - Download installation package: https://repo-nsight.ncloud.com/agent_controller_windows_pub_bm.zip - Unzip: unzip agent_controller_windows_pub_bm.zip - Run the Agent: agent_controller_windows\install_agent.bat classic ## Q. Where can I download the Agent script file for Linux? Note The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the `ps -ef | grep agent` command. Proceed according to the installed path. **A.** Click [to_stop_start_uninstall_agent.zip](https://github.com/NaverCloudPlatform/NSightAgent/raw/master/to_stop_start_uninstall_agent.zip) and download. Unzip the downloaded file and locate the script files in the Agent directory (/home1/nbpmon/agent_controller_linux/). You can start, stop, install, or delete the Agent through the script. ## Q. Do I have to have the Agent installed to monitor data in Server (VPC)? **A.** You need the Agent to collect performance metrics in Server (VPC). However, since the Agent is built in by default when creating servers, you don't need to install it separately. Note that if the Agent is deleted or does not run due to the user settings, it is impossible to collect data through Cloud Insight. ## Q. How do I check if the Agent is in operation? **A.** Check the method for your OS. - Linux Check whether the Agent process is alive through `ps -ef | grep agent`. If the agent_updater.py and agent.py processes are running, the Agent is working normally. - Window Check the nsight2_agent service's status. If the service has started, then it means that the Agent is in operation. ## Q. How do I stop or start the Agent? Note The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the `ps -ef | grep agent` command. Proceed according to the installed path. **A.** See how to stop/start the Agent for your OS. - Linux - Stop the Agent: Run /home1/nbpmon/agent_controller_linux/stop_agent.sh. - Start the Agent: Run /home1/nbpmon/agent_controller_linux/start_agent.sh. - Restart the Agent: Run /home1/nbpmon/agent_controller_linux/restart_agent.sh. - Window - Stop the Agent: Run C:\Program Files(x86)\NBP\agent_controller_windows\agent.bat stop. - Start the Agent: Run C:\Program Files(x86)\NBP\agent_controller_windows\agent.bat start. ## Q. How do I delete the Agent? Note The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the `ps -ef | grep agent` command. Proceed according to the installed path. **A.** See how to delete the Agent for your OS. - Linux You need to download the script file related to the Agent to delete it on Linux. See [Q. Where can I download the Agent script file for Linux?](/docs/en/cloudinsight-faq#QLinux%EC%9A%A9Agentscript%ED%8C%8C%EC%9D%BC%EC%9D%80%EC%96%B4%EB%94%94%EC%97%90%EC%84%9C%EB%8B%A4%EC%9A%B4%EB%A1%9C%EB%93%9C%ED%95%A0%EC%88%98%EC%9E%88%EB%82%98%EC%9A%94) first and download the script file and, see [Q. How do I stop or start the Agent?](/docs/en/cloudinsight-faq#QAgent%EB%A5%BC%EC%A4%91%EB%8B%A8%ED%95%98%EA%B1%B0%EB%82%98%EC%8B%9C%EC%9E%91%ED%95%98%EB%A0%A4%EB%A9%B4%EC%96%B4%EB%96%BB%EA%B2%8C%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98%EC%9A%94) and stop the Agent, and run /home1/nbpmon/agent_controller_linux/uninstall_agent.sh. - Window See [Q. How do I stop or start the Agent?](/docs/en/cloudinsight-faq#QAgent%EB%A5%BC%EC%A4%91%EB%8B%A8%ED%95%98%EA%B1%B0%EB%82%98%EC%8B%9C%EC%9E%91%ED%95%98%EB%A0%A4%EB%A9%B4%EC%96%B4%EB%96%BB%EA%B2%8C%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98%EC%9A%94) and stop the Agent, and run C:\Program Files (x86)\NBP\agent_controller_windows\agent.bat uninstall. ## Q. How do I reinstall the Agent? Note The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the `ps -ef | grep agent` command. Proceed according to the installed path. **A.** If installation has not been completed properly, you can reinstall the Agent in the following way: - Linux 1. Stop the Agent Run `/home1/nbpmon/agent_controller_linux/stop_agent.sh`. 2. Delete the Agent Run `/home1/nbpmon/agent_controller_linux/uninstall_agent.sh`. 3. Delete the Agent installation path Delete `/home1/nbpmon/agent_controller_linux`. Be sure to back up any necessary files. 4. Install the Agent For more information on how to install the Agent, see [Q. How do I install the Agent?](/docs/en/cloudinsight-faq#QAgent%EB%A5%BC%EC%84%A4%EC%B9%98%ED%95%98%EB%A0%A4%EB%A9%B4%EC%96%B4%EB%96%BB%EA%B2%8C%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98%EC%9A%94) - Window ``` C:\Program Files(x86)\NBP\agent_controller_windows\agent.bat stop ``` ``` C:\Program Files (x86)\NBP\agent_controller_windows\agent.bat uninstall ``` 1. Stop the Agent Run the following command: 1. Delete the Agent Run the following command: 1. Delete the Agent installation path Delete `C:\Program Files (x86)\NBP\agent_controller_windows`. Be sure to back up any necessary files. 2. Install the Agent For more information on how to install the Agent, see [Q. How do I install the Agent?](/docs/en/cloudinsight-faq#QAgent%EB%A5%BC%EC%84%A4%EC%B9%98%ED%95%98%EB%A0%A4%EB%A9%B4%EC%96%B4%EB%96%BB%EA%B2%8C%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98%EC%9A%94) ## Q. How do I check the Agent's logs? Note The Agent installation path may vary depending on the OS version. For Linux, you can check the path where the Agent is installed through the `ps -ef | grep agent` command. Proceed according to the installed path. **A.** The log files can be viewed as follows, depending on your OS: - Linux You can check log files in /home1/nbpmon/agent_controller_linux/logs. - Window You can check log files in C:\Program Files (x86)\NBP\agent_controller_windows\logs. ## Q. What should I do to adjust the log size of the Agent and the number of backups? **A.** You can adjust the log size of the Agent and the number of backups as follows: 1. Check the logger.py file according to your OS. - Linux /home1/nbpmon/agent_controller_linux/logger.py - Window C:\Program Files (x86)\NBP\agent_controller_windows\logger.py 2. Edit `LOG_SIZE_IN_BYTES` and `LOG_BACKUP_COUNT` among logger.py file details. ``` ... 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. Restart Agent after editing the logger.py file. ## Q. Is it necessary to understand how the actions are linked to each other to define permissions by actions using user-created policies? **A.** When you select specific actions to grant to a sub account, the system offers a feature to automatically select the related actions as well. ## Q. When receiving event information in SMS, what contents are contained in the SMS? **A.** Cloud Insight provides an SMS notification feature for cases where an event occurs, the event remains unresolved, and the event ends. The Message formats for each situation are as follows: | Send status | SMS Format | | --- | --- | | When the event occurs | [Ncloud] ${RuleName} ${Level} ${InstanceName} ${Condition} | | When reminding of the event | [Ncloud][Remind] ${RuleName} ${Level} ${InstanceName} ${Condition} | | When the event ends | [Ncloud][Resolve] ${RuleName} ${InstanceName} ${Condition} | SMS is sent with minimal information due to message capacity limitations according to message characteristics. If you need more information, it is recommended to use [Integration](https://guide.ncloud-docs.com/docs/en/cloudinsight-use-integration). ## Q. Cloud DB products are in use. How should I interpret the contents of the SMS that are automatically transferred when an event occurs? **A.** As metrics provided by each Cloud DB type are different, check the console page for details. The contents of the mainly used metrics are as follows: | 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 | The test DB Server is down. | | Cloud DB for MySQL(VPC) | mysql_slavedelay | [Ncloud] DB Down:0, Threshold:== 0, Duration:1min WARNING test mysql_slavedelay | Replication of the latest data from Master to Slave is delayed (data up to 1 minute ago is reflected). | | Cloud DB for MySQL(VPC) | mysql_slaverun | [Ncloud] DB Down:0, Threshold:== 0, Duration:1min WARNING test mysql_slaverun=0 | The Slave server of the test DB is not synchronized. | ## Q. The data on the Event page are different from actual event data. Why is this? **A.** The graph displayed when viewing events on the Event page in the console uses different aggregation intervals (such as `Min5`) depending on the event start and end times. To view the data that actually triggered the event rule, you must view the data with an aggregation interval of Min1. Therefore, you can check the Min1 data by configuring the Dashboard separately or by viewing the event rule on the Event Rule page and setting the viewing period to within 1 hour in the Details menu. ## Q. What are the criteria for the process name collecting ProcessPlugin? **A.** In the case of ProcessPlugin, information on matching process names is collected based on /proc/{pid}/stat or /proc/{pid}/cmdline. ## Q. Is there a way to stop event rule actions at specific times? **A.** You can use the Planned Maintenance feature to stop actions following the occurrence of an Event. Set the dimension for each product related to the event rule you wish to disable. ## How can I monitor a server's time offset (NTP offset) in Cloud Insight? **A.** To monitor the time offset, first create a Custom Schema in Cloud Insight, and then collect metrics using a script appropriate for the operating system (Linux or Windows). ### Create Custom Schema [Create a Custom Schema](/docs/en/cloudinsight-use-customschema) to store the collected NTP metrics. Enter the following items in the 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 | Note Because the metrics collected on Linux and Windows differ, configure the appropriate metrics for each environment to ensure proper operation. ### 1. Linux environment (based on `chrony`) This method collects the synchronization status of the chrony service already running on the system as a Custom Metric without requiring any additional packages. To check NTP metrics in a chrony environment: ``` $ 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 ``` **Key metrics to collect** | Field | Meaning | | --- | --- | | `ntp_system_time` | Local-server time offset (s). | | `ntp_last_offset` | Time offset measured at the last synchronization (s). | | `ntp_rms_offset` | Long-term average of offset (s). | | `ntp_root_delay` | Round-trip delay to the stratum 0 clock server (s). | | `ntp_stratum` | Server stratum level. | | `ntp_leap_status` | Synchronization/leap second status (Normal = normal, transmitted value = integer 0). | **Collect script** (`/usr/local/bin/ntp_metric.sh`) ``` #!/bin/bash set -euo pipefail CW_KEY="YOUR_CW_KEY" # 19-digit numeric key issued when creating the Custom Schema ACCESS_KEY="YOUR_NCP_ACCESS_KEY" SECRET_KEY="YOUR_NCP_SECRET_KEY" DIM_KEY="YOUR_ID_DIMENSION_KEY" # ID Dimension name registered in the Custom Schema 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 "Failed to run chronyc (chrony not installed)"; exit 1; } # System time: "X seconds slow/fast" → slow values are negative 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:-}" # Remove the leading "+" to prevent positive offsets from breaking the JSON number format 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" ``` #### Register Cron Save the collection script as `/usr/local/bin/ntp_metric.sh` and make it executable. Add it to Cron to run every minute. ``` # 1. Grant execution permissions chmod +x /usr/local/bin/ntp_metric.sh # 2. After running crontab -e, add the following line (runs every minute): * * * * * /usr/local/bin/ntp_metric.sh >/dev/null 2>&1 ``` #### Verify data collection About 2-3 minutes after registering the script with Cron, create a widget in the Cloud Insight console to verify that data is being collected properly. 1. In the console, navigate to **Menu** > **All Services** > **Management & Governance** > **Cloud Insight** > **Dashboard**. 2. Click **[Create dashboard]**, enter a dashboard name, and click **[Create]**. 3. For **Product Type**, select the Custom Schema created earlier. For **Metric**, select the metric you want to view. 4. If data points appear in the widget at 1-minute intervals, the data is being collected properly. #### Recommended notification thresholds The recommended thresholds for setting up Custom Metric-based notifications are as follows: | Metric | Warning | Critical | Description | | --- | --- | --- | --- | | `ntp_last_offset` | Outside ±0.1 s | Outside ±1.0 s | Latest measured time offset. | | `ntp_stratum` | 4 or more | 6 or more | Excessive Stratum level. | | `ntp_leap_status` | Other than 0 | - | Leap second imminent or synchronization error. | Note In addition to the chrony method above, you can use a Telegraf input plugin or Python with a library such as ntplib to collect measurements directly from multiple NTP servers. If you operate a standardized collector or need to compare measurements across multiple NTP servers, select the method appropriate for your environment. ### 2. Windows environment (based on `w32tm`) This method collects NTP metrics using the w32tm command and performance counters built into Windows. **Key metrics to collect** | Field | Meaning | | --- | --- | | `ntp_last_offset` | Most recently measured time offset (s). | | `ntp_root_delay` | Round-trip delay to the stratum 0 clock server (s). | | `ntp_stratum` | Server stratum level. | | `ntp_leap_status` | Synchronization/leap second status (0=Normal). | | `ntp_synced` | NTP synchronization status (1 = synchronized, 0 = failed). | | `ntp_reachable` | Reference NTP server reachability (1 = reachable, 0 = failed). | **Collect script** (`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', # 19-digit numeric key issued when creating the Custom Schema [string]$AccessKey = 'YOUR_NCP_ACCESS_KEY', [string]$SecretKey = 'YOUR_NCP_SECRET_KEY', [string]$DimKey = 'YOUR_ID_DIMENSION_KEY', # ID Dimension name registered in the Custom Schema [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 } # Current synchronization source $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 (numeric output is locale-independent) $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: Service-calculated 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, and Leap (based on English labels) $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 } # Sign with IAM Signature v2 before sending $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 } ``` #### Register schtasks To register schtasks to run the collection script every minute: ``` 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 ``` #### Verify data collection About 2-3 minutes after registering the script with schtasks, create a widget in the Cloud Insight console to verify that data is being collected properly. 1. In the console, navigate to **Menu** > **All Services** > **Management & Governance** > **Cloud Insight** > **Dashboard**. 2. Click **[Create dashboard]**, enter a dashboard name, and click **[Create]**. 3. For **Product Type**, select the Custom Schema created earlier. For **Metric**, select the metric you want to view. 4. If data points appear in the widget at 1-minute intervals, the data is being collected properly. #### Recommended notification thresholds The recommended thresholds for setting up Custom Metric-based notifications are as follows: | Metric | Warning | Critical | Description | | --- | --- | --- | --- | | `ntp_last_offset` | Outside ±0.1 s | Outside ±1.0 s | Latest measured time offset. | | `ntp_stratum` | 4 or more | 6 or more | Excessive Stratum level. | | `ntp_synced` | - | 0 | Sync failed. | | `ntp_reachable` | - | 0 | NTP server unreachable. | Note The above metric examples and thresholds are based on general web service standards. Financial and trading systems may require stricter standards. Adjust and use them according to your environment. ### Notification settings Values transmitted using this method are collected in Cloud Insight as Custom Schema metrics. To set up a notification, create a notification rule for the registered metric in the Cloud Insight console using the recommended thresholds above. Note For more information about Custom Schema and SendData APIs, see the following guides: - [Custom Schema user guide](/docs/en/cloudinsight-use-customschema) - [SendData API guide](https://api.ncloud-docs.com/docs/en/management-cloudinsight-senddata)