之前使用nginx-ingress-controller来记录后端真实ip，但是有位老哥说了，我没有用nginx-ingress-controller，而是用的原生nginx，这时候又当如何记录后端真实ip的问题呢。

本文展示如何使用nginx-ingress-controller来记录后端pod真实ip

上一小节描述了metrics、traces，本小节来把log也加进去，并且做一个traces与log的联动当查看日志的时候，可以同时跳转到对应的jaeger，查看分段trace情况。

jaeger的架构演变在之前的描述中，一直使用jaeger:all-in-one来做数据存储与展示，jaeger:all-in-one就是将collector、query、ui、storage等等功能的大杂烩，在调试与测试环境中，非常方便，但是在生产环境肯定是不能这样用，本节就来 将其拆分成对应的子模块。

经过上一节，opentelemetry的基本操作都已经融会贯通，但是有位老哥提出疑问？我的代码都已经写完了，为了添加全链路，还需要重构之前的代码吗？那这个代价太大了。那本章就来讨论一下opentelemetry的注入的问题本小节主要关注python注入。

某天一位业务研发老哥跑来咨询研发老哥：我的服务出现了504，但是不太清楚是哪个环节报错，每次请求需要访问4个微服务、2个数据库、1个redis、1个消息队列。。。苦逼运维：停停停，不要再说了，目前不支持链路追踪，只能手动帮你一个服务一个服务的排查了先请老哥大概描述了一下业务逻辑以及访问方式，10分钟过去了。再逐级排查每个服务以及对应访问的资源层，终于在半小时之后完成了故障定位。。。这效率也太低了，于是，关于链路建设项目提上了议程，目标只有一个，快速定位问题，提高稳定性。