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||The path of the Snaplex.|
|hostname||The path of the JCC host node. To specify multiple hosts, separate each hostname using a comma.|
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_type||The type of container: regular, mixed, or null.|
|down||Lists 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.|
|running||Lists 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_thread||The total thread count of the VM.|
|The name of the broker in the FeedMaster.|
|container_type||The type of container: regular or FeedMaster.|
|cpu_user||The 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_load||The 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_settings||Snaplex settings that are resolved at runtime. As of now, it displays only log settings associated with the Snaplex.|
|environment||The 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.
|generation||The unique identifier used to lease slots on the JCC node (not applicable to a FeedMaster).|
|instance_id||The 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).
|label||The name of the Snaplex.|
The location of the Snaplex: cloud if it is a Cloudplex, or sidekick if it is a Groundplex.
|max_execution_time||The longest execution time of a Pipelines in the Snaplex.|
|max_mem||The maximum percentage of memory that the Snaplex can use.|
|max_slots||The maximum slots that this Snaplex supports.|
|mean_execution_time||The 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_usage||The percentage of memory used in a FeedMaster by a broker.|
|min_execution_time||The shortest execution time of a Pipelines in the Snaplex.|
|min_jcc||The minimum number of JCCs that should be running at any time.|
|node_settings||Additional settings associated with this Snaplex (HTTP, HTTPS proxy, Jetty, and heap settings).|
|notification||Email addresses to which Snaplex notifications are sent.|
|open_file_descriptors||The keys to files. |
|org||The name of the org to which the Snaplex belongs.|
|owner||The owner of the Snaplex.|
|path||The path of the Snaplex.|
The SnapLogic release version that the JCC supports.
The maximum number of Pipelines queued for a Snaplex.
|rejected_requests||The 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_slots||The 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.
|Metric||Description||Response 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 node||Returns the number of slots in use.||<Snaplex_name>.cc_info.running.stats.slots_in_use|
|Memory used||Return the absolute value of memory usage in bytes.||<Snaplex_name>.cc_info.running.stats.mem_used_absolute|
|CPU used||Returns the percentage of CPU usage.||<Snaplex_name>.cc_info.running.stats.cpu_user|
|Disk used||Returns the percentage of disk space used.||<Snaplex_name>.cc_info.running.stats.disk_info[...]
|Open file descriptors||Returns the number of open file descriptors.||<Snaplex_name>.cc_info.running.stats.open_file_descriptors|
|Active threads||Returns the number of active threads.||<plex_name>.cc_info.running.stats.active_threads|
When viewing the API response, you might notice the variations for the same collection types, such as the following two pairs:
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.