需使用 cilium monitor -t 指定类型：-t drop 查丢包原因（如 Policy denied/Invalid destination），-t policy-verdict 看策略决策细节（含 rule-id、identity、flowID），-t debug 追踪 BPF 执行路径（如隧道 endpoint 异常）。
怎么打开 cilium monitor 的 debug / drop / policy 日志
cilium monitor 默认只输出基础事件，要看到 debug、drop、policy-verdict 这类细粒度日志，得手动开启对应子系统。核心是用 cilium monitor 命令加 -t 参数指定类型，不是改配置文件或重启 agent。
-
cilium monitor -t drop：捕获被内核丢弃的包（含原因，比如Policy denied或No route to host） -
cilium monitor -t policy-verdict：显示策略决策全过程，包括匹配了哪条NetworkPolicy、是否允许、触发的规则 ID -
cilium monitor -t debug：输出底层 BPF 程序执行路径（如tc ingress阶段、ct lookup结果），适合追踪连接建立失败或 NAT 异常
注意：-t debug 会产生大量日志，线上环境慎用；-t drop 和 -t policy-verdict 可长期开启，但建议配合 --from-pod 或 --to-pod 过滤，否则容易淹没关键信息。
drop 日志里 “Policy denied” 和 “Invalid destination” 区别在哪
这两类 drop 都写在同一个日志流里，但背后机制完全不同，直接决定排查方向。
-
Policy denied：说明包通过了路由和连接跟踪，但在 L3/L4 策略检查阶段被拒绝。常见于 NetworkPolicy 未覆盖端口、标签不匹配、或用了egress规则但没配toEntities或toCIDR -
Invalid destination：包压根没走到策略层，通常因为目的 IP 不属于任何已知 endpoint（比如 Pod 已销毁但 conntrack 表未清理）、或者访问的是 ClusterIP 但对应 Service 没后端 Pod
典型陷阱：看到 Policy denied 就去翻 NetworkPolicy，但实际可能是 endpoint 标签写错（比如 app: frontend 写成 app: front-end），导致策略根本没生效——这时 cilium endpoint list 和 cilium policy get 要一起看。
policy-verdict 日志怎么看“为什么允许/拒绝”
policy-verdict 日志每行包含决策动作（ALLOW/DENY）、触发规则来源（ingress/egress）、规则 ID（如 rule=123），以及关键上下文（源/目标 identity、端口、协议）。
- 规则 ID 对应
cilium policy get输出中的rule-id字段，不是数组下标 - 如果 verdict 是
DENY但没看到对应 rule-id，说明是默认拒绝（default-deny），即没有匹配到任何显式规则 - 同一连接可能有多个 verdict 日志（例如 TCP SYN 允许，但后续 ACK 被 deny），要按
flowID字段串联查看
示例片段：
cilium monitor -t policy-verdict | grep "flowID=0xabc123"
能帮你锁定某次连接的完整策略链路，比盲猜快得多。
debug 日志里 “Unable to get tunnel endpoint” 是什么问题
这个错误出现在 cilium monitor -t debug 中，通常表示 Cilium 正在尝试封装 VXLAN/Geneve 隧道包，但找不到目标节点的隧道 endpoint 信息。
常见原因：
- 目标 Node 的
cilium-agent崩溃或未启动，导致其 endpoint 信息未同步到 kvstore - kvstore（etcd/Consul）网络不通或响应超时，cilium 无法读取其他节点状态
- 节点间 MTU 不一致，导致隧道握手包被静默丢弃（尤其在云厂商 VPC 中）
验证方法：运行 cilium node list，看目标节点是否在列表中且状态为 ready；再执行 cilium status --verbose，检查 kvstore 连接和 health 状态。如果节点显示 unreachable，基本就是网络或 kvstore 问题，不是策略配置问题。
Cilium 的日志层级很细，但 debug/drop/policy-verdict 三者职责分明：drop 告诉你“包没了”，policy-verdict 告诉你“为什么没放行”，debug 则暴露“BPF 里哪一步卡住了”。混着看才有意义，单看一类容易漏掉上下文。
