Graph descriptions
Metrics graphs report key Snaplex node information. The table below lists the graphs in alphabetic order. The SnapLogic platform downsamples data to simplify the presentation.
| Graph title | Description |
|---|---|
| Active pipelines (count) | The number of pipelines currently running on this node. |
| Active threads (count) | The current number of live threads in the JVM. This includes both daemon and non-daemon threads. Generally, it's best to keep thread counts below 80% of the thread pool maximum. If counts are consistently high, investigate potential thread leaks or increase the thread pool size. |
| SnapLogic service use of combined committed memory (GiB) | The orange text and dotted line show the amount of physical memory available on the selected node in gibibytes. The blue line indicates heap average usage added to the green line for non-heap memory average usage. Generally, it's best to keep combined memory usage well below the physical RAM available on the node. If usage approaches the physical limit, consider increasing node memory or reducing concurrent pipeline executions. |
| Total use of node disks (%) | The average percentage of space used on all available mounts. Generally, it's best to keep disk usage below 80%. If usage is high, remove unnecessary files or increase available storage. |
| File descriptor use (%) | The average node use of the maximum number of configured file descriptors as a percentage. On Linux, file descriptors are used to open files and make network connections. Pipeline executions can encounter errors if the maximum number of descriptors isn't sufficient. Generally, it's best to keep file descriptor usage below 70%. If usage is high, investigate connection leaks or increase the file descriptor limit. |
| SnapLogic service use of heap memory (% max and GiB) |
The average percentage of the heap space allocated and used by the Snaplex service on the selected node. The orange text shows the maximum size set for JVM heap memory in gibibytes. The blue line indicates the average amount of committed (allocated) heap memory. The gold line shows the average amount of space used for heap memory. For Groundplexes, you can set the Max heap size when you create or update a Snaplex. Refer to the Java documentation for an explanation of the difference between heap and non-heap memory. Generally, it's best to keep post-garbage-collection heap usage below 75%. If usage is consistently high, increase the Max heap size or reduce concurrent pipeline executions. When a Snaplex node is in maintenance mode, some resources are still in use. Therefore, when viewing the node details in Monitor, you might notice relatively low memory consumption. |
| Network data received (KiB/sec) | The total amount of data coming in over the network to the Snaplex service measured in kibibytes per second. |
| Network data sent (KiB/sec) | The total amount of data sent over the network by the Snaplex service measured in kibibytes per second. |
| SnapLogic service use of non-heap memory (GiB) |
The non-heap space allocated and used by the Snaplex service on the selected node in gibibytes. The green line indicates the average amount of committed non-heap memory. The gold line shows the average amount of space used for non-heap memory. Refer to the Java documentation for an explanation of the difference between heap and non-heap memory. Generally, it's best to monitor for sustained growth without leveling off, which can indicate a class loader leak. Contact SnapLogic Support if non-heap memory grows continuously. |
| SnapLogic service use of node CPU (%) | The average percentage of the node's CPU capacity used by the Snaplex service. The
percentage reflects the CPU time used by the Snaplex service process compared with the total CPU
time available. Generally, it's best to keep service CPU usage below 70% sustained. If usage is consistently high, optimize pipeline logic or distribute workloads across additional nodes. Tip: Total CPU usage and Service CPU usage are measured separately and
change rapidly, so the relative percentages don't always align. Although the Service CPU is
often lower than Total CPU, it can appear higher because the downsampling algorithm selects different representative data points for each metric to preserve their individual visual characteristics.
|
| Last minute system load |
Only for nodes running on Unix-based operating systems. Not visible for nodes on Windows operating systems. Represents the 1 minute system load average, normalized by CPU core count. The values indicate: 0.5 — 50% CPU usage 1.0 — 100% CPU usage (fully saturated) Greater than 1.0 — CPU is overloaded (fully saturated with tasks waiting) Generally, it's best to keep normalized load below 0.7. Values consistently above 1.0 indicate the CPU is saturated, and you should consider scaling out to additional nodes. The normalized metric supports comparison of different node sizes. For example:
|
| Total use of node CPU (%) | The average percentage of node CPU capacity used over time by all processes running on
the node. The percentage reflects active time compared with the total time available. Generally, it's best to keep total CPU usage below 80% sustained. If usage is consistently high, identify resource-intensive processes or scale out to additional nodes. Tip: Total CPU usage and Service CPU usage are measured separately and
change rapidly, so the relative percentages don't always align. Although the Service CPU is
often lower than Total CPU, it can appear higher because the downsampling algorithm selects different representative data points for each metric to preserve their individual visual characteristics. |
Statistic downsampling
Because metric statistics include high volumes of data, the SnapLogic Platform downsamples them for visual representation. Most charts use the LTTB (Largest Triangle Three Buckets) algorithm, which intelligently selects representative data points that preserve the visual shape and key features of the time series. Network received and Network sent charts use time-interval averaging instead of LTTB.
For charts using LTTB, the number of data points displayed depends on the selected time period:
| Time period | Maximum number of data points |
| Last 15 minutes | 90 |
| Last 1 hour | 120 |
| Last 2 hours | 120 |
| Last 4 hours | 120 |
| Last 12 hours | 144 |
| Last 1 day | 144 |
| Last 2 days | 144 |
| Last 1 week | 84 |
| Longer periods (custom date range, up to 45 days) | 135 |
The LTTB algorithm selects these data points to preserve peaks, valleys, and significant trends while reducing visual clutter. Data points are not evenly spaced in time—they are chosen based on their visual significance.