Source#

Logging → SSources

A Source determines which log messages a node stores or sends to a Destination. It acts as a filter that selects messages based on the originating process, severity, content, or a combination of these criteria.

The deployment of a Source is driven by a Log, which determines the nodes that the Source will be configured on.

Severities#

Log messages can have different severities. The filter options described below can exclude messages that do not match a specified severity or messages below a specified severity.

The severities in the Source resource follow the severities as described in RFC 5424, which are listed below from more critical (top) to less critical (bottom):

• Emergency (level 0)
• Alert (level 1)
• Critical (level 2)
• Error (level 3)
• Warning (level 4)
• Notice (level 5)
• Informational (level 6)
• Debug (level 7)

OS-specific mappings#

Not every operating system uses these severity levels natively. An overview of severity mappings can be found below.

Severity operators follow these conventions:

• Exact matches the OS severity that corresponds to the specified syslog severity.
• Minimum matches the corresponding OS severity and all more critical OS severities.

Facilities#

On Linux-based operating systems, logging facilities distinguish messages from the underlying operating system from messages generated by routing processes.

Filtering by facility is not supported on SR OS.

Subsystems#

A log message is generated by a particular process, such as the AAA process for login events or BGP for BGP events. In EDA, these processes are called subsystems. Log messages can be sourced from a combination of subsystems, which may be named differently on different operating systems.

There are two ways of specifying which messages the Source will capture:

• By selecting generic subsystems, for which a translation to their OS-specific counterpart is determined by the Source abstraction
• By selecting OS-specific subsystems, exposing every subsystem available on that particular operating system

Generic subsystems#

The Source abstraction aims to match subsystems as defined in a particular operating system to a common, generic name. These generic subsystems are grouped in three categories:

• Security subsystems
• Operational subsystems
• Routing subsystems

For any particular operating system, a generic subsystem may translate to zero, one, or many subsystem names.

A user can select multiple generic subsystems.

Exhaustive list of generic subsystem mappings#

OS-specific subsystems#

Not all generic subsystems translate to a subsystem on every operating system. Similarly, not every subsystem on an operating system is linked to a generic subsystem.

Subsystem extensions allow the user to choose from all subsystems that are available on an operating system. This provides the greatest level of flexibility, but prevents the Source from being deployed across multiple operating systems.

Dependencies#

The Source resource does not have any dependencies.

Referenced resources#

The Source does not reference any other EDA resources.

Examples#

apiVersion: logging.eda.nokia.com/v1alpha1
kind: Source
metadata:
  name: bgp-source
  namespace: eda
spec:
  subsystems:
    routing:
      - BGP
  messageFiltering:
    matchMode: Deny
    rules:
      - operator: Contains
        text: Established

cat << 'EOF' | kubectl apply -f -
apiVersion: logging.eda.nokia.com/v1alpha1
kind: Source
metadata:
  name: bgp-source
  namespace: eda
spec:
  subsystems:
    routing:
      - BGP
  messageFiltering:
    matchMode: Deny
    rules:
      - operator: Contains
        text: Established
EOF

Custom Resource Definition#

To browse the Custom Resource Definition, go to crd.eda.dev.