Pushing Data to NetCrunch via REST API

NetCrunch provides node-specific listeners for non-traditional and custom script-based status and trend data. This is accomplished by adding one or more Generic Agent Sensors (REST listeners) to an existing node in the NetCrunch Atlas.

Configuring the atlas node

NetCrunch has 2 modes for monitoring nodes, dictated by your preference. The target node for the Generic Data Sensor(s) must be configured for Standard Monitoring.

• Standard monitoring: supports service validation as well as polling, push capabilities as well as sensors. This is the default setting for a monitored node and supports node sensors.

• Simplified monitoring: support for service validation only and does not support polling, listening or sensors.

Association via API-key, not IP address

In order to provide the highest level of flexibility, the data reflected by the sensor can come from anywhere, non-IP specific, as is assigned to a node(s) by a generated unique API key. This allows you to configure the sensor under any node you choose to reflect the desired metric or status. The API-key is system generated, and therefore cannot be used to report a single REST call to multiple Generic Agent Sensors or multiple nodes. This feature is 1-to-1 with respect REST call/Node.

Configuring the Generic Data Sensor

1. Navigate to the node settings of the target node where sensors need to be added
2. Click on Add Monitoring Sensor on the bottom of the screen
3. Select Generic Agent Data sensor
4. Set the name of the sensor: NetCrunch will automatically generate the sensor specific API key by concatenating the name of the sensor and node id.
5. Set Retention Time (minutes) - This dictates the duration of a valid value/status.
6. NetCrunch provides the specific API call highlighted in red for configuration at the source.

Engineering breadcrumb on Retention Time:

If the sensor does not receive an update within the configured retention time, it will default to a null(missing) value. If you are interested in retaining the last value as valid, be sure to set retention time to an appropriate duration beyond the interval set for the push API call. Retention time can be overridden and changed with each API push.

Using CURL to populate Trend data

Below is a method employing CURL to send properly formatted JSON via REST to populate a designated Generic Agent Sensor. Please refer to the following topic in NetCrunch documentation for detailed instructions

An example is provided below:

     curl.exe -X GET -H "Content-type: application/json" "vm-test-094.lab.ad.adrem/api/rest/1/sensors/MyName@1001/counter?Temp_Celcius=65&Wind_kmph=4&@retain=6"

• Uses GET method to send two counters and retention time to NetCrunch.
• Counter: Temp_Celsius equal to 65
• Counter: Wind_kmph equal to 4
• Retention Time: 6 minutes

Engineering breadcrumbs:

• Mandatory: Header = "Content-type: application/json"
• Retention time - if provided (optional) will reset retention time in sensor config
• Set retention time to 1 min longer than the scheduled push to avoid gaps in data
• Before any alert can be set on counters, a value needs to be sent to NetCrunch first, which accomplishes creating the counter

Observing Success:

And Data should appear in NetCrunch as a counter:

Adding Status data to Generic Agent Sensor

1. Open node settings on target node - select Generic Agent Data sensor created previously.
2. Click on + Add Alert
3. Select New Event for Monitoring Sensor Counter
4. Click on < select counter >, select counter and click on Add
5. Configure the rest of the alerting rules (type, number of samples) and save.

As the result - alert will be generated based on rules that were set.

Using CURL to send Status data

Similar to previous steps - the configured sensor is required.

Status alerts can be configured before any data is sent to NetCrunch as a counter is not required.

• Click on + Add alert in Sensor Configuration
• Click on New Event for Status Object Change

Status alerts require an Object Id to be configured. You should use a common name that clearly identifies the object of which status needs to be monitored. The provided example utilizes the ObjectID Door which can occupy two states - Opened or Closed.

An example of a Status Alerting Rule is provided. Upon update of the Door status to Opened, an alert will be raised. This alert will be resolved once Door status reverts to Closed.

Use the following CURL statements to toggle Door status:

curl.exe -X GET -H "Content-type: application/json" "vm-test-094.lab.ad.adrem/api/rest/1/sensors/MyName@1001/status?Door=Closed"

or...

curl.exe -X GET -H "Content-type: application/json" "vm-test-094.lab.ad.adrem/api/rest/1/sensors/MyName@1001/status?Door=Opened"

Engineering breadcrumbs:

Active alert status is maintained as long as reported Status is Open. Active alert status is not maintained if Status is set to Closed, or the status retention time expires. Be sure to buffer retention time by 1-minute longer than the push interval to accommodate delays in transmission of processing. This will reduce or eliminate false status reporting.

curlgeneric data sensorrestsending data