nebula 2.0 监控接口无数据

  • nebula 版本: 2.0 (docker 2.0镜像)
  • 部署方式: docker 集群部署. (通过docker compose 部署, 三台机器, 每台机器上一个 graphd/meta/strorage 容器)
  • 是否为线上版本:Y
  • 硬件信息
    • 磁盘 SSD
    • 72核 CPU, 384G 内存

问题描述

  1. 服务启动一段时间后, 监控数据丢失, 请求监控接口无数据返回.
  2. 当前场景是通过 exporter 导出数据到 prometheus, exporter 无数据.

场景复现
无法必现. 最近两次都是启动后约10天左右, 开始丢监控数据.

一些数据

# 直接请求接口
curl -G http://nebula02:19669/stats
curl: (52) Empty reply from server

# curl 请求总数, 有很多 curl 进程
ps -ef | grep http://nebula02:19669/status | wc -l
2504

日志: 没有看到合适的, 可以看下日志列表需要那个我单发出来

能先确认为什么会有那么多的 curl 进程来拿 metrics 的数据吗?如果使用 nebula-stats-exporter 获取 metrics,不会启动 curl 来获取。

直接请求接口时返回空结果,这是不正确的,可以去 graphd 的日志里面查看有没有类似:

Web service GetStatsHandler got error: 

的错误日志,看看有什么错误信息。

1 个赞

搜索关键字: GetStatsHandler
graph.error 日志里没有搜索到相关字段.
20 号监控没数据的, 然后搜索了下 19-21 的 info 日志也没搜到.

对了, 还有一个现象, 就是一旦出现这种情况, docker 容器就无法正常的重启了.
执行: docke-compose restart, 返回 `nixHTTPConnectionPool(host=‘localhost’, port=None): Read timed out.

盲猜是僵尸进程引起的 :rofl: :rofl:

$ docker inspect -f "{{ .State.Pid }}" nebula_graphd_1
7491
$ ps -ef|grep 7491
root      7491  7403  7 Jun11 ?        1-02:03:09 /usr/local/nebula/bin/nebula-graphd --flagfile=/usr/local/nebula/etc/nebula-graphd.conf --daemonize=false --meta_server_addrs=nebula02:9559,nebula03:9559,nebula04:9559 --port=9669 --ws_ip=nebula02 --ws_http_port=19669 --log_dir=/logs --v=0 --minloglevel=0 --enable_authorize=true
wuzhens+ 16330 35414  0 11:50 pts/1    00:00:00 grep --color=auto 7491
$ ps -ef|grep nebula02:19669|wc -l
2504
$ ps -ef|grep 7403|wc -l
2507
$ ps -ef|grep nebula02:19669
root     73174  7403  0 Jun21 ?        00:00:06 curl -sf http://nebula02:19669/status
root     73181  7403  0 Jun20 ?        00:00:06 curl -sf http://nebula02:19669/status
root     73199  7403  0 Jun20 ?        00:00:06 curl -sf http://nebula02:19669/status
...

curl 是容器内部请求的.

ps -ef 统计 curl 进程的触发时间
14号: 281
15号: 251
20号: 712
21号: 1259
平均唤醒时间都较短, 10s 以内

上面的 curl 进程应该是 healthcheck 导致的,你可以确认 docker 相关的配置是否是 10s 检查一次。

healthcheck 接口是 status
metrics 接口是 stats

根据上述另一现象,docker 容器无法正常启动,可以追踪一下 docker 有无相关日志和 dmsg,这个问题应该是 docker 容器进程出问题导致的 metrics 获取不正确。

针对你的部署方式有点疑问?既然是容器化集群部署,为啥使用的是 docker-compose,而不是 docker-swarm? docker-compose 提供的配置只是用来做单机部署的。

每台机器上使用 docker-compose 部署, 然后组的集群. 因为后期要迁移到 K8s, 所以目前先这么弄了.

另外, 健康检查配置如下, 按道理讲没啥问题

healthcheck:
      test: ["CMD", "curl", "-sf", "http://nebula02:19669/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

exporter 里已经对status接口做了调用,目的就是健康检查,这部分配置可以省略掉了

方便贴出你的三份 docker-compose.yaml 的配置吗?为方便起见,个人还是更建议使用 swarm 的方式部署,目前还不清楚你的三份 compose 的配置如何使用的同一个 network 保证联通?

这里有份 docker stack 的配置文件,可供你们来参考。当然以后上 k8s 集群了就不用这些步骤了,因为现在有提供 nebula-operator 可以做很多自动运维的工作。

version: '3.4'
services:
  metad0:
    image: vesoft/nebula-metad:v2.0.0
    environment:
      USER: root
      TZ:   "${TZ}"
    command:
      - --meta_server_addrs={{nebula02}}:9559,{{nebula03}}:9559,{{nebula04}}:9559
      - --local_ip={{nebula02}}
      - --ws_ip={{nebula02}}
      - --port=9559
      - --ws_http_port=19559
      - --data_path=/data/meta
      - --log_dir=/logs
      - --v=0
      - --minloglevel=0
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://{{nebula02}}:19559/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - 9559
      - 19559
      - 19560
    volumes:
      - ./data/meta0:/data/meta
      - ./logs/meta0:/logs
    restart: on-failure
    network_mode: host
    cap_add:
      - SYS_PTRACE

  storaged0:
    image: vesoft/nebula-storaged:v2.0.0
    environment:
      USER: root
      TZ:   "${TZ}"
    command:
      - --meta_server_addrs={{nebula02}}:9559,{{nebula03}}:9559,{{nebula04}}:9559
      - --local_ip={{nebula02}}
      - --ws_ip={{nebula02}}
      - --port=9779
      - --ws_http_port=19779
      - --data_path=/data/storage
      - --log_dir=/logs
      - --v=0
      - --minloglevel=0
    depends_on:
      - metad0
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://{{nebula02}}:19779/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - 9779
      - 19779
      - 19780
    volumes:
      - ./data/storage0:/data/storage
      - ./logs/storage0:/logs
    restart: on-failure
    network_mode: host
    cap_add:
      - SYS_PTRACE

  graphd:
    image: vesoft/nebula-graphd:v2.0.0
    environment:
      USER: root
      TZ:   "${TZ}"
    command:
      - --meta_server_addrs={{nebula02}}:9559,{{nebula03}}:9559,{{nebula04}}:9559
      - --port=9669
      - --ws_ip={{nebula02}}
      - --ws_http_port=19669
      - --log_dir=/logs
      - --v=0
      - --minloglevel=0
      - --enable_authorize=true
    depends_on:
      - metad0
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://{{nebula02}}:19669/status"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    ports:
      - "9669:9669"
      - 19669
      - 19670
    volumes:
      - ./logs/graph:/logs
    restart: on-failure
    network_mode: host
    cap_add:
      - SYS_PTRACE

三台配置是类似的. 由于一些特殊的原因, 我们机器的docker映射的端口不能被其他集群访问, 所以才用了 host 的方式

docker-compose 是直接从官方仓库拉取然后改的

好, 收到

想请教&确认一个问题: 现在已经把日志/数据挂载到本地磁盘了, 如果我重建容器, 会不会对使用有什么影响? 比如账户权限, 图数据等. (因为不清楚是不是有些数据在容器里, 挂载不到本地盘.

具体 docker-compsoe 配置见下文

数据挂载到本地后,重建容器是不影响其中的数据的,所有的数据都放置在 nebula/data 目录。看你的 compose 的配置没什么问题,有具体查看下述中的 docker 进程无响应的原因吗?

这个倒还没有细看, 在忙其他的事情, 暂时先搁置了.

明天我看有无时间排查下

遇到同样的问题,通过 netstat 命令查看,有很多 ESTABLISHED 状态的链接,日志中有 AsyncServerSocket.cpp:972] failed to dispatch newly accepted socket: all accept callback queues are full folly 的报错日志

sh-4.2# netstat -anp|grep 19559
tcp        0      0 :19559    0.0.0.0:*               LISTEN      1/./bin/nebula-meta
tcp        0      0 :47130    :19559    ESTABLISHED 62165/curl
tcp        0      0 :56504    :19559    ESTABLISHED 62393/curl
tcp        0      0 :40640    :19559    ESTABLISHED 11726/curl
tcp       84      0 :19559    :41384    ESTABLISHED 1/./bin/nebula-meta
tcp       84      0 :19559    :38396    ESTABLISHED 1/./bin/nebula-meta
tcp       84      0 :19559    :34718    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :37696    :19559    ESTABLISHED 13326/curl
tcp        0      0 :37254    :19559    ESTABLISHED 60645/curl
tcp        0      0 :44798    :19559    ESTABLISHED 13422/curl
tcp        0      0 :45770    :19559    ESTABLISHED 11329/curl
tcp        0      0 :34452    :19559    ESTABLISHED 61811/curl
tcp       84      0 :19559    :43112    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :34394    :19559    ESTABLISHED 58723/curl
tcp       84      0 :19559    :39044    ESTABLISHED 1/./bin/nebula-meta
tcp       84      0 :19559    :40562    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :47934    :19559    ESTABLISHED 58278/curl
tcp       84      0 :19559    :44548    ESTABLISHED 1/./bin/nebula-meta
tcp       84      0 :19559    :60040    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :50766    :19559    ESTABLISHED 62183/curl
tcp        0      0 :40650    :19559    ESTABLISHED 12431/curl
tcp       84      0 :19559    :53336    ESTABLISHED 1/./bin/nebula-meta
tcp       84      0 :19559    :52226    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :35400    :19559    ESTABLISHED 57982/curl
tcp       84      0 :19559    :47390    ESTABLISHED 1/./bin/nebula-meta
tcp       84      0 :19559    :46792    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :52790    :19559    ESTABLISHED 59797/curl
tcp       84      0 :19559    :37154    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :50412    :19559    ESTABLISHED 11359/curl
tcp       84      0 :19559    :58454    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :46816    :19559    ESTABLISHED 60429/curl
tcp        0      0 :41278    :19559    ESTABLISHED 61841/curl
tcp        0      0 :39928    :19559    ESTABLISHED 12713/curl
tcp       84      0 :19559    :46410    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :56070    :19559    ESTABLISHED 12389/curl
tcp        0      0 :36300    :19559    ESTABLISHED 62837/curl
tcp       84      0 :19559    :53832    ESTABLISHED 1/./bin/nebula-meta
tcp        0      0 :59208    :19559    ESTABLISHED 11239/curl
tcp        0      0 :39348    :19559    ESTABLISHED 12142/curl
tcp        0      0 :35716    :19559    ESTABLISHED 58500/curl
sh-4.2#

这个问题明显是连接太多,没有及时断开,造成服务端已经没有线程可以处理新的请求了。这里很疑惑的一点为什么你的容器内部的 healthcheck 在通过 curl 检查完毕之后没有断开链接?

可以贴一下 docker info 的结果吗?

问题应该是, status 接口异常,然后导致 curl 阻塞,导致的一对 established 状态的链接。

本地访问 status 接口为什么不用uds

sorry 这里我之前理解错了, checkhealth 的 timeout 是指如果超过这个时间, 则认为容器状态为不健康, 而不是命令的超时时间.

docker info

Containers: 46
 Running: 40
 Paused: 0
 Stopped: 6
Images: 17
Server Version: 18.09.5
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 5.4.0-40-generic
Operating System: Ubuntu 18.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 72
Total Memory: 376.6GiB
Name: nebula04
ID: LBXD:GK4A:OQET:BDIO:GSZX:WGVE:VLWS:6NPW:XWL6:RF3C:WSKN:GPQ5
Docker Root Dir: /data1/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 mirror.kce.sdns.ksyun.com
 172.16.0.0/16
 127.0.0.0/8
Registry Mirrors:
 http://mirror.kce.sdns.ksyun.com/
Live Restore Enabled: true
Product License: Community Engine

WARNING: No swap limit support

浙ICP备20010487号