Configure System Event Notifications
To receive the event messages generated and processed by NetQ, you must integrate a third-party event notification application into your workflow. You can integrate NetQ with Syslog, PagerDuty, Slack, and/or email. Alternately, you can send notifications to other third-party applications via a generic webhook channel.
In an on-premises deployment, the NetQ On-premises Appliance or VM receives the raw data stream from the NetQ Agents, processes the data, then stores and delivers events to the Notification function. The Notification function filters and sends messages to any configured notification applications. In a cloud deployment, the NetQ Cloud Appliance or VM passes the raw data stream to the NetQ Cloud service for processing and delivery.
You can implement a proxy server (that sits between the NetQ Appliance or VM and the integration channels) that receives, processes, and distributes the notifications rather than having them sent directly to the integration channel. If you use such a proxy, you must configure NetQ with the proxy information.
Notifications are generated for the following types of events:
Category | Events |
---|---|
Network Protocol Validations |
|
Interfaces |
|
Services |
|
Traces |
|
Sensors |
|
System Software |
|
System Hardware |
|
* This type of event can only be viewed in the CLI with this release.
Event filters are based on rules you create. You must have at least one rule per filter. A select set of events can be triggered by a user-configured threshold. Refer to the System Event Messages Reference for descriptions and examples of these events.
Event Message Format
Messages have the following structure:
<message-type><timestamp><opid><hostname><severity><message>
Element | Description |
---|---|
message type | Category of event; agent, bgp, clag, clsupport, configdiff, evpn, link, lldp, mtu, node, ntp, ospf, packageinfo, ptm, resource, runningconfigdiff, sensor, services, ssdutil, tca, trace, version, vlan or vxlan |
timestamp | Date and time event occurred |
opid | Identifier of the service or process that generated the event |
hostname | Hostname of network device where event occurred |
severity | Severity level in which the given event is classified; debug, error, info, or warning |
message | Text description of event |
For example:
You can integrate notification channels using the NetQ UI or the NetQ CLI.
To set up the integrations, you must configure NetQ with at least one channel, one rule, and one filter. To refine what messages you want to view and where to send them, you can add additional rules and filters and set thresholds on supported event types. You can also configure a proxy server to receive, process, and forward the messages. This is accomplished using the NetQ UI and NetQ CLI in the following order:
Configure Basic NetQ Event Notifications
The simplest configuration you can create is one that sends all events generated by all interfaces to a single notification application. This is described here. For more granular configurations and examples, refer to Configure Advanced NetQ Event Notifications.
A notification configuration must contain one channel, one rule, and one filter. Creation of the configuration follows this same path:
- Add a channel.
- Add a rule that accepts a selected set of events.
- Add a filter that associates this rule with the newly created channel.
Create a Channel
The first step is to create a PagerDuty, Slack, syslog, or email channel to receive the notifications.
You can use the NetQ UI or the NetQ CLI to create a Slack channel.
- Click , and then click Notification Channels in the Notifications section.
- The Slack tab is displayed by default.
-
Add a channel.
- When no channels have been specified, click Add Slack Channel.
- When at least one channel has been specified, click above the table.
-
Provide a unique name for the channel. Note that spaces are not allowed. Use dashes or camelCase instead.
-
Create an incoming webhook as described in the documentation for your version of Slack. Then copy and paste it here.
-
Click Add.
-
To verify the channel configuration, click Test.
- To return to your workbench, click in the top right corner of the card.
To create and verify the specification of a Slack channel, run:
netq add notification channel slack <text-channel-name> webhook <text-webhook-url> [severity info|severity warning|severity error|severity debug] [tag <text-slack-tag>]
netq show notification channel [json]
This example shows the creation of a slk-netq-events channel and verifies the configuration.
-
Create an incoming webhook as described in the documentation for your version of Slack.
-
Create the channel.
cumulus@switch:~$ netq add notification channel slack slk-netq-events webhook https://hooks.slack.com/services/text/moretext/evenmoretext Successfully added/updated channel slk-netq-events
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- -------- ---------------------- slk-netq-events slack info webhook:https://hooks.s lack.com/services/text/ moretext/evenmoretext
You can use the NetQ UI or the NetQ CLI to create a PagerDuty channel.
- Click , and then click Notification Channels in the Notifications section.
- Click PagerDuty.
-
Add a channel.
- When no channels have been specified, click Add PagerDuty Channel.
- When at least one channel has been specified, click above the table.
-
Provide a unique name for the channel. Note that spaces are not allowed. Use dashes or camelCase instead.
-
Obtain and enter an integration key (also called a service key or routing key).
-
Click Add.
-
Verify it is correctly configured.
- To return to your workbench, click in the top right corner of the card.
To create and verify the specification of a PagerDuty channel, run:
netq add notification channel pagerduty <text-channel-name> integration-key <text-integration-key> [severity info|severity warning|severity error|severity debug]
netq show notification channel [json]
This example shows the creation of a pd-netq-events channel and verifies the configuration.
-
Obtain an integration key as described in this PagerDuty support page.
-
Create the channel.
cumulus@switch:~$ netq add notification channel pagerduty pd-netq-events integration-key c6d666e210a8425298ef7abde0d1998 Successfully added/updated channel pd-netq-events
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- ---------------- ------------------------ pd-netq-events pagerduty info integration-key: c6d666e 210a8425298ef7abde0d1998
You can use the NetQ UI or the NetQ CLI to create a Slack channel.
- Click , and then click Notification Channels in the Notifications section.
- Click Syslog.
-
Add a channel.
- When no channels have been specified, click Add Syslog Channel.
- When at least one channel has been specified, click above the table.
-
Provide a unique name for the channel. Note that spaces are not allowed. Use dashes or camelCase instead.
-
Enter the IP address and port of the Syslog server.
-
Click Add.
-
To verify the channel configuration, click Test.
- To return to your workbench, click in the top right corner of the card.
To create and verify the specification of a syslog channel, run:
netq add notification channel syslog <text-channel-name> hostname <text-syslog-hostname> port <text-syslog-port> [severity info | severity warning | severity error | severity debug]
netq show notification channel [json]
This example shows the creation of a syslog-netq-events channel and verifies the configuration.
-
Obtain the syslog server hostname (or IP address) and port.
-
Create the channel.
cumulus@switch:~$ netq add notification channel syslog syslog-netq-events hostname syslog-server port 514 Successfully added/updated channel syslog-netq-events
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- -------- ---------------------- syslog-netq-eve syslog info host:syslog-server nts port: 514
You can use the NetQ UI or the NetQ CLI to create an email channel.
- Click , and then click Notification Channels in the Notifications section.
- Click Email.
-
Add a channel.
- When no channels have been specified, click Add Email Channel.
- When at least one channel has been specified, click above the table.
-
Provide a unique name for the channel. Note that spaces are not allowed. Use dashes or camelCase instead.
-
Enter a list of emails for the people who you want to receive notifications from this channel.
Enter the emails separated by commas, and no spaces. For example:
user1@domain.com,user2@domain.com,user3@domain.com
-
The first time you configure an email channel, you must also specify the SMTP server information:
- Host: hostname or IP address of the SMTP server
- Port: port of the SMTP server; typically 587
- User ID/Password: your administrative credentials
- From: email address that indicates who sent the event messages
After the first time, any additional email channels you create can use this configuration, by clicking Existing.
-
Click Add.
-
To verify the channel configuration, click Test.
- To return to your workbench, click .
To create and verify the specification of an email channel, run:
netq add notification channel email <text-channel-name> to <text-email-toids> [smtpserver <text-email-hostname>] [smtpport <text-email-port>] [login <text-email-id>] [password <text-email-password>] [severity info | severity warning | severity error | severity debug]
netq add notification channel email <text-channel-name> to <text-email-toids>
netq show notification channel [json]
The configuration is different depending on whether you are using the on-premises or cloud version of NetQ. Do not configure SMTP for cloud deployments as the NetQ cloud service uses the NetQ SMTP server to push email notifications.
For an on-premises deployment:
-
Set up an SMTP server. The server can be internal or public.
-
Create a user account (login and password) on the SMTP server. NetQ sends notifications to this address.
-
Create the notification channel using this form of the CLI command:
netq add notification channel email <text-channel-name> to <text-email-toids> [smtpserver <text-email-hostname>] [smtpport <text-email-port>] [login <text-email-id>] [password <text-email-password>] [severity info | severity warning | severity error | severity debug]
cumulus@switch:~$ netq add notification channel email onprem-email to netq-notifications@domain.com smtpserver smtp.domain.com smtpport 587 login smtphostlogin@domain.com password MyPassword123
Successfully added/updated channel onprem-email
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- ---------------- ------------------------ onprem-email email info password: MyPassword123, port: 587, isEncrypted: True, host: smtp.domain.com, from: smtphostlogin@doma in.com, id: smtphostlogin@domain .com, to: netq-notifications@d omain.com
For a cloud deployment:
-
Create the notification channel using this form of the CLI command:
netq add notification channel email <text-channel-name> to <text-email-toids>
cumulus@switch:~$ netq add notification channel email cloud-email to netq-cloud-notifications@domain.com
Successfully added/updated channel cloud-email
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- ---------------- ------------------------ cloud-email email info password: TEiO98BOwlekUP TrFev2/Q==, port: 587, isEncrypted: True, host: netqsmtp.domain.com, from: netqsmtphostlogin@doma in.com, id: smtphostlogin@domain .com, to: netq-notifications@d omain.com
You can use the NetQ UI or the NetQ CLI to create a Generic channel.
- Click , and then click Notification Channels in the Notifications section.
- Click Generic.
-
Add a channel.
- When no channels have been specified, click Add generic channel.
- When at least one channel has been specified, click above the table.
-
Provide a unique name for the channel. Note that spaces are not allowed. Use dashes or camelCase instead.
-
Enter a Webhook URL that you want to receive the notifications from this channel.
-
Set the desired notification severity, SSL, and authentication parameters for this channel.
-
Click Add.
-
To verify the channel configuration, click Test.
- To return to your workbench, click in the top right corner of the card.
To create and verify the specification of a Generic channel, run:
netq add notification channel generic <text-channel-name> webhook <text-webhook-url> [severity info | severity warning | severity error | severity debug] [use-ssl True | use-ssl False] [auth-type basic-auth generic-username <text-generic-username> generic-password <text-generic-password> | auth-type api-key key-name <text-api-key-name> key-value <text-api-key-value>]
netq show notification channel [json]
Create a Rule
The second step is to create and verify a rule that accepts a set of events. You create rules for system events using the NetQ CLI.
To create and verify the specification of a rule, run:
netq add notification rule <text-rule-name> key <text-rule-key> value <text-rule-value>
netq show notification rule [json]
Refer to Configure System Event Notifications for a list of available keys and values.
This example creates a rule named all-interfaces, using the key ifname and the value ALL, which sends all events from all interfaces to any channel with this rule.
cumulus@switch:~$ netq add notification rule all-interfaces key ifname value ALL
Successfully added/updated rule all-ifs
cumulus@switch:~$ netq show notification rule
Matching config_notify records:
Name Rule Key Rule Value
--------------- ---------------- --------------------
all-interfaces ifname ALL
Refer to Advanced Configuration to create rules based on thresholds.
Create a Filter
The final step is to create a filter to tie the rule to the channel. You create filters for system events using the NetQ CLI.
To create and verify a filter, run:
netq add notification filter <text-filter-name> rule <text-rule-name-anchor> channel <text-channel-name-anchor>
netq show notification filter [json]
These examples use the channels created in the Configure System Event Notifications topic and the rule created in the Configure System Event Notifications topic.
cumulus@switch:~$ netq add notification filter notify-all-ifs rule all-interfaces channel pd-netq-events
Successfully added/updated filter notify-all-ifs
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
notify-all-ifs 1 info pd-netq-events all-interfaces
cumulus@switch:~$ netq add notification filter notify-all-ifs rule all-interfaces channel slk-netq-events
Successfully added/updated filter notify-all-ifs
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
notify-all-ifs 1 info slk-netq-events all-interfaces
cumulus@switch:~$ netq add notification filter notify-all-ifs rule all-interfaces channel syslog-netq-events
Successfully added/updated filter notify-all-ifs
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
notify-all-ifs 1 info syslog-netq-events all-ifs
cumulus@switch:~$ netq add notification filter notify-all-ifs rule all-interfaces channel onprem-email
Successfully added/updated filter notify-all-ifs
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
notify-all-ifs 1 info onprem-email all-ifs
NetQ is now configured to send all interface events to your selected channel.
Refer to Advanced Configuration to create filters for threshold-based events.
Configure Advanced NetQ Event Notifications
If you want to create more granular notifications based on such items as selected devices, characteristics of devices, or protocols, or you want to use a proxy server, you need more than the basic notification configuration. The following section includes details for creating these more complex notification configurations.
Configure a Proxy Server
To send notification messages through a proxy server instead of directly to a notification channel, you configure NetQ with the hostname and optionally a port of a proxy server. If you do not specify a port, NetQ defaults to port 80. Only one proxy server is currently supported. To simplify deployment, configure your proxy server before configuring channels, rules, or filters.
To configure and verify the proxy server, run:
netq add notification proxy <text-proxy-hostname> [port <text-proxy-port>]
netq show notification proxy
This example configures and verifies the proxy4 server on port 80 to act as a proxy for event notifications.
cumulus@switch:~$ netq add notification proxy proxy4
Successfully configured notifier proxy proxy4:80
cumulus@switch:~$ netq show notification proxy
Matching config_notify records:
Proxy URL Slack Enabled PagerDuty Enabled
------------------ -------------------------- ----------------------------------
proxy4:80 yes yes
Create Channels
Create one or more PagerDuty, Slack, syslog, email, or generic channels to receive notifications.
NetQ sends notifications to PagerDuty as PagerDuty events.
For example:
To create and verify the specification of a PagerDuty channel, run:
netq add notification channel pagerduty <text-channel-name> integration-key <text-integration-key> [severity info|severity warning|severity error|severity debug]
netq show notification channel [json]
where:
Option | Description |
---|---|
<text-channel-name> | User-specified PagerDuty channel name |
integration-key <text-integration-key> | The integration key is also called the service_key or routing_key. The default is an empty string (""). |
severity <level> | (Optional) The log level to set, which can be one of info, warning, error, or debug. The severity defaults to info if unspecified. |
This example shows the creation of a pd-netq-events channel and verifies the configuration.
-
Obtain an integration key as described in this PagerDuty support page.
-
Create the channel.
cumulus@switch:~$ netq add notification channel pagerduty pd-netq-events integration-key c6d666e210a8425298ef7abde0d1998 Successfully added/updated channel pd-netq-events
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- ---------------- ------------------------ pd-netq-events pagerduty info integration-key: c6d666e 210a8425298ef7abde0d1998
NetQ Notifier sends notifications to Slack as incoming webhooks for a Slack channel you configure.
For example:
To create and verify the specification of a Slack channel, run:
netq add notification channel slack <text-channel-name> webhook <text-webhook-url> [severity info|severity warning|severity error|severity debug] [tag <text-slack-tag>]
netq show notification channel [json]
where:
Option | Description |
---|---|
<text-channel-name> | User-specified Slack channel name |
webhook <text-webhook-url> | WebHook URL for the desired channel. For example: https://hooks.slack.com/services/text/moretext/evenmoretext |
severity <level> | The log level to set, which can be one of error, warning, info, or debug. The severity defaults to info. |
tag <text-slack-tag> | Optional tag appended to the Slack notification to highlight particular channels or people. An @ sign must precede the tag value. For example, @netq-info. |
This example shows the creation of a slk-netq-events channel and verifies the configuration.
-
Create an incoming webhook as described in the documentation for your version of Slack.
-
Create the channel.
cumulus@switch:~$ netq add notification channel slack slk-netq-events webhook https://hooks.slack.com/services/text/moretext/evenmoretext severity warning tag @netq-ops Successfully added/updated channel slk-netq-events
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- ---------------- ------------------------ slk-netq-events slack warning tag: @netq-ops, webhook: https://hooks.s lack.com/services/text/m oretext/evenmoretext
To create and verify the specification of a syslog channel, run:
netq add notification channel syslog <text-channel-name> hostname <text-syslog-hostname> port <text-syslog-port> [severity info | severity warning | severity error | severity debug]
netq show notification channel [json]
where:
Option | Description |
---|---|
<text-channel-name> | User-specified syslog channel name |
hostname <text-syslog-hostname> | Hostname or IP address of the syslog server to receive notifications |
port <text-syslog-port> | Port on the syslog server to receive notifications |
severity <level> | The log level to set, which can be one of error, warning, info, or debug. The severity defaults to info. |
This example shows the creation of a syslog-netq-events channel and verifies the configuration.
-
Obtain the syslog server hostname (or IP address) and port.
-
Create the channel.
cumulus@switch:~$ netq add notification channel syslog syslog-netq-events hostname syslog-server port 514 severity error Successfully added/updated channel syslog-netq-events
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- -------- ---------------------- syslog-netq-eve syslog error host:syslog-server nts port: 514
The configuration is different depending on whether you are using the on-premises or cloud version of NetQ.
To create an email notification channel for an on-premises deployment, run:
netq add notification channel email <text-channel-name> to <text-email-toids> [smtpserver <text-email-hostname>] [smtpport <text-email-port>] [login <text-email-id>] [password <text-email-password>] [severity info | severity warning | severity error | severity debug]
This example creates an email channel named onprem-email that uses the smtpserver on port 587 to send messages to those persons with access to the smtphostlogin account.
-
Set up an SMTP server. The server can be internal or public.
-
Create a user account (login and password) on the SMTP server. NetQ sends notifications to this address.
-
Create the notification channel.
cumulus@switch:~$ netq add notification channel email onprem-email to netq-notifications@domain.com smtpserver smtp.domain.com smtpport 587 login smtphostlogin@domain.com password MyPassword123 severity warning Successfully added/updated channel onprem-email
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- ---------------- ------------------------ onprem-email email warning password: MyPassword123, port: 587, isEncrypted: True, host: smtp.domain.com, from: smtphostlogin@doma in.com, id: smtphostlogin@domain .com, to: netq-notifications@d omain.com
In cloud deployments as the NetQ cloud service uses the NetQ SMTP server to push email notifications.
To create an email notification channel for a cloud deployment, run:
netq add notification channel email <text-channel-name> to <text-email-toids> [severity info | severity warning | severity error | severity debug]
netq show notification channel [json]
This example creates an email channel named cloud-email that uses the NetQ SMTP server to send messages to those persons with access to the netq-cloud-notifications account.
-
Create the channel.
cumulus@switch:~$ netq add notification channel email cloud-email to netq-cloud-notifications@domain.com severity error Successfully added/updated channel cloud-email
-
Verify the configuration.
cumulus@switch:~$ netq show notification channel Matching config_notify records: Name Type Severity Channel Info --------------- ---------------- ---------------- ------------------------ cloud-email email error password: TEiO98BOwlekUP TrFev2/Q==, port: 587, isEncrypted: True, host: netqsmtp.domain.com, from: netqsmtphostlogin@doma in.com, id: smtphostlogin@domain .com, to: netq-notifications@d omain.com
To create and verify the specification of a generic channel, run:
netq add notification channel generic <text-channel-name> webhook <text-webhook-url> [severity info | severity warning | severity error | severity debug] [use-ssl True | use-ssl False] [auth-type basic-auth generic-username <text-generic-username> generic-password <text-generic-password> | auth-type api-key key-name <text-api-key-name> key-value <text-api-key-value>]
netq show notification channel [json]
where:
Option | Description |
---|---|
<text-channel-name> | User-specified generic channel name |
webhook <text-webhook-url> | URL of the remote application to receive notifications |
severity <level> | The log level to set, which can be one of error, warning, info, or debug. The severity defaults to info. |
use-ssl [True | False] | Enable or disable SSL |
auth-type [basic-auth | api-key] | Set authentication parameters. Either basic-auth with generic-username and generic-password or api-key with a key-name and key-value |
Create Rules
A single key-value pair comprises each rule. The key-value pair indicates what messages to include or drop from event information sent to a notification channel. You can create more than one rule for a single filter. Creating multiple rules for a given filter can provide a very defined filter. For example, you can specify rules around hostnames or interface names, enabling you to filter messages specific to those hosts or interfaces. You can only create rules after you have set up your notification channels.
NetQ includes a predefined fixed set of valid rule keys. You enter values as regular expressions, which vary according to your deployment.
Rule Keys and Values
Service | Rule Key | Description | Example Rule Values |
---|---|---|---|
BGP | message_type | Network protocol or service identifier | bgp |
hostname | User-defined, text-based name for a switch or host | server02, leaf11, exit01, spine-4 | |
peer | User-defined, text-based name for a peer switch or host | server4, leaf-3, exit02, spine06 | |
desc | Text description | ||
vrf | Name of VRF interface | mgmt, default | |
old_state | Previous state of the BGP service | Established, Failed | |
new_state | Current state of the BGP service | Established, Failed | |
old_last_reset_time | Previous time that BGP service was reset | Apr3, 2019, 4:17 PM | |
new_last_reset_time | Most recent time that BGP service was reset | Apr8, 2019, 11:38 AM | |
ConfigDiff | message_type | Network protocol or service identifier | configdiff |
hostname | User-defined, text-based name for a switch or host | server02, leaf11, exit01, spine-4 | |
vni | Virtual Network Instance identifier | 12, 23 | |
old_state | Previous state of the configuration file | created, modified | |
new_state | Current state of the configuration file | created, modified | |
EVPN | message_type | Network protocol or service identifier | evpn |
hostname | User-defined, text-based name for a switch or host | server02, leaf-9, exit01, spine04 | |
vni | Virtual Network Instance identifier | 12, 23 | |
old_in_kernel_state | Previous VNI state, in kernel or not | true, false | |
new_in_kernel_state | Current VNI state, in kernel or not | true, false | |
old_adv_all_vni_state | Previous VNI advertising state, advertising all or not | true, false | |
new_adv_all_vni_state | Current VNI advertising state, advertising all or not | true, false | LCM | message_type | Network protocol or service identifier | clag |
hostname | User-defined, text-based name for a switch or host | server02, leaf-9, exit01, spine04 | |
old_conflicted_bonds | Previous pair of interfaces in a conflicted bond | swp7 swp8, swp3 swp4 | |
new_conflicted_bonds | Current pair of interfaces in a conflicted bond | swp11 swp12, swp23 swp24 | |
old_state_protodownbond | Previous state of the bond | protodown, up | |
new_state_protodownbond | Current state of the bond | protodown, up | |
Link | message_type | Network protocol or service identifier | link |
hostname | User-defined, text-based name for a switch or host | server02, leaf-6, exit01, spine7 | |
ifname | Software interface name | eth0, swp53 | |
LLDP | message_type | Network protocol or service identifier | lldp |
hostname | User-defined, text-based name for a switch or host | server02, leaf41, exit01, spine-5, tor-36 | |
ifname | Software interface name | eth1, swp12 | |
old_peer_ifname | Previous software interface name | eth1, swp12, swp27 | |
new_peer_ifname | Current software interface name | eth1, swp12, swp27 | |
old_peer_hostname | Previous user-defined, text-based name for a peer switch or host | server02, leaf41, exit01, spine-5, tor-36 | |
new_peer_hostname | Current user-defined, text-based name for a peer switch or host | server02, leaf41, exit01, spine-5, tor-36 | MLAG (CLAG) | message_type | Network protocol or service identifier | clag |
hostname | User-defined, text-based name for a switch or host | server02, leaf-9, exit01, spine04 | |
old_conflicted_bonds | Previous pair of interfaces in a conflicted bond | swp7 swp8, swp3 swp4 | |
new_conflicted_bonds | Current pair of interfaces in a conflicted bond | swp11 swp12, swp23 swp24 | |
old_state_protodownbond | Previous state of the bond | protodown, up | |
new_state_protodownbond | Current state of the bond | protodown, up | |
Node | message_type | Network protocol or service identifier | node |
hostname | User-defined, text-based name for a switch or host | server02, leaf41, exit01, spine-5, tor-36 | |
ntp_state | Current state of NTP service | in sync, not sync | |
db_state | Current state of DB | Add, Update, Del, Dead | |
NTP | message_type | Network protocol or service identifier | ntp |
hostname | User-defined, text-based name for a switch or host | server02, leaf-9, exit01, spine04 | |
old_state | Previous state of service | in sync, not sync | |
new_state | Current state of service | in sync, not sync | |
Port | message_type | Network protocol or service identifier | port |
hostname | User-defined, text-based name for a switch or host | server02, leaf13, exit01, spine-8, tor-36 | |
ifname | Interface name | eth0, swp14 | |
old_speed | Previous speed rating of port | 10 G, 25 G, 40 G, unknown | |
old_transreceiver | Previous transceiver | 40G Base-CR4, 25G Base-CR | |
old_vendor_name | Previous vendor name of installed port module | Amphenol, OEM, NVIDIA, Fiberstore, Finisar | |
old_serial_number | Previous serial number of installed port module | MT1507VS05177, AVE1823402U, PTN1VH2 | |
old_supported_fec | Previous forward error correction (FEC) support status | none, Base R, RS | |
old_advertised_fec | Previous FEC advertising state | true, false, not reported | |
old_fec | Previous FEC capability | none | |
old_autoneg | Previous activation state of auto-negotiation | on, off | |
new_speed | Current speed rating of port | 10 G, 25 G, 40 G | |
new_transreceiver | Current transceiver | 40G Base-CR4, 25G Base-CR | |
new_vendor_name | Current vendor name of installed port module | Amphenol, OEM, NVIDIA, Fiberstore, Finisar | |
new_part_number | Current part number of installed port module | SFP-H10GB-CU1M, MC3309130-001, 603020003 | |
new_serial_number | Current serial number of installed port module | MT1507VS05177, AVE1823402U, PTN1VH2 | |
new_supported_fec | Current FEC support status | none, Base R, RS | |
new_advertised_fec | Current FEC advertising state | true, false | |
new_fec | Current FEC capability | none | |
new_autoneg | Current activation state of auto-negotiation | on, off | |
Sensors | sensor | Network protocol or service identifier | Fan: fan1, fan-2 Power Supply Unit: psu1, psu2 Temperature: psu1temp1, temp2 |
hostname | User-defined, text-based name for a switch or host | server02, leaf-26, exit01, spine2-4 | |
old_state | Previous state of a fan, power supply unit, or thermal sensor | Fan: ok, absent, bad PSU: ok, absent, bad Temp: ok, busted, bad, critical |
|
new_state | Current state of a fan, power supply unit, or thermal sensor | Fan: ok, absent, bad PSU: ok, absent, bad Temp: ok, busted, bad, critical |
|
old_s_state | Previous state of a fan or power supply unit. | Fan: up, down PSU: up, down |
|
new_s_state | Current state of a fan or power supply unit. | Fan: up, down PSU: up, down |
|
new_s_max | Current maximum temperature threshold value | Temp: 110 | |
new_s_crit | Current critical high temperature threshold value | Temp: 85 | |
new_s_lcrit | Current critical low temperature threshold value | Temp: -25 | |
new_s_min | Current minimum temperature threshold value | Temp: -50 | |
Services | message_type | Network protocol or service identifier | services |
hostname | User-defined, text-based name for a switch or host | server02, leaf03, exit01, spine-8 | |
name | Name of service | clagd, lldpd, ssh, ntp, netqd, netq-agent | |
old_pid | Previous process or service identifier | 12323, 52941 | |
new_pid | Current process or service identifier | 12323, 52941 | |
old_status | Previous status of service | up, down | |
new_status | Current status of service | up, down |
Rule names are case sensitive, and you cannot use wildcards. Rule names can contain spaces, but you must enclose them with single quotes in commands. It is easier to use dashes in place of spaces or mixed case for better readability. For example, use *bgpSessionChanges* or *BGP-session-changes* or *BGPsessions*, instead of *BGP Session Changes*. Use tab completion to view the command options syntax.
Example Rules
Create a BGP rule based on hostname:
cumulus@switch:~$ netq add notification rule bgpHostname key hostname value spine-01
Successfully added/updated rule bgpHostname
Create a rule based on a configuration file state change:
cumulus@switch:~$ netq add notification rule sysconf key configdiff value updated
Successfully added/updated rule sysconf
Create an EVPN rule based on a VNI:
cumulus@switch:~$ netq add notification rule evpnVni key vni value 42
Successfully added/updated rule evpnVni
Create an interface rule based on FEC support:
cumulus@switch:~$ netq add notification rule fecSupport key new_supported_fec value supported
Successfully added/updated rule fecSupport
Create a service rule based on a status change:
cumulus@switch:~$ netq add notification rule svcStatus key new_status value down
Successfully added/updated rule svcStatus
Create a sensor rule based on a threshold:
cumulus@switch:~$ netq add notification rule overTemp key new_s_crit value 24
Successfully added/updated rule overTemp
Create an interface rule based on port:
cumulus@switch:~$ netq add notification rule swp52 key port value swp52
Successfully added/updated rule swp52
View Rule Configurations
Use the netq show notification
command to view the rules on your
platform.
cumulus@switch:~$ netq show notification rule
Matching config_notify records:
Name Rule Key Rule Value
--------------- ---------------- --------------------
bgpHostname hostname spine-01
evpnVni vni 42
fecSupport new_supported_fe supported
c
overTemp new_s_crit 24
svcStatus new_status down
swp52 port swp52
sysconf configdiff updated
Create Filters
You can limit or direct event messages using filters. Filters are created based on rules you define and each filter contains one or more rules. When a message matches the rule, it is sent to the indicated destination. Before you can create filters, you need to have already defined rules and configured channels.
As you create filters, they are added to the bottom of a list of filters. By default, NetQ processes event messages against filters starting at the top of the filter list and works its way down until it finds a match. NetQ applies the first filter that matches an event message, ignoring the other filters. Then it moves to the next event message and reruns the process, starting at the top of the list of filters. NetQ ignores events that do not match any filter.
You mght have to change the order of filters in the list to ensure you capture the events you want and drop the events you do not want. This is possible using the before
or after
keywords to ensure one rule is processed before or after another.
This diagram shows an example with four defined filters with sample output results.
Filter names can contain spaces, but must be enclosed with single quotes in commands. It is easier to use dashes in place of spaces or mixed case for better readability. For example, use bgpSessionChanges or BGP-session-changes or BGPsessions, instead of 'BGP Session Changes'. Filter names are also case sensitive.
Example Filters
Create a filter for BGP events on a particular device:
cumulus@switch:~$ netq add notification filter bgpSpine rule bgpHostname channel pd-netq-events
Successfully added/updated filter bgpSpine
Create a filter for a given VNI in your EVPN overlay:
cumulus@switch:~$ netq add notification filter vni42 severity warning rule evpnVni channel pd-netq-events
Successfully added/updated filter vni42
Create a filter for when a configuration file is updated:
cumulus@switch:~$ netq add notification filter configChange severity info rule sysconf channel slk-netq-events
Successfully added/updated filter configChange
Create a filter to monitor ports with FEC support:
cumulus@switch:~$ netq add notification filter newFEC rule fecSupport channel slk-netq-events
Successfully added/updated filter newFEC
Create a filter to monitor for services that change to a down state:
cumulus@switch:~$ netq add notification filter svcDown severity error rule svcStatus channel slk-netq-events
Successfully added/updated filter svcDown
Create a filter to monitor overheating platforms:
cumulus@switch:~$ netq add notification filter critTemp severity error rule overTemp channel onprem-email
Successfully added/updated filter critTemp
Create a filter to drop messages from a given interface, and match
against this filter before any other filters. To create a drop-style
filter, do not specify a channel. To list the filter first, use the
before
option.
cumulus@switch:~$ netq add notification filter swp52Drop severity error rule swp52 before bgpSpine
Successfully added/updated filter swp52Drop
View the Filter Configurations
Use the netq show notification
command to view the filters on your
platform.
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
swp52Drop 1 error NetqDefaultChann swp52
el
bgpSpine 2 info pd-netq-events bgpHostnam
e
vni42 3 warning pd-netq-events evpnVni
configChange 4 info slk-netq-events sysconf
newFEC 5 info slk-netq-events fecSupport
svcDown 6 critical slk-netq-events svcStatus
critTemp 7 critical onprem-email overTemp
Reorder Filters
In the netq show notification filter
command above, the drop-based filter is listed first and the critical events filters are listed last. Because NetQ processes notifications based on the filters’ order, reordering the events so that the critical events appear higher up in the list makes sense. To reorder the critical events filters, use the before
and after
options.
For example, to put the two critical event filters just below the drop filter:
cumulus@switch:~$ netq add notification filter critTemp after swp52Drop
Successfully added/updated filter critTemp
cumulus@switch:~$ netq add notification filter svcDown before bgpSpine
Successfully added/updated filter svcDown
You do not need to reenter all the severity, channel, and rule information for existing rules if you only want to change their processing order.
Run the netq show notification
command again to verify the changes:
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
swp52Drop 1 error NetqDefaultChann swp52
el
critTemp 2 critical onprem-email overTemp
svcDown 3 critical slk-netq-events svcStatus
bgpSpine 4 info pd-netq-events bgpHostnam
e
vni42 5 warning pd-netq-events evpnVni
configChange 6 info slk-netq-events sysconf
newFEC 7 info slk-netq-events fecSupport
Suppress Events
NetQ can generate many network events. You can create rules to suppress events so that they do not appear using either the Events card or the CLI. Suppressing events is particularly useful for reducing the number of event notifications attributable to known issues or false alarms.
You can set time parameters to suppress events in a given time period. If you do not configure time parameters, the event is suppressed for two years. If you are testing a new network configuration, a switch may generate many messages. Creating a suppression rule that applies over a short time frame can be useful for silencing messages to limit distractions.
You can suppress events for the following types of messages:
- agent: NetQ Agent messages
- bgp: BGP-related messages
- btrfsinfo: Messages related to the BTRFS file system in Cumulus Linux
- clag: MLAG-related messages
- clsupport: Messages generated when creating the
cl-support script
- configdiff: Messages related to the difference between two configurations
- evpn: EVPN-related messages
- link: Messages related to links, including state and interface name
- ntp: NTP-related messages
- ospf: OSPF-related messages
- sensor: Messages related to various sensors
- services: Service-related information, including whether a service is active or inactive
- ssdutil: Messages related to the storage on the switch
Add an Event Suppression Configuration
You can suppress events using the NetQ UI or NetQ CLI.
To suppress events using the NetQ UI:
- Click (main menu).
- In the side navigation under Network, click Events.
- In the table, navigate to the column labeled Suppress Events.
- Hover over the row and select Suppress events to create parameters for the suppression rule. You can configure individual suppression rules or you can create a group rule that suppresses events for all message types.
- Enter the suppression rule parameters and click Create.
When you add a new configuration using the CLI, you can specify a scope, which limits the suppression in the following order:
- Hostname.
- Severity.
- Message type-specific filters. For example, the target VNI for EVPN messages, or the interface name for a link message.
NetQ has a predefined set of filter conditions. To see these conditions, run netq show events-config show-filter-conditions
:
cumulus@switch:~$ netq show events-config show-filter-conditions
Matching config_events records:
Message Name Filter Condition Name Filter Condition Hierarchy Filter Condition Description
------------------------ ------------------------------------------ ---------------------------------------------------- --------------------------------------------------------
evpn vni 3 Target VNI
evpn severity 2 Severity error/info
evpn hostname 1 Target Hostname
clsupport fileAbsName 3 Target File Absolute Name
clsupport severity 2 Severity error/info
clsupport hostname 1 Target Hostname
link new_state 4 up / down
link ifname 3 Target Ifname
link severity 2 Severity error/info
link hostname 1 Target Hostname
ospf ifname 3 Target Ifname
ospf severity 2 Severity error/info
ospf hostname 1 Target Hostname
sensor new_s_state 4 New Sensor State Eg. ok
sensor sensor 3 Target Sensor Name Eg. Fan, Temp
sensor severity 2 Severity error/info
sensor hostname 1 Target Hostname
configdiff old_state 5 Old State
configdiff new_state 4 New State
configdiff type 3 File Name
configdiff severity 2 Severity error/info
configdiff hostname 1 Target Hostname
ssdutil info 3 low health / significant health drop
ssdutil severity 2 Severity error/info
ssdutil hostname 1 Target Hostname
agent db_state 3 Database State
agent severity 2 Severity error/info
agent hostname 1 Target Hostname
ntp new_state 3 yes / no
ntp severity 2 Severity error/info
ntp hostname 1 Target Hostname
bgp vrf 4 Target VRF
bgp peer 3 Target Peer
bgp severity 2 Severity error/info
bgp hostname 1 Target Hostname
services new_status 4 active / inactive
services name 3 Target Service Name Eg.netqd, mstpd, zebra
services severity 2 Severity error/info
services hostname 1 Target Hostname
btrfsinfo info 3 high btrfs allocation space / data storage efficiency
btrfsinfo severity 2 Severity error/info
btrfsinfo hostname 1 Target Hostname
clag severity 2 Severity error/info
clag hostname 1 Target Hostname
For example, to create a configuration called mybtrfs
that suppresses OSPF-related events on leaf01 for the next 10 minutes, run:
netq add events-config events_config_name mybtrfs message_type ospf scope '[{"scope_name":"hostname","scope_value":"leaf01"},{"scope_name":"severity","scope_value":"*"}]' suppress_until 600
Remove an Event Suppression Configuration
You can remove event suppression configurations using the NetQ UI or NetQ CLI.
To remove suppressed event configurations:
- Click (main menu).
- In the side navigation under Network, click Events.
- Select Show suppression rules at the top of the page.
- Navigate to the rule you would like to delete. Click the three-dot menu and select Delete. If you’d like to pause the rule instead of deleting it, click Disable.
To remove an event suppression configuration, run netq del events-config events_config_id <text-events-config-id-anchor>
.
cumulus@switch:~$ netq del events-config events_config_id eventsconfig_10
Successfully deleted Events Config eventsconfig_10
Show Event Suppression Configurations
You can view suppressed events using the NetQ UI or NetQ CLI.
To view suppressed events:
- Click (main menu).
- In the side navigation under Network, click Events.
- Select Show suppression rules at the top of the page.
You can view all event suppression configurations, or you can filter by a specific configuration or message type.
cumulus@switch:~$ netq show events-config events_config_id eventsconfig_1
Matching config_events records:
Events Config ID Events Config Name Message Type Scope Active Suppress Until
-------------------- -------------------- -------------------- ------------------------------------------------------------ ------ --------------------
eventsconfig_1 job_cl_upgrade_2d89c agent {"db_state":"*","hostname":"spine02","severity":"*"} True Tue Jul 7 16:16:20
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine02
eventsconfig_1 job_cl_upgrade_2d89c bgp {"vrf":"*","peer":"*","hostname":"spine04","severity":"*"} True Tue Jul 7 16:16:20
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c btrfsinfo {"hostname":"spine04","info":"*","severity":"*"} True Tue Jul 7 16:16:20
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c clag {"hostname":"spine04","severity":"*"} True Tue Jul 7 16:16:20
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c clsupport {"fileAbsName":"*","hostname":"spine04","severity":"*"} True Tue Jul 7 16:16:20
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c configdiff {"new_state":"*","old_state":"*","type":"*","hostname":"spin True Tue Jul 7 16:16:20
21b3effd79796e585c35 e04","severity":"*"} 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c evpn {"hostname":"spine04","vni":"*","severity":"*"} True Tue Jul 7 16:16:20
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c link {"ifname":"*","new_state":"*","hostname":"spine04","severity True Tue Jul 7 16:16:20
21b3effd79796e585c35 ":"*"} 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c ntp {"new_state":"*","hostname":"spine04","severity":"*"} True Tue Jul 7 16:16:20
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c ospf {"ifname":"*","hostname":"spine04","severity":"*"} True Tue Jul 7 16:16:20
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c sensor {"sensor":"*","new_s_state":"*","hostname":"spine04","severi True Tue Jul 7 16:16:20
21b3effd79796e585c35 ty":"*"} 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c services {"new_status":"*","name":"*","hostname":"spine04","severity" True Tue Jul 7 16:16:20
21b3effd79796e585c35 :"*"} 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_1 job_cl_upgrade_2d89c ssdutil {"hostname":"spine04","info":"*","severity":"*"} True Tue Jul 7 16:16:20
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
spine04
eventsconfig_10 job_cl_upgrade_2d89c btrfsinfo {"hostname":"fw2","info":"*","severity":"*"} True Tue Jul 7 16:16:22
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
fw2
eventsconfig_10 job_cl_upgrade_2d89c clag {"hostname":"fw2","severity":"*"} True Tue Jul 7 16:16:22
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
fw2
eventsconfig_10 job_cl_upgrade_2d89c clsupport {"fileAbsName":"*","hostname":"fw2","severity":"*"} True Tue Jul 7 16:16:22
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
fw2
eventsconfig_10 job_cl_upgrade_2d89c link {"ifname":"*","new_state":"*","hostname":"fw2","severity":"* True Tue Jul 7 16:16:22
21b3effd79796e585c35 "} 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
fw2
eventsconfig_10 job_cl_upgrade_2d89c ospf {"ifname":"*","hostname":"fw2","severity":"*"} True Tue Jul 7 16:16:22
21b3effd79796e585c35 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
fw2
eventsconfig_10 job_cl_upgrade_2d89c sensor {"sensor":"*","new_s_state":"*","hostname":"fw2","severity": True Tue Jul 7 16:16:22
21b3effd79796e585c35 "*"} 2020
096d5fc6cef32b463e37
cca88d8ee862ae104d5_
fw2
When you filter for a message type, you must include the show-filter-conditions
keyword to show the conditions associated with that message type and the hierarchy in which they get processed.
cumulus@switch:~$ netq show events-config message_type evpn show-filter-conditions
Matching config_events records:
Message Name Filter Condition Name Filter Condition Hierarchy Filter Condition Description
------------------------ ------------------------------------------ ---------------------------------------------------- --------------------------------------------------------
evpn vni 3 Target VNI
evpn severity 2 Severity error/info
evpn hostname 1 Target Hostname
Examples of Advanced Notification Configurations
The following section lists examples of advanced notification configurations.
Create a Notification for BGP Events from a Selected Switch
This example creates a notification integration with a PagerDuty channel called pd-netq-events. It then creates a rule bgpHostname and a filter called 4bgpSpine for any notifications from spine-01. The result is that any info severity event messages from Spine-01 is filtered to the pd-netq-events channel.
cumulus@switch:~$ netq add notification channel pagerduty pd-netq-events integration-key 1234567890
Successfully added/updated channel pd-netq-events
cumulus@switch:~$ netq add notification rule bgpHostname key node value spine-01
Successfully added/updated rule bgpHostname
cumulus@switch:~$ netq add notification filter bgpSpine rule bgpHostname channel pd-netq-events
Successfully added/updated filter bgpSpine
cumulus@switch:~$ netq show notification channel
Matching config_notify records:
Name Type Severity Channel Info
--------------- ---------------- ---------------- ------------------------
pd-netq-events pagerduty info integration-key: 1234567
890
cumulus@switch:~$ netq show notification rule
Matching config_notify records:
Name Rule Key Rule Value
--------------- ---------------- --------------------
bgpHostname hostname spine-01
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
bgpSpine 1 info pd-netq-events bgpHostnam
e
Create a Notification for Warnings on a Given EVPN VNI
This example creates a notification integration with a PagerDuty channel called pd-netq-events. It then creates a rule evpnVni and a filter called 3vni42 for any warning messages from VNI 42 on the EVPN overlay network. The result is that any event messages from VNI 42 with a severity level of ‘warning’ are filtered to the pd-netq-events channel.
cumulus@switch:~$ netq add notification channel pagerduty pd-netq-events integration-key 1234567890
Successfully added/updated channel pd-netq-events
cumulus@switch:~$ netq add notification rule evpnVni key vni value 42
Successfully added/updated rule evpnVni
cumulus@switch:~$ netq add notification filter vni42 rule evpnVni channel pd-netq-events
Successfully added/updated filter vni42
cumulus@switch:~$ netq show notification channel
Matching config_notify records:
Name Type Severity Channel Info
--------------- ---------------- ---------------- ------------------------
pd-netq-events pagerduty info integration-key: 1234567
890
cumulus@switch:~$ netq show notification rule
Matching config_notify records:
Name Rule Key Rule Value
--------------- ---------------- --------------------
bgpHostname hostname spine-01
evpnVni vni 42
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
bgpSpine 1 info pd-netq-events bgpHostnam
e
vni42 2 warning pd-netq-events evpnVni
Create a Notification for Configuration File Changes
This example creates a notification integration with a Slack channel called slk-netq-events. It then creates a rule sysconf and a filter called configChange for any configuration file update messages. The result is that any configuration update messages are filtered to the slk-netq-events channel.
cumulus@switch:~$ netq add notification channel slack slk-netq-events webhook https://hooks.slack.com/services/text/moretext/evenmoretext
Successfully added/updated channel slk-netq-events
cumulus@switch:~$ netq add notification rule sysconf key message_type value configdiff
Successfully added/updated rule sysconf
cumulus@switch:~$ netq add notification filter configChange severity info rule sysconf channel slk-netq-events
Successfully added/updated filter configChange
cumulus@switch:~$ netq show notification channel
Matching config_notify records:
Name Type Severity Channel Info
--------------- ---------------- -------- ----------------------
slk-netq-events slack info webhook:https://hooks.s
lack.com/services/text/
moretext/evenmoretext
cumulus@switch:~$ netq show notification rule
Matching config_notify records:
Name Rule Key Rule Value
--------------- ---------------- --------------------
bgpHostname hostname spine-01
evpnVni vni 42
sysconf message_type configdiff
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
bgpSpine 1 info pd-netq-events bgpHostnam
e
vni42 2 error pd-netq-events evpnVni
configChange 3 info slk-netq-events sysconf
Create a Notification for When a Service Goes Down
This example creates a notification integration with a Slack channel called slk-netq-events. It then creates a rule svcStatus and a filter called svcDown for any services state messages indicating a service is no longer operational. The result is that any service down messages are filtered to the slk-netq-events channel.
cumulus@switch:~$ netq add notification channel slack slk-netq-events webhook https://hooks.slack.com/services/text/moretext/evenmoretext
Successfully added/updated channel slk-netq-events
cumulus@switch:~$ netq add notification rule svcStatus key new_status value down
Successfully added/updated rule svcStatus
cumulus@switch:~$ netq add notification filter svcDown severity error rule svcStatus channel slk-netq-events
Successfully added/updated filter svcDown
cumulus@switch:~$ netq show notification channel
Matching config_notify records:
Name Type Severity Channel Info
--------------- ---------------- -------- ----------------------
slk-netq-events slack info webhook:https://hooks.s
lack.com/services/text/
moretext/evenmoretext
cumulus@switch:~$ netq show notification rule
Matching config_notify records:
Name Rule Key Rule Value
--------------- ---------------- --------------------
bgpHostname hostname spine-01
evpnVni vni 42
svcStatus new_status down
sysconf configdiff updated
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
bgpSpine 1 info pd-netq-events bgpHostnam
e
vni42 2 warning pd-netq-events evpnVni
configChange 3 info slk-netq-events sysconf
svcDown 4 error slk-netq-events svcStatus
Create a Filter to Drop Notifications from a Given Interface
This example creates a notification integration with a Slack channel called slk-netq-events. It then creates a rule swp52 and a filter called swp52Drop that drops all notifications for events from interface swp52.
cumulus@switch:~$ netq add notification channel slack slk-netq-events webhook https://hooks.slack.com/services/text/moretext/evenmoretext
Successfully added/updated channel slk-netq-events
cumulus@switch:~$ netq add notification rule swp52 key port value swp52
Successfully added/updated rule swp52
cumulus@switch:~$ netq add notification filter swp52Drop severity error rule swp52 before bgpSpine
Successfully added/updated filter swp52Drop
cumulus@switch:~$ netq show notification channel
Matching config_notify records:
Name Type Severity Channel Info
--------------- ---------------- -------- ----------------------
slk-netq-events slack info webhook:https://hooks.s
lack.com/services/text/
moretext/evenmoretext
cumulus@switch:~$ netq show notification rule
Matching config_notify records:
Name Rule Key Rule Value
--------------- ---------------- --------------------
bgpHostname hostname spine-01
evpnVni vni 42
svcStatus new_status down
swp52 port swp52
sysconf configdiff updated
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
swp52Drop 1 error NetqDefaultChann swp52
el
bgpSpine 2 info pd-netq-events bgpHostnam
e
vni42 3 warning pd-netq-events evpnVni
configChange 4 info slk-netq-events sysconf
svcDown 5 error slk-netq-events svcStatus
Create a Notification for a Given Device that Has a Tendency to Overheat (Using Multiple Rules)
This example creates a notification when switch leaf04 has passed over the high temperature threshold. Two rules were necessary to create this notification, one to identify the specific device and one to identify the temperature trigger. NetQ then sends the message to the pd-netq-events channel.
cumulus@switch:~$ netq add notification channel pagerduty pd-netq-events integration-key 1234567890
Successfully added/updated channel pd-netq-events
cumulus@switch:~$ netq add notification rule switchLeaf04 key hostname value leaf04
Successfully added/updated rule switchLeaf04
cumulus@switch:~$ netq add notification rule overTemp key new_s_crit value 24
Successfully added/updated rule overTemp
cumulus@switch:~$ netq add notification filter critTemp rule switchLeaf04 channel pd-netq-events
Successfully added/updated filter critTemp
cumulus@switch:~$ netq add notification filter critTemp severity critical rule overTemp channel pd-netq-events
Successfully added/updated filter critTemp
cumulus@switch:~$ netq show notification channel
Matching config_notify records:
Name Type Severity Channel Info
--------------- ---------------- ---------------- ------------------------
pd-netq-events pagerduty info integration-key: 1234567
890
cumulus@switch:~$ netq show notification rule
Matching config_notify records:
Name Rule Key Rule Value
--------------- ---------------- --------------------
bgpHostname hostname spine-01
evpnVni vni 42
overTemp new_s_crit 24
svcStatus new_status down
switchLeaf04 hostname leaf04
swp52 port swp52
sysconf configdiff updated
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
swp52Drop 1 error NetqDefaultChann swp52
el
bgpSpine 2 info pd-netq-events bgpHostnam
e
vni42 3 warning pd-netq-events evpnVni
configChange 4 info slk-netq-events sysconf
svcDown 5 critical slk-netq-events svcStatus
critTemp 6 critical pd-netq-events switchLeaf
04
overTemp
View Notification Configurations in JSON Format
You can view configured integrations using the netq show notification
commands. To view the channels, filters, and rules, run the three flavors of the command. Include the json
option to display JSON-formatted output.
For example:
cumulus@switch:~$ netq show notification channel json
{
"config_notify":[
{
"type":"slack",
"name":"slk-netq-events",
"channelInfo":"webhook:https://hooks.slack.com/services/text/moretext/evenmoretext",
"severity":"info"
},
{
"type":"pagerduty",
"name":"pd-netq-events",
"channelInfo":"integration-key: 1234567890",
"severity":"info"
}
],
"truncatedResult":false
}
cumulus@switch:~$ netq show notification rule json
{
"config_notify":[
{
"ruleKey":"hostname",
"ruleValue":"spine-01",
"name":"bgpHostname"
},
{
"ruleKey":"vni",
"ruleValue":42,
"name":"evpnVni"
},
{
"ruleKey":"new_supported_fec",
"ruleValue":"supported",
"name":"fecSupport"
},
{
"ruleKey":"new_s_crit",
"ruleValue":24,
"name":"overTemp"
},
{
"ruleKey":"new_status",
"ruleValue":"down",
"name":"svcStatus"
},
{
"ruleKey":"configdiff",
"ruleValue":"updated",
"name":"sysconf"
}
],
"truncatedResult":false
}
cumulus@switch:~$ netq show notification filter json
{
"config_notify":[
{
"channels":"pd-netq-events",
"rules":"overTemp",
"name":"1critTemp",
"severity":"critical"
},
{
"channels":"pd-netq-events",
"rules":"evpnVni",
"name":"3vni42",
"severity":"warning"
},
{
"channels":"pd-netq-events",
"rules":"bgpHostname",
"name":"4bgpSpine",
"severity":"info"
},
{
"channels":"slk-netq-events",
"rules":"sysconf",
"name":"configChange",
"severity":"info"
},
{
"channels":"slk-netq-events",
"rules":"fecSupport",
"name":"newFEC",
"severity":"info"
},
{
"channels":"slk-netq-events",
"rules":"svcStatus",
"name":"svcDown",
"severity":"critical"
}
],
"truncatedResult":false
}
Manage NetQ Event Notification Integrations
You might need to modify event notification configurations at some point in the lifecycle of your deployment. You can add channels, rules, filters, and a proxy at any time. You can remove channels, rules, and filters if they are not part of an existing notification configuration.
For integrations with threshold-based event notifications, refer to Configure System Event Notifications.
Remove an Event Notification Channel
If you retire selected channels from a given notification application, you might want to remove them from NetQ as well. You can remove channels if they are not part of an existing notification configuration using the NetQ UI or the NetQ CLI.
To remove notification channels:
- Click , and then click Notification Channels in the Notifications section.
-
Click the tab for the type of channel you want to remove (Slack, PagerDuty, Syslog, Email).
-
Select one or more channels.
-
Click .
To remove notification channels, run:
netq del notification channel <text-channel-name-anchor>
This example removes a Slack integration and verifies it is no longer in the configuration:
cumulus@switch:~$ netq del notification channel slk-netq-events
cumulus@switch:~$ netq show notification channel
Matching config_notify records:
Name Type Severity Channel Info
--------------- ---------------- ---------------- ------------------------
pd-netq-events pagerduty info integration-key: 1234567
890
Delete an Event Notification Rule
You might find after some experience with a given rule that you want to edit or remove the rule to better meet your needs. You can remove rules if they are not part of an existing notification configuration using the NetQ CLI.
To remove notification rules, run:
netq del notification rule <text-rule-name-anchor>
This example removes a rule named swp52 and verifies it is no longer in the configuration:
cumulus@switch:~$ netq del notification rule swp52
cumulus@switch:~$ netq show notification rule
Matching config_notify records:
Name Rule Key Rule Value
--------------- ---------------- --------------------
bgpHostname hostname spine-01
evpnVni vni 42
overTemp new_s_crit 24
svcStatus new_status down
switchLeaf04 hostname leaf04
sysconf configdiff updated
Delete an Event Notification Filter
You might find after some experience with a given filter that you want to edit or remove the filter to better meet your current needs. You can remove filters if they are not part of an existing notification configuration using the NetQ CLI.
To remove notification filters, run:
netq del notification filter <text-filter-name-anchor>
This example removes a filter named bgpSpine and verifies it is no longer in the configuration:
cumulus@switch:~$ netq del notification filter bgpSpine
cumulus@switch:~$ netq show notification filter
Matching config_notify records:
Name Order Severity Channels Rules
--------------- ---------- ---------------- ---------------- ----------
swp52Drop 1 error NetqDefaultChann swp52
el
vni42 2 warning pd-netq-events evpnVni
configChange 3 info slk-netq-events sysconf
svcDown 4 critical slk-netq-events svcStatus
critTemp 5 critical pd-netq-events switchLeaf
04
overTemp
Delete an Event Notification Proxy
You can remove the proxy server by running the netq del notification proxy
command. This changes the NetQ behavior to send events directly to the notification channels.
cumulus@switch:~$ netq del notification proxy
Successfully overwrote notifier proxy to null