Notifier#

Installation#

Notifier app can be installed using EDA Store or by running the app-installer workflow with kubectl:

apiVersion: core.eda.nokia.com/v1
kind: Workflow
metadata:
  name: notifier-install
  namespace: eda-system
spec:
  type: app-installer
  input:
    operation: install
    apps:
      - app: notifier
        catalog: eda-catalog-builtin-apps
        vendor: nokia
        version:
          type: semver
          value: v3.0.0

cat << 'EOF' | kubectl apply -f -
apiVersion: core.eda.nokia.com/v1
kind: Workflow
metadata:
  name: notifier-install
  namespace: eda-system
spec:
  type: app-installer
  input:
    operation: install
    apps:
      - app: notifier
        catalog: eda-catalog-builtin-apps
        vendor: nokia
        version:
          type: semver
          value: v3.0.0

EOF

Configuration#

After installing the app, you can configure your notification sources and destinations. You have the option to choose between two sources - Alarm or Query - and can send notifications to multiple destinations.

Sources are defined using the Notifier or ClusterNotifier Custom Resources (CRs), while destinations¹ (referred to as Providers) are set up using the Provider or ClusterProvider CRs. You can mix and match sources, as well as send notifications to multiple destinations.

The ClusterNotifier and ClusterProvider CRs are deployed in the eda-system namespace and provide system-wide notification capabilities across all EDA namespaces. In contrast, the regular Notifier and Provider CRs are namespace-scoped and can only generate notifications from alarms or queries within their own namespace.

Notification source#

Alarm#

To configure the source of the notifications, you need to create a Notifier or ClusterNotifier CR.

The example below shows a ClusterNotifier CR that genrates notifications based on any alarm across all namespaces and sends them to the referenced discord provider.

apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterNotifier
metadata:
  name: alarms-to-discord
  namespace: eda-system
spec:
  description: "Notifier for all alarms to Discord"
  enabled: true
  sources:
    alarms:
      include:
        - "*"
  providers:
    - discord

cat << 'EOF' | kubectl apply -f -
apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterNotifier
metadata:
  name: alarms-to-discord
  namespace: eda-system
spec:
  description: "Notifier for all alarms to Discord"
  enabled: true
  sources:
    alarms:
      include:
        - "*"
  providers:
    - discord

EOF

You can filter which alarms trigger notifications by specifying their type in the include/exclude lists (for example, InterfaceDown, TopoLinkDown). For ClusterNotifier CRs, you can further refine the scope by specifying which namespaces to monitor.

Query#

EQL queries can be used as a source for notifications. Users can specify the table, select relevant fields, and define conditions to trigger a notification. When the condition is met, a notification is generated and sent using the referenced providers.

The notification format can be customized using two fields; title and template; both use Go templates.. These templates render based on a map that includes all selected fields and the keys returned by the table. The key names match the raw column names shown in the EDA UI query tool.

For example, querying the table .namespace.node.srl.interface returns the keys:

• namespace.name
• namespace.node.name
• name (this is the interface name)
• and any field that was explicitly requested under fields.

The example below shows a ClusterNotifier CR that generates notifications whenever an interface operational state changes to down while its administrative state is enable.

apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterNotifier
metadata:
  name: interface-down-notifier
  namespace: eda-system
spec:
  enabled: true
  sources:
    query:
      table: .namespace.node.srl.interface
      fields:
        - admin-state
        - oper-state
        - .namespace.node.name
      where: admin-state = "enable" and oper-state = "down"
      title: Interface Down Alert
      template: |
        Namespace: {{ index . "namespace.name" }}.
        Interface {{ index . "name"}} is DOWN on node {{ index . "namespace.node.name"}}.
        (State admin/oper: {{ index . "oper-state" }}/{{ index . "admin-state"}})    
  providers:
    - discord

cat << 'EOF' | kubectl apply -f -
apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterNotifier
metadata:
  name: interface-down-notifier
  namespace: eda-system
spec:
  enabled: true
  sources:
    query:
      table: .namespace.node.srl.interface
      fields:
        - admin-state
        - oper-state
        - .namespace.node.name
      where: admin-state = "enable" and oper-state = "down"
      title: Interface Down Alert
      template: |
        Namespace: {{ index . "namespace.name" }}.
        Interface {{ index . "name"}} is DOWN on node {{ index . "namespace.node.name"}}.
        (State admin/oper: {{ index . "oper-state" }}/{{ index . "admin-state"}})    
  providers:
    - discord

EOF

Provider reference#

The Notifier/ClusterNotifier CR references the notification destination(s) by name. In the examples above, the discord provider referenced in the ClusterNotifier CR is the name of the ClusterProvider CR that should exist in the eda-system namespace. When using namespace-scoped notifiers, both the Notifier and Provider CRs must be in the same namespace, for example namespace: eda.

Notification destination#

Notifier supports multiple notification destinations (aka providers), and leverages the shoutrrr package to send notifications to the supported providers with a few provider using custom integrations. The full list of supported providers is available at the shouterrr docs.

Notifier app knows which provider to use based on the uri field in the Provider or ClusterProvider CR.

Discord#

To send notifications to Discord a user needs to create a Discord webhook². The webhook URL should look like this:

https://discord.com/api/webhooks/webhookid/token

Replace the https:// scheme with discord://

discord://discord.com/api/webhooks/webhookid/token

Now everything is ready for the ClusterProvider CR creation with the following configuration:

apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterProvider
metadata:
  name: discord
  namespace: eda-system
spec:
  enabled: true
  uri: discord://discord.com/api/webhooks/webhookid/token

cat << 'EOF' | kubectl apply -f -
apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterProvider
metadata:
  name: discord
  namespace: eda-system
spec:
  enabled: true
  uri: discord://discord.com/api/webhooks/webhookid/token

EOF

The Discord username posting the notification can be customized using a query parameter username overwriting the default webhook bot name. For example : discord://discord.com/api/webhooks/123456789/XXXXXXXXXXXXX?username=EDA

The following example of a Discord notification shows two different TopoLink alarm states: a critical alarm when all members are down (red), and a major alarm when the link is in degraded state (green). Each notification includes detailed information about the resource, its state, and timing.

Teams#

The teams provider allows users to send MS Teams notifications when events occur in the network or within EDA. The integration is done using Teams Incoming Webhook Connector, a guide can be found here³.

Copy the generated webhook address and replace the https:// scheme with teams:// to configure the teams provider.

apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterProvider
metadata:
  name: teams
  namespace: eda-system
spec:
  enabled: true
  uri: teams://<company>.webhook.office.com/webhookb2/XXXXX

cat << 'EOF' | kubectl apply -f -
apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterProvider
metadata:
  name: teams
  namespace: eda-system
spec:
  enabled: true
  uri: teams://<company>.webhook.office.com/webhookb2/XXXXX

EOF

The following example shows notifications from the EDA Notifier app to Teams that shows two consecutive messages: a TopoLinkDown alarm (critical severity, not cleared) indicating all members are down, followed by a TopoLinkDegraded alarm that has been cleared (major severity, cleared=true). Each notification provides structured information including namespace, resource details, severity level, and timestamp.

Slack#

The slack provider allows users to send Slack notifications when events occur in the network or within EDA. The integration is done using Slack webhooks, you can find the guide here⁴.

Copy the generated webhook address and replace the https:// scheme with slack:// to configure the slack provider.

The Slack channel where the notification must be posted as well as the username posting it can optionally be customized using a query parameters channel and username overwriting the default webhook name and destination channel. For example : slack://hooks.slack.com/services/XXXXX/YYYYYY/ZZZZZZ?username=EDA&channel=alerts

apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterProvider
metadata:
  name: slack
  namespace: eda-system
spec:
  enabled: true
  uri: slack://hooks.slack.com/services/ABC/DEF/GHI

cat << 'EOF' | kubectl apply -f -
apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterProvider
metadata:
  name: slack
  namespace: eda-system
spec:
  enabled: true
  uri: slack://hooks.slack.com/services/ABC/DEF/GHI

EOF

The following example of a Slack notification shows two consecutive messages: a TopoLinkDown alarm (critical severity, red icon) indicating all members are down, followed by a TopoLinkDegraded alarm that has been cleared (major severity with green checkmark, cleared=true). Both messages provide detailed information including namespace, resource name, group, severity, and timestamp.

Email#

The email provider allows users to send notifications as emails when events occur in the network or within EDA. Notifier sends an email given an SMTP address and some additional parameters:

The SMTP address must start with smtp://. If a username and password are required, they must be part of the URI authority field smtp://$user:$password@host Additional query parameters can be added to the URI:

• from : The sender email address
• to : The recipient email address
• startTLS : yes | no, if set to yes the connection to the SMTP server must use TLS.
• useHTML : yes | no, if set to yes the email content type will be set to "text/html; charset=UTF-8" otherwise "text/plain; charset=UTF-8"

Example email ClusterProvider CR:

apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterProvider
metadata:
  name: email
  namespace: eda-system
spec:
  enabled: true
  uri: smtp://$user:[email protected][email protected]&[email protected]&startTLS=yes

cat << 'EOF' | kubectl apply -f -
apiVersion: notifiers.eda.nokia.com/v1
kind: ClusterProvider
metadata:
  name: email
  namespace: eda-system
spec:
  enabled: true
  uri: smtp://$user:[email protected][email protected]&[email protected]&startTLS=yes

EOF