Using G2 custom monitors, you can build and manage independent monitoring solutions without relying on the platform. Remote Script Executor executes shell, PowerShell, and Python scripts on Linux and Windows workstations.
Key features include:
- User-defined external arguments support the script through custom attributes.
- Monitor level script execution: Ability to pull more metrics in a single script execution.
- Ability to execute different types of scripts through custom script options apart from default options.
- Ability to use credentials attached to the device in the script using the dynamic macro support.
Constraint:
Windows workstation monitoring using a Linux Gateway is not supported.
Step 1: Create metrics
Define metrics metadata that correlates with your script output and matches the monitor you define in the next step.
- Select a client from the All Clients list.
- Go to Setup > Monitoring > Metrics.
- From METRICS, click + Add.
- From Create Metric, enter the values for the fields described in the following tables and click Save.
Metric specification
Field | Description |
---|---|
Metric Scope | (required) Partner- or client-specific metric specification:
|
Adaptor Type | (required) Application. Select from the supported agent or gateway adapters. |
Name | (required) Unique metric name. The recommended naming convention is: . For example, apache_tomcat_webapps_count . |
Tag Name | User-defined tags for filtering. |
Display Name | (required) Name to display, such as **System Drive Free Space**. |
Description | Description of the metric. |
Data Point type | (required) Type of data point specification:
|
Units | Metric unit specification associated with the data point type. Click the drop-down menu to select from the available units. |
Unit Multiplication Factor | Factor to multiply the data point value by. |
Datapoint value conversion | Datapoint value conversion specification:
|
Metric Processing | Metric processing specification:
|
[1] See the Metric token reference for a list of the tokens that can be used in the Subject and Description fields.
Step 2: Create a monitor
A custom Remote Script Executor monitor is a collection of Remote Script Executor metrics. You can create a template based on the Remote Script Executor monitor.
Macros are used to pass dynamic arguments to scripts. Use the static and dynamic macros listed in the following tables to make native and custom attributes available to the monitor.
You must create metrics in Step 1: Create metrics before creating a monitor.
- Select a client from the All Clients list.
- Go to Setup > Monitoring > Monitors
- Click + Create New.
- On the CREATE A MONITOR page, enter the fields listed in the following table and click Save. The newly created monitor is added to the list of monitors.
Monitor specification
Method | Description |
---|---|
Monitor Scope | (required) Partner- or client-specific monitor specification:
|
Adapter Type | (required) Application. Select from the supported agent or gateway adapters. |
Name | (required) Unique monitor name. |
Description | (required) Description of the monitor |
Metrics | (required) Click +Add to add metrics. Search for the previously defined metrics and click Add Metrics. |
Configuration Parameters | Click +Add to add configuration parameters. Search for the parameter and click Add to add it to the monitor:
|
Static macros
Use static macros to override the resource values. See the Static macro reference for a list of static macros.
Dynamic macros
You can use a dynamic macro to get custom device attributes. The script custom attribute specification syntax is:
${customattribute.customAttributekey}
For example, if you have a macro defined as ${customattribute.serviceName}
in the script, and the device has a custom attribute key-value pair of serviceName:oracledb
, the ${customattributes.serviceName}
macro is replaced with the value oracledb
.
Use a dynamic macro to get device credentials instead of keeping the username and password in plain text form. The macro replaces a credential replacement when the script executes. The general credential syntax is:
${credentials.CredentialName.credentialField}
For example, if you define a credential with name JMXCred on the device, you can use the macro ${credentials.JMXCred.username}
to authenticate.
Script execution path for configuration parameters in Linux and Windows
The following runtime executables should be available in your Path variable for the corresponding operating system.
Script Type | Linux | Windows |
---|---|---|
Bash | bash | Not Applicable |
Shell | sh | Not Applicable |
Powershell | Not Applicable | powershell.exe |
Python | python | python.exe |
Perl | Perl | Not Applicable |
If your runtime is not set as an environment variable, provide the runtime absolute path in custom.script.execution.path
. For example, if python is not set, set custom.script.execution.path
to /usr/lib/python
.
Step 3: Create a template
A template is an instance of a monitor and is applied to devices.
- Select a client from the All Clients list.
- Go to Setup > Monitoring >Templates.
- From Templates, click + Add.
- From MONITOR TEMPLATE, provide details for the following parameters and click Save.
Method | Description |
---|---|
Select Template Scope | (required) Partner- or client-specific monitor specification:
|
Collector Type | Select Agent |
Monitor Type | Select G2 Monitors |
Applicable for | Select Device |
Template Name | Name of the template |
Description | Summary of the template |
Generation | Generation that the template belongs to |
Tags | User-defined tags for filtering |
Prerequisites | Essential things to consider when using this template |
Status | Active or end-of-life template |
Notes | Information that you want to add to the template |
Template Family Name | Category that applies to the application, such as Windows Server, Storage Server, or Network Server |
Deployment Type | One of the following methods to use to apply the template to the resource:
|
After adding the template, add component thresholds and component filters by editing metric values. For more information, see Add Filter and Define Threshold
Step 4: Assign a template
- From the left pane, click Infrastructure. The Infrastructure screen of the selected client is displayed.
- From the Resources tab, select the required resource from the list of resources. Or, use the search option to find the resource.
- Click the resource name to view details.
- From the left pane, click Monitors.
- From the Templates tab, click +Assign Templates.
- From Apply Templates, select the templates.
The selected Templates section displays the chosen templates. - Click Assign. The template gets assigned to the selected device.
After assigning the template to a resource for monitoring, click Get Latest Metric Values to view the latest metric information.
Step 5: View graphs
The Agent monitors the system using the assigned templates and displays the results in a graphical format.
- From the left pane, click Infrastructure.
- From the Resources tab, select the required resource from the list of resources. Or, use the search option to find the resource.
- Click the resource name to view details.
- From the left pane, click Metrics. The Metrics page displays graphs generated by all monitoring templates assigned to a device.
- Search with the template name to filter the graphs.
Remote Script Executor example
Script
#!/bin/bash
CPU=$(top -bn1 | grep load | awk ‘{printf "%.2f\t\t\n", $(NF-2)}’)
MEMORY=$(free -m | awk ‘NR==2{printf "%.2f\t\t", $3*100/$2 }’)
DISK=`df -h | awk ‘$NF=="/"{ print $5}’ | sed ‘s/%//g’`
printf "{\"disk.utilization\" : %s , \"memory.utilization\" : %s , \"cpu.usage\" : %s}" "$DISK" "$MEMORY" "$CPU"
Output :
{"disk.utilization" : 23 , "memory.utilization" : 24.28 , "cpu.usage" : 0.64 }
Standard JSON output format
Format 1
{
"Metric1": 98,
"Metric2": 70,
"Metric3": 80
}
Format 2
{
"Metric1": 98,
"Metric2": "STATE",
"Metric3": 80
}
}
Format 3
{
"MetricName1": {
"components": {
"component1": 70,
"component2": 98
}
},
"MetricName2": {
"components": {
"component1": 77,
"component2": 98
}
}
}
Format 4
alertTokens: Using alertTokens, you can add more information to the alert Subject and Description.
{
"MetricName1": {
"components": {
"component1": "STATE",
"component2": 98
},
"alertTokens": {
"token1": "value",
"token2": "value2"
}
},
"MetricName2": {
"components": {
"component1": 77,
"component2": 98
},
"alertTokens": {
"token1": "value",
"token2": "value2"
}
}
}
Format 5
{
"MetricName1": 254,
"MetricName2": {
"components": {
"comp1": 90,
"comp2": 60
}
},
"MetricName3": {
"components": {
"component1": "STATE",
"component2": 98
},
"alertTokens": {
"token1": "value",
"token2": "value2"
}
}
}
Format 6
component level alertTokens: We can specify alertToken value for each component separately as mentioned for metricName4
Note: This format supports from Agent V12 and above
{
"MetricName1": 254,
"MetricName2": {
"components": {
"comp1": 90,
"comp2": 60
}
},
"MetricName3": {
"components": {
"component1": "STATE",
"component2": 98
},
"alertTokens": {
"token1": "value",
"token2": "value2"
}
},
"MetricName4": {
"components": {
"component1": 10,
"component2": 20
},
"alertTokens": {
"token1": {
"component1": "comp1 token1 value",
"component2": "comp2 token1 value"
},
"token2": {
"component1": "comp1 token2 value",
"component2": "comp2 token2 value"
}
}
}
}