参与现场问题解决总结（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、网络等负载高或异常情况
原因及方案： 提供精确的监控和告警

三. 思路

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

#mermaid-svg-ZGa1b1aePsb78us6 {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-ZGa1b1aePsb78us6 .error-icon{fill:#552222;}#mermaid-svg-ZGa1b1aePsb78us6 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-ZGa1b1aePsb78us6 .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-ZGa1b1aePsb78us6 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-ZGa1b1aePsb78us6 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-ZGa1b1aePsb78us6 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-ZGa1b1aePsb78us6 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-ZGa1b1aePsb78us6 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-ZGa1b1aePsb78us6 .marker.cross{stroke:#333333;}#mermaid-svg-ZGa1b1aePsb78us6 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-ZGa1b1aePsb78us6 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-ZGa1b1aePsb78us6 .cluster-label text{fill:#333;}#mermaid-svg-ZGa1b1aePsb78us6 .cluster-label span{color:#333;}#mermaid-svg-ZGa1b1aePsb78us6 .label text,#mermaid-svg-ZGa1b1aePsb78us6 span{fill:#333;color:#333;}#mermaid-svg-ZGa1b1aePsb78us6 .node rect,#mermaid-svg-ZGa1b1aePsb78us6 .node circle,#mermaid-svg-ZGa1b1aePsb78us6 .node ellipse,#mermaid-svg-ZGa1b1aePsb78us6 .node polygon,#mermaid-svg-ZGa1b1aePsb78us6 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-ZGa1b1aePsb78us6 .node .label{text-align:center;}#mermaid-svg-ZGa1b1aePsb78us6 .node.clickable{cursor:pointer;}#mermaid-svg-ZGa1b1aePsb78us6 .arrowheadPath{fill:#333333;}#mermaid-svg-ZGa1b1aePsb78us6 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-ZGa1b1aePsb78us6 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-ZGa1b1aePsb78us6 .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-ZGa1b1aePsb78us6 .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-ZGa1b1aePsb78us6 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-ZGa1b1aePsb78us6 .cluster text{fill:#333;}#mermaid-svg-ZGa1b1aePsb78us6 .cluster span{color:#333;}#mermaid-svg-ZGa1b1aePsb78us6 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-ZGa1b1aePsb78us6 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;}
文档

文档

文档

文档

组件

组件

系统

系统

       思路 
     

       已知问题方法论 
     

       问题分类和归档 
     

       共享知识库 
     

       结合问题深入源码 
     

       组件运维优化思路 
     

       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功能可能是更好的选择。

六. 总结