文章采集调用(是因为使用分布式追踪系统监控服务(1)_社会万象_光明网(组图))

　　文章采集调用(是因为使用分布式追踪系统监控服务(1)_社会万象_光明网(组图))

　　上周的工作是开发一个运维需求——一个连接到公有云的分布式跟踪系统。在服务上线商业化之前，运维能力需要满足商业化需求，而在商业化运维需求中，使用分布式跟踪系统来监控服务是必须的，所以就有了这个需求。一个星期后，代码已经开发的差不多了，还缺少验证和上线工作。在此之前，我会先回顾一下。

　　之所以连接分布式跟踪系统如此重要，是因为使用分布式跟踪系统监控服务有以下好处

　　我们的服务主要使用Python和Go语言开发，您可以分别获取相应的SDK进行开发。整个开发对接流程大致如下：

　　联系接口人沟通嵌入解决方案，使用统一的SDK进行嵌入代码开发测试，整理服务——微服务——节点——日志路径信息，服务——微服务——业务——URL信息。公司分布式跟踪系统的日志采集借用了现有日志服务的能力。日志服务收到调用链日志后，会直接转发到分布式跟踪系统，因此需要将信息分别反馈给日志采集系统和分布式跟踪系统在服务节点上安装日志采集代理升级微服务，打开开关打印调用链日志（开始打印调用链日志，同时，节点上的日志采集代理将采集到的调用链日志信息上报给日志系统）生产环境验证连接效果：本地打印调用链日志正常，日志采集代理正常上报调用链日志；分布式跟踪系统可以检索到服务的跟踪信息，可以正常显示微服务依赖拓扑图。线上生产环境埋在各个站点，哪里需要打印点开发的调用链日志？并且可以正常显示微服务依赖拓扑图。线上生产环境埋在各个站点，哪里需要打印点开发的调用链日志？并且可以正常显示微服务依赖拓扑图。线上生产环境埋在各个站点，哪里需要打印点开发的调用链日志？

　　与性能调优类似，管理可以包括：HTTP请求服务/客户端、RPC请求服务/客户端、数据库访问、中间件调用和本地方法调用。

　　默认情况下应该跟踪哪些点？

　　我认为对于所有项目，我们应该默认收录

5 种点：

　　埋点法

　　听说Go还有办法直接替换Go-SDK来完成嵌入式函数注入...

　　两个重要的纸张标准

　　由 Uber 发起的 OpenTracing *敏*感*词*会的成员项目。OpenTracing 语义规范定义了数据模型和一些用于数据采集

的接口。它应该被视为分布式跟踪系统的接口标准。著名的 Jaeger 和 Zipkin 都实现了 OpenTracing API。

　　行业实践参考链接