问题描述
场景复现
无法必现. 最近两次都是启动后约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:
的错误日志，看看有什么错误信息。
搜索关键字: GetStatsHandler
graph.error 日志里没有搜索到相关字段.
20 号监控没数据的, 然后搜索了下 19-21 的 info 日志也没搜到.
对了, 还有一个现象, 就是一旦出现这种情况, docker 容器就无法正常的重启了.
执行: docke-compose restart, 返回 `nixHTTPConnectionPool(host=‘localhost’, port=None): Read timed out.
盲猜是僵尸进程引起的 
$ 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