DataBuff剑齿虎APM

简体中文

English

简体中文

English

常见问题 ​

安装、启动或使用中踩过的已知问题。Docker / K8s 日常操作见 Docker 运维、Kubernetes 运维。

Doris FE 启动失败：CgroupInfo.getMountPoint() NPE ​

现象 ​

ai-apm-doris-fe 起不来，日志里有：

text
Caused by: java.lang.NullPointerException: Cannot invoke "jdk.internal.platform.CgroupInfo.getMountPoint()" because "anyController" is null
    at java.base/jdk.internal.platform.cgroupv2.CgroupV2Subsystem.getInstance(CgroupV2Subsystem.java:81)

常见于 Ubuntu 24.04、较新内核（如 6.12+）、Docker 27/28、cgroup v2 环境。BDB JE 初始化时会读 JVM 的 OS/容器指标，这里炸掉后 FE 整进程退出。

原因 ​

这是 JDK 读 Linux cgroup v2 失败，不是 DataBuff 业务代码。官方镜像 apache/doris:fe-4.1.1（以及目前最新的 fe-4.1.3）自带 BiSheng OpenJDK 17.0.11，fe.conf 的 JAVA_OPTS_FOR_JDK_17 没有关掉容器探测。换到 fe-4.1.3 修不了——官方 issue #56784、#60536 是过期关闭，没有合进发版。

处理 ​

在 JAVA_OPTS_FOR_JDK_17 开头加上 -XX:-UseContainerSupport。关掉容器探测后，JVM 不再按 cgroup 自动算堆，必须继续保留 compose / manifest 里已有的 -Xmx patch（Docker 安装默认 1200m，本地开发 compose 为 512m）。

Docker：改 docker-compose.yml 里 FE 的 command（在改堆内存的 sed 之后、exec bash init_fe.sh 之前）：

yaml
    command:
      - |
        sed -i 's/-Xmx8192m/-Xmx1200m/g' /opt/apache-doris/fe/conf/fe.conf
        sed -i 's/-Xms8192m/-Xms1200m/g' /opt/apache-doris/fe/conf/fe.conf
        grep -q -- '-XX:-UseContainerSupport' /opt/apache-doris/fe/conf/fe.conf \
          || sed -i 's/^JAVA_OPTS_FOR_JDK_17="/JAVA_OPTS_FOR_JDK_17="-XX:-UseContainerSupport /' /opt/apache-doris/fe/conf/fe.conf
        exec bash init_fe.sh

本地开发 deploy/local/docker-compose.yml 同样加这两行 grep / sed，堆内存仍用原来的 512m。

已经在跑的环境：直接改容器内配置后重启：

bash
docker exec ai-apm-doris-fe grep -q -- '-XX:-UseContainerSupport' \
  /opt/apache-doris/fe/conf/fe.conf \
  || docker exec ai-apm-doris-fe sed -i \
    's/^JAVA_OPTS_FOR_JDK_17="/JAVA_OPTS_FOR_JDK_17="-XX:-UseContainerSupport /' \
    /opt/apache-doris/fe/conf/fe.conf
docker restart ai-apm-doris-fe

上述命令可重复执行；若 fe.conf 已包含该参数，不会再次追加。

K8s： deploy/k8s/manifests/doris.yaml 里 FE 容器启动脚本，同样在改 -Xmx 之后、exec bash init_fe.sh 之前加上面那两行 grep / sed。

验证 ​

bash
docker logs ai-apm-doris-fe 2>&1 | tail -50
# 不应再出现 CgroupInfo.getMountPoint / anyController is null

docker exec ai-apm-doris-fe grep JAVA_OPTS_FOR_JDK_17 /opt/apache-doris/fe/conf/fe.conf
# 应包含 -XX:-UseContainerSupport

FE 健康后，8030 / 9030 可探活，ingest / web 才能起来。

模型连通性：curl 能通，「测试连通性」报 Model request timeout after PT30S ​

现象 ​

AI 平台的模型 Provider 配置里，同样的 Base URL 与 API Key：宿主机上 curl 请求 <Base-URL>/chat/completions 秒回 200，DataBuff 里点「测试连通性」约 30 秒后报 Model request timeout after PT30S（真实对话同样超时）。内网部署（vLLM、经网关 / WAF 代理的模型服务）场景居多。

原因 ​

「测试连通性」由 ai-apm-web 容器内的 AgentScope SDK 发起，与宿主机 curl 有两点关键差异：

  • 运行环境：测试跑在容器（自定义 bridge 网络）里。内网域名若靠宿主机 /etc/hosts 或内网 DNS 解析，容器读不到宿主机的 /etc/hosts；宿主机用 systemd-resolved（/etc/resolv.conf 指向 127.0.0.53）时容器同样解析不了。
  • HTTP 版本：AgentScope 传输层默认走 HTTP/2（TLS ALPN 协商）；老版本 curl 不支持 h2、实际走 HTTP/1.1。网关 / WAF 对 JDK 的 h2 请求"建连但不回包"时，请求会静默挂起。

PT30S 是探测对整个请求（建连 + TLS + 响应）的总超时。DNS 解析失败、证书不受信、端口拒绝都会在几秒内立即报错；等满 30 秒说明请求被静默挂起，基本只有上述两类原因。

处理 ​

第一步：强制 HTTP/1.1（成本最低，优先尝试）。 在 compose 的 ai-apm-web 服务 environment 块加一行（Docker 安装版 deploy/docker/docker-compose.yml、本地开发 deploy/local/docker-compose.yml）：

yaml
      APM_AGENT_LLM_FORCE_HTTP11: "true"

该变量映射到配置项 apm.agent.llm-force-http11（发行版各 application.yml 已带好占位符，无需改代码），启动后「测试连通性」与真实对话的 LLM 请求全部改走 HTTP/1.1。改完必须重建容器——环境变量变更不会被 docker restart 拾取：

bash
docker compose up -d --force-recreate ai-apm-web
docker logs ai-apm-web 2>&1 | grep -i "HTTP/1.1"
# 应看到：AgentScope LLM HTTP transport forced to HTTP/1.1 (apm.agent.llm-force-http11=true)

第二步：开关生效后仍超时，排查容器到网关的网络路径（域名 / Key / 模型 ID 换成实际值）：

bash
docker exec ai-apm-web getent hosts llm.example.internal   # 解析到的 IP 是否与宿主机一致
docker exec ai-apm-web timeout 5 bash -c 'exec 3<>/dev/tcp/llm.example.internal/443' && echo TCP-OK
docker exec ai-apm-web curl -sS -m 10 \
  -H "Authorization: Bearer <API-Key>" -H 'Content-Type: application/json' \
  -d '{"model":"<模型ID>","messages":[{"role":"user","content":"ping"}]}' \
  https://llm.example.internal/v1/chat/completions

容器内 curl 也超时 → 网络问题：在 compose 里给 ai-apm-web 加 extra_hosts（内网域名到 IP 的映射），或让容器使用可用的内网 DNS。容器内 curl 秒回、只有平台超时 → 回到第一步，确认 HTTP/1.1 开关已生效。

验证 ​

「测试连通性」提示连接成功。若报错是其他文案，可直接对号入座：

  • UnknownHostException：容器 DNS 问题，同第二步排查；
  • PKIX path building failed：网关证书不在 JDK 信任库（curl 用操作系统证书库，Java 用自带的 cacerts），需将网关证书链导入容器 JDK 的 cacerts；
  • 404 ... model not found：模型 ID 与服务端不一致。vLLM 区分大小写，服务端是 deepseek-v4 就不能填 DeepSeek-V4，以 /v1/models 返回为准；
  • 401：API Key 错误。

相关文档 ​