Skip to main content

Problem indicators

To facilitate the creation and management of custom problem indicators, allowing you to indicate any number of problems with your environment, OUs, Orders, etc., there's several services available for fine-tuning.

Permissions

The Monitors permission is required in order to be able to see the Monitors dashboard, with the MonitorNotifications required for the alerts.

Service
CreateMonitor
UpdateMonitor
DeleteMonitor

CRUD services for monitors

{
"Handler": "SettingVulnerabilities",
"Name": "SettingVulnerabilities",
"Description": "Monitor vulnerable settings",
"DefaultLevel": 1,
"ScriptID": 5
}

The possible types set in the DefaultLevel property in the services above are:

  • 0: Info
  • 1: Warning
  • 2: Error
  • 3: Fatal

Some monitors can be configured by setting the Data property in CreateMonitor and UpdateMonitor.

Monitor configuration

Check if conditions are available per handler

The main configuration option is to set conditions. First run GetAvailableMonitorHandlers to check if conditions are available for the handler.

{
// Request can be left empty
}

The ScriptedOrders monitor takes the customization of order monitors to a whole new level. For more information, see Orders Monitor.

Get which conditions are available per handler

{
"Handler": "TransputJobs"
}

Setting conditions for monitors

You can set conditions for monitors by setting the MainConditionGroup property in the Data property in either CreateMonitor or UpdateMonitor.

This is the format of a ConditionGroup:

{
"MatchAny": bool,
"Conditions": Condition[]
"Groups": ConditionGroup[]
}

The format of a Condition:

{
"Field": string,
"ValueOperator": string,
"Value": string
}

With the MatchAny property you can define whether all conditions should be valid or not.

So, for example, to create a monitor that seeks all failed transput jobs for order/shipment RGC exports, we can call CreateMonitor as follows:

{
"Handler": "TransputJobs",
"Name": "Failed RGC",
"Description": "Monitor for failed RGC exports",
"DefaultLevel": "Error",
"Data": {
"MainConditionGroup": {
"MatchAny": false,
"Conditions": [
{"Field": "Name", "ValueOperator": "Contains", "Value": "RGC"},
{"Field": "StatusID", "ValueOperator": "Equals", "Value": "-1"}
],
"Groups": [
{
"MatchAny": true,
"Conditions": [
{"Field": "TypeID", "ValueOperator": "Equals", "Value": "1"},
{"Field": "TypeID", "ValueOperator": "Equals", "Value": "2"}
]
},
{
"MatchAny": true,
"Conditions": [
{"Field": "DaysOld", "ValueOperator": "LessThan", "Value": 10},
{"Field": "DaysOld", "ValueOperator": "Equals", "Value": 10}
]
}
]
}
}
}

Query-like: 'all transput jobs where name contains RGC and status is failed and (type is orders or shipments) and (days old is less than 10 or equal to 10)'

Monitor owners

You can specify if a role is only able to view or view + edit a specific monitor by enabling the IsAllowedToEdit property in the CreateMonitorRoleOwner service. Enabling this will mean the role can edit that specific Monitor even when the Edit permission of the Monitors functionality is disabled.

{
"MonitorID":20,
"RoleID": 1,
"IsAllowedToEdit":true
}

Running monitors

A Monitor can be run by manually calling RunMonitor or by creating a recurring task, such as RunTaskPlugin.

{
"ID": 2
}

Getting monitor results

Call GetMonitorResults to fetch the latest results for all monitors.

{
// Empty request
}

The content of 'LastResult' varies by handler and is therefore not typed. How each handler stores information will be documented later.

Monitor alerts

The first step to creating the alert itself, via CreateMonitorAlert.

{
"MonitorID": "1",
"Level": "Warning",
"Threshold":"5",
"Description":"If more than 5 warnings available, sound the alarm!",
"EmailSubject":"5 or more monitor warnings"
}

With this ID from the above service, you can call CreateMonitorAlertEmailRecipient to set an email address for the warning to be sent out to.

{
"AlertID": "2",
"Name": "Pedro",
"EmailAdress":"pedro@docs-inc.org",
}