在Knative Eventing中如果遇到事件未处理的异常情况，如何进行排查？
首先需要明确当前版本的事件处理模型
社区给出的0.3版本事件处理模型：
0.5版本事件处理模型：
参照事件处理模型依次从上游到下游进行排查处理
这里以0.5事件处理模型下，部署Kubernetes Event Source example 为例：
1) 查看部署事件源
# kubectl get KubernetesEventSource testevents -o yaml
AI 代码解读
2) 查看 Broker
kubectl get broker default -o yaml
AI 代码解读
3) 查看 Ingress
// Ingress service
# kubectl get svc default-broker -o yaml
// Ingress deployment
# kubectl get deployments default-broker-ingress -o yaml
AI 代码解读
4) 查看 Channel
// 查看Channel资源
# kubectl get channel default-broker-8ml79 -o yaml
// 查看Channel 分发日志信息
# kubectl -n knative-eventing logs --tail=500 in-memory-channel-dispatcher-5d4c7f6cfb-xj7lg dispatcher
AI 代码解读
5) 查看 Subscription
# kubectl get subscription default-testevents-trigger-thdv4 -o yaml
AI 代码解读
6) 查看 Filter
# kubectl logs --tail=500 default-broker-filter-65656d665f-zflfz filter
AI 代码解读
此处我们可以发现有异常错误信息
经排查是由于CoreDNS不兼容导致的, 社区已经提出issue, 当前部署环境使用的是1.1.3， 升级到1.2.6即可解决这个问题。
通过上面这个例子我们可以大致了解event中处理事件的流程。当然如何没有发现问题，我们可以继续向下游继续排查。我们可以查看部署的服务是否Ok
7) 最后测试服务是否正常
// 获取istio外部访问地址
# kubectl -n istio-system get svc istio-ingressgateway
// 执行curl 访问进行测试服务是否正常
# curl -H "Host: event-display.default.example.com" http://172.19.xx.xx
AI 代码解读
其它
针对 Eventing 中事件处理过程是否能提供事件追踪机制，以方便问题排查， 社区计划在 v0.6.0 版本中添加 Tracing support， 有兴趣的可以关注一下
参考
https://github.com/knative/docs/tree/master/docs/eventing/debugging
