故障处理
企业版维护

采集器失联

创建时间：2024-11-01 最近修改时间：2025-10-24

#1. 采集器失联

告警触发条件：采集器被控制器标记为失联
计算方法：当控制器连续5个同步周期没有接收到采集器的同步消息时被认为是失联，同步周期为系统-采集器-配置中设置的最长同步间隔
处理方法：
- 在控制器上可进行的排查
  - 通过抓包确认采集器是否正常请求了控制器的TCP 20035（当打开TLS时为20135）端口
  - 若采集器在正常请求，打开系统-采集器-配置中的日志发送，并在控制器的/var/log/messages中确认采集器是否有WARN或ERR日志
- 登录采集器所在服务器进行排查
  - systemctl status trident确认进程是否在运行、及是否设置为开机自启动（enable）
  - 通过telnet确认是否可请求控制器的TCP 20035（当打开TLS时为20135）端口
  - 观察trident的CPU开销，确认是否由于cgroup或k8s配置导致CPU受限、进而导致请求控制器变慢

#2. 采集器丢包

deepflow_agent_collector.drop-before-window
- 原因：包延时大或聚合产生的额外延时大
- 处理：增大采集器高级配置 second-flow-extra-delay-second
deepflow_agent_collector.drop-inactive
- 原因：流量中的客户端和服务端 IP 均被判定为非活跃时出现，一般是由于子网和 IP 资源未覆盖流量中的 非 Internet IP 导致
- 处理：在流日志搜索栏中将 全路径 修改为 广域网 并输入 is_internet=是 的搜索条件，可查看这些流量的双端 IP 地址，并将非 Internet IP 录入到平台中
deepflow_agent_collect_sender.dropped
- 原因：采集器向数据节点发送统计、监控、日志等数据失败
- 处理：
  - 在控制器执行deepflow-ctl trisolaris.check --cip $ip --cmac $mac config | grep analyzer_ip检查配置的数据节点 IP 是否正确
  - 在控制器执行deepflow-agent-ctl -a $ip -p $port rpc --get config | grep analyzer_ip检查下发的数据节点 IP 是否正确
  - 在控制器执行deepflow-agent-ctl -a $ip -p $port rpc --get config | grep socket_type确认通信端口的类型，0 为 UDP，1 为 TCP
  - 在对应的数据节点上检查端口是否正常监听
    - deepflow-server: netstat -anp | grep 20033
  - 通信端口为 TCP 模式时在采集器上通过telnet确认是否能正常访问上述端口
  - 通信端口为 UDP 模式时在采集器上检查采集器日志中Socket send failed，可能由于网络突然中断导致
deepflow_agent_dispatcher.err
- 原因：采集网卡驱动问题
- 处理：采集器宿主机执行ifconfig $eth down; ifconfig $eth up
deepflow_agent_dispatcher.get_token_failed
- 原因：到达采集限速
- 处理：采集器配置提高采集包限速
deepflow_agent_dispatcher.invalid_packets
- 原因：网包长度小于 18 字节，也可能是隧道解析后的长度不足
- 处理：通过修改采集器配置中解封装隧道类型为空来避免
deepflow_agent_dispatcher.kernel_drops
- 原因：采集流量突发或处理性能不足
- 处理：
  - 采集器配置中：减少采集包长，提高 CPU 限制
  - 采集器高级配置中增大配置afpacket-blocks和afpacket-blocks-enabled
  - 使用 bild（仅专属类型采集器）
deepflow_agent_dispatcher.retired
- 原因：采集包时间回退
- 处理：采集器高级配置中减少配置afpacket-blocks和afpacket-blocks-enabled
deepflow_agent_ebpf_collector.kern_lost
- 原因：eBPF使用的perf buffer已满，导致kernel/eBPf数据丢失。
- 处理：
  - 在static_config -> ebpf中增加perf-pages-count的配置值。这个值默认值是128，取值范围[32, 8192]，可以按照512,1024,2048,4096,8192顺序逐渐加大，观察直到不再出现丢失报警为止。
  - 如果上面的方法未能解决，在static_config中关掉golang uprobe, 方法是golang: ""（配置成""）。这样golang的HTTP2数据就会由kernel probe获取而不是由用户态的probe获取，但是准确度不如uprobe的方式高（可能会存在一些HTTP2数据解析不出来）。
deepflow_agent_ebpf_collector.user_enqueue_lost
- 原因：用户态接收eBPF数据处理过慢或缓存过小。
- 处理：
  - 在static_config -> ebpf中增加ring-size的配置值，默认是65536，增加到131072。
  - 如果上面方法未能解决，可以在static_config -> ebpf中增加thread-num，这个数值是工作线程的线程数量，可以逐渐增加并观察是否解决（但不要超过采集器所在机器的CPU数量）。
deepflow_agent_flow_aggr.drop-before-window
- 原因：包延迟比较大，超出聚合窗口
- 处理：增大采集器高级配置中packet-delay
deepflow_agent_flow_aggr.drop-in-throttle
- 原因：超过采集器限速
- 处理：增加采集器配置流日志采集速率
deepflow_agent_flow_map.drop_by_capacity
- 原因：采集的流并发超过限制
- 处理：增大采集器高级配置中flow-count-limit
deepflow_agent_flow_map.drop_by_window
- 原因：包延迟比较大，超出聚合窗口
- 处理：增大采集器高级配置中packet-delay
deepflow_agent_l7_session_aggr.throttle-drop
- 原因：超过采集器限速
- 处理：增加采集器配置应用日志采集速率
deepflow_agent_quadruple_generator.drop-before-window
- 原因：包延时大或聚合产生的额外延时大
- 处理：增大采集器高级配置 second-flow-extra-delay-second
deepflow_agent_queue.overwritten
- 原因：采集器队列丢包，上游突发过多或下游处理性能不足
- 处理：增大采集器高级配置中相应队列长度

module	配置
1-tagged-flow-to-quadruple-generator	flow-queue-size
1-tagged-flow-to-app-protocol-logs	flow-queue-size
2-second-flow-to-minute-aggrer	flow: flow-aggr-queue-size
2-flow-with-meter-to-second-collector	quadruple-queue-size
2-flow-with-meter-to-minute-collector	quadruple-queue-size
2-flow-with-meter-to-l7-second-collector	quadruple-queue-size
2-flow-with-meter-to-l7-minute-collector	quadruple-queue-size
2-protolog-to-collector-sender	flow-sender-queue-size
3-flowlog-to-collector-sender	flow-sender-queue-size
3-doc-to-collector-sender	collect-sender-queue-size
1-proc-event-to-sender	external-metrics-sender-queue-size
1-otel-to-sender	external-metrics-sender-queue-size
1-prometheus-to-sender	external-metrics-sender-queue-size
1-telegraf-to-sender	external-metrics-sender-queue-size
1-profile-to-sender	external-metrics-sender-queue-size
1-compressed-otel-to-sender	external-metrics-sender-queue-size

以下几个仅在专属服务器类型（ANALYZER模式）时出现

module	配置
0.1-raw-packet-to-flow-generator	analyzer-queue-size
0.2-packet-to-additional-pipeline	analyzer-queue-size

以下几个仅在闭源版本出现

module	配置
1-mini-meta-packet-to-pcap-handler	pcap: queue-size
2-pcap-batch-to-sender	pcap: queue-size
1-packet-sequence-block-to-parser	packet-sequence-queue-size, packet-sequence-queue-count
2-packet-sequence-block-to-sender	packet-sequence-queue-size, packet-sequence-queue-count

#3. 采集器异常

告警触发条件：采集器状态异常

错误码	含义
`DISK_NOT_ENOUGH`	自检失败：日志所在磁盘剩余空间不足100MB
`MEM_NOT_ENOUGH`	自检失败：可用内存不足
`COREFILE_TOO_MANY`	自检失败：Coredump文件过多
`NPB_FUSE`	分发熔断
`NPB_BPS_THRESHOLD_EXCEEDED`	分发流量达到限速
`NPB_NO_GW_ARP`	到分发点的网关ARP无法找到
`RX_PPS_THRESHOLD_EXCEEDED`	采集包速率达到限速
`ANALYZER_NO_GW_ARP`	到数据节点的网关ARP无法找到
`INVALID_CONFIGURATION`	控制器下发的配置信息校验不通过
`THREAD_THRESHOLD_EXCEEDED`	采集器线程数超限
`PROCESS_THRESHOLD_EXCEEDED`	采集器进程数超限
`TOO_MANY_POLICIES`	采集器编译生成的分发和PCAP策略数量超限
`FREE_MEM_EXCEEDED`	空闲内存超限
`LOG_FILE_EXCEEDED`	日志文件大小超限
`CONTROLLER_SOCKET_ERROR`	控制SOCKET错误
`ANALYZER_SOCKET_ERROR`	数据SOCKET错误
`NPB_SOCKET_ERROR`	分发SOCKET错误
`INTEGRATION_SOCKET_ERROR`	集成SOCKET错误
`CGROUPS_CONFIG_ERROR`	CGROUPS配置错误
`SYSTEM_LOAD_CIRCUIT_BREAKER`	系统负载超限触发熔断
`DATA_BPS_THRESHOLD_EXCEEDED`	数据流量达到限速

`NORMEPTION_LICENSE_NOT_ENGOUTH`	采集器授权个数不足
`VTAP_EXCEPTION_ALLOC_ANALYZER_FAILED`	分配数据节点失败
`VTAP_EXCEPTION_ALLOC_CONTROLLER_FAILED`	分配控制器失败

#3.1 自检失败：日志所在磁盘剩余空间不足100MB

确认日志所在磁盘空间是否充足，若默认日志目录如法扩容，可修改trident.yaml中的log-level。

#3.2 自检失败：可用内存不足

使用free -m确认Trident运行环境的内存是否充足，若内存充足可再使用cat /proc/meminfo | grep MemAvailable确认可用内存是否充足。

如果出现free显示的内存充足但MemAvailable不够的情况，检查sysctl -A 2>&1 | grep min_free_kbytes值是否设置过大，可考虑缩小该值。

#3.3 分发熔断

前往Trident运行环境，使用ip r get $分发点IP确认分发的出接口，并查看该网口的流量是否过大，根据情况适当调高熔断阈值。

#3.4 分发流量达到限速

前往系统-采集器-详情页查看分发流量速率曲线`，通过调高分发流量限速或精细化分发策略解除告警。

#3.5 到分发点的网关ARP无法找到

前往Trident运行环境，使用arping命令确认是否能获取到网关的ARP。

#3.6 采集包速率达到限速

前往系统-采集器-详情页查看采集流量速率曲线`，通过调高采集流量限速解除告警。

#3.7 到数据节点的网关ARP无法找到

前往Trident运行环境，使用arping命令确认是否能获取到网关的ARP。

#3.8 控制器下发的配置信息校验不通过

控制器下发了非法配置，具体配置错误信息请查看采集器日志。

#3.9 采集器线程数超限

采集器进程内的线程数超过限制，可能是采集器运行环境中的网卡或网络命名空间数量过多导致。线程数量的多少仅影响采集器进程本身。线程数的上限可通过系统-采集器-配置页面进行调整。

#3.10 采集器进程数超限

采集器进程数量超过限制，可能由于部署问题导致一个服务器上启动了多个采集器，也可能是有其他 trident 或 deepflow-agent 同名的进程运行在该服务器上。进程数的上限可通过系统-采集器-配置页面进行调整。

#3.11 采集器编译生成的分发和PCAP策略数量超限

分发和PCAP策略过多，或者过于零碎，若采集器发现基于这些策略编译后生成的规则有可能占用过多的内存（使得采集器的内存消耗超过允许的最大值），则会上报此异常。需要检查策略配置是否能够精简、合并，例如端口号的限制是否可去掉、IP 列表是否可合并等。另外也可通过系统-采集器-配置页面增大采集器的内存上限来绕过此问题。

#3.12 空闲内存超限

采集器运行环境的系统空闲内存比例超过限制，一般情况下可能由于系统存在 Cache 内存未及时释放，也可能是其他进程消耗了过多的内存。系统空闲内存的上限可通过系统-采集器-配置页面进行调整。

#3.13 日志文件大小超限

采集器生成的日志文件大小超过限制，需要检查是否存在采集器日志大量刷屏的情况。文件大小的上限可通过系统-采集器-配置页面进行调整。

#3.14 控制SOCKET错误

采集器与控制器之间通信的 gRPC Socket 有异常，依次检查采集器、控制器 deepflow-server 进程的日志查明异常原因。

#3.15 数据SOCKET错误

采集器与数据节点之间通信的 Socket 有异常，依次检查采集器、数据节点 deepflow-server 进程的日志查明异常原因。

#3.16 分发SOCKET错误

采集器与分发隧道端点之间通信的 Socket 有异常，检查采集器日志查明异常原因。

#3.17 集成SOCKET错误

采集器接收第三方数据（Prometheus、Telegraf、OpenTelemetry 等）的 Socket 有异常，检查采集器日志查明异常原因。

#3.18 CGROUPS配置错误

采集器配置 cgroups 出现问题，可能是由于主机未安装启用 cgroups，出现此异常时，并不影响 deepflow-agent 运行，deepflow-agent 会用定时检查 cpu 和内存的方式代替 cgroups 限制其资源（定时检查时间间隔默认为 10s，可修改采集器配置的 static_config 中的 guard-interval 配置为其他的时间间隔）。可在主机检查安装并启用 cgroups 以达到更好的资源限制效果。

#3.19 采集器授权个数不足

采集器授权数量不足，请检查系统-授权管理页面确认有足够的软件授权。

#3.20 分配数据节点失败

前往系统-控制器-列表页，检查采集器所在可用区是否有从控制器，且状态正常。如果没有的话，需要调整从控制器对应的区域和可用区，使得采集器所在可用区有从控制器。
前往系统-数据节点-列表页，检查采集器所在可用区的数据节点的关联采集器数量，是否已经达到最大值。如果达到最大值，需要调整阈值（资源满足的情况下）或者增加数据节点。

#3.21 分配控制器失败

前往系统-控制器-列表页，检查采集器所在可用区是否有从控制器，且状态正常。如果没有的话，需要调整从控制器对应的区域和可用区，使得采集器所在可用区有从控制器。
前往系统-控制器-列表页，检查采集器所在可用区的控制器的关联采集器数量，是否已经达到最大值。如果达到最大值，需要调整阈值（资源满足的情况下）或者增加控制器。

#4. 采集器CPU超限

告警触发条件：采集器CPU消耗5分钟持续达到限制的70%
计算方法：CPU限制见系统-采集器-配置
处理方法：此告警极少触发，若流量过大需要视情况增大CPU限制

#5. 采集器内存超限

告警触发条件：采集器内存消耗5分钟持续达到限制的70%
计算方法：内存限制见系统-采集器-配置
处理方法：查看系统-采集器-列表点击采集器名进入详情页，根据内存消耗曲线和流量曲线适当调高内存限制

#6. 进程启动

告警触发条件：采集器进程启动
处理方法：
- 服务器可登录：查看服务器上/var/log/trident/trident.log日志文件，搜索WARN或ERR确定重启原因。
- 不可登录操作系统的采集器：确认系统-采集器-配置中的日志发送是否打开，若已打开可通过若可通过页面上的系统-采集器-列表中点击某个采集器查看日志。