参与现场问题解决总结(Kafka、Hbase)

一. 背景

Kafka和Hbase在现场应用广泛,现场问题也较多,本季度通过对现场问题就行跟踪和总结,同时结合一些调研,尝试提高难点问题的解决效率,从而提高客户和现场满意度。非难点问题(历史遇到过问题):这类问题一般容易解决,区域技术支持、总部技术支持已经过滤了一版(会到组内和组件责任人,目前虽然积累了一些现场问题解决经验和文档(这些大部分是基于已知问题点))难点问题(未知问题):但是对于未知类型(或者是能定位到,但是不容易解决的,大约总问题的10%-20%),除了基于日志、现在、linux传统命令行排查外,我们缺少一些高效率的工具箱形成解决未知问题方法论,目前组内解决未知问题的压力偏大, 面对现场难点问题时承压明显。

二. 现场问题归纳

1. Kafka

以下为重庆璧山现场Kakfa问题解决总结:
问题:leader下线问题
排查:经排查,主要是配置的线程数和内存不足导致
解决:通过使用基线已知优化参数解决

问题:cqbs009节点未上线副本较多
排查:因磁盘故障
解决:替换磁盘后解决

问题:egrep慢kafka broker无法启动
排查:发现卡在kafka启动脚本中
解决:修复了Kafka启动脚本

2. Hbase

以下为南昌市局Hbase问题解决总结:

问题:Hbase入库积压
排查:经过现场出差排查,是单个节点WAL写入慢,拖慢整体入库性能
解决:停止慢节点RS,迁移为其他节点

以下为重庆市局Hbase问题解决总结:
问题:感知抓拍数据入库断流     
分析:初步排查是因为有两个实例wal异常导致 wal异常影响写入的情况,通常是磁盘问题网络异常
解决:hbp3.1分支已经代码对这种情况进行了规避,hbp3.0还没有测试发布补丁,发布补丁解决

以下为重庆项目Hbase问题解决总结:
问题:8.28 gc导致的RS挂掉
原因及方案:能否确定是业务压力还是环境导致的,能否通过资源或配置调整规避,或其它规避OR解决方案,顺便整体看下集群负载情况

问题:8.29 CPU卡死导致的kubelet not ready,进一步导致所在节点HBase实例(有HMaster角色)
原因及方案:一方面联系硬件排查cpu方面原因,一方面调研下将服务pod改为类k8s自身服务的Static方式可行性

问题:8.30 18:04 出现HBase全部重启情况
原因及方案:需要确定是否跟k8s有关,重要服务使用daemonSet控制器可以避免kubelet not ready后发生重启问题

问题:Meta表损坏未能自动修复
原因及方案:修复指导文档不适用,提供优化后的自动化修复脚本和文档

问题:对于如HBase负载高(HBase写数据慢情况如何告警),节点cpu、网络等负载高或异常情况
原因及方案: 提供精确的监控和告警

三. 思路

总结上一章节各现场问题解决情况,总结思路为

文档
文档
文档
文档
组件
组件
系统
系统
思路
已知问题方法论
问题分类和归档
共享知识库
结合问题深入源码
组件运维优化思路
Kafka运维优化思路
Hbase运维优化思路
系统
硬件和基础设施优化
Kubernetes 使用优化
1.建立高效排查和解决已知问题方法论

问题分类和归档:建立问题分类体系,包括已知问题和未知问题,以及它们的历史解决方案和经验。
共享知识库:建立一个内部知识库,收集并整理已知问题、解决方案、优化经验等,方便团队成员快速查询和共享经验。
深入原理:了解代码结构和原理,方便排查有一定难度的问题

2. Kafka 运维优化思路

配置调优: 确保Kafka集群的配置参数(例如线程数、内存分配)与实际负载相匹配。定期审查配置以确保它们满足当前的需求,特别是在扩展或升级时。
磁盘监控和维护: 设置磁盘监控和预警,及时检测到磁盘故障并采取预防措施,如替换磁盘。此外,考虑使用RAID或分布式存储以提高可靠性。
启动脚本维护: 保持Kafka启动脚本的完整性和可靠性,确保能够正确启动Kafka Broker。还要确保及时更新脚本以反映最新的最佳实践和安全修复。

3.Hbase 运维优化思路

WAL写入性能优化: 对于WAL写入慢的问题,可以进一步调整Hbase的WAL相关配置,如WAL刷写频率,以提高写入性能。还可以监控磁盘和网络问题,确保它们没有导致性能瓶颈。
版本升级和补丁管理: 考虑将Hbase升级到支持自动规避某些问题的版本(2.4.17),或者及时应用已知的修复补丁。有助于减少因为已知问题而导致的性能问题。
资源调优: 分析资源使用情况,包括CPU、内存和网络,并根据需要进行调整。此外,确保Hbase集群的硬件配置满足负载需求。
监控和告警: 设置监控和告警系统以及日志收集,以便及时感知集群中的性能问题和异常。建议使用专业监控工具来监测Hbase的负载、性能和健康状态。
自动化修复脚本: 提供自动化修复脚本,以帮助解决常见问题,如Meta表损坏。这可以减少手动干预的需求。
静态Pod配置: 对于HBase运行在Kubernetes集群上的情况,考虑将关键服务的Pod配置为Static方式,以避免kubelet not ready问题。
负载均衡和故障转移: 确保Hbase集群中的负载均衡和故障转移机制正常工作,以提高系统的可用性和性能。以上提到的优化思路可以帮助您改进Kafka和Hbase的运维效率,减少未知问题的发生,并提高现场问题的解决速度,从而提高客户和现场的满意度。根据具体情况,您可能需要进一步详细规划和实施这些优化策略。

4. 硬件和基础设施优化

硬件健康监测:建立硬件健康检查机制,及时监测磁盘、内存、CPU等硬件健康状态,预防硬件故障。
基础设施优化:考虑对硬件进行升级或替换,以满足业务的性能需求,例如更换磁盘,升级内存或CPU等。

5. Kubernetes 使用优化

资源调整:针对Kubernetes环境中的Kafka和HBase,调整容器资源分配,确保资源合理利用和避免资源不足导致的问题。
Pod配置调整:优化Pod配置,例如静态Pod、Pod的调度策略,以避免Kubelet not ready等问题。

通过这些优化思路,您可以提高团队解决已知/未知问题的能力,降低现场难点问题带来的压力,增强现场问题的解决效率,提高客户和现场的满意度。

四. 自动化运维

Kafka和Hbase目前运维,主要基于Metric(查看和告警)、Log(错误日志)

历史经验:

上述方式,能够解决70%-80%左右的现场问题,这些问题点偏向于历史已经发生过的、有经验总结的问题(例如错误日志就是典型的依赖人工历史经验)

新型问题:

然而,对于以前未遇到过的疑难问题(约20%左右,这里面包括组件自身可能的问题点,以及非组件问题,例如网络波动),这20%基本上属于疑难问题了,通过Metric、Log并不能快速排查解决,疑难问题/未知问题-排查解决周期一般比较长,容易导致问题升级,带来体验上的负面影响,且解决未知疑难问题过程中,传统的Metric和Log方式基本上用处比较小,可以考虑借助一些新的轻量级工具。

解决思路:

此时,考虑从三个方面进行优化疑难问题解决(都有相应的工具),缩短任务排查解决周期,提高用户满意度:

补全trace:
补全链路信息,方便出问题的时候,快速定位到是那台机器的哪个实例,同时对网络波动等问题,主流的trace工具有较好的指标分析
补全profile:
通过metric或者trace定位到实例后
    非性能问题:历史遇到过的且有日志报错的问题,通过历史经验和最近实践文档解决
    性能问题:CPU、内存、锁等性能问题,可通过arthas profile等火焰图工具解决
自动修复:
60% case:目前基于Hbase的Metric,能够非常方便的做成自动修复工具,覆盖60%左右现场问题,做到自动化巡检和解决
80% case:以Hbase为例,预计接入Hbase的Error和Warming日志,通过类似正则表达式方式匹配,可覆盖到80%问题,做到自动化巡检和解决
剩余20%未知case:通过profile或者其他工具定位解决后,加入到Habse自动化运维工具

五. Profile工具-简要调研

上一章节,我们提到了补全profile火焰图数据,方便排查性能问题,以下是几个市面上的profile工具调研,以供参考

arthas profile功能

Arthas是阿里云提供的Java诊断工具,用于帮助开发者分析Java应用程序的性能和问题。Arthas具有丰富的功能,其中之一就是profile命令,用于分析应用程序的性能热点。以下是profile命令的一些主要特点和功能:火焰图支持: profile命令能生成火焰图,这是一种可视化的性能分析工具,可以直观地显示函数调用关系,帮助开发者快速定位性能瓶颈。CPU性能分析: profile命令主要用于分析应用程序的CPU性能热点,可以帮助开发者找出消耗最多CPU时间的方法。指定时间和采样间隔: 开发者可以指定profile命令运行的时间和采样间隔。这可以帮助开发者控制性能分析的粒度和持续时间。支持多线程: profile命令能够分析多线程环境中的性能热点,这对于并发编程的性能分析尤为重要。简单易用: Arthas的profile命令使用简单,只需要指定要分析的类或方法,即可开始性能分析

使用示例:

profile --event cpu --duration 30s --thread 2 com.example.demo.service.MyService myMethod

上述命令将对com.example.demo.service.MyService类中的myMethod方法进行30秒的CPU性能分析,采样间隔为2毫秒。总的来说,Arthas的profile命令是一个非常有用的性能分析工具,能帮助Java开发者快速定位和解决应用程序中的性能问题。

pyroscope

Pyroscope是一个开源性能分析工具,用于帮助开发者监测、分析和优化应用程序的性能。它可以用于不同编程语言的应用程序,包括Python、Go、Node.js等。以下是Pyroscope的一些主要特点和功能:实时性能分析: Pyroscope可以实时捕获应用程序的性能数据,包括CPU使用率、内存占用、函数调用等信息。这使开发者能够快速识别性能瓶颈和问题。火焰图支持: Pyroscope生成火焰图,这是一种可视化工具,用于直观地展示应用程序的性能剖析信息。通过火焰图,开发者可以清晰地看到函数调用关系,从而更容易地进行性能优化。低侵入性: Pyroscope的集成相对简单,并且对应用程序的性能影响较小。开发者可以将其嵌入到应用程序中,以收集性能数据。支持多种编程语言: Pyroscope支持多种编程语言,包括Python、Go、Node.js、Ruby等。这使得开发者可以在不同的应用程序中使用Pyroscope进行性能分析。可扩展性: Pyroscope提供了API和插件系统,允许开发者根据需要扩展其功能,以满足特定的性能分析需求。开源和免费: Pyroscope是开源项目,可以免费使用和定制。它的源代码可以在GitHub上找到。总之,Pyroscope是一个有助于开发者识别和解决应用程序性能问题的强大工具,特别适用于需要实时性能分析和可视化的场景。它提供了直观的性能数据展示,帮助开发团队更快速地优化其应用程序。

阿里云应用实时监控服务ARMS
接入CPU&内存诊断功能

CPU&内存诊断可以有效发现Java程序中因为CPU、内存和IO导致的瓶颈问题,并且按照方法名称、类名称和行号进行细分统计,最终协助开发者优化程序、降低延迟、增加吞吐、节约成本。本文介绍如何开通ARMS CPU&内存诊断功能以及如何查看CPU&内存诊断数据。

使用代码热点诊断慢调用链的问题

ARMS代码热点作为一种监控诊断工具,通过持续剖析技术定时采集请求线程堆栈快照,真实还原代码执行的第一现场

使用场景
当促销活动出现慢调用时,ARMS代码热点可为您快速定位问题代码。
当系统出现大量慢调用时,ARMS代码热点可为您自动保存第一现场。
当业务太复杂,偶发性慢调用无法复现时,ARMS代码热点可为您还原代码真实方法层面的执行轨迹。
当调用链中因为缺失对应用代码非框架层面的方法埋点时,代码热点帮您还原对应缺失埋点的实际方法调用耗时。

排查JVM进程CPU使用率过高的问题

问题现象:Java程序CPU使用率为200%。
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

解决方案:
登录ARMS控制台,选择应用监控 > 应用列表。
然后单击目标应用名称。
在左侧导航栏中单击CPU&内存诊断。
在CPU&内存诊断页面通过聚合分析定位CPU消耗较大的线程。
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

定位关键代码并完成优化
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

上图显示为2个消耗CPU的线程对应的代码
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

排查内存使用率较高的问题

问题定位:

登录ARMS控制台,在左侧导航栏选择应用监控->应用列表。
在应用列表页面顶部选择目标地域,然后单击目标应用名称。
在左侧导航栏中单击CPU&内存诊断。
在CPU&内存诊断页面选择目标快照时间后单击聚合分析。
在快照详情面板选择性能分析类型为Allocated Memory,然后定位collect-heap内存时的主要申请方法是哪些
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

解决方案
创建内存申请程序,此处模拟了一个逻辑简单的内存申请程序。
启动3个线程,每个线程间隔1秒申请1M*N的内存
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

每秒申请1M*N的内存,3个线程分别对应的N为1、2、3,因此3个线程每分钟分别申请的内存为60M、120M、180M,共计360M。
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

备注:由于arthas profile与阿里云ARMS,底层都是基于一个开源的工具
async-profiler实现,可以理解为arthas profile为命令行工具没有交互界面,阿里云ARMS为一个产品,为了精简使用,后续以arthas为基准

arthas profile与pyroscope对比

Arthas的profile命令和Pyroscope都是用于性能分析的工具,但它们有一些不同之处,以下是它们之间的比

1.类型和用途

Arthas profile: Arthas是一个Java诊断工具,其中的profile命令主要用于分析Java应用程序的CPU性能热点。它是一种命令行工具,旨在帮助开发者快速识别并解决Java应用程序中的性能问题。
Pyroscope: Pyroscope是一个开源的实时性能分析平台,支持多种编程语言,包括Go、Java、Python、Ruby等。它提供了更广泛的性能分析功能,包括CPU、内存、函数调用等多方面的分析,并提供直观的可视化工具。

  1. 支持的编程语言:
    Arthas profile: Arthas主要面向Java应用程序。
    Pyroscope: Pyroscope支持多种编程语言,这使得它更适用于多语言的应用程序堆栈。

  2. 可视化工具:
    Arthas profile: Arthas的profile命令可以生成火焰图,但其可视化能力相对有限,主要用于展示Java方法的性能热点。
    Pyroscope: Pyroscope提供了丰富的可视化工具,包括火焰图、堆栈图等,可以更全面地展示性能数据,使开发者能够更容易地理解和分析性能问题。

  3. 集成难度和侵入性:
    Arthas profile: Arthas的使用相对简单,但需要将其嵌入到Java应用程序中,因此可能对应用程序的性能有一定影响
    Pyroscope: Pyroscope的集成较为灵活,可以在应用程序中低侵入性地收集性能数据,对应用程序的性能影响较小。

  4. 扩展性:
    Arthas profile: Arthas是一个命令行工具,扩展性相对较低。Pyroscope: Pyroscope提供了API和插件系统,允许开发者根据需要扩展其功能,以满足特定的性能分析需求。

综上所述:
Arthas的profile命令主要适用于Java应用程序的CPU性能分析,而Pyroscope是一个更全面的性能分析平台,支持多种编程语言,提供更多的可视化工具和灵活的集成选项。选择哪个工具取决于您的具体需求和应用程序的特点。如果需要跨语言性能分析或更广泛的性能分析功能,Pyroscope可能是更好的选择,当前大数据系统以Java主,arthas profile功能可能是更好的选择。

六. 总结

能分析需求。

综上所述:
Arthas的profile命令主要适用于Java应用程序的CPU性能分析,而Pyroscope是一个更全面的性能分析平台,支持多种编程语言,提供更多的可视化工具和灵活的集成选项。选择哪个工具取决于您的具体需求和应用程序的特点。如果需要跨语言性能分析或更广泛的性能分析功能,Pyroscope可能是更好的选择,当前大数据系统以Java主,arthas profile功能可能是更好的选择。

六. 总结

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值