dashdot 6.3.4 使用与运维详解

目标：面向已经把 dashdot 跑起来的读者，讲清「日常怎么用、出问题怎么查」——界面六大监控组件逐项实测讲解、只读数据接口（/info、/load/*）与实时通道（socket.io）逐端点实测、单组件嵌入与移动端适配要点、告警能力边界与外接方案、探活/升级/回滚运维清单。全部命令与回显来自 Ubuntu 26.04.1 LTS 服务器（dashdot 6.3.4，服务端口 8142）实测。

一、环境信息

本文全部命令与回显来自以下真实环境，逐条实测：

💡 说明：dashdot 是纯 Web GUI 仪表盘，没有命令行工具——所有「使用」都在浏览器界面完成，所有「对接」都走本文第四节的只读接口。本文不涉及部署，部署与升级操作请配合部署篇使用。

二、前置条件

2.1 运行实例与访问入口

1. dashdot 已在服务器上运行并可访问（部署见 《dashdot 6.3.4 Docker Compose 部署指南》）。
2. 界面与接口均为 HTTP 明文服务，本机探活用 http://127.0.0.1:8142，远程访问用 http://<服务器IP>:8142。

2.2 无认证体系——先谈访问控制

dashdot 6.3.4 没有登录系统、没有用户与权限概念：任何能访问到端口的客户端都能看全部监控数据、调用全部接口。因此使用前必须先定访问边界：

• 仅内网/本机使用：绑定内网地址或用防火墙限制来源即可；
• 需要暴露到公网：必须在反向代理层加认证（HTTP Basic Auth、OAuth2 代理等）。以 Nginx Basic Auth 为例，创建演示账号 admin / q1w2e3r4：

htpasswd -bc /etc/nginx/dashdot.htpasswd admin q1w2e3r4   # 生成认证文件

实测回显：

Adding password for user admin

Nginx 对应站点配置中加上：

location / {
    auth_basic "dashdot";
    auth_basic_user_file /etc/nginx/dashdot.htpasswd;
    proxy_pass http://127.0.0.1:8142;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;      # WebSocket 升级（实时通道必需）
    proxy_set_header Connection "upgrade";
}

⚠️ 注意：Upgrade/Connection 两行不能省——dashdot 的界面图表完全依赖 WebSocket 实时通道（见 4.9），反代不转发 WebSocket 升级时界面会一直空白。

2.3 客户端工具

三、界面六大监控组件逐项讲解

3.1 组件总览与布局规则

打开 http://<服务器IP>:8142，看到的是深色玻璃拟态卡片墙。卡片种类共六种、数量与顺序由 widget_list 参数决定，默认 os,cpu,storage,ram,network 五张，gpu 需显式加入（参数细节见 《dashdot 6.3.4 配置参数详解》）：

界面行为规则（以 v6.3.4 源码 apps/view/src/ 为据）：

• 卡片排列为弹性栅格，每张卡片有 grow（宽度权重）与 min_width（最小宽度，GPU 卡 700px、其余 300~500px），窗口变窄时卡片自动换行堆叠，750px 以下切换为移动端布局（见 5.2）；
• 右上角是深浅色切换控件，默认跟随系统配色，手动切换后偏好存本地、重开页面保留；
• 鼠标悬停左上角 dash. 标识会浮出当前版本号（默认 show_dash_version: icon_hover）；
• 每张图表默认保留 20 个数据点的滚动窗口（*_shown_datapoints，可配），历史数据不落盘，重启即清零；
• 页面加载失败时界面直接给出错误卡片，两种文案：Invalid or incomplete static data loaded!（静态信息不完整）与 Unable to connect to backend!（实时通道连不上，多与反代 WebSocket 配置有关）。

3.2 OS 组件（Server 卡片）

展示主机身份三要素：系统名（Os）、架构（Arch）、开机至今（Up since）。数据来自 /info 的 os 域，本机实测：

{
    "os": {
        "arch": "x64",
        "distro": "Ubuntu",
        "kernel": "7.0.0-38-generic",
        "platform": "linux",
        "release": "26.04.1 LTS",
        "uptime": 140690.99,
        "dash_version": "6.3.4",
        "dash_buildhash": "24cc5d61e10f5255a44f85b5b35d333a3b9bc6d8"
    }
}

界面 Up since 显示为「X days, X hours, X minutes」并在页面内实时递增（源码在客户端用 uptime 初值 + 页面停留时间累加，不需要刷新页面就能看到时长增长）。注意 v6.2.0 起 dashdot 上报的是宿主 OS 而非服务自身运行环境（官方 CHANGELOG 明确），所以这里看到的就是宿主机系统。

3.3 CPU 组件

信息表来自 /info 的 cpu 域，图表数据来自实时通道的 cpu-load 事件（与 /load/cpu 同构）。本机实测两条数据对照：

{
    "cpu": {
        "brand": "Intel",
        "model": "Core™ i7-14700KF",
        "cores": 6,
        "ecores": 0,
        "pcores": 6,
        "threads": 6,
        "frequency": null
    }
}

[{"load":67.3469387755102,"temp":0,"core":0},{"load":42.70833333333333,"temp":0,"core":1},{"load":36.08247422680412,"temp":0,"core":2},{"load":29.166666666666668,"temp":0,"core":3},{"load":24.742268041237114,"temp":0,"core":4},{"load":25.773195876288657,"temp":0,"core":5}]

界面表现：

• 默认显示总负载一条曲线；点击卡片上的核数开关（cpu_cores_toggle_mode: toggle 默认）展开为逐核曲线，每核一条、颜色区分，与上例 core 0~5 数组一一对应；
• 负载按百分比展示；temp 字段有值且开启 DASHDOT_ENABLE_CPU_TEMPS 时显示温度曲线，本机为虚拟机无传感器恒为 0（部署篇 FAQ 有详细排障）；
• frequency 为 null 时信息表该行显示空值，虚拟机场景常见，可用 DASHDOT_OVERRIDE_CPU_FREQUENCY 补显示值（只改界面，不改接口原始值——这是配置篇 5.6 讲过的覆盖机制）。

3.4 Storage 组件

信息表来自 /info 的 storage 域（物理盘视角：设备名、品牌、类型），用量图表来自 storage-load 事件（逻辑挂载视角：已用字节）。本机实测对照：

{
    "storage": [
        {
            "size": 322122547200,
            "disks": [
                {
                    "device": "sda",
                    "brand": "VMware,",
                    "type": "HD"
                }
            ]
        }
    ]
}

[172782182400]

/load/storage 返回的 172782182400 字节（约 160.9 GiB）就是界面上那根「已用」条形的数值，堆叠条的浅色部分是可用空间，悬停浮窗显示 XX.X % Used 与 已用 / 总量 两行。

界面行为要点：

• 多块盘/多分区时按页显示，每页 3 条（storage_widget_items_per_page），卡片底部出现翻页控件；
• 某块盘没有匹配到可用挂载点时，图表位置显示虚线空条与 No mount found 浮窗——这对应接口层的 -1 哨兵值，是部署挂载问题在界面上的直接投影（排障见部署篇 FAQ Q1）；
• 数据 60 秒刷新一次（storage_poll_interval 默认 60000ms），刚写入大量文件后条形不会立刻变化，等下一个周期即可。

3.5 RAM 组件

信息表来自 /info 的 ram 域，图表来自 ram-load 事件：

{
    "ram": {
        "size": 16178016256,
        "layout": [
            {
                "brand": "Not Specified",
                "type": "DRAM",
                "frequency": null
            }
        ]
    }
}

{"load":7785586688}

load: 7785586688 字节（约 7.25 GiB）除以 size: 16178016256 就是界面显示的内存占用百分比。与宿主 free 同瞬核对过：dashdot 读数与 free 的 used 差约 1 MB（0.01% 量级），读数可信（部署篇有完整核对过程）。内存条品牌来自 dmidecode，虚拟机里显示 Not Specified 属正常。

3.6 Network 组件

信息表来自 /info 的 network 域，图表来自 network-load 事件，上行与下行是两张独立曲线图（↑ 与 ↓ 标识）：

{
    "network": {
        "interfaceSpeed": 1000,
        "speedDown": 131084785.66432852,
        "speedUp": 20146017.42193535,
        "lastSpeedTest": 1793411020950,
        "type": "Wired"
    }
}

{"up":5181.56195582286,"down":43396.07922417055}

解读要点（两处容易误读）：

• interfaceSpeed 是链路速率（本机 1 Gb/s 网卡显示 1000），读不到时回退显示 10000；speedUp/speedDown 是周期测速结果（本机下行约 131 Mb/s），lastSpeedTest 是最近一次测速的毫秒时间戳。这三者与实时流量曲线无关；
• 实时流量接口的单位是字节/秒：上例 down: 43396.08 即约 42.4 KB/s，界面图表悬停值做了 ×8 换算按 bit/s 展示（源码 tooltip 渲染 bpsPrettyPrint(value * 8)）。自写脚本消费 /load/network 时别把字节当比特；
• 测速周期默认 240 分钟，启动后立即跑一次、实测约 29 秒，期间下行曲线会出现一个大尖峰——是测速流量，不是业务流量。

3.7 GPU 组件

GPU 卡片默认不在组件清单里，需 DASHDOT_WIDGET_LIST 加入 gpu 才渲染。本机无独立显卡，接口层返回空清单：

{"layout":[]}

此时若强行把 gpu 加入组件清单，卡片信息表与图表均为空态——没有数据不报错，只是空。GPU 数据采集依赖 NVIDIA 设备（官方另有 :nvidia 分发包，部署篇中有专门的分发包选型说明），layout 数组中每张卡含品牌、型号、显存；多卡时图表按卡拆分，嵌入模式下可用 filter 参数只看负载或显存图（见 5.1）。

💡 技术拓展：dashdot 的六组件是「一台主机的全景视角」，不含进程级、服务级与多主机聚合能力；要进程级明细或跨主机汇总，属于 Netdata、Prometheus+Grafana 一类方案的领地（选型对比见 《dashdot 6.3.4 介绍与选型指南》）。界面上的六个组件全部是宿主硬件视角——如果目标是监控某几个具体服务，需要另配方案。

四、数据接口详解

4.1 接口体系总览与 /graphql 实测澄清

dashdot 6.3.4 对外暴露两套数据通道：

约定：全部只读 GET、无请求体、无认证、无分页参数；接口随 DASHDOT_DISABLE_INTEGRATIONS=true 一并关闭（实测 404，见部署篇 FAQ Q5）。

关于「GraphQL 端点」：坊间部分教程称 dashdot 可通过 /graphql 查询数据，v6.3.4 实测不存在该端点。GET 与 POST 各实测一次：

curl -s -i http://127.0.0.1:8142/graphql
curl -s -i -X POST http://127.0.0.1:8142/graphql -H 'Content-Type: application/json' -d '{"query":"{ cpu { load } }"}'

实测回显（GET，节选）：

HTTP/1.1 404 Not Found
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Security-Policy: default-src 'none'
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Content-Length: 146
Vary: Accept-Encoding
Date: Sat, 31 Oct 2026 02:32:41 GMT
Connection: keep-alive
Keep-Alive: timeout=5

<pre>Cannot GET /graphql</pre>

实测回显（POST，节选）：

HTTP/1.1 404 Not Found
Content-Length: 147

<pre>Cannot POST /graphql</pre>

以 v6.3.4 源码（apps/server/src/index.ts）为据，服务端只注册了上表列出的路由，GraphQL 依赖从未引入。外部集成一律走 REST 快照 + socket.io 订阅的组合，下文逐端点实测。

💡 说明：本节以下所有响应均为「接口原样返回 + 排版缩进」，长响应标注节选。端口统一 8142。

4.2 /config：当前生效配置快照

返回解析后的全部 DASHDOT_ 参数（排障第一入口，配置篇 3.1 已详细介绍）。本节补充一个版本核对相关的实测发现——官方分发形态下响应顶层没有 version 字段：

curl -s http://127.0.0.1:8142/config | python3 -c "import json,sys; d=json.load(sys.stdin); print(sorted(d.keys()))"

实测回显：

['config']

而源码逻辑是 /config 本应返回 {config, version, buildhash} 三键，version 从包内 version.json 读取；实测该包运行目录下确有此文件，但代码以「程序目录上溯三级」的固定路径查找，与分发包的实际目录层级不匹配，读不到就回退为空值——JSON 序列化时空值键被省略。启动日志里那行 Version file not found. This is normal on from-source builds. 在官方分发形态同样出现，就是这条路径的副产品。

正确版本核对姿势是用 /info 的 os.dash_version（见 4.3），它来自包清单而非 version.json，实测稳定返回 6.3.4：

curl -s http://127.0.0.1:8142/info | python3 -c "import json,sys; print(json.load(sys.stdin)['os']['dash_version'])"

实测回显：

6.3.4

4.3 /info：静态硬件信息（全量）

六大组件信息表的数据源，只在启动时采集一次、运行期不变（uptime 除外，它按响应时刻计算）。完整实测回显：

{
    "os": {
        "arch": "x64",
        "distro": "Ubuntu",
        "kernel": "7.0.0-38-generic",
        "platform": "linux",
        "release": "26.04.1 LTS",
        "uptime": 140690.99,
        "dash_version": "6.3.4",
        "dash_buildhash": "24cc5d61e10f5255a44f85b5b35d333a3b9bc6d8"
    },
    "cpu": {
        "brand": "Intel",
        "model": "Core™ i7-14700KF",
        "cores": 6,
        "ecores": 0,
        "pcores": 6,
        "threads": 6,
        "frequency": null
    },
    "ram": {
        "size": 16178016256,
        "layout": [
            {
                "brand": "Not Specified",
                "type": "DRAM",
                "frequency": null
            }
        ]
    },
    "storage": [
        {
            "size": 322122547200,
            "disks": [
                {
                    "device": "sda",
                    "brand": "VMware,",
                    "type": "HD"
                }
            ]
        }
    ],
    "network": {
        "interfaceSpeed": 1000,
        "speedDown": 131084785.66432852,
        "speedUp": 20146017.42193535,
        "lastSpeedTest": 1793411020950,
        "type": "Wired"
    },
    "gpu": {
        "layout": []
    }
}

消费注意：

• storage 是物理盘视角（size 为整盘字节），与 /load/storage 的逻辑挂载用量不是一套口径（两套口径的量化差异见部署篇 4.3 的同瞬核对）；
• network.speedUp/speedDown 是最近一次测速结果（bit/s），lastSpeedTest 为毫秒时间戳；
• 设过 DASHDOT_OVERRIDE_* 的读者注意：/info 永远返回原始采集值，覆盖值只在 /config 与界面上体现（配置篇 Q2 的结论，接口消费时同样适用）。

4.4 /load/cpu：逐核负载快照

curl -s http://127.0.0.1:8142/load/cpu

实测回显：

[{"load":67.3469387755102,"temp":0,"core":0},{"load":42.70833333333333,"temp":0,"core":1},{"load":36.08247422680412,"temp":0,"core":2},{"load":29.166666666666668,"temp":0,"core":3},{"load":24.742268041237114,"temp":0,"core":4},{"load":25.773195876288657,"temp":0,"core":5}]

字段：load 为该核负载百分数、temp 为温度（未启用温度采集恒 0）、core 为核序号。数组长度 = 核数。聚合平均的取法见 6.2 告警脚本。

4.5 /load/ram：内存用量快照

curl -s http://127.0.0.1:8142/load/ram

实测回显：

{"load":7785586688}

单键 load，单位字节，除以 /info 的 ram.size 即占用率。

4.6 /load/storage：逻辑挂载用量快照

curl -s http://127.0.0.1:8142/load/storage

实测回显：

[172782182400]

数组按挂载点逐项给出已用字节；某项为 -1 表示该挂载无匹配数据（对应界面 No mount found 空条）。

4.7 /load/network：实时网速快照

curl -s http://127.0.0.1:8142/load/network

实测回显：

{"up":5181.56195582286,"down":43396.07922417055}

单位字节/秒（不是比特），见 3.6 的解读。空闲期读数为几百 KB/s 以下属正常，测速窗口内会出现 10 MB/s 量级尖峰。

4.8 /load/gpu：显卡负载快照

curl -s http://127.0.0.1:8142/load/gpu

实测回显（无显卡环境）：

{"layout":[]}

有 NVIDIA 卡时 layout 数组内每卡一个对象（负载、显存等字段）。无卡环境恒为空数组，不会 404、不会报错。

4.9 实时通道 socket.io（六事件推送）

界面全部数据走这条通道，路径为 /socket（设置了 DASHDOT_ROUTING_PATH 时为 <routing_path>/socket）。连接后服务端持续推送六个事件：

不引客户端库也能验证通道——socket.io 走 Engine.IO 协议，用 curl 长轮询即可走通全流程。实测（三步：握手拿 sid → 连接默认命名空间 → 收事件包）：

SID=$(curl -s 'http://127.0.0.1:8142/socket/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; raw=sys.stdin.read(); print(json.loads(raw[raw.index('{'):])['sid'])")
curl -s -X POST "http://127.0.0.1:8142/socket/?EIO=4&transport=polling&sid=$SID" \
  -H 'Content-Type: text/plain;charset=UTF-8' --data-raw '40'    # 连接命名空间
curl -s --max-time 6 "http://127.0.0.1:8142/socket/?EIO=4&transport=polling&sid=$SID"

实测回显（第一步握手响应）：

0{"sid":"Py8C1OvpHboaAkhcAAAF","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":20000,"maxPayload":1000000}

💡 说明：sid 每次连接随机生成，本文各步回显取自多轮实测，读者复现时 sid 必然不同；握手 JSON 的其余字段为服务端固定参数。

POST 返回：

ok

首次轮询收到命名空间确认与 static-info 事件包（连包，实测节选）：

40{"sid":"iXKtgZGIjaSMXRrKAAAC"}42["static-info",{"os":{"arch":"x64","distro":"Ubuntu","kernel":"7.0.0-38-generic","platform":"linux","release":"26.04.1 LTS","uptime":140767.76,"dash_version":"6.3.4","dash_buildhash":"24cc5d61e10f5255a44f85b5b35d333a3b9bc6d8"},"cpu":{"brand":"Intel","model":"Core™ i7-14700KF","cores":6,"ecores":0,"pcores":6,"threads":6,"frequency":null},...

再次轮询收到 cpu-load 实时包（实测）：

42["cpu-load",[{"load":57.14285714285714,"temp":0,"core":0},{"load":27.55102040816326,"temp":0,"core":1},{"load":29.591836734693878,"temp":0,"core":2},{"load":70.40816326530613,"temp":0,"core":3},{"load":28.125,"temp":0,"core":4},{"load":30.927835051546392,"temp":0,"core":5}]]

协议要点：0 开头为 Engine.IO 握手包、40 为命名空间连接确认、42 为事件帧（42["事件名",载荷]）。正式集成用任意语言的 socket.io 客户端即可，无需手工处理上述帧格式。

💡 说明：前端进页面时会先连 socket 收 static-info 再渲染界面——所以 DASHDOT_DISABLE_INTEGRATIONS=true 虽然实测只关 REST 路由（io.on('connection') 的订阅不受该开关控制），但同源页面的 socket 连接默认不被跨域放行，跨域嵌入场景下该开关等于「REST 与跨域实时通道全关」，同源本机访问不受影响。

4.10 轮询频率建议

REST 端点每次请求都是即时计算，无缓存、无限流，但采集源本身有节拍（CPU/RAM/Network 1 秒、Storage 60 秒）。外部轮询建议：动态指标 ≥1 秒（与采集节拍对齐，再快只是重复读数）、Storage ≥60 秒；需要秒级连续曲线时直接订阅 socket.io 事件，省掉 HTTP 开销也不给主机添采集负担。

五、单组件嵌入与移动端适配

5.1 嵌入模式（single-widget）与 URL 参数

dashdot 支持把单个组件渲染成无外框的独立小图，用于 Wiki、主页面板等场景嵌 iframe。入口是主地址带 graph 查询参数，实测：

curl -s -o /dev/null -w 'HTTP %{http_code}  %{time_total}s  %{size_download} bytes\n' \
  'http://127.0.0.1:8142/?graph=cpu&showPercentage=true'

实测回显：

HTTP 200  0.004351s  761 bytes

返回的是同一个页面壳（HTML 内不含图表，图表由前端连 socket 后渲染），浏览器打开后即见满屏单组件 CPU 图。全部可用参数（以 v6.3.4 源码 apps/view/src/services/query-params.ts 为据）：

尺寸值支持 px/rem/em/%/vh/vw/ch/ex，纯数字按 px 处理。示例：/?graph=network&filter=down&theme=light 嵌入一张浅色下行流量图；/?graph=storage&multiView=true 嵌入逐盘用量视图。

⚠️ 注意：嵌入模式同样走 WebSocket 实时通道，iframe 跨域嵌入时反代需放行 CORS 与 WebSocket（服务端在未关闭 integrations 时默认 Access-Control-Allow-Origin: *，实测响应头见 4.1 回显）。

5.2 移动端适配

以 v6.3.4 源码（apps/view/src/services/mobile.tsx）为据，判定阈值是视口宽度 750px：低于该值进入移动端布局。实测行为差异：

• 页面留白从 7vh/4vw 收窄为固定 50px/25px，卡片纵向间距从 70px 收窄为 40px；
• 卡片按 min_width（300~700px）逐个换行，750px 以下实际呈单列堆叠，整页纵向滚动；
• 图表、翻页、深浅色切换等功能完整保留，无阉割；
• 手机浏览器首次进入会跟随系统深浅色（取系统 color-scheme）。

无需任何配置，响应式是内置行为。若移动端卡片过宽（如 700px 的 GPU 卡），可下调对应 *_widget_min_width 参数（配置篇 5.2）。

5.3 深浅色与页面标题

• 深浅色：右上角控件手动切换，默认跟随系统；嵌入模式用 theme 参数强制；
• 页面标题：HTML 壳里恒为 <title>dash.</title>，浏览器标签显示的标题由前端按 page_title 配置运行时改写——用 curl 验证标题只能看到 dash.（部署篇 Q6 的实测结论），嵌入 iframe 场景下标签页标题不生效，属预期。

六、告警能力与外接方案

6.1 边界：dashdot 没有内置告警

以 v6.3.4 全量源码核查：前端无通知组件、后端无阈值判断逻辑，六个组件只展示不判断，没有任何报警、邮件、Webhook 能力。参数体系里也不存在 alert 类配置项（配置篇 75 个参数可交叉印证）。dashdot 的定位是「看」，告警必须外接。

6.2 外接告警实测：阈值探针脚本

最轻量的外接方式是定时任务轮询 /load/* 做阈值判断。以下脚本实测可用（本机保存为 dashdot-cpu-alert.sh），取六核均值与阈值比较，输出告警/正常行：

#!/usr/bin/env bash
# dashdot CPU 负载告警探针：轮询 /load/cpu 取六核均值，与阈值比较后输出告警/正常行
# 用法: ./dashdot-cpu-alert.sh <阈值百分数>   （缺省 80）
THRESHOLD=${1:-80}
AVG=$(curl -s --max-time 3 http://127.0.0.1:8142/load/cpu \
  | python3 -c "import json,sys; v=[c['load'] for c in json.load(sys.stdin)]; print(round(sum(v)/len(v),1))")
NOW=$(date '+%Y-%m-%d %H:%M:%S')
if python3 -c "exit(0 if ${AVG:-0} > $THRESHOLD else 1)"; then
  echo "[$NOW] ALERT  cpu_avg=${AVG}%  > ${THRESHOLD}%"
else
  echo "[$NOW] OK     cpu_avg=${AVG}%  <= ${THRESHOLD}%"
fi

实测两次运行（第一档正常、第二档故意压低阈值触发告警）：

./dashdot-cpu-alert.sh 80
./dashdot-cpu-alert.sh 20

实测回显：

[2026-10-31 10:41:32] OK     cpu_avg=34.0%  <= 80%
[2026-10-31 10:41:32] ALERT  cpu_avg=34.0%  > 20%

6.3 外接渠道建议

• 触发频率：cron 每 1~5 分钟一轮足够；/load/cpu、/load/ram 单次请求毫秒级返回，负载可忽略；
• 通知渠道：脚本里把 ALERT 分支换成邮件（mail/sendmail）、IM Webhook（飞书/钉钉/企业微信机器人）即可；告警行里已带时间、指标值、阈值，直接作为通知正文；
• 可扩展指标：同法监控内存（/load/ram 除以 /info 的 ram.size）、磁盘（/load/storage 对照 /info 的 storage.size）、网速（/load/network，注意字节/秒口径）；
• 不要把面板当告警源：dashdot 无状态、图表仅 20 个数据点窗口，事后无法回溯「告警时刻」的曲线，需要回溯能力的场景请用带时序存储的方案（选型对比见介绍篇）。

七、日常运维要点

7.1 探活

dashdot 无内置健康检查端点，探活用 /config（轻量且能同时验证配置解析正常）。实测四个路径的状态码与耗时：

for p in / /config /not-exist; do
  curl -s -o /dev/null -w "$p -> %{http_code}  %{time_total}s\n" "http://127.0.0.1:8142$p"
done

实测回显：

/ -> 200  0.001566s
/config -> 200  0.002402s
/not-exist -> 404

• / 返回 200 只说明页面壳能出，图表正常与否取决于 WebSocket 通道；严格探活可加一步 socket 握手验证（4.9 的第一步，拿到 0{"sid":...} 即通道可用）；
• /not-exist 返回 404 说明路由层活着，可用于区分「服务挂了」与「路径错了」；
• 定时探活示例：cron 每 5 分钟 curl -fsS -m 3 -o /dev/null http://127.0.0.1:8142/config || 告警动作。

7.2 日志巡检要点

运行日志的关键行及其含义（实测过的正常形态）：

无状态服务、日志量极小，日常巡检看「进程在 + /config 200 + 六组件图表在动」三项即可。

7.3 升级与回滚

升级动作本身（换版本号重建运行实例）在部署篇第十节已实测，本节给升级前后的验证清单——dashdot 无状态、无数据迁移，风险全部集中在「新版本采集行为变化」，验证是唯一防线。

升级前留档（两份 JSON 足够）：

curl -s http://127.0.0.1:8142/config > dashdot-config-6.3.4.json
curl -s http://127.0.0.1:8142/info   > dashdot-info-6.3.4.json

升级后按序验证（每步带本机 6.3.4 的预期值）：

curl -s http://127.0.0.1:8142/info | python3 -c "import json,sys; print(json.load(sys.stdin)['os']['dash_version'])"   # 应输出新版本号
curl -s http://127.0.0.1:8142/load/cpu   # 应返回核数条目的数组
curl -s http://127.0.0.1:8142/load/ram   # 应返回 {"load":<字节数>}
curl -s http://127.0.0.1:8142/load/storage   # 应返回已用字节数组（不能是 [-1]）
curl -s http://127.0.0.1:8142/load/network   # 应返回 {"up":..,"down":..}

实测回显（6.3.4 基线，升级后逐项对照）：

6.3.4
[{"load":67.3469387755102,"temp":0,"core":0},{"load":42.70833333333333,"temp":0,"core":1},{"load":36.08247422680412,"temp":0,"core":2},{"load":29.166666666666668,"temp":0,"core":3},{"load":24.742268041237114,"temp":0,"core":4},{"load":25.773195876288657,"temp":0,"core":5}]
{"load":7785586688}
[172782182400]
{"up":5181.56195582286,"down":43396.07922417055}

外加两项人工检查：浏览器打开界面六组件图表正常滚动；diff 对比升级前后 dashdot-config-*.json，确认新增/移除的参数项（v6 系列内升级无参数删除，跨大版本升级要重点核对，v6.0.0 有过测速单位口径的 BREAKING 变更，CHANGELOG 记录在案）。

回滚：把版本号改回旧版重建即可（部署篇第十节），回滚后重复上述验证清单。因无任何落盘状态，回滚零数据代价。

7.4 重启后的数据表现

进程重启（含升级重建）后的预期行为，运维时不要误判为故障：

• 全部图表清零，20 个数据点窗口从头累积（约 1 分钟后 CPU/RAM/Network 曲线重新连贯，Storage 要等 60 秒）；
• 启动即重跑一次测速（约 29 秒，期间网速曲线大尖峰）；
• 面板本地设置（深浅色等）不受影响（存浏览器侧），服务端无任何状态丢失问题——因为本来就没有服务端状态。

八、常见问题（排障实录）

Q1：对接方说 dashdot 有 GraphQL 接口，/graphql 却一直 404？ v6.3.4 没有 GraphQL 端点（4.1 有 GET/POST 双实测与源码依据）。数据对接走 /info + /load/* 快照或 socket.io 订阅；升级到更新版本后如需 GraphQL，先 curl 实测再写代码，别按旧教程硬编码。

Q2：/config 里取不到 version 字段？ 官方分发形态实测顶层只有 ['config'] 一个键（4.2 有完整实录），version/buildhash 因包内版本文件路径未命中而被省略。版本核对一律用 /info 的 os.dash_version。日志里 Version file not found... 一行在官方分发形态同样出现，不是故障。

Q3：界面一直空白，/config 却返回 200？ 界面数据走 WebSocket（/socket），与 REST 是两条通道。多为反向代理没转发 WebSocket 升级头（2.2 的 Upgrade/Connection 两行），或浏览器控制台报 Unable to connect to backend!。本机直连端口可复现界面正常，则问题必在反代层。

Q4：/load/gpu 返回 {"layout":[]}，是坏了吗？ 不是。无 NVIDIA 卡或未用 GPU 分发包时就是空数组（4.8 实测），界面对应空卡片。需要 GPU 监控时按部署篇的分发包选型一节换 :nvidia 分发包并透传显卡设备。

Q5：/load/network 的数值和界面图表对不上？ 接口单位是字节/秒，界面按比特/秒显示（×8，见 3.6）。另外界面图表有 20 点窗口且 1 秒一格，瞬时不完全一致属正常。

Q6：嵌入 iframe 后小图不渲染？ 确认三件事：URL 带了 graph 参数（不带就是完整面板）；嵌入页与 dashdot 同源或反代放行了 CORS；反代转发了 WebSocket。curl 只能验证页面壳 200（5.1 实测 761 字节），图表渲染必须浏览器实测。

Q7：想加「CPU 超过 80% 发飞书」这类告警？ dashdot 无此能力（6.1），按 6.2/6.3 外接：cron + 探针脚本 + Webhook，十分钟内可落地。

九、参考链接

• 官方文档（集成/API）：https://getdashdot.com/docs/integration/api
• 官方文档（组件嵌入）：https://getdashdot.com/docs/integration/widgets
• 官方 FAQ：https://getdashdot.com/docs/faq
• 服务端路由源码：https://github.com/MauriceNino/dashdot/blob/v6.3.4/apps/server/src/index.ts
• 嵌入参数源码：https://github.com/MauriceNino/dashdot/blob/v6.3.4/apps/view/src/services/query-params.ts
• 站内选型参考：《dashdot 6.3.4 介绍与选型指南》
• 站内部署参考：《dashdot 6.3.4 Docker Compose 部署指南》
• 站内配置参考：《dashdot 6.3.4 配置参数详解》