跳到正文
首页
中间件与大数据
运维避坑
中间件与大数据运维避坑案例整理
中间件与大数据运维避坑案例整理
整理自用户提供的《新炬运维避坑指南合集》41
篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 38
个案例 。期数按专辑标题编号；来源链接取自离线文章元数据。
查看或下载 Markdown 原稿
案例目录
第 41 期｜BES
前台模块都提示报错问题分析
专辑文件：01.html，第 8 个案例
查看原文 现象：
某系统web应用从weblogic迁移到BES中间件，应用测试发现，前台；var
faultMessage = '<%=request.getAttribute("retInfo")%>'；;代码
在weblogic中返回的是null ,但是在bes中返回的是空
导致前台好多模块都提示报错，正常返回null 则不会报错。处置过程：
按照代码分析，判断逻辑中如果返回不是null则会进入条件分支处理逻辑执行，而bes中返回的不是’null’而是空，则会导致条件分支一定会进入到处理逻辑；；需要查看bes返回空是否可以修改为返回’null’；检查WEB-INF/weblogic.xml中不存在print-nulls属性。；系统参数中检查已添加运维建议： BES 默认不输出
null，只输出空字符串，导致依赖 null 判断的业务代码逻辑异常；配置
printNulls=true 让 BES 兼容 Weblogic 输出
null，问题解决。；国产化过程中，需要注意替换前后的软件兼容性，注意不兼容的参数
第 41 期｜BES
页面进入相关模块响应异常问题分析
专辑文件：01.html，第 9 个案例
查看原文 现象：
某资源管理系统web应用从weblogic迁移到BES中间件，页面进入相关模块响应异常(返回空白页)，原weblogic环境正常；；代码中有实现“onClick”方法，但是执行时报找不到该方法处置过程：
经过对源码进行分析，最终发现系代码实现时按钮“；onClick”与公共struts框架标签库中配置属性名称；“onclick”大小写不一致，导致在bes中间件中运行报错。运维建议：
跨中间件迁移的核心风险之一是应用代码对原中间件的隐性依赖，看似正常运行的代码，往往隐含不规范实现。；只有从开发源头严守编码标准，迁移前充分评估中间件差异，迁移中全面验证交互细节，问题处理时优先根治代码缺陷，才能最大限度降低迁移风险，保障系统平稳切换。
第 40 期｜kafka
消息延迟问题分析
专辑文件：02.html，第 7 个案例
查看原文 现象：
某日业务kafka消息延迟，经消费端重启服务也无法解决，检查kafka消息延迟情况，发现topic
2分区延迟严重，达到一万多消息堆积，其他分区正常。处置过程：
检查kafka集群和对应异常的topic所有分区状态，均正常，写入消息也正常；；通过消费组命令核查topic消费情况除了分区2，其他分区都可以正常消费；；使用kafka的消息查询命令，查询分区2卡住的offset消息，发现消息体异常，多了类似$的通配符，导致应用消费无法解析；运维建议：
应用对消息消费时，容错手段过少，未对异常消息过滤；后续如类似消息卡住情况，应用又无法短时间更新代码解决的情况时，可用kafka命令调整offset跳过异常消息临时解决
第 40
期｜elasticsearch 频繁出现red和green交替告警问题分析
专辑文件：02.html，第 8 个案例
查看原文 现象：
ES频繁出现red和green交替告警，经核查；是某个索引的分片承载了超出其合理范围的文档数量,ES单个分片只能承载约21亿文档.导致索引不可用，集群进入red状态，但ES会尝试重新分配或恢复该分片，恢复后又会出现上面的问题。处置过程：
与业务确认是否可删除索引，确认为日志索引可以删除。；明确集群 red
告警的排查、，快速定位超限索引并止损，避免影响业务消息传输。运维建议：
开展分片容量规范培训；明确业务侧责任，要求所有索引单分片文档数严格控制在
2000 万～5000
万。；单分片文档数、索引总文档数，设置预警阈值，提前预警超限风险。
第 40
期｜elasticsearch 某个盘磁盘使用率95%问题分析
专辑文件：02.html，第 9 个案例
查看原文 现象：
ES出现某个盘磁盘使用率95%，但其他盘磁盘使用率60%的情况，导致分片只读告警，原因是ES设置了磁盘95%触发只读保护。处置过程：
临时对此磁盘上的索引关闭副本，并清理部分数据，恢复集群可用。；排查原因：业务新增部分索引，未预估索引大小，导致出现大分片情况（2分片1副本1.5T数据），规范应该是1个分片50~100G，此索引的数据把此磁盘撑满触发只读保护。；合理分配分片存储，避免集中过载；完善应急流程，明确只读告警，兼顾快速恢复与根源整改。运维建议：
强化业务管控；新增索引必须提交数据量预估报告，单分片严格控制在
50~100G，违规索引禁止上线。；完善监控告警
第 40 期｜kafka
集群内部断网后异常问题分析
专辑文件：02.html，第 10 个案例
查看原文 现象： kafka集群内部断网后异常处理。处置过程：
网络割接导致kafka集群内部断网进而导致集群异常业务程序无法生产消费；检查kafka进程正常，日志有异常输出；重启异常日志节点启动失败运维建议： 网络割接前；提前通知运维侧，制定 Kafka
集群应急方案，必要时临时停止集群或调整业务流量，避免断网引发异常。；设置
Kafka
日志保留期限、文件大小阈值，定期自动清理过期日志，避免日志堆积；新增日志文件数量
/ 大小监控，触发阈值及时告警。
第 39
期｜zookeeper/hbase 集群内部断网后异常问题分析
专辑文件：03.html，第 1 个案例
查看原文 现象：
regionserver节点几乎每天都随机有节点退服，且日志没有任何报错信息。处置过程：
根据日志分析发现info日志报jute.Maxbuffer大小为4m，考虑可能是事务过大导致。；经过业务沟通评估后；计划将jute.Maxbuffer改为8M。运维建议：
经过复核查验官网不要改大jute.Maxbuffer，后回退改动。；后将cms垃圾回收改为G1，也出现了直接进入夯死状态，并触发rit。后回退。；目前业务使用版本情况如下
第 37
期｜UDAL 连接数不够或创建连接的速度跟不上问题分析
专辑文件：05.html，第 6 个案例
查看原文 现象：
某业务系统反馈应用卡顿，程序获取数据库连接超时，通过查看应用日志报错，结合数据库日志报错，发现某条sql为⼀个⼴播语句，且查询的表为分⽚表+库内分桶结构，获取连接数放⼤，定位为由于连接数不够或创建连接的速度跟不上，导致程序发现异常。处置过程：
业务通过服务保障支撑群反馈；应用连接数据库超时。；DBA收到通知后，对该数据库进行检查，由于该库是UDAL架构分布式，首先检查智能运维工作台上的数据库历史拨测情况，无异常；应用连接层,dbproxy状态，发现状态均正常，其次检查数据库底层库，发现底层库在故障时间点，连接数突增。运维建议： 通过对该表进行分析，point_ ba lance_
source为分片表，共有12个分⽚*2个分桶，分⽚键范围查询⾛了⼴播+库内分桶，⼀条这个SQL需要24个后端连接。⼴播查询+库内分桶，会放⼤连接数要求，业务优化该sql，分片表必须要求带上分片键，避免sql广播消耗数据库资源。；因此考虑是由于连接数不够或创建连接的速度跟不上导致的报错，另⼀⽅⾯，dbproxy默认后端连接池配置、mysql默认配置⽐较⼩，需要进⾏调优。；SQL
规范执行
第 37
期｜clickhouse 分布式DDL语句执行阻塞问题分析
专辑文件：05.html，第 7 个案例
查看原文 现象：
业务执行脚本，部分语句执行成功，后续语句执行时卡在一条truncate语句，分布式DDL语句执行阻塞。处置过程：
查看clickhouse分布式DDL目录，配置文件中<distributed_ddl>配置。；查看目录下有哪些DDL语句；"ls
/clickhouse/task_queue/ddl/ck_hunandx_new"运维建议：
新增分布式表状态监控项；发现即联系应用侧确认时间窗口进行整改。；规范业务sql语句脚本编写
第 36
期｜hadoop节点异常宕机后无法重启集群
专辑文件：06.html，第 10 个案例
查看原文 现象： hadoop节点异常宕机后无法重启集群。处置过程：
Hadoop集群出现单NameNode节点异常宕机情况。尝试通过标准流程重启集群时，发现SSH连接至故障节点时触发以下报错；can't
be established.ED25519 key fingerprint is
SHA256:J5a33/DnLkZNpHppbrojLQeutNHA9+FcElmZmjHOiiQ.This host key is
known by the following other
names/addresses:~/.ssh/known_hosts；该错误直接导致集群无法完成节点间的SSH免密通信，进而阻断了HDFS、YARN等核心组件的启动流程。运维建议：
Hadoop集群需要保持节点间的ssh互信，单点SSH信任关系异常即可导致全局服务启动失败；节点主机名/IP地址变更后需及时同步更新SSH密钥信任关系；服务重启需严格遵循依赖层级
第 31
期｜Kafka消费组消息数量持续增长
专辑文件：11.html，第 9 个案例
查看原文 现象： kafka某个消费组消息数量持续增长。处置过程：
确定这个消费组下是否有消费者；去对应消费者的服务日志里确定当前服务是否正在正常消费生产者的消息；和研发确定当前消费者的数量是否足以支撑消费生产者的消息运维建议：
因为同一个topic下的某一个分区只能被某个组中的同一个消费者消费，当我们生产者生产的消息无法实时被消费者消费的时候，适当扩大分区数，让该topic可以同时支撑多个消费者来消费，可以显著提高并行消费能力；增加消费者实例提高消费组的消费能力，；需注意分区数
第 28
期｜NBU备份集群环境Master服务异常
专辑文件：14.html，第 1 个案例
查看原文 现象：
master服务一直无法正常启动；；master01主机bpps
-x进程缺少较多，查看hastatus
-sum状态正常，手动启动服务后，可正常连接，但是3分钟后，服务又中断。处置过程： 停止master集群；hastop all
force；依次启动master01和02运维建议： 避免单机重启操作；在集群环境中，遇到
master 服务无法启动时，避免使用单机重启操作如 bp.kill_all 和
bp.start_all。这些操作可能导致双机信息不同步，从而引发服务启动异常。应优先考虑通过集群管理工具如
hastatus 和 hagrp 来进行集群层面的操作。；集群操作规范
第 28 期｜Kafka异常退出
专辑文件：14.html，第 6 个案例
查看原文 现象： 异常退出。处置过程：
登录服务器查看$KAFKA_HOME/log/server.log日志报错；org.apache.kafka.common.errors.KafkaStorageException:
Error；deleting segments运维建议：
分析报错日志定位问题；在发生异常退出时，首先要登录服务器查看相关日志。在此案例中，Kafka日志明确指出由于缺失日志文件导致的错误。通过查看具体报错信息，可以快速定位问题的根源。；确认文件和目录的完整性
第 27
期｜NBU备份客户端连接异常
专辑文件：15.html，第 5 个案例
查看原文 现象： can't connect to
client，备份过程中提示无法连接客户端，不过有时候也会执行备份成功。处置过程： 登陆主机查看备份进程及备份配置；./bpps
-x;cat bp.config；测试到master的1556端口正常。运维建议：
全网连通性测试；在进行备份任务时，确保对所有目标主机；（如 Media
服务器）
第 27
期｜weblogic控制台实例启动异常
专辑文件：15.html，第 8 个案例
查看原文 现象：
某省XX系统Weblogic控制台弱密码修改后，应用加载不结束，实例启动异常问题处理。排查与原因：
拉应用侧开发人员一起分析，查看业务日志，分析业务调用逻辑，没有找到。；最后通过jstack导出被管Server的线程dump进行分析，发现部分线程在执行连接zk的相关方法卡住了，怀疑连接zk连接不上导致应用工程无法加载完成。处置过程：
某省XX系统Weblogic弱口令改造，控制台密码改造完成后，被管server启动异常，业务异常。；控制台密码重置命令；${JAVA_HOME}/bin/java
-classpath ${WL_HOME}/server/lib/weblogic.jar
weblogic.security.utils.AdminAccount ${NewAdminUserName}
${NewAdminPassword}运维建议：
在执行任何可能影响系统稳定性的操作前，对关键域进行全域备份。这有助于在出现问题时快速恢复系统至稳定状态，减少业务中断时间。；在处理服务启动异常时，我们曾误认为由于服务未正常启动，导出线程dump无法获取有用信息；然而，实际上通过线程dump分析，我们最终定位了问题的关键点——zk连接问题。因此，无论服务是否启动成功，当出现性能异常或启动失败时，都应立即导出线程dump进行分析。这有助于快速定位问题根源，提高故障处理效率。
第 24
期｜Flink任务数据入库延迟问题分析
专辑文件：18.html，第 6 个案例
查看原文 现象：
本地上云应用日志接入，出现一个flink任务数据入库延迟。前端查询日志显示数据延迟大于10小时。；建立对Flink任务、Kafka消费、数据流状态的实时监控和预警机制，确保问题能够第一时间被发现，并及时采取措施缓解延迟。；3）优化TaskManager线程模型处置过程：
1）分析flink任务；对比处理其他数据的flink业务，发现均无异常排除因flink本身导致的问题。；2）分析数据运维建议：
1）灵活调整配置应对业务增长；随着数据量和业务需求的增长，静态的任务配置难以满足实时性要求。定期评估业务增长趋势，预留至少30%的资源冗余以应对突发情况，并灵活调整Flink任务的配置。；2）加强实时监控和预警机制
第 23
期｜Coherence集群缓存超时问题分析
专辑文件：19.html，第 3 个案例
查看原文 现象：
响应客户要求，对通用Coherence集群主机操作系统进行国产化，由redhat7.6升级到BCliunx
21.10；；分批次升级，于6月6日晚完成通用Coherence集群所有主机操作系统国产化升级，6月14日，工单系统维护人员反馈连接通用Coherence集群缓存超时。处置过程： coherence
通用集群版本12.2.1.3.18；升级BCLinux 21.10
sp2,；系统内核版本4.19.90-2107.6.0.0227.28运维建议：
多个数据库驱动共存时要确认实际加载的驱动版本；当系统中存在多个数据库驱动文件时，必须确保应用程序实际加载的驱动版本是与数据库兼容且经过测试的版本。；老旧系统或不同组件使用各自版本的情况下，容易出现版本混淆的问题
第 23
期｜clickhouse副本间延迟现象问题分析
专辑文件：19.html，第 4 个案例
查看原文 现象：
应用侧反馈CK准生产环境；批量入数据时出现数据比预期少，经检查为副本间延迟导致。排查与原因：
多次执行应用侧脚本，发现不规律的出现临时表数据比实际查询的业务数据少。；经分析测试发现，此类为应用脚本大批量插入数据导致副本延迟副本短时间内数据不一致，与应用侧沟通因业务需要脚本整体流程有时间限制各步骤间无法添加等待时间，不能等副本同步完成后再进行后续步骤。；经我侧多次测试验证，通过调整参数<load_balancing>first_or_random</load_balancing>将脚本操作限制在各分片的第一个副本可以规避副本延迟的影响。处置过程：
业务脚本逻辑分析；应用侧脚本流程，通过多个临时表处理将今日的业务数据写入历史表，理论上业务数据只会增加不会减少。；应用侧脚本包含操作，各步骤存在大量的truncate和
insert into xxx select from
xxx，各步骤随机选择副本执行且统计期间无等待时间。运维建议：
跨副本操作需要充分考虑副本间同步延迟；本次故障暴露了在分布式数据库环境中，跨副本操作时因副本间同步延迟可能导致数据不一致的问题。ReplicatedMergeTree引擎依赖于ZooKeeper进行元数据的同步，同时通过拉取数据部分来实现物理一致性。；当大批量数据插入时，副本间的同步可能会出现延迟
第 23
期｜clickhouse重建表时报错问题分析
专辑文件：19.html，第 5 个案例
查看原文 现象：
应用侧反馈重建INF35BSN.BALANCE_SOURCE_L表时报错；“ Existing table
metadata；ZooKeeper differs处置过程： 查看日志发现重建表时报错；Code: 342.
DB::Exception: Existing table metadata in；ZooKeeper differs in mode
of运维建议：
使用同步删除操作确保表元数据的一致性；本次故障的根源在于表删除后，ClickHouse中的数据文件和元数据文件已被删除，但ZooKeeper中仍保留了表的元数据路径，导致在重建表时出现了元数据不匹配的错误。；为了避免类似问题的发生，在删除表时使用同步删除操作
第 23
期｜regionserver掉线问题分析
专辑文件：19.html，第 7 个案例
查看原文 现象：
某业务新搭建集群CDH-5.9.3，业务迁移后使用中频繁的偶发性出现几个regionserver掉线情况出现，且每次的regionserver节点随机掉线，regionserver并没有任何负载依然会有掉线情况发生。处置过程：
尝试检查集群网络；自己测试和协调网络组协助排查均未发现问题。；怀疑防火墙问题运维建议：
严格遵循官方支持的版本信息；在部署和使用企业级软件时，严格遵循官方支持的操作系统和软件版本非常重要。本次故障的根因是CDH
5.9.3在非官方支持的CentOS
7.6上运行，虽然最初安装成功并能正常启动服务，但仍存在潜在的兼容性问题，导致系统出现偶发性故障。；通过此次经验，可以得出
第 22
期｜BES经典故障之内存溢出
专辑文件：20.html，第 5 个案例
查看原文 现象：
当JVM中的资源占用的内存超过最大内存时就会出现内存溢出，JVM内存溢出分为堆内存溢出、元空间内存溢出、线程栈内存溢出等。根据内存溢出信息进行调整优化以及资源扩容。处置过程：
首先重启BES服务器保证服务可用。；使用MemoryAnalyzer工具进行分析；打开heapdump进行分析，可以看出具体的内存使用，以及对用的对象使用占有率较高的情况。通过dump文件信息排查内存分配相关的代码。找到JVM堆中对象最多的类，重点分析。运维建议：
定期监控JVM内存使用，防止内存溢出问题；JVM内存溢出常常是在内存分配不当或资源使用过度时发生，因此需要定期监控JVM的内存使用情况，包括堆内存、元空间、线程栈等关键区域。；通过监控工具
第 22
期｜BES经典故障之占CPU高
专辑文件：20.html，第 6 个案例
查看原文 现象：
主机CPU使用率高影响主机计算性能，导致主机上的服务性能降低或者不可用。该场景通常是因为当前存在大量线程抢占CPU资源或者部分线程占用CPU资源长时间不释放导致。处置过程：
通过分析CPU使用率高的线程堆栈信息；确认是否是调用外部资源无响应、线程死锁等原因。例如是因为数据库宕机、外部服务不可用，可通过启动相应服务来解决。；如果是并发数导致CPU使用，可通过搭建集群、主机资源扩容、减少线程池最大连接数等方式解决运维建议：
监控与预警机制需覆盖CPU使用情况，及时响应问题；CPU高占用会影响系统性能，甚至导致服务不可用。；（如Prometheus、Zabbix等）
第 22
期｜BES经典故障之服务假死
专辑文件：20.html，第 7 个案例
查看原文 现象：
BES进程还在，但是应用无法访问，BES日志没有输出或者无异常信息。处置过程：
TCP连接无法建立：连接数已经达到单个进程的上限、大量的TCP连接为CLOSE_WAIT、TIME_WAIT状态等待释放资源。；系统负载过高导致无法处理连接请求。；出现线程死锁。运维建议：
定期检查系统的TCP连接状态，预防连接数耗尽；服务假死问题可能由大量TCP连接进入CLOSE_WAIT或TIME_WAIT状态引发，导致资源无法及时释放。；定期监控系统的连接数，特别是高并发场景下，应该配置合理的连接超时策略和回收机制，防止连接数耗尽。通过工具如netstat或ss定期检查连接状态，并根据需要调优内核参数
第 21
期｜BES中间件实例报“java.sql.SQLException”问题分析
专辑文件：21.html，第 10 个案例
查看原文 处置过程：
反馈业务侧核查对应表字段最大值，报错本身是由库抛出，初步怀疑插入表字段值大于表结构中表字段大小。；业务侧核查反馈表字段类型为varchar4000，插入数据大小低于此值。；让业务侧核查有问题的BES实例加载的库驱动版本，怀疑未加载到正常使用驱动版本，业务侧核查后反馈加载的驱动为应用工程目录下自带的ojdbc14.jar。运维建议：
ojdbc14.jar为老版本，升级驱动包，后续我们在BES产品lib目录下放置ojdbc6.jar驱动，应用重启会优先加载使用产品目录下驱动。；使用高版本驱动包后问题解决，后续未出现相关问题。；多个数据库驱动共存时要确认实际加载的驱动版本
第 18
期｜weblogic线程池使用率100%
专辑文件：24.html，第 4 个案例
查看原文 现象：
业务侧反馈某系统在上线重启实例之后频繁收到Weblogic线程池使用率100%告警。处置过程： 查看该weblogic
Server历史监控数据，发现weblogic线程总数在上线后缩容至个位数，当业务量上升后，获取线程达到线程总数上限触发告警。；但是weblogic线程池本身拥有线程自扩容，自调优机制，待线程池耗尽后会自己进行自扩容满足业务使用，但是当业务上线重启实例后，weblogic自缩容机制会将线程池进行缩容。运维建议：
可以配置线程池最小值参数，；Dweblogic.threadpool.MinPoolSize=xxx；，根据业务量、主机性能等方面评估设置值，当weblogic实例重启后会创建配置的线程最小值连接，减少业务量高并发时自扩容线程的耗时，导致出现短暂的阶梯式的线程池使用100%情况出现。
第 14
期｜Weblogic大版本升级后，应用部署失败问题
专辑文件：28.html，第 7 个案例
查看原文 现象：
某系统Weblogic大版本升级，从weblogic10.3.6.0+jdk1.6升级到weblogic12.2.1.4+jdk1.8，应用部署异常，启动失败。处置过程：
协调应用侧开发人员核查确认应用工程代码是否与原生产环境一致；；开启weblogic
日志的dubug模式，从日志中看报错的方法类均与org.glassfish.jersey相关，系jersey2.X版本，而现场应用工程使用的是jersey1.X版本，对应类方法类为com.sun.jersey 。；发现Weblogic优先加载了Weblogic12.2.1.4安装目录下的org.glassfish.jersey*相关方法类（jersey2.X版本），导致应用工程启动异常。运维建议：
大版本升级前，应充分了解相关版本升级注意事项；全面掌握新版本相比老版本新增，优化，升级，删除等调整了哪些内容；同步告知开发人员，做相关适配改造
第 14
期｜weblogic中间件的应用系统,数据库相关方法调用失败
专辑文件：28.html，第 8 个案例
查看原文 现象：
业务侧反馈数据库相关方法调用失败，数据库侧同事核查并反馈当前库并无异常，但在此之前的某个时间数据库有重启操作；（测试环境国产数据库，时常做优化、配置修改，会涉及库重启生效。）处置过程：
从日志看是应用从JDBC连接池取到的连接都是已关闭连接。；weblogic数据源连接池配置，发现该数据源未勾选“保留时测试连接”选项。；该选项，需要如下两个参数配合运维建议：
Weblogic数据源的“保留时测试连接”选项默认都是关闭状态，应该在；创建JDBC连接池时直接勾选/开启该选项；BES中间件数据源配置默认会开启“获取连接池验证”选项，保证连接有效性，“连接空闲时验证”选项默认是禁用，该选项是主动探测池中连接，主动保证池中连接为有效连接，
第 11
期｜nbu 恢复数据库时，一个通道恢复完，hang 住且无报错
专辑文件：31.html，第 6 个案例
查看原文 现象： 1）nbu
恢复数据库时；，一个通道恢复完，就会hang
住无反应，也无报错；如果是单独恢复小的数据文件没问题。但是只要恢复大的数据文件就会hang
住。处置过程： 这是由于服务器和nbu
之前有防火墙，超过一定时间的连接，如果没有数据传输就会中断连接；根据官方文档；修改内核参数用系统的keepalive运维建议：
提前检查防火墙问题，参考官方文档不让防火墙断开。
第
10 期｜ElasticSearch数据量大，内存使用率高，集群处于不稳定运行状态
专辑文件：32.html，第 2 个案例
查看原文 现象：
ES集群节点丢失，登录主机查看情况，发现集群总数据量已达84.6T，堆内存使用率均超过70%预警值，监控出现断采，日志显示已频繁出现gc情况，同时出现节点响应超时的日志。过一段时间节点加入集群集群自动恢复。此后再次收到告警短信，同样的问题再次出现并自动恢复，集群处于不稳定状态。处置过程：
经分析集群不稳定的原因主要是数据量太大，超过规划值，因此需要减少数据量，后续由应用侧清理上个月的数据以减轻集群压力，集群恢复正常。运维建议：
应用侧梳理现有业务，进行数据生命周期管理，管控数据量。；应用侧做索引改造，由月索引改造为日索引。；新增内存存储比.内存分片比监控项。
第
10 期｜ElasticSearch GA05版本安装中ES报错创建索引失败，无法连接ES
专辑文件：32.html，第 3 个案例
查看原文 现象： es创建索引失败。；failed connect to
es-ip;connection refused；Caused by处置过程：
确认elasticsearch进程状态正常。；手动连接es：执行curl -XGET
http://ip:9200/ 发现无法连接 提示"missing
authentication"于是进一步查看es的配置文件,进而确认es安全鉴权已开启，加上用户密码后，发现仍然无法连接。；根据日志报错与鉴权证书文件相关，继续追踪发现在报错路径下并未发现任何文件存在,证书路径参数无法找到文件，导致无法通过用户密码正常访问es，后面我们在安装es的路径下却发现已生成好的证书，于是手动将elasticsearch.yml中的证书路径修改为安装es路径，重启服务并正常访问。运维建议：
安装配置custom.yml中修改snc_home_path默认配置后，务必修改下$install_dir/install_product_V4.0-GA05_20230420/snc_product/roles/elasticsearch/templates/elasticsearch.yml.j2中鉴权文件路径。
第
10 期｜ElasticSearch
国产化迁移平台后资源池全局搜索功能异常，提示"未搜索到结果"
专辑文件：32.html，第 4 个案例
查看原文 现象：
为保证数据迁移顺利，新老平台采用版本一致，均为GA04。；数据库迁移因涉及数据库较多,直接将老平台mysql库路径迁移，拷贝数据目录至新环境对应的mysql安装目录处，后启动mysql，并检查比对数据信息。；老环境es数据丢弃不做迁移并停用es服务,新环境中es的数据使用初始化以后。处置过程：
因平台数据刚做初始化动作,未同步至es中，导致全局搜索在调用es服务获取数据失败，进而手动同步下数据，开发工具-快捷入口，执行"全量资源服务同步至es服务"，后再次全局搜索，发现问题并未根治。；检查snc-base-resource服务在nacos配置中的配置文件信息，发现es的地址显示仍指向老地址,包括zk,kafka,redis,mysql等信息仍是老版，后随机检查其他多个配置文件，发现配置文件信息并均被覆盖为老版，此时问题浮出，根据mysql迁移步骤分析，判断出nacos配置库被一并迁移至新平台，导致各微服务的配置信息均采用老版，手动同步es的操作也是将数据同步至老平台的es服务。；开始处理故障，停止全部微服务，重部nacos。运维建议：
Mysql数据迁移过程中方案欠佳，未考虑nacos数据库会被覆盖问题，进而导致微服务连接至老平台环境，引发一系列问题。；平台整体数据迁移过程中，在采用直接迁移数据目录这种高效的策略方式时，应多考虑特殊服务的数据情况，最好逐个数据库检查，对其所承载的业务了解透彻，做到细致入微。
第 10
期｜zookeeper 3号机发生重启，业务连接不上zookeeper集群
专辑文件：32.html，第 10 个案例
查看原文 现象： zookeeper
3号机发生重启，业务连接不上zookeeper集群。处置过程：
3号机发生重启。；查看3号机zookeeper日志及节点状态报zkerver not
running。；检查发现1和5号机zk进程down了。运维建议：
从整个故障到解决故障，核实日志查看zookeeper集群卡在3号节点宕机后，其余4个节点一直处于选举状态，查看日志一直到人工接入处理前进行了几千轮的选举，每论选举看选举结果是超过半数以上的节点选举成功，但是不断的在下一轮重复选举过程，通过选举日志产看基本每轮选举结果都是5、4两个节点选举为leader，查看5、4号节点日志信息发现关键信息。；couldn’t
bind；to 105
第 9
期｜kafka 部分topic分区出现leader是-1情况导致分区不可用
专辑文件：33.html，第 8 个案例
查看原文 现象： kafka 部分topic分区出现leader
是-1情况导致分区不可用。处置过程：
kafka集群业务出现部分分区无法写入情况，检查集群状态发现部分topic的分区leader
是-1，也即没有任何分区ID的情况。；先尝试使用kafka-reassign-partitions命令，编写topic的json，将此分区恢复，发现修复失败。；于是尝试从zk底层进行修复，先get
/brokers/topics/{topic名字}/partitions/{分区id}/state
查看异常分区信息运维建议：
从根本解决就是增加每个topic的副本数，修改为2或3副本，避免单副本时，一旦损坏一个数据盘就导致数据丢失和分区不可用情况；；尽量使用较新稳定版本kafka，过老版本升级。
第 7
期｜ElasticSearch数据库启动失败处置
专辑文件：35.html，第 6 个案例
查看原文 现象：
ES启动失败，查看ES日志发现这样的报错；virtual memory
areas；.max_map_count [处置过程：
查看ES进程，ES启动失败；；查看ES日志发现这样的报错；virtual memory
areas运维建议： 在/etc/elasticsearch/elasticsearch.yml
开启了 bootstrap.memory_lock:
false这个配置，elasticsearch官网生产环境需要设置bootstrap.memory_lock:
true。；官网的解释；发生系统swapping的时候ES节点的性能会非常差，也会影响节点的稳定性。所以要不惜一切代价来避免swapping。swapping会导致Java
GC的周期延迟从毫秒级恶化到分钟，更严重的是会引起节点响应延迟甚至脱离集群。
第 6
期｜Zookeeper临时节点不自动删除
专辑文件：36.html，第 8 个案例
查看原文 现象：
zookeeper作为业务的注册中心，业务程序启动后会在zookeeper中进行注册临时节点，业务程序宕机后临时节点未进行自动删除。导致通过调用zookeeper访问注册中心的程序会将请求分发到已宕机的程序，对业务造成影响。；在搜索引擎针对进行搜索，寻找他人的。结果未发现完全相同的故障类型。；升级手段1处置过程：
常规手段1；业务反馈这类问题后，第一时间查看zookeeper日志，查看是否有异常报错。结果未发现明显错误。；常规手段2运维建议：
bug一般具有以下几个特性：复现难度高，频率低，日志记录不完全或者不记录，网上资料较少。；当我们遇到中间件故障的时候，会默认觉得是配置文件不够优化，或者部署出现不合理等。更进一步会排查业务程序是否配置合理，但不会去关注中间件自身可能出现的bug。又由于bug具有第1点中的特性，所以排查起来非常困难。这里如果遇到非常棘手的问题，可以看看相关中间件的bug信息。
第 4 期｜KAFKA
topic分区不足致新增proxy异常
专辑文件：38.html，第 2 个案例
查看原文 现象： topic分区不足致新增proxy异常。处置过程： 执行命令扩展分区；./bin/kafka-topics.sh
--zookeeper IP:2181 --alter --partitions {proxy数量+N} --topic
dcp_agent_command。运维建议：
需扩展proxy注册到zk对应的分区，kafka中会创建一个名为dcp_agent_command的topic用于下发监控指定给snc
agent，默认创建6个分区(partitions)，当proxy数量超过6个时，应当新增分区数量，避免消息通道阻塞。需要根据业务提前做好topic分区。
第 2
期｜Elasticsearch未分配分片异常
专辑文件：40.html，第 8 个案例
查看原文 现象： Elasticsearch未分配分片异常。；2.
处置方案；查看哪些索引导致集群进入运维建议：
以混沌工程为切入点，完善相关监控项和自愈方案开发。；完善ES告警体系，对ES未分片进行告警。
第 1 期｜weblogic
nginx反序列化攻击处置
专辑文件：41.html，第 6 个案例
查看原文 现象：
确认本次攻击是由wls9-async组件导致，在反序列化处理输入信息时存在缺陷，攻击者可以在/_async/AsyncResponseService路径下传入恶意的XML格式的数据。；2.
处置方案；通过前端nginx限制/_async路径跳转；运维建议：
定期对各类开源组件进行升级，并配置好相关白名单，从而降低各类安全风险。