4. 工作流说明
本节旨在 network fault and problem management 语境中, 补充说明第 3.2 节所定义术语之间的关系. 此处文本和图形仅用于解释, 对术语定义不具有规范性.
Resources 与 Characteristics 之间的关系如图 1 所示. 注意, Network system 与 Resources 之间, Resources 与 Characteristics 之间均存在 1:n 关系; 为清晰起见, 图中未显示这一点.
Characteristics
^
|
Resources
^
|
Network system
图 1: Resources and Characteristics
Resource 的 Characteristic 的 Value 可以随时间变化. 具体 Changes in Value 可能在特定时间被注意到 (作为数字 Changes), 被 Detected, 并被视为 Events. 这显示在图 2 左侧.
图 2 中部显示 Characteristic 的 Value 如何随时间变化. Value 可以在特定时间或周期性地被 Detected, 并产生作为 States 的 Conditions (进而产生 State Changes).
实践中, Characteristic 可能如图 2 右侧所示以模拟方式随时间变化. Value 可以周期性读取或报告, 即被 Detected, 从而产生可能被视为 Relevant Values 的模拟 Values; 或者可以如图 6 所示随时间评估.
Event State Value
Condition
^ ^ ^
Detect : Detect : Detect :
: : :
^ ^ ^ ^ ^ /\
: : : : : / \
: : : : : /\ / \
__ __ _____ / \/
| | | | /\/
__| |__ ____| |____ /
Change at a time Change over time Change over time
图 2: Characteristics and Changes
图 3 显示 Events 的工作流进展. 如上所述, Event 是某一时间 Characteristic 的 Value 的 Change. 可以对 Event 进行评估 (考虑 policy, 相对于特定 perspective, 着眼于 intent, 并结合其他 Events, States 和 Values), 以确定它是否是 Occurrence, 并可能指示 Change of State. Occurrence 可能是不期望的 (Fault), 这可能导致生成 Alert. 或者, Occurrence 可能是 Problem 的证据, 并可能直接指示 Cause. 在某些情况下, Alert 可能产生 Alarm, 以突出显示 Problem 的潜在或实际存在.
Alert - - - > Alarm
^
|
| -----> Cause
| |
|----------> Problem
|
|
Fault
^
|
|
|
Occurrence
^
|
|----------> State
|
|
Event
图 3: Event and Dependent Terms
与 Events 的工作流并行, 图 4 显示 States 的工作流进展. 如图 2 所示, 在特定时间注意到的 Change 会产生 State. 可以在考虑 policy, 相对于特定 perspective, 着眼于 intent, 并结合其他 Events, States 和 Values 的情况下, 认为 State 具有 Relevance. Relevant State 可被认为是 Problem, 或者可能指示 Problem 或潜在 Problem.
Problems 可以基于 Symptoms 来考虑, 并可以直接或间接映射到 Causes. Incident 源自一个或多个 Problems. Alarm 可以因 Problem 而引发, 转换到 alarmed State 可能产生 Alert.
Alarm - - -> Alert
^
| ------> Incident
| |
| | ---> Cause
| | |
Problem---------> Symptom
^
|
| Relevance
|
|
State
图 4: State and Dependent Terms
图 5 显示如何整合 Faults 和 Problems 来确定 Causes. 箭头显示一个项目如何可能引发另一个项目.
Cause 可以由 Faults, Problems 和 Symptoms 指示或从中确定. 一个 Cause 可能指向另一个 Cause, 也可以被视为 Symptom. Causes 的确定可以考虑多个输入. Incident 源自一个或多个 Problems.
---------
------------- | |
| ----------> | Symptom |
| | | |
| | ---------
v | ^
--------- |
------->| Cause |<--------- |
| --------- | |
| ^ | | |
| | | | |
| --- | |
| | |
--------- --------- ----------
| Fault |------------------->| Problem |------->| Incident |
--------- --------- ----------
图 5: Symptoms and Causes 的整合
图 6 显示 thresholds 在考虑模拟 Values 和 Events 时的重要性. 图中的箭头显示一个项目如何可能引发或使用另一个项目. 使用 threshold-driven Events 和 States (以及它们可能引发的 Alerts) 时必须谨慎, 以抑制任何 "flapping" (从而可观察到一致 States), 并避免压垮 management processes 或 systems. Analog Values 可以从 Resource 读取或通知, 并可能跨越 threshold, 被视为 Relevant Values, 或随时间评估. Events 可以被计数, Count 可能跨越 threshold 或达到 Relevant Value.
Threshold Process 可以是实现特定的, 并受 policies 约束. 当 threshold 被跨越且任何其他条件匹配时, 可以确定一个 Event, 并像处理任何其他 Event 一样处理它.
Occurrence
^
|
|---------------------> State
|
| ------- Relevance
|------>| Count |-----------------------------> Value
| ------- | ^
| | | |
| | | | Relevance
| | v |
| | ----------- ----------------
Event | | Evaluated | | |
^ | | over time |<--------| Analog Value |
| v ----------- | |
| ----------- | | |
| | Threshold | | | |
|<----| Process |<------ | |
| | |<----------------------| |
| ----------- ----------------
| ^
| |
| Detect Detect |
| |
Change at a Time Change over Time
图 6: Counts, Thresholds, and Values