...
The configuration option 'opconfig_raise_alert_events' (default: true) controls whether opConfig sends any alert events to NMIS.
From opConfig 4.3.2, it is possible to specify a time out per command, that will override the opconfig_plugin_timeout setting, 'plugin_interaction_timeout'.
Collecting device configuration data with a plugin
...
Required values for condition elements
| Key | Value |
|---|---|
| message | String - Message |
| condition | 0 means a bad state for this condition, 1 means a good state for the condition, undef signals that the state of this condition is not known. |
URL Cell
You can have the conditions table render a URL cell in one or many rows.
| Key | Value |
|---|---|
| url | http or https link |
| url_label | Optional label for the link, if none if given then the url is displayed |
| Code Block | ||
|---|---|---|
| ||
push(@foundConditions, {
message=> "Interface $interface has HIGH percentage of INPUT packets being switched by the processor.",
url => "http://example.com/knowlege",
url_label => "Knowledge Base",
condition => 1,
}); |
...
Render a link which when the user clicks displays a tooltip.
| Key | Value |
|---|
| tooltip | String to render in the tooltip view |
| Code Block | ||
|---|---|---|
| ||
push(@foundConditions, {
message=>"Interface $interface has HIGH percentage of OUTPUT packets being switched by the processor.",
tooltip => "This is a bad thing, you should release the monkeys",
condition => 0,
}); |
Tagging
| Key | Value |
|---|---|
| ts_tag | Tag to filter command sets by for creating a new virtual operator job |
| Code Block | ||
|---|---|---|
| ||
push(@foundConditions,{
message=>"Interface $interface has HIGH percentage of input errors.",
ts_tag=>'interface_errors',
condition => 1
}); |
...
New Derived Information Elements in opConfig 4.2.1
Virtual Operator Parameters
opConfig now supports a hash element being part of the derived data rows array. This allows greater flexibility in displaying data to the user and generating troubleshooting workflows.
Virtual Operator Parameters
Gives the user an opportunity to create a new virtual operator job with predefined parameters, clicking the link takes the user to the Virtual Operator Job form and all values are prefilled out.
For example we could have a command_set called "ping" which accepts the parameter $ipaddress. We could pass the ip of the interfaces opConfig has just collected. This creates chainable jobs which can create a powerful troubleshooting workflow.
| Key | Valye |
|---|---|
| command_set | String, name of the command_set you wish the user to run |
| parameters | Hash of parameters you wish to give to the virtual operator job |
| Code Block | ||
|---|---|---|
| ||
| Code Block | ||
| ||
push(@mtr_table, ["Item 1", "Item 2", {command_set => "ping", parameters => { ipaddress => "1.1.1.1"}}]); push(@mtr_table, ["Item 1", "Item 2", {command_set => "ping", parameters => { ipaddress => "81.81.8.1.1"}}]); push(@mtr_table, ["Item 1", "Item 2", {command_set => "ping", parameters => { ipaddress => "8.8.8.8"}}]); |
Related Virtual Operator Job
In opConfig plugins you can tigger new jobs to be run and have the job_id returned in the current context, if you create a related_job cell and pass in the job_id opConfig will render a cell with a link through to the job your triggered.
| key | value |
|---|---|
| related_job | ID of a queued or run virtual operator job |
| related_job_label | (optional) String for the related job link, if none is given it show "Related Job" |
| Code Block | ||
|---|---|---|
| ||
push(@mtr_table, ["Item 1", "Item 2", {related_job => $job_id_1, related_job_label => "Custom Label"}]);
push(@mtr_table, ["Item 1", "Item 2", {related_job => $job_id_2}]); |
...