问题定位排查方式
Posted 魏小言
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了问题定位排查方式相关的知识，希望对你有一定的参考价值。
问题定位排查方式
这个问题很突然，也很粗糙，可能是呆过一线/二线公司后，不经意间对比的一些思考。
问题发现
今天搭建系统监控的时候，发现Collect模块用了Redis分布式锁解决Collect的单点问题。没什么问题，挺好，实现逻辑、重试设计性能都不错，唯一的问题是，无法快速定位当前Collect任务节点。
问题分析
为什么要定位Collect节点/？
因为若日志收集出现问题，需要到节点机器上快速翻日志定位分析问题………
乍一看，没问题，确实需要有种机制快速定位到当前的任务执行节点，不过你细品，这样合理吗/？
这样的机制合理吗？
沉默一下，思考下。
设计快速定位节点的方案——合理——用来解问题；
但这种直接到机器上翻看日志，定位问题的机制有点过时、拘谨了，不太严谨。来，细聊下：
这种机制的前提是：rd了解任务在哪台机器执行，机器的IP，机器日志目录，机器日志格式等信息。
目前基于云原生的微服务、容器技术兴起，在大型架构搭建中，服务都将以分布式部署集群方式提供。
也就是说：
rd面向都不是一台一台的机器，而会是容器，集群，BNS，HTTP API等形式，等弄明白提供服务的机器IP，都过年了……
不同服务可能是不同的团队维护开发，日志格式、日志目录认知成本会很大……
而且线上生产机器要和线下、测试机器权限隔离，确保服务器的隔离性……
一个团队整体那么多同学，如何保证操作的安全性……
…
机制适用的群体/范围/？
可能这种机制在中小系统架构是普遍的，但针对目前的技术发展，除非衔接的业务目前体量有限，这种机制很不严谨。
纯评级的话，很差、差、良好、优秀四个等级，可以评为差级别。
问题解答
良好的解决方式是什么呢/？
这样的问题应该从项目基础设置解决更好，搭建中控机，隔离线上机器，日志增加节点信息数据供中控机查询定位；
甚至可以在中控机做各种模块的拆分；
在服务器线上/下权限隔离上，更安全可靠；
在微服务化、容器化的浪潮中，中控+隔离才是最佳！
附录
总的思索下来，存在即合理；机制的合理性与使用的环境相关联，什么时候用什么样的机制；
或许，这也是大公司与小公司差别的体现之一……
以上是关于问题定位排查方式的主要内容，如果未能解决你的问题，请参考以下文章