Cassandra 3.11.10突发崩溃无日志记录，求排查思路

1. 收集系统级崩溃核心线索 #

• 检查内核级日志：除/var/log/messages外，执行dmesg | grep -i 'kill\|oom'检索内核日志，部分OOM-kill记录仅会出现在内核日志中；也可查看/var/log/kern.log（Debian/Ubuntu环境）。
• 排查core dump文件：若系统开启core dump功能，检查Cassandra工作目录或/var/core下是否生成core文件，用gdb <Cassandra的Java可执行文件路径> <core文件路径>加载分析崩溃线程栈。
• 验证资源限制配置：执行ulimit -a查看Cassandra运行用户的当前资源限制，重点确认open files（需≥100000）、max user processes（需≥32768），同时检查/etc/security/limits.conf中的持久化配置是否生效。

2. 确认vm.max_map_count配置有效性 #

• 先执行sysctl vm.max_map_count查看当前生效值，若未达到1048575，说明修改未生效：可执行sysctl -p临时生效，同时检查/etc/sysctl.conf或/etc/sysctl.d/下的配置文件是否正确写入该值，避免重启后被覆盖。
• 若配置已生效仍有警告，检查系统内存映射占用：执行lsof | wc -l查看总打开文件数，或针对Cassandra进程执行lsof -p <Cassandra进程ID> | wc -l，确认是否接近系统限制；该警告本质是虚拟内存映射数不足，极端情况会导致进程无法分配内存区域引发崩溃。

3. JVM层面异常排查（非OOM场景） #

• 查找hs_err_pid*.log文件：JVM崩溃时会在Cassandra启动目录生成该日志，记录崩溃时的线程、内存、JVM参数等关键信息，是定位JVM crash的核心依据。
• 检查非堆内存使用：Cassandra大量依赖堆外内存（Direct Memory、Metaspace），即使堆内存正常，堆外内存耗尽也会导致JVM直接崩溃且不写入system.log；可补充监控非堆指标，或确认JVM参数-XX:MaxDirectMemorySize配置是否合理（默认等于堆最大内存）。
• 验证JVM参数兼容性：Cassandra 3.11.x推荐使用CMS垃圾收集器，若误配G1或自定义不稳定GC参数，可能引发兼容性崩溃；同时确认JDK版本为8（3.11.x不支持JDK11+）。

4. Cassandra自身隐性问题排查 #

• 检查数据目录完整性：崩溃后重启前，查看data/data下各keyspace目录是否有损坏的SSTable文件，可执行nodetool scrub尝试修复（需在离线或低负载下操作）。
• 排查近期schema变更：确认崩溃前是否有大量表创建/删除、索引修改等操作，不当的schema变更可能触发节点崩溃；若节点能临时启动，可查看system_schema.keyspaces和system_schema.tables的变更记录。
• 检查日志磁盘状态：执行df -h确认Cassandra日志所在磁盘是否有剩余空间，避免因磁盘满导致system.log无法写入。

5. 补全监控维度 #

• 补充监控CPU使用率、磁盘IO、网络流量：崩溃前可能出现CPU突增、磁盘IO打满（如大规模compaction）、网络中断等情况，这些指标可辅助定位诱因。
• 优化日志滚动策略：检查Cassandra的logback配置，确保日志滚动逻辑合理，避免关键日志被意外删除。

内容的提问来源于stack exchange，提问作者daniel