在Kubernetes里一步步摸索着搞清楚怎么弄出靠谱的可观测性来

（来源：根据个人在Kubernetes项目中的实践经验总结）

一开始在Kubernetes里搞可观测性,真的是一头雾水，什么日志、指标、链路追踪，听起来都懂，但放到Kubernetes这个动态变化的环境里，感觉完全不是那么回事，容器今天在这台机器上，明天可能就没了，服务名字变来变去，IP地址更是捉摸不定，我当时就想，第一步总得先能看到点什么吧，不能两眼一抹黑。

我最先动手的是日志,在传统服务器上，登录上去用tail -f命令看日志是天经地义的事，但在Kubernetes里，你用kubectl logs命令看一个Pod的日志，如果这个Pod因为某种原因重启了，你之前看的日志就断了，新的日志又在新启动的Pod里，这太被动了，根本没法排查历史问题，第一步就是把所有Pod的日志集中到一个地方去，我试了EFK栈，就是Elasticsearch、Fluentd和Kibana，Fluentd像个勤劳的小蜜蜂，它在每个节点上以DaemonSet的方式运行，自动收集这个节点上所有容器的日志，然后打包发送给Elasticsearch存起来，最后用Kibana这个界面去搜索、查看，这一步做完，感觉世界清晰了一大半，至少不管Pod怎么蹦跶，它的日志我都能在一个地方查到了，这算是可观测性的第一个基础。

光有日志还不够,日志是事后的，你得等出了问题再去查，我们更需要一种能提前发现问题、实时看到系统健康状况的手段，这就是指标的意义，我开始研究监控指标，Kubernetes本身提供了很多基础指标，比如Pod的CPU用了多少、内存用了多少，这些通过Metrics API就能拿到，但光有这个不够，我的应用程序跑得怎么样呢？比如我这个API服务的响应时间是多少？每秒处理多少个请求？出错了多少？这时候就需要应用自己暴露指标，我选择了Prometheus，因为它和Kubernetes是“黄金搭档”，我在应用代码里用Prometheus的客户端库，埋点一些关键的指标，比如请求次数、耗时、错误码这些，配置Prometheus让它自动去发现Kubernetes里所有这些暴露了指标的服务，定期去抓取，接着用Grafana画成dashboard，CPU使用率、内存压力、QPS、延迟曲线全都一目了然地展示出来，设置好告警规则后，一旦某个指标不正常，比如错误率突然飙升，就能立刻收到报警，这一步做完，感觉从“被动救火”变成了“主动巡逻”，心里踏实多了。

后来遇到了更复杂的问题,一个用户请求从前端到后端，可能经过了网关、认证服务、业务服务A、业务服务B好几个环节，如果这个请求变慢了或者出错了，到底是哪个环节的锅？靠查日志就像大海捞针，一个个服务去翻时间戳，效率极低，这时候就需要链路追踪了，我引入了Jaeger，这需要在每个服务的代码里做一些改动，确保每个请求进来都生成一个唯一的追踪ID，并且这个ID能在服务之间的调用中像接力棒一样传递下去，这样，在Jaeger的界面里，我就能看到一个请求完整的生命周期，它在每个服务里呆了多久，调用了哪些数据库，耗时多少，一清二楚，有一次线上一个接口特别慢，用链路追踪一查，发现是卡在了一个不起眼的第三方API调用上，问题很快就定位了，这步就像是给系统装上了X光机，能看到内部的结构和流转。

一步步摸索下来,我的体会是，Kubernetes的可观测性不是装一个神器就能解决的，它是一个组合拳，日志让你知道“发生了什么”，是排查问题的最终依据；指标让你知道“现在状态怎么样”，是监控和告警的基础；链路追踪让你知道“问题出在哪个环节”，是分析复杂依赖关系的利器，这三者缺一不可，而且需要根据自己业务的复杂程度逐步建设和完善，一开始可以先把日志和基础监控做起来，保证基本 visibility；等业务复杂了，再上链路追踪，整个过程就是不断地遇到问题、寻找工具、动手实践、解决问题的循环，没有什么捷径，但每一步都会让系统变得更透明、更可控。