Snaplex Monitoring APIs

In this Article

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

Purpose

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

Parameters

The Snaplex Monitoring API uses the following two parameters:

  • plex_path
  • hostname

Parameter Details

ParameterDescriptionSyntaxExample
plex_pathThe path of the Snaplex.


plex_path=/<organization>/shared/<plexname>


plex_path=/snaplogic/shared/Test%20Cloud

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


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


hostname=canxl-jcc8.clouddev.snaplogic.com,canxl-jcc9.clouddev.snaplogic.com

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:

Example: https://elastic.snaplogic.com/api/1/rest/public/snaplex/SnapLogicCertificationOrg?plex_path=/SnapLogicCertificationOrg/shared/Cloud

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:

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

KeyDescription
active_threadThe total thread count of the VM.

broker_name

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

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

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

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

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

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

The SnapLogic release version that the JCC supports.

queue_size

The maximum number of Pipelines queued for a Snaplex.

rejected_requestsThe number of rejected API requests.
request_response

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.

restart_max_waiting_time

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.

restart_request_time

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

restart_request_user

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

runtime_path_id

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

slow_queue

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

stddev_exec_time_ms

The standard deviation of execution time.

system_load_average


System CPU load normalized by the number of available CPUs.

timed_out_requests

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.

<Snaplex_name>.cc_info.running[].cc_load.stats.active_pipelines
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:

cc_load.stats.open_file_descriptors
cc_info.running[].stats.open_file_descriptors

Example 2:

cc_info.running[].cc_load.stats.active_threads
cc_info.running[].stats.active_threads

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