案例分享_如何定位容器云平台重大问题.docx

《案例分享_如何定位容器云平台重大问题.docx》由会员分享，可在线阅读，更多相关《案例分享_如何定位容器云平台重大问题.docx（14页珍藏版）》请在第一文库网上搜索。

1、案例分享如何定位容器云平台重大问题摘要在容器平台中，我们除了会涉及操作系统层面的知识，还会涉及容器存储、容器网络、容器日志管理及监控告警、C1/CD （持续集成/持续交付）等相关领域的技术。每个领域都有可能是问题的产生点，只有在分析定位出具体点时，我们才好依据该技术相关工具或者阅读源码来解决它。定位问题，是在分析问题后，我们可以结合各种日志、监控告警等平台提供的功能来排除干扰项，找到问题的诱发根因。问题背景：容器平台上线一年多后，总有很少部分租户称他们的某个业务部署在Kubernetes容器平台后经常会重启，也很少部分租户称某个业务在运行一段时间时会产生大量的CLOSETAI/ ,还有租户反馈

2、说某个业务跑着就会hang住。刚开始我们都会让业务开发者先自己找问题，因为这些租户反映的只是偶偶发生，大多数租户没有反映类似问题，我们会理所当然的认为是租户业务自身问题，而非平台问题。当然大多数情况下，还是租户业务本身程序没有写好，或者健康检查配置不当等引起。1 .排除干扰项分析完了问题，一般会根据经验先从比较简单的可能产生的影响因素开始排除干扰选项，这样我们大概就会有一个比较接近问题根因的方向。比如上面三个问题中的其中一个容器内出现大量处于CLOSE_WAIT状态的TCP链接：J J产tcpCLOSE-WAIT 320172.16.84.72:3560010.129.49.16:443tcp

3、CLOSE-WAIT10172.16.84.72:870010.129.22.27:40738tcpESTAB00172.16.84.72:5428410.129.40.32:61616tcpCLOSE-WAIT10172.16.84.72:870010.129.22.27:38480tcpCLOSE-WAIT10172.16.84.72:870010.129.22.27:47020tcpESTAB00172.16.84.72:5479810.129.40.32:61616tcpESTAB00172.16.84.72:5458010.129.40.32:61616tcpESTAB00172.1

4、6.84.72:4822010.129.40.32:61616tcpESTAB00172.16.84.72:4854010.129.40.32:61616tcpCLOSE-WAIT10172.16.84.72:870010.129.22.27:56852tcpCLOSE-WAIT10172.16.84.72:870010.129.22.27:44490tcpCLOSE-WAIT10172.16.84.72:870010.129.22.27:55586tcpCLOSE-WAIT10172.16.84.72:870010.129.22.27:54204tcpCLOSE-WAIT10172.16.8

5、4.72:870010.129.22.27:46570tcpESTAB00172.16.84.72:5338810.129.40.32:61616tcpESTAB00172.16.84.72:5145610.129.40.32:61616tcpESTAB00172.16.84.72:5271610.129.40.32:61616tcpCLOSE-WAIT10172.16.84.72:870010.129.22.27:55400tcpCLOSE-WAIT10172.16.84.72:870010.129.22.27:38952rootxyx-message-center-5b869d674f-s

6、lt9t:/# ss -an I grep CLOSE-WAIT I wc -I166rootxyx-message-center-5b869d674f-slt9t:/#“CLOSE-WAIT”有很多原因引起,有可能是服务端代码处理TCP挥手不合理引起，比如忘记了 close相应的socket连接，那么自然不会发出FIN包；还比如出现死循环之类的问题，导致close最后没有被调用执行；还有可能是服务端程序响应过慢，或者存在耗时逻辑，导致close延后；也可能是accept的backlog设置的太大，导致服务端来不及消费的情况，引起多余的请求还在队列里就被对方关闭了。还有可能是内核参数配置没有做

7、优化处理,比如调整 u tcp keepalive time v u tcp keepal ive intvl v /“tcp keepalive probes”等。林林总总，但经过我们排查后，以上的可能影响点都不是，所以排除上述这些干扰选项。在排查业务问题的时候，我们还要结合“业务方”与“平台方”的各自对自身代码熟悉的优势，发挥出凝聚力，一起来排查。“业务方”一一从如下几个方向进行了代码方面的排查：1、多次检查TCP四次挥手代码逻辑；2、检查springboot的相关配置是否恰当;3、由于连接数过多，也排查了 tomcat线程池相关代码；4、修改ActiveMQ连接池的配置；5、采用jsta

8、ck、jmap查看应用的线程堆栈，确定程序没有死锁，只看到少量线程在block和wait状态;6、采用jstack-gcutil查看java垃圾回收时间，因为其可能会引起垃圾回收异常等；以上发现都是正常的，无果。“平台方”一一尝试过以下排查：1、修改Kubernetes node主机的内核相关配置（比如：tcp keepalived相关参数,ulimit限制数等）；2 检查 Kubernetes Ingress 入口 Nginx 的配置（比如：Kubernetes Nginx的超时配置与业务自身Nginx的超时时间减少些，比如900秒；改用NodePort模式不经过Nginx代理等），发现同样

9、有问题，这个就排除采用Nginx代理引起，也就排除了 Nginx参数配置问题；3、排查docker分区的文件系统，排除容器底层导致；4查看dockerd日志和系统日志；5、还有各种其他可能的方面都尝试过等等；以上的可能影响点都不是，所以排除上述这些干扰选项。到此为止，虽然都没有找到一点头绪，但我们至少排除了很多干扰项，这个也是接近根因的必经之路。当时在分析问题的过程中，实然闪现在我脑海中，会不会是程序本身hang住了，才引起了 CLOSE-WAIT出现？这个问题其实是需要界定的，后面会讲到。2 .日志分析日志平台是日志分析的主要工具，它也是收集业务容器日志及系统日志的输入口，业务日志的展示与统

10、计、分析的窗口。容器的日志都需要统一输出到日志平台，有以下几点考虑：因为容器的临时性，容器重启或销毁后就会丢失日志，所以需要日志平台的持久存储。需要按日志存储时间、日志量大小、日志错误类型、业务访问率、客户端访问方式等等来搜索、分析。需要以图形化展示各种统计效果，方便观察整体表现形为，抓住容易被忽视的抽像部分，也就是有大局观。2.1 日志平台架构下面我稍微简要介绍一些日志平台使用到的相关组件的概念，详情请参考相关文献。早期一般使用ELK架构模式，即由ElasticSearchLogstash和Kiabana三个开源工具组成： ElasticSearch是一个基于Lucene的开源分布式搜索引擎

11、。它的特点有很多，比如分布式，零配置，自动发现，索引自动分片，索引副本机制，RESTful风格接口，多数据源，自动搜索负载等等。它提供了一个分布式、多用户能力的全文搜索引擎，基于RESTful web接 o ElasticSearch是用Java开发的，并作为Apache许可条款下的开放源码发布。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。在ElasticSearch中，所有节点的数据是均等的。 Logstash是一个完全开源的工具，它可以对你的日志进行收集、过滤、分析，支持大量的数据获取方法，并将其存储以实现搜索、统计等功能。它带有一个web界面，可以搜索和展示所有日

12、志。一般工作方式为C/S架构，Client端安装在需要收集日志的主机上，Server端负责将收到的各节点日志进行过滤、修改等。 Kibana是一个基于浏览器页面的ElasticSearch前端展示工具，也是一个开源和免费的工具，Kibana可以为Logstash和ElasticSearch提供的日志分析友好的Web界面，可以帮助您汇总、分析和搜索重要数据日志。最近一般我们采用EFK架构模式，即采用fluentd或者fluent bit来采集容器日志（包括标准控制台日志及用户自定义业务日志）代替Logstash,其他工具保持不变。Fluentd是一个开源的通用日志采集和分发系统，可以从多个数据源

13、采集日志，并将日志过滤和加工后分发到多种存储和处理系统。Fluentd处于日志采集流程的中间层。它可以从Apache/Nginx等广泛应用的系统、数据库、自定义系统中采集日志，数据进入Fluentd后可根据配置进行过滤、缓存，最终分发到各种后端系统中。这些后端系统包括告警系统（Nagios）、分析系统（MongoDB、MySQL、分析op、Elas系统earch）、存储系统（AmazonS3）等。也就是说，Fluentd就是把通常的日志采集-分发-存储流程提炼出来，用户只需要考虑业务数据，至于数据的传输、容错等过程细节都交给Fluentd 来做。fluent bit是一个C实现的轻量级多平台开

14、源日志收集工具，相比fluentd资源占用要小，相对的插件数量上要比fluentd要少的多，功能上也少一些。它允许从不同的源收集数据并发送到多个目的地。完全兼容Docker 和 Kubernetes 生态环境。在查询搜索方面，主流的有ElasticSearch,目前也有很多公司开始使用 ClickHouseoClickHouse是近年来备受关注的开源列式数据库（columnar DBMS）,主要用于数据分析（OLAP）领域。目前国内社区火热，各个大厂纷纷跟进大规模使用。传统数据库在数据大小比较小，索引大小适合内存，数据缓存命中率足够高的情形下能正常提供服务。但这种理想情况最终会随着业务的增长而

15、走到尽头，使得查询会变得越来越慢。我们可能会通过增加更多的内存，订购更快的磁盘等纵向扩展的方式来解决问题。如果我们的需求是解决怎样快速查询出结果，那么这就是ClickHouse的主场了。它适用于读多于写；大宽表，读大量行但是少量列，结果集较小；数据批量写入，且数据不更新或少更新；无需事务，数据一致性要求低；灵活多变，不适合预先建模等场景。在我们的生产环境中，一般7天内的热日志从ElasticSearch中查询，7天外的冷日志从ClickHouse中查询，因为随着天数的增加，数据量越来越多，ClickHouse作用越来越明显。携程团队曾对ClickHouse与ElasticSearch做过一次比较，他们得出