3. Terminology
Questa sezione conserva il testo RFC per la network fault and problem management terminology, inclusi Event, State, Fault, Problem, Symptom, Cause, Alert, Alarm, workflow figures, security, privacy e IANA considerations.
3. Terminology
This section contains key terms. It is split into three subsections.
* Section 3.1 contains terms that help set the context for network
fault and problem management systems.
* Section 3.2 includes specific and detailed core terms that will be
used in other documents that describe elements of the network
fault and problem management systems.
* Section 3.3 provides three further terms that may be helpful.
3.1. Context Terminology
This section includes some terminology that helps describe the
context for the rest of this work. The terms may be viewed as a
cascaded sequence of processes, starting with Network Telemetry and
building to Network Observability. The definitions are deliberately
kept relatively terse. Further documents may expand on these terms
without loss of specificity. Such contextualization (if any) should
be highlighted clearly in those documents.
Network Telemetry: This is defined in [RFC9232] and describes the
process of collecting operational network data categorized
according to the network plane (e.g., Layer 3, Layer 2, and Layer
1) from which it was derived. Data collected through the Network
Telemetry process does not contain any data related to service
definitions (i.e., "intent" per Section 3.1 of [RFC9315]).
Network Monitoring: This is the process of keeping a continuous
record of functions related to a network topology. It involves
tracking various aspects such as traffic patterns, device health,
performance metrics, and overall network behavior. This approach
differentiates Network Monitoring from resource or device
monitoring, which focuses on individual resources or components
(Section 3.2).
Network Analytics: This is the process of deriving analytical
insights from operational network data. A process could be
executed by a piece of software, a system, or a human that
analyzes operational data and outputs new analytical data related
to the operational data -- for example, a symptom.
Network Observability: This is the process of enabling network
behavioral assessment through analysis of observed operational
network data (logs, alarms, traces, etc.) with the aim of
detecting symptoms of network behavior, and identifying anomalies
and their causes. Network Observability begins with information
gathered using Network Monitoring tools. That information may be
further enriched with other operational data. The expected
outcome of the observability processes is identification and
analysis of deviations in observed state versus the expected state
of a network.
Thus, there is a cascaded sequence where the following relationships
apply:
* Network Telemetry is the process of collecting operational data
from a network.
* Network Monitoring is the process of creating/keeping a record of
data gathered in Network Telemetry.
* Network Analytics is the process of deriving insight through the
data recorded in Network Monitoring.
* Network Observability is the process of enabling behavioral
assessment of a network through Network Analytics.
3.2. Core Terms
The terms in this section are presented in an order that is intended
to flow such that it is possible to gain understanding reading top to
bottom. The figures and explanations in Section 4 may aid
understanding the terms set out here.
Resource: A Resource is an element of a network system.
* Resource is a recursive concept so that a Resource may be a
collection of other Resources (for example, a network node
comprises a collection of network interfaces).
Characteristic: A Characteristic is an observable or measurable
aspect or behavior associated with a Resource.
* A Characteristic may be considered to be built on facts (see
"Value", below) and the contexts and descriptors that identify
and give meaning to the facts.
* The term "Metric" (see "metric" in [RFC9417]) is another word
for a measurable Characteristic, which may also be thought of
as analogous to a "variable".
Value: A Value is a measure of a Characteristic associated with a
Resource. It may be in the form of a categorization (e.g., high
or low), an integer (e.g., a count or gauge), or a reading of a
continuous variable (e.g., an analog measurement), etc.
Change: In the context of Network Monitoring, a Change is the
variation in the Value of a Characteristic associated with a
Resource. A Change may arise over a period of time.
* Not all Changes are noteworthy (i.e., they do not have
Relevance).
* Perception of Change depends upon Detection, the sampling
rate/accuracy/detail, and perspective.
* It may be helpful to qualify this as "Value Change" because the
English word "change" is often heavily used.
Event: An Event is the variation in Value of a Characteristic of a
Resource at a distinct moment in time (i.e., the period is
negligible).
* Compared with a Change, which may be over a period of time, an
Event happens at a distinct moment in time. Thus, an Event may
be the observation of a Change.
Condition: A Condition is an interpretation of the Values of a set
of one or more Characteristics of a Resource (with respect to
working order or some other aspect relevant to the Resource
purpose/application) -- for example, "low available memory".
Thus, it is the output of a function applied to a set of one or
more variables.
State: A State is a particular Condition that a Resource has (i.e.,
it is in a State) at a specific time. For example, a router may
report the total amount of memory it has and how much is free.
These are the Values of two Characteristics of a Resource. These
Values can be interpreted to determine the Condition of the
Resource, and that may determine the State of the router, such as
shortage of memory.
* While a State may be observed at a specific moment in time, it
is actually determined by summarizing measurement over time in
a process sometimes called State compression.
* It may be helpful to qualify this as "Resource State" to make
clear the distinction between this and other uses of "state"
such as "protocol state".
* This term may be contrasted with "operational state" as used in
[RFC8342]. For example, the state of a link might be up/down/
degraded, but the operational state of the link would include a
collection of Values of Characteristics of the link.
Detect (hence Detected, Detection): To Detect is to notice the
presence of something (State, Change, Event, activity, etc.)
* Also to notice a Change (from the perspective of an observer
such as a monitoring system).
Relevance: Relevance is the consideration of an Event, State, or
Value (through the application of policy, relative to a specific
perspective or intent, and in relation to other Events, States,
and Values) to determine whether it is of note to the system that
controls or manages the network. Note, for example, that not all
Changes are Relevant.
* This term may also be used as "Relevant Event", "Relevant
State", or "Relevant Value".
Occurrence: An Occurrence is a Relevant Event or a particular
Relevant Change.
* An Occurrence may be an aggregation or abstraction of multiple
fine-grained Events or Changes.
* An Occurrence may occur at any macro or micro scale because
Resources are a recursive concept. An Occurrence may be
perceived, depending on the scope of observation (i.e.,
according to the level of Resource recursion that is examined).
That is, Occurrences, themselves, are a recursive concept.
Fault: A Fault is an Occurrence (i.e., an Event or a Change) that is
not desired/required (as it may be indicative of a current or
future undesired State). Thus, a Fault happens at a moment in
time. A Fault can potentially be associated with a Cause. See
[RFC8632] for a more detailed discussion of network faults.
* Note that there is a distinction between a Fault and a Problem
that depends on context. For example, in a connectivity
service where redundancy is present, a link down is a Problem,
but from the perspective of managing the network resources, a
link down is a Fault. Likewise, for example, in a router with
two power supplies, if the backup power supply fails leaving
the primary unprotected, this is a Problem.
Problem: A Problem is a State that is undesirable and that may
require remedial action. A Problem cannot necessarily be
associated with a Cause. The resolution of a Problem does not
necessarily act on the thing that has the Problem.
* Note that there is a historic aspect to the concept of a
Problem. The current State may be operational, but there could
have been a Fault that is unexplained, and the fact of that
unexplained recent Fault is a Problem.
* Note that while a Problem is unresolved it may continue to
require attention. A record of resolved Problems may be
maintained in a log.
* Note that there may be a State that is considered to be a
Problem from several perspectives. For example, consider a
"loss of light" State that may cause multiple services to fail.
In this example, a new State (the light recovers) may cause the
Problem to be resolved from one perspective (the services are
operational once more) but may leave the Problem as unresolved
(because the loss of light has not been explained). Further,
in this example, there could be another development (the reason
for the temporary loss of light is traced to a microbend in the
fiber that is repaired) resulting in that unresolved Problem
now being resolved. But, in this example, this still leaves a
further Problem unresolved (a microbend occurred, and that
Problem is not resolved until it is understood how it occurred
and a remedy is put in place to prevent recurrence).
Cause: A Cause is the Events (Detected or otherwise) that gave rise
to a Fault/Problem.
Incident: Also referred to as "Network Incident". An Incident is an
undesired Occurrence such as an unexpected interruption of a
network service, degradation of the quality of a network service,
or the below-target performance of a network service. An Incident
results from one or more Problems, and a Problem may give rise to
or contribute to one or more Incidents. Greater discussion of
Network Incident relationships, including Customer Incidents and
Incident management, can be found in [Net-Incident-Mgmt-YANG].
Symptom: A Symptom is an observable Value, Change, State, Event, or
Condition considered as an indication of a Problem or potential
Problem.
Anomaly: Also referred to as "Network Anomaly". An Anomaly is an
unusual or unexpected Event or pattern in network data in the
forwarding plane, control plane, or management plane that deviates
from the normal, expected behavior. See [Net-Anomaly-Arch] for
more details.
Alert: An Alert is an indication of a Fault.
Alarm: As specified in [RFC8632], an Alarm signifies an undesirable
State in a Resource that requires corrective action. From a
management point of view, an Alarm can be seen as a State in its
own right and the transition to this State may result in an Alert
being issued. The receipt of this Alert may give rise to a
continuous indication (to a human operator) highlighting the
potential or actual presence of a Problem.
3.3. Other Terms
Three other terms may be helpful:
Intermittent: A State that is not continuous but that keeps
recurring in some time frame.
Transient: A State that is not continuous and that occurs once in
some time frame.
Recurrent: A Problem that is actively resolved but returns.