启动中可能的异常

Kafka

• 异常原因：mkdir: cannot create directory '/bitnami/kafka/config': Permission denied
• 解决方法：确认clklog_init.sh脚本执行且成功。

Zookeeper

• 异常原因：mkdir: cannot create directory '/bitnami/zookeeper/data': Permission denied
• 解决方法：确认clklog_init.sh脚本执行且成功。

Redis

• 异常原因：无权限 (Permission denied)
• 解决方法：确认clklog_init.sh脚本执行且成功。

Mysql

• 异常原因：Fatal glibc error: CPU does not support x86-64-v2
• 解决方法：将docker-compose-clklog-XXX-base.yml编排文件中的mysql镜像地址改成registry.cn-shanghai.aliyuncs.com/clklog/mysql:8.4.0-oraclelinux8

Clickhouse

• 异常原因：clklog数据库及统计表创建失败
• 解决方法：
  • 检查clklog-init容器的状态是否正常。
  • 检查docker-compose-clklog-XXX.yml编排文件clklog-init节点INIT_MYSQL_DB配置项是否正确。

运行中可能的异常

clklog-receiver

• 接收不到数据

  • 检查客户端是否正常配置receiver数据接收地址。
  • 确认接收地址中的project是否已经在后台项目管理里注册。如果刚注册，过30秒后，再尝试提交数据。
  • 检查receiver-server.log是否有异常信息

提示

receiver接收的日志说明

• receiver接收的原始日志会以文本文件的形式，以项目编码为目录存储于clklog_dc_data/receiverlogs下。
• 日志文件store.log按天进行数据归档。
• 在实际运营中，可根据实际情况备份或删除receiver接收的原始日志文本文件。

注意

• 标准模式下，只要receiver能正常接收并将数据存储至receiverlogs中，则其他服务的异常停止不会造成数据丢失，查找并处理相关问题后，重启相关服务，系统会继续处理未入库的数据。
• 快速模式下，如果receiver能正常接收并将数据存储至receiverlogs中，但clickhouse数据库出现问题，重启相关服务，未入库的数据不会重新入库，只会存在于receiverlogs中。

clklog-processing

• 1. 内存溢出导致容器宕机

  • 删除2个processing容器(taskmanager和jobmananger)。
  • 调整编排文件docker-compose-clklog-full.yml中taskmanager节点taskmanager.memory.process.size的配置。
  • 重启容器。

• 2.异常：Could not acquire the minimum required resources

  • 删除2个processing容器(taskmanager和jobmananger)。
  • 重启容器。

• 3. 异常：Exceeded checkpoint tolerable failure threshold

  • 在processing的配置文件/clklog_dc_config/processing/config.properties增加配置flink.checkpoint.timeout=300000。
  • 删除2个processing容器。
  • 重启容器。

• 4. 处理慢

  • 调整processing的配置文件/clklog_dc_config/processing/config.properties中的flink.parallelism配置。
    • 注意：配置的值过大会增大内存消耗, 需要相应调整编排文件docker-compose-clklog-full.yml中taskmanager节点taskmanager.memory.process.size的配置。
  • 重启容器。

clklog-ui

• 1. 无法登录

  • 检查clklog-manage容器的状态及日志。

• 2. 所有前端页面报错502

  • 等待容器启动完成，大约3分钟。

• 3. 事件分析/数据统计的接口502【付费版】

  • 检查clickhouse数据库中里mysql_tbl_*相关表是否能正常访问，如果不能正常访问，则检查编排文件docker-compose-clklog-XXX.yml中clklog-init节点下的INIT_MYSQL_*的四个配置项，配置如果没有问题，先drop掉mysql_tbl_*相关表，然后重启clklog-init容器。

• 4. 前端页面没有数据

  检查容器内各个服务是否正常。

  • 1）容器内服务有异常，则查看出现出现时的容器日志，根据异常日志调整相关配置后重启容器。

  • 2）容器内各服务正常，但前端页面没有数据。

    • 可能的原因：定时计算任务间隔时长设置不合理。
    • 解决方法：调整编排文件docker-compose-clklog-XXX.yml中clklog-init的INIT_CALC_IN_ORDER_CRON项的定时任务的间隔时长配置。

    提示

    前端数据说明

    • 前端数据读取的是通过clklog-init服务定时计算生成的中间表的结果。
    • 定时计算的间隔时长取决于INIT_CALC_IN_ORDER_CRON的配置。
    • 间隔时长的设置需大于所有脚本执行总时长
      • 社区版
        • 总时长为开始执行area_detail_bydate到执行visitor_detail_bysession结束的时间差。
        • 如果数据库中没有看到visitor_detail_bysession的记录，先通过INIT_CALC_IN_ORDER_CRON把时间间隔调长。
      • 付费版
        • 总时长为开始执行area_detail_bydate到执行user_detail_byinfo结束的时间差。
        • 如果数据库中没有看到user_detail_byinfo的记录，先通过INIT_CALC_IN_ORDER_CRON把时间间隔调长。
    • 脚本执行时间可通过 docker logs <clklog-init容器ID> | grep <相应脚本名>命令进行查看相应脚本执行日志。

• 5.【系统设置-日志汇总】功能没有数据

  • 检查编排文件docker-compose-clklog-XXX.yml中clklog-init节点配置项CLKLOG_MANAGE_LOG_STORE_PATH是否配置正常，指向clklog-receiver的日志目录。

clklog-manage

• 容器启动失败，反复重启
  • 查看容器日志，查找重启原因，根据实际情况修改编排文件配置后，重启容器。
  • 没有明确报错信息的情况下可能是内存不足引起的，可尝试调大编排文件docker-compose-clklog-XXX.yml中clklog-manage节点的memory限制。

clklog-api

• 容器启动失败，反复重启
  • 查看容器日志，查找重启原因，根据实际情况修改编排文件配置后，重启容器。
  • 没有明确报错信息的情况下可能是内存不足引起的，可尝试调大编排文件docker-compose-clklog-XXX.yml中clklog-api节点的memory限制。

mysql

• 宕机
  • 查看容器日志，查找重启原因，根据实际情况修改编排文件配置后，重启容器。
  • 没有明确报错信息的情况下可能是内存不足引起的，可尝试调大编排文件docker-compose-clklog-XXX-base.yml中mysql节点的memory限制。

clickhouse

• 宕机
  • 查看容器日志，查找重启原因，根据实际情况修改编排文件配置后，重启容器。
  • 没有明确报错信息的情况下可能是内存不足引起的，可尝试调大编排文件docker-compose-clklog-XXX-base.yml中clickhouse节点memory限制。

redis

• 宕机
  • 查看容器日志，查找重启原因，根据实际情况修改编排文件配置后，重启容器。
  • 没有明确报错信息的情况下可能是内存不足引起的，可尝试调大编排文件docker-compose-clklog-XXX-base.yml中redis节点memory限制。

运维建议

Docker部署虽然简单快速，但由于Docker容器在运行过程中可能会出现很多不可预测的问题，也需要根据实际运营情况调整编排文件中的相关配置，为了有效监控Docker容器运行状态，建议使用一些常用的监控工具如Prometheus、Grafana和cAdvisor等对Docker容器进行监控，这样运维人员可以有效地监控容器使用情况，并设置报警机制，以便及时响应潜在的问题，以提高系统的可靠性，也为系统的持续运行提供了保障。