数据节点丢包

创建时间:2024-11-01 最近修改时间:2024-11-01

#1. 数据节点丢包

类型 指标集 指标
队列丢包 ingester.queue metrics.overwritten
流日志采样丢包 ingester.decoder metrics.drop_count
数据写入丢包 ingester.ckwriter metrics.write_failed_count
收到无效数据丢包 ingester.recviver metrics.invalid
  • 告警触发条件:数据节点丢包
  • 处理方法:
    • 点击告警事件中的数据节点主机名,或访问系统-数据节点列表页面并点击数据节点名字
      • 查看数据节点最近24小时系统CPU、内存、磁盘负载曲线和丢包曲线
      • 判断是否由于系统负载高导致的丢包
        • 若是则需要进行数据节点扩容
    • 通过调整数据节点 Ingester 模块配置参数,增大处理能力避免处理丢包。 具体配置项见队列丢包处理流日志采样丢包处理
      • Deepflow-Server 的 Ingester 配置项位置:/usr/local/deepflow/templates/values.yaml 文件的 deepflow->configmap->server.yaml->ingester
        • 配置项参考: https://github.com/deepflowio/deepflow/blob/[v6.1|v6.2|vx.x]/server/server.yaml
      • 修改配置后需执行/usr/local/deepflow/bin/deepflow-deploy -u生效。
    • 队列丢包处理
      • 查看http://<DeepFlow>/grafana-server/ Dashboard: DeepFlow System/DeepFlow Server - Ingester Pannel: Queue(+pending/-drop) 相应队列负载
        • 若是队列处理能力不足,可以通过修改配置文件增加相应队列长度(当偶尔丢包或间隔丢包时)或队列数量(当持续丢包时)解决
队列名 队列数量配置 队列长度配置 队列说明
1-recv-unmarshall unmarshall-queue-count unmarshall-queue-size 指标数据处理队列
1-receive-to-decode-l4/l7 flow-log-decoder-queue-count flow-log-decoder-queue-size 流日志处理队列
1-receive-to-decode-telegraf/prometheus/deepflow_stats ext-metrics-decoder-queue-count ext-metrics-decoder-queue-size 其他数据处理队列
1-receive-to-decode-profile profile-decoder-queue-count profile-decoder-queue-size 性能分析数据处理队列
1-receive-to-decode-proc_event perf-event-decoder-queue-count perf-event-decoder-queue-size IO等事件的处理队列
1-receive-to-decode-raw_pcap pcap-queue-count pcap-queue-size pcap包处理队列
flow_metrics- 前缀 metrics-ck-writer->queue-count metrics-ck-writer->queue-size 指标数据写入队列
flow_log-l7_packet 前缀 pcap-ck-writer->queue-count pcap-ck-writer->queue-size pcap数据写入队列
flow_log- 前缀除flow_log-l7_packet flowlog-ck-writer->queue-count flowlog-ck-writer->queue-size 流日志数据写入队列
ext_metrics- 前缀 ext_metrics-ck-writer->queue-count ext_metrics-ck-writer->queue-size 其他数据写入队列
profile- 前缀 profile-ck-writer->queue-count profile-ck-writer->queue-size 性能分析数据写入队列
  • 流日志采样丢包处理
    • 查看http://<DeepFlow>/grafana-server/ Dashboard: DeepFlow System/DeepFlow Server - Ingester Pannel: flow log(throttle-drop) 相应队列丢包量
    • 默认 l4/l7 流日志处理能力都限制为50000条/秒,避免占用过量系统资源
      • 若系统资源(CPU、内存、磁盘)充足,可以修改配置(throttle)增大处理能力,避免丢包
  • 数据写入丢包处理
    • 登录告警事件中的数据节点主机
    • 查看TSDB服务是否正常: 执行kubectl -n deepflow get pod | grep clickhouse看服务状态是否正常
      • 若服务状态异常,请联系DeepFlow技术支持人员。
    • 查看是否有足够的磁盘剩余空间: 执行df -h 看是否磁盘空间占满导致写入失败.
      • 若磁盘剩余空间不足,清理磁盘空间或扩容磁盘。
    • 查看 DeepFlow-Server 的日志,查找关键字write block failed ,可以看到写入失败的原因
    • 根据错误信息进行处理
  • 收到无效数据丢包
    • 查看 DeepFlow-Server 的日志,查找关键字TCP client,可以获取无效数据发送者的 IP 地址
      • 若是 DeepFlow-Agent 发送的,则确认 DeepFlow-Agent 和 DeepFlow-Server 模块版本是否配套
      • 若是非 DeepFlow-Agent IP 地址,则需要禁止该 IP 地址发送数据到数据节点的监听端口(默认:30033)
        • 也可提高该告警阈值,屏蔽此类 IP 发送数据产生的告警

#2. 数据节点负载高

  • 告警触发条件:数据节点负载5分钟持续达到限制的70%
  • 计算方法:CentOS系统中通过top命令查询到的最近1分钟load值与服务器CPU逻辑核数的比值
  • 处理方法:
    • 点击告警事件中的数据节点主机名,或访问系统-数据节点列表页面并点击数据节点名字
    • 查看数据节点最近24小时系统负载曲线
    • 若超过5%的时间达到服务器CPU逻辑核数量的70%,则需要进行服务器扩容
    • 否则,查看同时是否有其他告警事件,解决其他告警即可

#3. 数据节点失联

  • 告警触发条件:主控制器无法通过RESTful API连通故障控制器
  • 计算方法:
    • 主控制周期调用http://{host}:20014/v1/health/探测,若收到回复则认为正常
    • 超过一分钟从未收到回复信息,则认为异常
    • 主控制器每隔3秒扫描一次所有控制器和数据节点
  • 处理方法:
    • 运维人员收到告警后应当尽快通过带外的方式登录数据节点进行恢复
点击查看

数据节点失联时,采集器自动切换发送数据的数据节点,默认切换时间为1分钟(由系统-采集器-配置页面的最长同步间隔决定)。最坏情况下可能丢失4分钟的故障数据节点负责接收的采集器数据。

点击查看

若有控制器或数据节点失联,控制器探测的时间间隔可能由于等待超时大于3秒。

提示

默认情况下通过22端口探测SSH服务,若部署环境使用其他SSH端口需要修改/etc/manager.yaml中的check_port并重启manager进程。

#4. 数据节点磁盘空间不足

  • 告警触发条件:数据节点任何一块磁盘使用空间大于70%
  • 处理方法:
    • 点击告警事件中的数据节点主机名,或访问系统-数据节点列表页面并点击数据节点名字,查看数据节点最近24小时磁盘用量曲线,评估是否需要进行磁盘或服务器扩容
    • 访问系统-数据节点下的存储配置页,查看不同功能对磁盘的消耗,评估是否需要减少功能数据的保留时长