OSPF Watcher 实战手册

1. 本手册的使用方式

每个练习：做一处变更，预测 OSPF 结果，观察 Watcher 事件，然后在 Topolograph 监控、SDK 中，以及-对于关联练习-在 agent 的回答中找到同一事实。在下一个独立练习之前恢复实验环境。

Watcher CSV 行是确定性的源事件。
监控和 SDK 证明事件已被接收且可查询。
agent 仅用于把多个事件关联成一次事故，绝不替代源行。

2. 六路由器实验环境的启动与验证

运行 OSPF Watcher 仓库中基于 GRE 的公开 ospf01 拓扑。

命令

cd containerlab/ospf01
sudo clab inspect --all
sudo clab destroy --topo ospf01.clab.yml --cleanup   # only if a stale ospf01 is listed
sudo ./prepare.sh
sudo clab deploy --topo ospf01.clab.yml
sudo docker logs clab-ospf01-ospf-watcher
sudo tail -f watcher/logs/watcher1.ospf.log

需确认项继续前需确认的事实

六个路由器容器加 watcher 均已运行：docker ps --filter name=clab-ospf01 列出 clab-ospf01-router1..6 和 clab-ospf01-ospf-watcher，State 均为 Up。
watcher 已获得 LSDB 并正在抓包：docker logs clab-ospf01-ospf-watcher 显示 "OSPF LSDB received" 行和 "Start sniffing on interface: eth1"。
邻接均为 Full：docker exec clab-ospf01-router1 vtysh -c 'show ip ospf neighbor' 列出每个邻居处于 Full 状态；此时第一个 Topolograph 图包含六个路由器。

回滚： 完成本手册后，在 containerlab/ospf01/ 目录下用 sudo clab destroy --topo ospf01.clab.yml --cleanup 删除实验环境。

3. 网络事件记录的格式

本手册使用三类事件：host、metric 和 network。把 event_object 理解为发生变化的对象，event_status 为状态转换，event_detected_by 为发布或检测到变化的路由器。graph_time 是 watcher 为本次运行所用的标签，用于选择 Topolograph 图。

把上面的 metric 行当作一句话来读：在 2026-09-06T13:11:04Z，watcher ospfwatcher-demo 看到路由器 10.10.10.2 重新发布它到 10.10.10.3 的链路，开销从 10 变为 222，本地接口为 192.168.23.1，区域 0.0.0.0 / AS 12345。紧随其后的 network 行对该链路上的子网 192.168.23.0/24 携带同样的 10 -> 222 变化。

字段顺序：watcher_time、watcher_name、event_name、event_object、event_status、[开销字段]、event_detected_by、graph_time、area_num、asn、[类型字段]、sesid、srcid。
area_num 0.0.0.0 和 asn 12345 标识路由域；sesid 是 watcher 会话，srcid 是源路由器 id。

Watcher 日志 (CSV)

host: 2026-09-06T13:04:25.256Z,ospfwatcher-demo,host,10.10.10.2,down,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
metric: 2026-09-06T13:11:04.205Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:10,new_cost:222,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.1,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
network: 2026-09-06T13:11:04.207Z,ospfwatcher-demo,network,192.168.23.0/24,changed,old_cost:10,new_cost:222,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1

4. 事件从何而来

一次 OSPF 变更产生一行 Watcher CSV。Fluent Bit 将其转发到 Topolograph，Topolograph 存储它并通过监控页面、事件 API 和 SDK 暴露。下面每个练习都在你可用的每个层级上核对同一事实。

ospf01 Watcher 日志 -> Fluent Bit CSV 解析器 -> Topolograph 接收 -> 监控页面 + 事件 API -> Topolograph SDK
监控页面：OSPF/IS-IS Real-Time Monitoring。按时间戳选择图，设置时间窗口，点击 Find logs；开关用于过滤子网 / 链路 / 开销事件。
该页面的图选择器按从新到旧列出 watcher 报告的每个拓扑快照-那就是 watcher 发送的拓扑。

graph 06Sep2026_12h31m41s 的 Topolograph OSPF/IS-IS Real-Time Monitoring 页面：图选择器和 Find logs，事件流显示 metric 10 -> 222 和 222 -> 10 以及 192.168.23.0/24 标签，下方是包含六个路由器和链路权重的拓扑图。

SDK 请求

from topolograph import Topolograph

topo = Topolograph(url="http://<your-topolograph>:8080",
                   username="<email>", password="<password>")
graph = topo.graphs.get(latest=True)
print(graph.graph_time, graph.protocol, graph.hosts)

SDK 输出

06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo ospf {'count': 6}

5. 点到点链路上的开销变化

更改 router2 eth1 朝向 router3 的方向。OSPF 开销是有向的，因此反方向 router3 到 router2 的开销不能当作同一个标量。

命令

sudo docker exec clab-ospf01-router2 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'ip ospf cost 222'

核对此次变更。 打开你环境中每一个可用的来源，并与下面的示例逐一核对。

Watcher 日志变更及其回滚对应的 metric 和 network 行 4 行

Watcher 日志 (CSV)

2026-09-06T13:11:04.205Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:10,new_cost:222,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.1,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:11:04.207Z,ospfwatcher-demo,network,192.168.23.0/24,changed,old_cost:10,new_cost:222,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# rollback (no ip ospf cost 222):
2026-09-06T13:11:18.365Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:222,new_cost:10,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.1,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:11:18.367Z,ospfwatcher-demo,network,192.168.23.0/24,changed,old_cost:222,new_cost:10,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1

监控事件流中的 10 -> 222 metric 变化

在 OSPF/IS-IS Real-Time Monitoring 页面，于 Choose the graph 中选择该图，将 From/To 窗口设为 13:11 UTC 左右并点击 Find logs。开启 Changed metric 后，事件流显示一行：object 10.10.10.3，detected by 10.10.10.2，10 -> 222-仅 router2 -> router3 方向。反方向未列出。事件流下方的拓扑图以新权重重绘 router2-router3 链路。

SDK 核对 get_adjacency_events 和 get_network_events 返回相同的对象和开销 2 个事件

SDK 请求

adj = graph.events.get_adjacency_events(
    start_time="2026-09-06T13:11:00Z", end_time="2026-09-06T13:11:10Z")
net = graph.events.get_network_events(
    start_time="2026-09-06T13:11:00Z", end_time="2026-09-06T13:11:10Z")
print(adj["adjacency_cost_change_events"])
print(net["network_cost_change_events"])
e = adj["adjacency_cost_change_events"][0]
print(e.event_object, e.event_detected_by, e.old_cost, e.new_cost, e.local_ip_address)

SDK 输出

[Event(name=metric, status=changed, object=10.10.10.3)]
[Event(name=network, status=changed, object=192.168.23.0/24)]
10.10.10.3 10.10.10.2 10 222 192.168.23.1

metric 事件指明 router2 -> router3 方向（event_object 10.10.10.3，event_detected_by 10.10.10.2），开销 10 -> 222；192.168.23.0/24 携带同样的变化。两个列表中都没有反方向。

询问 agent 关于 router2 的通用事故问题

提问： What happened with router2 in the last 10 minutes?

已记录的回答（Qwen；每次运行措辞会变）

In the 06Sep2026_12h31m41s snapshot, router2 (10.10.10.2) had one change in this window - an OSPF metric change on its link to 10.10.10.3, detected by router2 itself. No prefix, link, or node went down.

13:11:04 - router2 raised the cost of its link to 10.10.10.3 from 10 to 222 (192.168.23.0/24, area 0).

13:11:19 - router2 restored that cost from 222 back to 10.

Only the router2 -> 10.10.10.3 direction produced an event; the reverse 10.10.10.3 -> router2 direction did not change.

本次运行观察到：router2 以开销 222（原为 10）重新发布它到 router3 的链路；反方向 router3 -> router2 未变化。

回滚： 执行 no ip ospf cost 222，并确认反向的 222 -> 10 metric 和 network 事件。

6. 检测内部与外部前缀事件

每个前缀实验都独立进行。配置为 /24 掩码的 OSPF loopback 在本实验环境中以 /32 主机路由发布。

6a. 在 router2 loopback 上添加 192.168.123.1/24；观察 192.168.123.1/32 up 且开销 -1 -> 0（internal）。
6b. 在 router6 loopback 上添加 10.10.136.6/24；观察 10.10.136.6/32 up 且开销 -1 -> 0（internal）。
6c. 在 router6 上删除静态路由 6.6.6.6/32；观察 6.6.6.6/32 down 且开销 11 -> -1（external，type 2）。

命令

sudo docker exec clab-ospf01-router2 vtysh \
  -c 'conf t' -c 'interface lo' -c 'ip address 192.168.123.1/24'

核对此次变更。 打开你环境中每一个可用的来源，并与下面的示例逐一核对。

Watcher 日志每个子练习一行 up/down 和一行 changed 6 行

Watcher 日志 (CSV)

# 6a router2: ip address 192.168.123.1/24 on interface lo
2026-09-06T13:12:06.600Z,ospfwatcher-demo,network,192.168.123.1/32,up,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:12:06.601Z,ospfwatcher-demo,network,192.168.123.1/32,changed,old_cost:-1,new_cost:0,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# 6b router6: ip address 10.10.136.6/24 on interface lo
2026-09-06T13:12:28.916Z,ospfwatcher-demo,network,10.10.136.6/32,up,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:12:28.917Z,ospfwatcher-demo,network,10.10.136.6/32,changed,old_cost:-1,new_cost:0,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# 6c router6: no ip route 6.6.6.6/32 192.168.36.3
2026-09-06T13:12:51.315Z,ospfwatcher-demo,network,6.6.6.6/32,down,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:12:51.315Z,ospfwatcher-demo,network,6.6.6.6/32,changed,old_cost:11,new_cost:-1,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,external,2,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1

监控事件流中新增和撤回的前缀

在 OSPF/IS-IS Real-Time Monitoring 页面选择该图，将 From/To 窗口设为 13:12 UTC 左右并点击 Find logs。开启 New/Old Subnets 后，192.168.123.1/32 和 10.10.136.6/32 显示为新增，6.6.6.6/32 显示为撤回；事件流下方的拓扑图加入这两条主机路由并移除被撤回的一条。

SDK 核对 get_network_events，每个子练习一个 changed 事件 3 个事件

SDK 请求

for window in [("2026-09-06T13:12:05Z", "2026-09-06T13:12:08Z"),
               ("2026-09-06T13:12:27Z", "2026-09-06T13:12:30Z"),
               ("2026-09-06T13:12:50Z", "2026-09-06T13:12:53Z")]:
    net = graph.events.get_network_events(start_time=window[0], end_time=window[1])
    for e in net["network_up_down_events"]:
        print(e.event_object, e.event_status, e.event_detected_by,
              f"{e.old_cost} -> {e.new_cost}", e.subnet_type, e.int_ext_subtype)

SDK 输出

192.168.123.1/32 changed 10.10.10.2 -1 -> 0 internal 0
10.10.136.6/32 changed 10.10.10.6 -1 -> 0 internal 0
6.6.6.6/32 changed 10.10.10.6 11 -> -1 external 2

loopback 上的 /24 以 /32 发布。可达性是 up/down 事件；开销变化是 changed 事件。被撤回的路由是 external / type 2，两个 loopback 是 internal / 0。

询问 agent 关于前缀变化的通用问题

提问： Which prefixes changed in the last 15 minutes, and were they internal or external?

已记录的回答（Qwen；每次运行措辞会变）

In the 06Sep2026_12h31m41s snapshot, three prefixes changed between 13:12 and 13:13 UTC - each advertised and then withdrawn within about ten seconds.

192.168.123.1/32 - internal, seen from 10.10.10.2 at 13:12:07 (cost 0), gone by 13:12:18.

10.10.136.6/32 - internal, seen from 10.10.10.6 at 13:12:29 (cost 0), gone by 13:12:40.

6.6.6.6/32 - external, withdrawn by 10.10.10.6 at 13:12:51 (was cost 11), back by 13:13:03.

192.168.123.1/32 and 10.10.136.6/32 are internal; 6.6.6.6/32 is the only external prefix.

本次运行观察到：192.168.123.1/32 和 10.10.136.6/32 作为内部主机路由被加入；6.6.6.6/32（external，type 2）被撤回。

回滚： 6a：在 router2 interface lo 上 no ip address 192.168.123.1/24。6b：在 router6 interface lo 上 no ip address 10.10.136.6/24。6c：在 router6 上 ip route 6.6.6.6/32 192.168.36.3。每一步之后确认反向事件。

7. 检测连通性丢失与恢复

关闭 router2 eth1，检查关联的事件集合，然后用 no shutdown 恢复接口。

命令

# down
sudo docker exec clab-ospf01-router2 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'shutdown'
# recovery
sudo docker exec clab-ospf01-router2 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'no shutdown'

核对此次变更。 打开你环境中每一个可用的来源，并与下面的示例逐一核对。

Watcher 日志 router2-router3 链路的中断事件集与恢复事件集 down + up

Watcher 日志 (CSV)

# router2: interface eth1 / shutdown
2026-09-06T13:04:25.256Z,ospfwatcher-demo,host,10.10.10.2,down,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:25.256Z,ospfwatcher-demo,metric,10.10.10.2,changed,old_cost:10,new_cost:-1,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.2,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:25.257Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:10,new_cost:-1,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.1,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:25.259Z,ospfwatcher-demo,network,192.168.23.0/24,down,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# router2: interface eth1 / no shutdown
2026-09-06T13:04:40.438Z,ospfwatcher-demo,network,192.168.23.0/24,up,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:40.458Z,ospfwatcher-demo,host,10.10.10.2,up,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:40.459Z,ospfwatcher-demo,metric,10.10.10.2,changed,old_cost:-1,new_cost:10,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.2,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:45.557Z,ospfwatcher-demo,host,10.10.10.3,up,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1

监控事件流中作为一次波动的中断

在 OSPF/IS-IS Real-Time Monitoring 页面选择该图，将 From/To 窗口设为 13:04 UTC 左右并点击 Find logs。开启 Up/Down Links 后，10.10.10.2 先 down 后 up，两个有向开销都变为 -1 再恢复，192.168.23.0/24 变为不可达再恢复；事件流下方的拓扑图移除 router2-router3 链路再恢复。

SDK 核对 get_adjacency_events 返回成对的 down/up 变化 4 次变化

SDK 请求

adj = graph.events.get_adjacency_events(
    start_time="2026-09-06T13:04:20Z", end_time="2026-09-06T13:04:50Z")
for e in adj["all_host_up_down_events"]:
    print(e.event_name, e.event_object, "detected_by", e.event_detected_by,
          f"{e.old_cost} -> {e.new_cost}", e.watcher_time[11:19])

SDK 输出

metric 10.10.10.2 detected_by 10.10.10.3 10 -> -1 13:04:25
metric 10.10.10.3 detected_by 10.10.10.2 10 -> -1 13:04:25
metric 10.10.10.2 detected_by 10.10.10.3 -1 -> 10 13:04:40
metric 10.10.10.3 detected_by 10.10.10.2 -1 -> 10 13:04:45

host 10.10.10.2 down，由 10.10.10.3 检测到，两个有向开销均为 -1，192.168.23.0/24 down；随后是镜像的恢复。

询问 agent 关于网络的通用事故问题

提问： What happened in the network in the last 30 minutes?

已记录的回答（Qwen；每次运行措辞会变）

There was 1 wave of activity, starting at 13:04:25 UTC and involving 2 devices - a brief link flap between 10.10.10.2 and 10.10.10.3 that fully recovered (converged) within ~21 seconds.

13:04:25 - device 10.10.10.2 lost adjacency (link down, cost 10 -> -1).

13:04:25 - device 10.10.10.3 lost adjacency (link down, cost 10 -> -1).

13:04:41 - device 10.10.10.2 restored adjacency (link up, cost -1 -> 10).

13:04:46 - device 10.10.10.3 restored adjacency (link up, cost -1 -> 10).

Pattern: flap - all devices recovered within the wave, so the network re-converged.

回答指出发生故障的邻接（10.10.10.2 - 10.10.10.3）由 10.10.10.3 检测到，两个开销均为 -1，以及恢复过程-与上面 CSV 行相同的事实，而问题从未提到 'adjacency' 或 'failure'。

回滚： no shutdown 恢复接口；等待 host、network 和 metric 的恢复事件。

8. 广播中转网段的事件呈现

用 router6 eth1 将中转网段的上报与点到点情形作对比。

命令

# cost
sudo docker exec clab-ospf01-router6 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'ip ospf cost 66'
# then, separately: shutdown, then no shutdown
sudo docker exec clab-ospf01-router6 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'shutdown'
sudo docker exec clab-ospf01-router6 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'no shutdown'

核对此次变更。 打开你环境中每一个可用的来源，并与下面的示例逐一核对。

Watcher 日志开销变化指明远端路由器 id，以及一对 shutdown/恢复 cost + up/down

Watcher 日志 (CSV)

# router6: interface eth1 / ip ospf cost 66   (and rollback ip ospf cost 6)
2026-09-06T13:13:13.841Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:6,new_cost:66,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.36.6,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:13:25.028Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:66,new_cost:6,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.36.6,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# router6: interface eth1 / shutdown
2026-09-06T13:13:36.241Z,ospfwatcher-demo,host,10.10.10.6,down,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:13:36.241Z,ospfwatcher-demo,metric,10.10.10.6,changed,old_cost:10,new_cost:-1,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.36.3,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# router6: interface eth1 / no shutdown
2026-09-06T13:14:30.447Z,ospfwatcher-demo,host,10.10.10.6,up,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:14:30.447Z,ospfwatcher-demo,metric,10.10.10.6,changed,old_cost:-1,new_cost:10,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.36.3,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1

监控中转开销变化与 router6 中断

在 OSPF/IS-IS Real-Time Monitoring 页面选择该图，将 From/To 窗口设为 13:13-13:14 UTC 左右并点击 Find logs。metric 事件的 object 是 10.10.10.3（远端路由器 id），event_detected_by 是 10.10.10.6-不同于点到点链路，那里的 object 是邻居。事件流下方的拓扑图重新赋权，然后移除并恢复 router6 的连接。

SDK 核对针对中转开销和 shutdown/恢复的 get_adjacency_events 4 次变化

SDK 请求

cost = graph.events.get_adjacency_events(
    start_time="2026-09-06T13:13:10Z", end_time="2026-09-06T13:13:30Z")
for e in cost["adjacency_cost_change_events"]:
    print("cost", e.event_object, e.event_detected_by, f"{e.old_cost} -> {e.new_cost}", e.watcher_time[11:19])
flap = graph.events.get_adjacency_events(
    start_time="2026-09-06T13:13:30Z", end_time="2026-09-06T13:14:35Z")
for e in flap["all_host_up_down_events"]:
    print("updown", e.event_object, e.event_detected_by, f"{e.old_cost} -> {e.new_cost}", e.watcher_time[11:19])

SDK 输出

cost 10.10.10.3 10.10.10.6 6 -> 66 13:13:13
cost 10.10.10.3 10.10.10.6 66 -> 6 13:13:25
updown 10.10.10.6 10.10.10.3 10 -> -1 13:13:36
updown 10.10.10.6 10.10.10.3 -1 -> 10 13:14:30

在中转网段上，metric 事件指明远端路由器 id（10.10.10.3），由 router6 检测到；shutdown 表现为 host 10.10.10.6 down，随后恢复。

询问 agent 关于 router6 的通用事故问题

提问： What happened on router6 in the last 20 minutes?

已记录的回答（Qwen；每次运行措辞会变）

In the 06Sep2026_12h31m41s snapshot, router6 (10.10.10.6) first flapped the cost of its link to 10.10.10.3, then lost that adjacency and recovered - about a 55 second outage.

13:13:14 - router6 changed the cost of its link to 10.10.10.3 from 6 to 66.

13:13:25 - router6 restored that cost from 66 back to 6.

13:13:36 - neighbor 10.10.10.3 reported its adjacency to router6 down (metric 10 -> -1).

13:14:31 - 10.10.10.3 reported the adjacency back up (metric -1 -> 10); router6 re-advertised its side at cost 6 by 13:14:36.

Pattern: a brief metric flap on the router6 - 10.10.10.3 link, then a short outage that fully recovered.

本次运行观察到：router6 -> router3 的中转开销从 6 -> 66 再变回，随后 router6 的连接中断（metric -1）并恢复。

回滚： ip ospf cost 6 恢复基线；no shutdown 恢复邻接。确认反向的 metric 事件。