1. 集群前端报错
1.1 Redis 集群节点异常
1.1.1 问题描述
1.1.2 原因分析
某个节点出现异常或已经宕掉，无法继续在 Redis 集群中提供服务。
1.1.3 解决方案
1）登录 Redis 集群，输入cluster nodes检查 Redis 集群状态。
redis-cli -h ip -p 端口 -a 密码 # 客户端远程连接某个节点，输入对应的 ip、端口、密码。
当我们检查到某个 Redis 节点是宕机（fail）状态，请及时检查该 Redis 节点进程，若进程还在，则kill掉进行重启，若进程不在，则直接启动该节点，启动后再次进行检查是否恢复。
2）如果想进一步确认 Redis 集群的可用性，可以连接某个主节点（master）测试是否能够写入 key。
正常情况：
异常情况：
当我们检测到 Redis 集群是无法写入（down）的状态时，此种异常较为罕见，建议重启整个 Redis 集群。
1.2 节点间 JAR 包不一致报错
1.2.1 问题描述
1.2.2 报错原因
节点启动过程会与第一个加入集群的节点对比 jar 包是否一致，若检测到不一致情况，则前端进行异常展示并给出详细的异常信息。
1.2.3 解决方案
参照异常提示， 检查各个节点下的 jar 包并进行调整，调整完毕后重启节点，再观察是否还有报错。
1.3 同步失败报错
1.3.1 问题描述
同步失败报错，如下图所示：
1.3.2 原因分析
该节点与文件同步基准节点进行文件同步时，出现同步错误或者请求超时，重复尝试3次仍然无法成功，则前端进行异常展示。
1.3.3 解决方案
检查节点间通信、网络状态是否正常，若有异常则及时进行调整。
1.4 平台无法连接到Redis
报表界面访问的时候，报错：Could not get a resource from the pool 如需访问请联系管理员，如下图所示：
可能的原因：
Redis 宕机
网络异常
工程运行时修改了 Redis密码
解决方案：
如果是 Redis 宕机或网络异常，正常排查和解决即可
如果是 Redis 修改了密码需重启 Tomcat 工程，重启工程后进入平台页面重新配置 Redis 密码即可
2. 分布式集群报错
2.1 Alluxio 无法正常启动
2.1.1 问题描述
Alluxio 一直启动不成功。
2.1.2 原因分析
Spider 组件内存配置不正确。
2.1.3 解决方案
如果自行调整过 Spider 组件的内存，需要重新修改下内存配置。
2.2 Spider 集群主机心跳丢失
2.2.1 问题描述
集群中的主机出现100%的内存占用的情况，导致其他 master 无法连接这台主机，心跳丢失。
2.2.2 原因分析
内存配置过小。
2.2.3 解决方案
需要升级硬件配置，增大内存配置。
2.3 Spider 集群基础上启动 Web 集群失败
2.3.1 问题描述
Web 集群双节点只能启动一个节点，另一个节点访问报错，如下图所示：
2.3.2 原因分析
Tomcat 文件夹权限问题，非 root 用户启动。
2.3.3 解决方案
使用 root 用户启动集群。
2.4 Spider Alluxio 主节点挂掉，BI 模板全部不能访问
2.4.1 问题描述
BI 查询报错，发现 Alluxio master 节点挂掉，Master 的日志中有对应的 oom 报错。如下图所示：
2.4.2 原因分析
Alluxio master 执行 hdfs 命令，在高负载的情况下，内存不足。
2.4.3 解决思路
Alluxio Master 需要调大内存，找到ALLUXIO_MASTER_JAVA_OPTS，如果没有或者被注释，那么直接添加。如果有的话就添加相应的 Xms和 Xmx 参数，最后点击Save 按钮保存配置。
如下图所示：
2.5 Spider 集群下模板预览变慢
2.5.1 问题描述
做了 Spider 集群，每天有很多人在使用，使用的时候就会造成 spark 的任务阻塞，导致模板预览变慢。
2.5.2 原因分析
磁盘速度很慢导致分布式速度上不来。
2.5.3 解决方案
升级硬件配置。
3. 平台异常通知
集群为了便于大家及时发现并排查问题，针对异常情况也会进行异常通知，通知包括邮件通知、短信通知、消息通知，平台开通集群异常提醒即可收到。
| 异常原因 | 通知内容 | 解决方案 |
|---|---|---|
| jar包不一致 | 节点 #nodename# 与节点 #nodename# 的 jar 包不一致，将影响集群工程的稳定性，请前往集群节点管理页面查看详细异常信息，并及时处理。 | 1.2中已给出 |
| 节点脱离集群提醒 | 节点 #nodename# 已脱离集群环境，可能原因为：节点 FullGC、节点宕机、节点间通信不畅、节点负载过高、其他异常。为避免影响用户使用，请及时检查该节点状态，若该节点长时间无法自行恢复，则建议重启该节点。 | 前往集群节点管理界面，看看报脱离的节点是否还存在。 a、如果节点已经消失，在服务器中查看应用进程，若进程还在，则 kill 掉再进行重启，若进程已经不在了，则直接重启该节点工程； b、如果节点还存在，则前往智能运维-内存管理或者直接进入服务器内查看节点的 内存/CPU 占用情况，看看是否有飙升现象，如果节点 内存/CPU 过高，则重启该节点； 上面两种方法仅为临时解决方案，造成节点脱离的原因大致有三个：负载过高导致频繁 FullGC、线程阻塞导致 内存/CPU 飙升、节点宕机 |
| 节点间时间不一致 | 节点 #nodename# 与节点 #nodename# 系统时间相差超过 XX 秒，为避免影响用户使用，请及时调整使各节点时间保持一致。 | 检查各个节点的时间是否一致，当节点间系统时间误差超过 30s 时会进行报错提醒，因为包括登录等基础功能的使用可能会受到时间不一致的影响。 windows 系统可以手动将各个节点的系统时间调为一致，Linux 系统调整节点间时间可以参考文档：Linux 系统如何配置各个节点的时间一致性？ |
| Redis集群节点异常 | Redis 集群 #ip:port# 节点已无法正常使用，可能原因为：节点宕机、内存已满、其他异常。为避免影响用户使用，请前往状态服务器配置页面查看详情，并及时处理。 | 1.1中已给出 |
| 文件服务器宕机 | 文件服务器出现无法正常读写的情况，可能原因为：文件服务器宕机、磁盘已满、其他异常。为避免影响用户使用，请及时检查文件服务器状态。 | 若启动过程中连接不上文件服务器，可从文件服务器状态，防火墙是否开放端口等角度进行排查。 若使用过程中出现了这个报错，则从三个方向进行排查： a、检查文件服务器的状态，看看是否是文件服务器宕机了； b、检查配置的 WEB-INF 目录是否还能正常读写； c、检查文件服务器的磁盘空间剩余情况，可能是磁盘满了导致无法读写，若磁盘满需要扩充磁盘空间。 |
| 文件同步失败提醒 | 集群节点 #nodename# 与基准节点存在不一致文件，且无法自动同步。请检测该节点状态 | 本文 1.3 中已给出 |
4. BI 数据更新问题
4.1 更新卡住，重启后无法停止更新
4.1.1 问题描述
单表更新卡住，重启后更新进度页面显示仍在更新。
4.1.2 原因分析
集群若只有一个节点重启，不会清状态服务器 Redis 里的更新进度，需要重启整个集群，才会重置更新进度，如果只重启一个节点，之前在进行中的任务会强制失败，未开始的任务会继续更新。
4.1.2 解决方案
将所有的集群节点关闭之后全部重启。
5. 11300016 服务器服务响应时间过长
本文档的解决方案适用于 JAR 包为 2020-01-15 之前发布的版本，2020-01-15 及以后发布的版本可以直接在前端修改参数：集群参数配置
为了解决一些集群环境单节点故障导致的问题，我们对「集群内部转发逻辑」进行了优化。对于节点之间的请求设置了超时时间，默认的读写超时时间是 18s ，对于部分用户来说，这个参数会影响模板的访问并会收到异常消息通知，如有此情况可根据本帮助文档自行调整。
问题描述：
1）报错页面：
2）异常通知：
解决方案：
可以通过手动在配置数据库 fine_conf_entity 表中插入对应的字段和值来进行调整，如下表所示：
| 字段 | 自定义值（单位：ms） | 注释 |
|---|---|---|
ClusterRedirect Config.socket Timeout | 90000 | 含义： 读写超时的时间，如果在超时时间内服务器未返回或收到任何数据，视为超时，超时 5 次会通知管理员检查节点状态。 参数调整建议： 如果没有大数据量计算或导出的模板，则建议配置不超过 90000（单位ms）。如果有大数据量计算或导出的模板，则根据最长耗时的模板时间进行配置。 说明： 这个参数与 nginx 中的参数为 proxy_read_timeout 和 proxy_send_timeout 对应，不能超过nginx 里的这两个参数的值。 |
6. Web 集群部分节点卡死
问题描述：
集群某一节点卡死，后台打印的日志包含：BLOCKED（on object monitor），locked <0x0000000549f947f0>。如下图所示：
原因分析：
这个问题是由于所有的线程都使用同一个 Category，写日志的线程太多时，就出现了部分线程 Block，但是上图的是获取了锁之后被 block 掉，导致死锁；
解决方案：
目前由于需要兼容 jdk1.6，无法使用更高版本的 log4j，因此这个问题只能通过设置日志级别来解决。进入管理系统>智能运维>平台日志，将系统日志级别调整为 error，如下图：
调整完后重启卡主的节点即可；
7. 数据集一直等待更新
问题描述：
用户工程为 5.1.1 版本，redis集群，全局更新和单表更新都一直处于等待更新状态，日志中只有报错：
cannot find class java.lang.ClassNotFoundException: com.fr.plugin.db.json.core.JSONConnection
原因分析：
redis 脏数据导致。
解决方案：
方案一：升级工程
工程升级到 5.1.3 及以上版本即可。
方案二：清理 redis 脏数据
注：如果 Redis 中存储的有非常重要的数据，选择 flushall 方式时需注意。
cd /usr/redis/redis-5.0.4/src #访问redis根目录，根据实际情况修改
redis-cli -p 端口 -a 密码 #启动客户端
flushdb #方式一：清空当前redis数据库缓存
flushall #方式二：清空整个redis缓存
上一篇：集群组件出错优化
