---
title: "Troubleshoot metric issues"
slug: "cloudinsight-troubleshoot-metric"
updated: 2026-10-08T07:17:32Z
published: 2026-10-08T07:17:32Z
canonical: "guide.ncloud-docs.com/cloudinsight-troubleshoot-metric"
---

> ## 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.

# Troubleshoot metric issues

Available in Classic and VPC

You might run into the following problems when using Cloud Insight. Find out causes and possible solutions.

## Troubleshoot metric collection failure issues

Metric suddenly stops being collected.

#### Cause

Cloud Insight Agent may not work properly after a point when the disk usage of the root(/) path is above 99%.

#### Solution

Check or free up disk space on the path, then restart the Agent and verify that metrics are being collected properly.

## Troubleshoot inconsistency issues between server's proc_mem_usert and memory's mem_user

The `proc_mem_usert` in the server is higher than `mem_usert` in the memory.

#### Cause

The description for each metric is as follows:

| Item | Description |
| --- | --- |
| SERVER/proc_mem_usert | Memory usage rate for the entire process in the server. |
| MEMORY/mem_usert | Memory usage rate for the whole server. |

Generally, the server memory is used by multiple elements other than processes, so MEMORY/mem_usert tends to be greater than SERVER/proc_mem_usert.

`SERVER/proc_mem_usert` can be larger than `MEMORY/mem_usert` in the following cases:

- `SERVER/proc_mem_usert` is the sum of Local Memory occupied by the process + Shared Memory referred to by the process (RSS) used by all processes. If multiple processes refer to the same Shared Memory page, then the sum of RSS can be aggregated to be higher than the actual memory usage rate since they are added repeatedly to the RSS.
- The value for RSS is only updated when a process is using the CPU. Under a situation where the CPU load is very high, the CPU may not be assigned to each process. In this case, the update of RSS values may not be done properly. Thus, the sum of all RSS values may be greater than the actual memory usage rate.

#### Solution

To check the exact memory usage rate, use `MEMORY/mem_usert` rather than `SERVER/proc_mem_usert`.

## Troubleshoot inconsistency issues between CPU's used_rto are server's avg_cpu_used_rto

The CPU's used_rto is higher or lower than the server's avg_cpu_used_rto.

#### Cause

The description for each metric is as follows:

| Item | Description |
| --- | --- |
| CPU/used_rto | Utilization of each vCPU. Example: If there are 4 vCPUs, usage rate for one among cpu_idx: 0 to 3. |
| SERVER/avg_cpu_used_rto | The average CPU usage rate in the entire server. |

Due to the characteristics of the Linux architecture, a specific process has a tendency to use a specific CPU more, rather than using all CPUs equally. In such a case, `CPU/used_rto` may appear higher or lower than `SERVER/avg_cpu_used_rto`.

#### Solution

To check the exact average CPU usage rate of the server, use `SERVER/avg_cpu_used_rto` rather than `CPU/used_rto`.

## Troubleshoot inclusion issues for the metric uncollected during widget creation

The metric not collected during widget creation is included in the metrics list.

#### Cause

While creating the widget, the list of all metrics provided by the selected product is displayed. Even if a currently uncollected metric is added to the widget, it is displayed on the widget if it is collected later. However, metrics that require additional configuration for collection (such as detailed monitoring or Plugin settings), metrics that are not supported for the target resource, or metrics that are not available for certain operating systems in Server (Classic) or Server (VPC) may still be displayed.

#### Solution

After checking why the metric list is displayed, refer to the metric descriptions provided in the console.

              Note

              

If you're still having trouble finding what you need, click on the feedback icon and send us your thoughts and requests. We'll use your feedback to improve this guide.

## Troubleshoot Process Plugin metric collection failure issues

I've registered Process Plugin, but the related metric is not collected.

#### Cause

The process name may have been properly registered.

#### Solution

1. Check the PID of the process.

Check the PID of the process using the `ps -ef | grep <프로세스명>` command.

Example: If the process is `java -jar myapp.jar --port=8080`, run the following command:

```
ps -ef | grep java
```

Check the PID of the process in the result.

1. Check the exact run commands.

After checking the PID, you can view the run commands through `/proc/{pid}/cmdline`. In cmdline files, the arguments are stored separately by null byte (`\0`). To check all commands exactly, run the following command:

```
cat /proc/{pid}/cmdline | tr '\000' '\040'
```

For more information, see [man official documentation](https://man7.org/linux/man-pages/man5/proc_pid_cmdline.5.html).

1. Register the process name using a wildcard.

It is recommended to register the process name to a wide range using a wildcard (`*`) first, and then check if the metrics are being collected properly.

Example:

- To collect metrics for all processes that include `java`, register with `*java*`.
- After checking if the metrics are collected properly, register with a narrower range, like `*java -jar myapp.jar*`.

1. Use metrics for exact monitoring.

- For more precise monitoring, the `process_count` metric is more useful than the `is_process_up` metric.
- For more information, see the [Guide](https://guide.ncloud-docs.com/docs/en/cloudinsight-troubleshoot-event#servervpc%EC%9D%98-isprocessup%EC%9C%BC%EB%A1%9C-%EB%AA%A8%EB%8B%88%ED%84%B0%EB%A7%81-%EC%A4%91-%EC%9D%B4%EC%83%81%EC%9D%B4-%EC%97%86%EB%8A%94%EB%8D%B0-%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EB%B0%9C%EC%83%9D).