Snaplex Monitoring APIs

This topic might be out-of-date and is replaced by the following:

In this Article

Use Snaplex Monitoring APIs to query Snaplex and Java Component Container (JCC) wrapper information. The API returns information about Snaplex nodes.


  • If used without parameters, the API returns information about all the nodes in the organization (Org).
  • If plex_path or hostname are specified, the API returns information about only those nodes.


The Snaplex Monitoring API uses the following two parameters:

  • plex_path
  • hostname

Parameter Details

plex_pathThe path of the Snaplex.



hostnameThe path of the JCC host node. To specify multiple hosts, separate each hostname using a comma.

hostname=<hostname>,<hostname2>, ...,

Making Snaplex Monitoring API Requests

Using REST Clients

Consider the following Snaplex Monitoring API request. It uses plex_path as part of its query:

You can similarly use the hostnames for which you want to run your query, as shown below:

Using HTTP or HTTPS Calls

You can also send API requests as HTTP or HTTPS calls. Such calls must be structured as follows:


You need valid SnapLogic credentials to view the response to this API call.

Understanding Snaplex Monitoring API Responses

The API response shown below offers only the high-level view of an API call to a host. Additional response details are provided later in this document.

This section only describes those API response elements that are relevant to users.

Consider the following sample response:

The API request retrieves the following data headers:

  • statusLine: Indicates whether the request was successful and provides request-related data.
  • entity: Contains the actual API response.
    • response_map: Contains the API response map. This is the data for which you execute the API request.
    • headers: Contains metadata related to the API request and response.

The actual content of the API call is included in the response_map section. The remainder of this document details the contents of this section.

The Response Map Section

The response_map section of the API response contains the actual data returned as a result of API execution. This section is a map where the plex_path ("/snaplogic/shared/Test%20Cloud" in our example above) serves as the key. The map returned contains details associated with the plex_path.

The response_map section organizes Snaplex information into two sections:

  • cc_info: Provides information about the JCCs running on the specified Snaplex.
  • plex_info: Provides metadata related to the specified Snaplex.

Understanding JCC Information (cc_info)

The cc_info section of the API response comprises the following pieces of information about JCC nodes:

container_typeThe type of container: regular, mixed, or null.
downLists all the JCC nodes that were in down state and not processing requests when the API request was made​. Each item in the list is a map containing more details about the container. For example, a message is returned under alerts if your Snaplex version is deprecated and needs to be updated.
runningLists all the containers that were in running state when the API request was made. Each item in the list is a map containing more details about the container (JCC node).

The API response provides detailed data for each JCC node (in down or running state) as indicated below:

Container details are displayed as a series of key-value attribute pairs. This section provides information related to the attributes displayed in the container details response.

cc_info > Customer Info Maps (info_map)

Expanding the info_map section of the output displays the following details:

cc_info > Container Stats (stats)

Expanding the stats section of the output displays the following details:

Understanding Snaplex Information (plex_info)

Metadata associated with the Snaplex is displayed as indicated below:

Snaplex information is displayed as a series of key-value pairs. This section describes the values expected against each key.

active_threadThe total thread count of the VM.


The name of the broker in the FeedMaster.
container_type​The type of container: regular or FeedMaster​.
cpu_userThe CPU load at the time of collecting the cc_info stats from the JCC node. The value is stated as a percentage and is stated as in decimal form. The value may represent less than 1 percent of overall system CPU usage at the time of the API call.
current_loadThe number of current active Pipelines.

If true, then the notifications related to the concerned JCC node are not sent (even to the default recipient). Default: False.

dynamic_settingsSnaplex settings that are resolved at runtime. As of now, it displays only log settings associated with the Snaplex.
environmentThe name of the environment to which the Snaplex belongs. This detail is taken from the data you provided when you created the Snaplex in SnapLogic.

The load balancer being used to send tasks to the FeedMaster configured with the Snaplex. If configured, requests are sent first to the load balancer (instead of directly to the FeedMaster).

It is possible to configure more than one FeedMaster to a Snaplex. In that configuration, you may want to put a load balancer in front of the FeedMasters, so that the requests are automatically distributed.

generationThe unique identifier used to lease slots on the JCC node (not applicable to a FeedMaster).
instance_idThe unique identifier of this Snaplex.

The load balancer being used to send tasks to the JCC node. If configured, requests are first sent to the load balancer (instead of directly to this JCC node).

labelThe name of the Snaplex.

The location of the Snaplex: cloud if it is a Cloudplex, or sidekick if it is a Groundplex. 

max_execution_timeThe longest execution time of a Pipelines in the Snaplex.
max_memThe maximum percentage of memory that the Snaplex can use.
max_slotsThe maximum slots that this Snaplex supports.
mean_execution_timeThe mean execution time of Pipelines in the Snaplex.

The memory load at the time of collecting the cc info from the JCC node. The value is stated as a percentage and is stated as in decimal form. The value may represent less than 1 percent of overall system memory is used when you make this API call.

memory_percent_usageThe percentage of memory used in a FeedMaster by a broker.
min_execution_timeThe shortest execution time of a Pipelines in the Snaplex.
min_jccThe minimum number of JCCs that should be running at any time.
node_settingsAdditional settings associated with this Snaplex (HTTP, HTTPS proxy, Jetty, and heap settings).
notificationEmail addresses to which Snaplex notifications are sent.
open_file_descriptorsThe keys to files. 
orgThe name of the org to which the Snaplex belongs.
ownerThe owner of the Snaplex.
pathThe path of the Snaplex.

The SnapLogic release version that the JCC supports.


The maximum number of Pipelines queued for a Snaplex.

rejected_requestsThe number of rejected API requests.

The REST API request and response metrics from the metrics registry. 

The key includes the following subfields:

  • request_meter: The number of requests and the mean rate at which requests have occurred since the meter was created.
  • response_timer: Includes the number of responses and the total minimum, maximum, and mean times in milliseconds of processing each incoming request and return response.
reserved_slotsThe number of slots that the Snaplex should reserve for pipelines run from the SnapLogic UI. Triggered, Ultra Tasks, and Scheduled Tasks do not use these slots.


The maximum amount of time for which the Snaplex should wait for Pipelines to finish before restarting. This setting is applicable only after a Snaplex restart is triggered through the UI.


The timestamp at the time of the most recent Snaplex restart.


The user who last restarted the Snaplex. A Snaplex rolling restart can be triggered from the Dashboard or when a Snaplex version is changed.


An internal identifier for the Snaplex that is used by SnapLogic.


A message queue is too slow, dropping all new requests.


The standard deviation of execution time.


System CPU load normalized by the number of available CPUs.


The number of timed out requests.

Guidelines for Collecting Metrics

You can collect metrics for resource utilization across various Orgs and Hosts. If you specify plex_path, the API returns information of that specific Snaplex only.

MetricDescriptionResponse of API Format
Active Pipelines in a JCC node

Returns a list of runtimes (RUUIDs) from running Pipelines.

Metrics for Active Pipelines do not display in all Stats collections in the API response. For details about Pipeline processing, see the Active Threads metric.

Slots in use in a JCC nodeReturns the number of slots in use.<Snaplex_name>.cc_info.running[].stats.slots_in_use
Memory usedReturn the absolute value of memory usage in bytes.<Snaplex_name>.cc_info.running[].stats.mem_used_absolute
CPU usedReturns the percentage of CPU usage.<Snaplex_name>.cc_info.running[].stats.cpu_user
Disk usedReturns the percentage of disk space used.<Snaplex_name>.cc_info.running[].stats.disk_info[...]

Open file descriptorsReturns the number of open file descriptors.<Snaplex_name>.cc_info.running[].stats.open_file_descriptors
Active threadsReturns the number of active threads.<plex_name>.cc_info.running[].stats.active_threads

API Response

When viewing the API response, you might notice the  variations for the same collection types, such as the following two pairs:

Example 1:


Example 2:


These variations differ in that the data sources used while preparing the response to the API call, even though their common part is both from the same source. When the returned field record contains cc_load, the data is refreshed when the JCC node updates Pipeline runtimes. The other returned field records marked stats are updated every 20 seconds when the JCC node sends its heartbeat to the network.

See Also