Docker环境下InfluxDB 2.0 Python客户端运行数小时后静默停止写入的问题排查求助

看起来你遇到的这个静默停写问题确实挺棘手的——服务还在正常接收通知数据，没有任何报错日志，就是写不进InfluxDB，重启客户端容器就立刻恢复，这大概率是长连接资源泄漏、线程挂起或者容器资源耗尽类的问题。结合你的配置、代码和已做的尝试，我来梳理几个最可能的原因，以及对应的排查和解决思路：

一、最可能的原因：客户端资源泄漏导致容器资源耗尽 #

问题分析 #

你的定期重连逻辑看似每小时清理一次客户端，但很可能存在资源释放不彻底的情况：

• InfluxDB Python客户端的write_api.close()或client.close()在某些版本（尤其是v1.20.x之前）存在bug，无法彻底释放底层的Socket连接，长时间运行后会耗尽Docker容器的文件描述符（Socket属于文件描述符的一种）。
• Docker容器默认的文件描述符上限并不高（通常是1024或4096），一旦耗尽，新的写请求无法创建连接，但同步写模式下客户端可能会吞掉资源耗尽的异常，导致静默失败。
• 你的重连逻辑没有加线程锁，可能出现「主线程正在写数据，后台线程同时销毁客户端」的竞态场景，导致部分连接资源被异常占用无法释放。

排查&解决思路 #

1. 监控容器资源使用情况：
   在停写问题出现后，进入influx-adapter-api容器执行以下命令：

   # 查看进程的文件描述符数量
   lsof -p $(pgrep python) | grep IPv4 | wc -l
   # 查看容器的文件描述符上限
   cat /proc/$(pgrep python)/limits | grep "Max open files"
   

   如果连接数持续增长到接近上限，那就是资源耗尽的问题。

2. 调整Docker容器的资源上限：
   在docker-compose.yml的influx-adapter-api服务中添加ulimits配置，调高文件描述符上限：

   influx-adapter-api:
     image: influx-adapter-api:latest
     restart: unless-stopped
     expose:
       - "8008"
     volumes:
       - setting:/influx-adapter-api
     ulimits:
       nofile:
         soft: 65535
         hard: 65535
     environment:
       - PYTHONUNBUFFERED=1  # 确保日志实时输出，避免缓冲吞日志
   

3. 修复重连逻辑的线程安全：
   给客户端操作加线程锁，避免竞态条件导致的资源泄漏：

   from influxdb_client import InfluxDBClient
   from influxdb_client.client.write_api import SYNCHRONOUS
   from datetime import datetime
   import time, threading, logging
   
   class InfluxWriter:
       def __init__(self, url, org, bucket, username, password):
           self.url = url
           self.org = org
           self.bucket = bucket
           self.username = username
           self.password = password
           self.lock = threading.Lock()  # 新增线程锁
           self.client = InfluxDBClient(
               url=url,
               username=username,
               password=password,
               org=org,
               timeout=30_000  # 新增30秒超时，避免线程挂起
           )
           self.write_api = self.client.write_api(write_options=SYNCHRONOUS)
           threading.Thread(target=self._periodic_reconnect, daemon=True).start()
   
       def _periodic_reconnect(self):
           while True:
               time.sleep(3600)
               self._reconnect()
   
       def _reconnect(self):
           with self.lock:  # 重连时加锁
               try:
                   self.write_api.close()
                   self.client.close()
               except Exception as e:
                   logging.warning(f"Reconnect cleanup warning: {str(e)}")
               # 主动置空旧对象，触发GC回收
               self.write_api = None
               self.client = None
               # 重建客户端
               self.client = InfluxDBClient(
                   url=self.url,
                   username=self.username,
                   password=self.password,
                   org=self.org,
                   timeout=30_000
               )
               self.write_api = self.client.write_api(write_options=SYNCHRONOUS)
   
       def write_notification_to_influxdb(self, measurement, fields, timestamp):
           data = {"measurement": measurement, "fields": fields, "time": timestamp}
           with self.lock:  # 写操作加锁
               try:
                   self.write_api.write(bucket=self.bucket, record=data)
                   self.write_api.flush()
               except Exception as e:
                   logging.error(f"Write error: {str(e)}", exc_info=True)  # 新增栈轨迹日志
                   if "session not found" in str(e):
                       self._reconnect()
                       # 重试一次写操作
                       try:
                           self.write_api.write(bucket=self.bucket, record=data)
                           self.write_api.flush()
                       except Exception as retry_e:
                           logging.error(f"Retry write failed: {str(retry_e)}", exc_info=True)
   

二、次可能的原因：线程挂起/死锁 #

问题分析 #

你的代码中存在两个风险点：

• 客户端初始化时没有设置超时参数：同步写模式下，如果InfluxDB端的连接意外中断（比如网络波动），客户端线程会一直阻塞在IO操作上，不会抛出异常，导致这个线程挂起，若所有处理线程都挂起，就会出现静默停写。
• 后台重连线程是守护线程，若主线程出现隐性死锁（比如写操作和重连操作的资源竞态），也会导致写请求无法执行。

解决思路 #

1. 必须给客户端加超时参数：
   如上面的代码修改所示，初始化InfluxDBClient时添加timeout=30_000（30秒超时），确保IO操作不会无限阻塞。
2. 用线程栈分析工具排查挂起：
   安装py-spy工具到客户端容器，在停写时采样线程栈：

   # 容器内安装py-spy
   pip install py-spy
   # 采样线程栈
   py-spy dump -p $(pgrep python)
   

   如果看到大量线程阻塞在requests或urllib3的IO操作上，就是超时参数没生效的问题。

三、Docker网络隐性问题 #

问题分析 #

Docker默认的bridge网络偶尔会出现半开连接的问题：网络波动导致InfluxDB和客户端之间的连接断了，但客户端没有检测到（缺少心跳机制），还在往死连接里写数据，同步模式下不会触发异常。

解决思路 #

1. 给客户端配置HTTP心跳：
   初始化客户端时开启Keep-Alive心跳，或者自定义WriteOptions添加重试机制：

   from influxdb_client.client.write_api import WriteOptions
   
   # 自定义同步写配置，添加重试和超时
   write_options = WriteOptions(
       write_type=SYNCHRONOUS,
       timeout=10_000,
       retry_interval=5000,
       max_retries=3
   )
   self.write_api = self.client.write_api(write_options=write_options)
   

2. 使用自定义Docker网络：
   在docker-compose.yml中创建自定义网络，让两个服务加入该网络，避免默认bridge网络的转发问题：

   networks:
     influx-network:
       driver: bridge
   
   services:
     influxdb:
       # ... 原有配置
       networks:
         - influx-network
     influx-adapter-api:
       # ... 原有配置
       networks:
         - influx-network
   

四、官方已知问题&推荐方案 #

1. 升级InfluxDB Python客户端版本：
   旧版本（v1.20.x之前）的客户端存在明确的连接泄漏bug，务必升级到最新稳定版：
   在客户端容器的requirements.txt中指定：

   influxdb-client>=1.39.0
   

2. 优先使用异步写API：
   官方推荐长驻服务使用异步写API+连接池，比同步模式的资源管理更高效，内置重试和连接复用机制，能有效避免资源泄漏问题。你之前试过异步模式可能是配置不对，参考官方示例调整即可。
3. 不要用定期重连，改用异常触发重连：
   定期重连反而可能在正常连接时破坏会话，建议只在捕获到连接类异常（如session not found、连接超时）时再触发重连。

最后总结 #

优先从资源耗尽（文件描述符）和线程挂起入手排查：先恢复写操作的完整异常日志、给客户端加超时、给重连逻辑加锁、调整Docker的ulimits配置，同时升级客户端版本。如果问题仍存在，建议切换到官方推荐的异步写API，这是长驻写服务的更优解。

内容来源于stack exchange