问题定位排查方式

问题定位排查方式

这个问题很突然，也很粗糙，可能是呆过一线/二线公司后，不经意间对比的一些思考。

问题发现

今天搭建系统监控的时候，发现Collect模块用了Redis分布式锁解决Collect的单点问题。没什么问题，挺好，实现逻辑、重试设计性能都不错，唯一的问题是，无法快速定位当前Collect任务节点。

问题分析

为什么要定位Collect节点/？

因为若日志收集出现问题，需要到节点机器上快速翻日志定位分析问题………
乍一看，没问题，确实需要有种机制快速定位到当前的任务执行节点，不过你细品，这样合理吗/？

这样的机制合理吗？

沉默一下，思考下。
设计快速定位节点的方案——合理——用来解问题；

但这种直接到机器上翻看日志，定位问题的机制有点过时、拘谨了，不太严谨。来，细聊下：

这种机制的前提是：rd了解任务在哪台机器执行，机器的IP，机器日志目录，机器日志格式等信息。
目前基于云原生的微服务、容器技术兴起，在大型架构搭建中，服务都将以分布式部署集群方式提供。
也就是说：

rd面向都不是一台一台的机器，而会是容器，集群，BNS，HTTP API等形式，等弄明白提供服务的机器IP，都过年了……
不同服务可能是不同的团队维