指南 › MeshWatch Central

其他语言 English · 日本語 · 한국어 · 简体中文

MeshWatch Central — 安装与集成

Central 是你自己运行的服务器。它接收桌面产品的告警，汇入一个收件箱，并按设备关联。当前版本 1.3.8。

本版本的变化

完整发布说明

开始之前

Central 应当放在一直开机的服务器上，而不是笔记本上。它在 8443 端口以明文 HTTP 提供服务 — 8443 通常意味着 HTTPS，但在你为它加上反向代理之前，Central 并不说 HTTPS。输入 https:// 会直接连不上。

有两种安装方式，选择之前请先读这段：

安装 — Docker

需要先安装并运行 Docker。然后一条命令：

docker run -d --name meshwatch-central -p 8443:8443 -v central-data:/data ethan99199/meshwatch-central:1.3.8

刻意保持在一行：用反斜杠折行的写法粘进 PowerShell 会出错，因为 PowerShell 不用反斜杠做续行。

确认已启动，应当看到 Up … (healthy)：

docker ps --filter name=meshwatch-central

如果终端回答 docker: The term 'docker' is not recognized 或 command not found，说明没有装 Docker；也可能是你在安装 Docker 之前就打开了终端，这时新开一个窗口就能找到。

安装 — Node 版（含 Windows Server）

Node.js 18 或更高，仅此而已。Central 没有 npm 依赖，安装时不会去下载任何东西。

解压到一个长期存放的位置，然后在 PowerShell 中先切换到那个目录。漏掉这一步是最常见的错误：Node 会在你当前所在的目录里找 src\server.js，然后报 Cannot find module。

cd C:\MeshWatchCentral\mwc-1.3.8
$env:MWC_DATA_DIR = "C:\ProgramData\meshwatch-central"; node src\server.js

在 Linux 或 macOS 上：

MWC_DATA_DIR=/var/lib/meshwatch-central node src/server.js

MWC_DATA_DIR 是写入数据库和设置的位置。请选择一个会被备份、且运行 Node 的账户有写权限的路径。

从终端启动时，关闭那个窗口 Central 就停止了。正式部署请注册为服务 — Windows 上用 NSSM 或设为开机运行的计划任务，Linux 上用 systemd 单元。

该分发包是授权软件，不是开源软件。你可以在自己的服务器上运行，但不得再分发。条款见压缩包内的 LICENCE.txt。

首次运行

  1. 打开 http://<your-server>:8443；如果就在这台机器上，则是 http://localhost:8443。
  2. 创建第一个管理员账户。这个界面只会出现一次。
  3. 开放 8443 端口，让产品能够访问服务器。在 Windows Server 上：
New-NetFirewallRule -DisplayName "MeshWatch Central 8443" -Direction Inbound -LocalPort 8443 -Protocol TCP -Action Allow

查出产品应当填写的地址：

ipconfig | Select-String IPv4

接入产品

在你接入任何东西之前，Central 里什么都不会出现。Central 不会自己发现产品，需要用令牌把每个产品指向它。

  1. 在 Central 打开 Agents。选择产品，填写一个标签 — 它不是从别处查来的值，而是你自己起的名字，用来区分不同的安装（例如总部、上海机房）— 然后按 Issue token。
  2. 令牌只显示一次。关闭之前请先复制。若丢失，重新签发一个并吊销旧的。
  3. 在产品中打开它的 MeshWatch Central 设置，填入地址和令牌。位置如下：SyslogWatch、DeviceWatch 与 TrapWatch — Settings → MeshWatch Central。TrafficWatch — Alerts 按钮（打开 Alerts & delivery）。CertWatch 与 ConfigWatch — 左侧栏的 MeshWatch Central 面板。
  4. 使用 http://<central-server>:8443。不是 localhost — 产品在另一台机器上。也不是 https://。
  5. 勾选发送告警的选项，保存，然后按 Test connection。DeviceWatch 1.2.8 及更新版本、SyslogWatch 1.3.8 及更新版本无需勾选和保存：测试成功后会自动保存地址和令牌并开启连接，按钮变为 Done。

具备该连接功能的版本如下。更早的版本没有，也就没有地方粘贴令牌：

接入 MeshServerWatch

MeshServerWatch 与上面的步骤不同：设置位于代理上报的 MeshServerWatch Manager 上，而不在每台被监控的服务器上。需要 Central 1.3.9 及以上，该版本在 Agents 的产品列表中加入了 MeshServerWatch。为 MeshServerWatch 签发令牌，然后在 Manager 界面中打开 Settings → MeshWatch Central，填入 Central 地址和令牌，按 Test：测试成功会保存设置并开启转发；为其他产品签发的令牌会被拒绝并提示所属产品。Manager 转发所有告警（阈值、无上报以及代理的错误日志行）和每台服务器一行设备信息（主机名、IP 和别名、状态 up 或 silent，以及类似 "CPU 12% · Mem 56% · Disk C: 96%" 的一行说明），设备行每台服务器每 5 分钟最多一次。原始指标时间序列从不转发，图表留在 Manager 上。详见 MeshServerWatch 指南第 7 节。

实际经过网络的内容

告警摘要，以及一个用于关联的设备名。仅此而已。

Central 从不接收原始日志行、配置文件、证书、私钥或抓包数据。产品发送的是严重级别、设备名和一行摘要。这不只是隐私立场 — 这也是 Central 能保持轻量的原因，以及在 Central 不可达时产品仍照常工作的原因。

怎么看这些界面

控制台有七个页签：Overview、Incidents、Alerts、Devices、Agents、Users 和 Settings。Agents 和 Users 只对管理员显示。时间按浏览器的本地时间显示；事件报告和 CSV 导出使用 UTC。

Overview

首页，适合一直挂在墙上的屏幕上。上面的一切都是从 Central 已有的数据中统计出来的，没有任何估算；没有数据的面板不会留白，而是写明，例如 none in the last 24 hours。

  • 状态条 — 按状态统计的代理数（reporting、connected、waiting；已吊销的令牌单独计数）、宕机设备、未确认的 critical 告警（全部时间）、最近 24 小时的事件数和告警数及与前 24 小时相比的变化、未确认告警（最近 24 小时和全部时间）。
  • 四个严重级别方块 — 最近 24 小时 critical、error、warning、info 的数量，各自附与前 24 小时相比的变化。
  • Alerts per hour — 以每小时一根柱、按严重级别堆叠显示最近 24 小时，刻度为你所在的时区。鼠标悬停在柱上可看到数量。
  • Noisiest devices 与 Most frequent kinds — 最近 24 小时告警最多的设备和最常见的告警类型，各取前五。
  • Devices down — 只列出由产品直接报告了状态的设备。仅从告警中得知的设备没有状态，因此不会出现在这里。
  • Latest alerts — 最新的十条告警，每条带 Acknowledge 按钮。
  • Last 24 hours by product — 各产品的告警数及与前 24 小时的对比。凡有有效令牌的产品都会列出，包括什么都没发送的。
  • Latest correlated incidents — 最新的五条事件。

Overview、Incidents、Alerts 和 Devices 每 30 秒刷新一次，但当你正在输入框中输入或选择时会跳过这一次，因此不会清掉你输入的内容。Agents、Users 和 Settings 从不自动刷新 — 请按顶部的 Refresh。

告警与事件

告警是某个产品发来的一条报告 — 即 Alerts 中的一行。事件是两个或更多不同产品在 30 分钟内报告了同一台设备。事件在你每次查看时从告警实时计算：从不存储，没有打开或关闭的状态，其告警超过保留期被删除后事件也随之消失。单个产品反复报告同一件事不算事件 — 那在该产品自己的界面里已经能看到。

容易出问题的是“同一台设备”。各产品对设备的叫法不同：DeviceWatch 发送你给设备起的标签，SyslogWatch 发送 syslog 报头中的主机名，TrapWatch 发送发出 trap 的 IP 地址。只有当两个名称仅在大小写或域名后缀上不同时 — core-sw-01.example.com 和 Core-SW-01 都是 core-sw-01 — 或者产品在报告中附带了匹配的 host、IP 或别名时，Central 才把它们视为同一台设备。IP 地址按原样比较。除此之外 Central 不做猜测：Core Switch 这样的标签与 core-sw-01 仍是两台不同的设备，因为错误的合并比不合并更糟。

如果两个产品在监视同一台设备，Incidents 却一直为空，请打开 Devices。如果这台设备出现在两行，说明各产品对它的叫法不同。请把 DeviceWatch 中的标签改成与另一产品所用的主机名一致 — 例如把交换机的标签设为 core-sw-01，而不是 Core Switch。TrapWatch 以 IP 地址称呼设备，因此会与使用同一地址的产品关联。

技术说明：报告格式接受可选字段 host、ip 和 aliases，产品可以发送这些字段。发送时，只要有一个名称匹配，就会把这些行连成同一台设备。

Alerts

所有已接入产品的全部告警汇成一个列表，按产品标注的时间（而不是到达时间）从新到旧排列。可按 Severity、Product 和 State（open 或 acknowledged）筛选。Agent 列显示每行由哪个令牌发送，Kind 显示告警类型；如果某产品的告警出现在另一个产品名下，说明那个令牌是为另一个产品签发的。页签显示符合条件的最新 200 条，标题显示真实总数。

Acknowledge 按单条告警进行，并记录是谁在何时确认的；确认后该行显示此人和时间，而不再显示按钮。operator 和 admin 可以确认；viewer 只看到 open。

Export CSV 下载符合当前筛选条件的告警，最多 500 条，列为 When、Product、Agent、Device、Severity、Kind、Summary、Acknowledged At、Acknowledged By。文件中的时间为 UTC。

Incidents

每个事件一张卡片：设备、其中告警的最高严重级别、涉及的产品、开始时间，以及多少分钟内有多少条告警。如果各产品对设备用了不同名称，其余名称列在 also reported as 之后。下面的时间线按顺序列出每条告警，使用你的本地时间。

Download report 保存一份仅由该事件的告警生成的 Markdown 草稿，其中所有时间均为 UTC。Acknowledge all 一次确认该事件中所有未确认的告警（operator、admin）。如果下载时提示事件已不存在，说明它的告警已超过保留期。

Devices

无论有多少产品报告，每台设备只占一行，列为 Device、Label、Vendor、Reported by、Status、Last report。如果该行还以其他名称匹配过，这些名称显示在设备名下方。有产品报告为 down 的设备排在最前。可用 Product 筛选只看一个产品。

  • Status — 每个产品一个标记。DeviceWatch: up 或 DeviceWatch: down 是该产品报告的状态。from alerts 表示该产品在告警中提到过这台设备，但从未发送过它的状态，因此不知道是 up 还是 down。
  • Last report — 产品在最新一次报告或告警上标注的时间。鼠标悬停可看到 Central 收到它的时间；积压的内容一次性送达时，各条仍保留自己的时间。
  • 点击某一行可展开这台设备在所有产品中的完整告警历史，再点一次收起。

Agents

仅管理员可见。每个令牌一行，列为 Product、Label、Created、Last contact、Last report、State。

  • waiting — 该令牌从未联系过 Central。
  • connected — 产品的 Test connection 已成功，但还没有发送任何内容。在有事情发生之前这是正常的：ConfigWatch 在运行一次备份后发送，TrapWatch 在收到第一个 trap 时发送。
  • reporting — 已发送过告警或设备。

产品不发送心跳，因此 Central 从不把某个产品显示为 down。最后一次收到它的消息是什么时候，看 Last contact（令牌最后一次到达 Central 的时间，无论是测试还是数据）和 Last report。

签发令牌时，选择产品、填写标签，然后按 Issue token。令牌只显示一次，旁边有 Copy 按钮；粘贴到产品中后按 Done，之后便无法再次显示。Revoke 之后，Central 会拒绝此后用该令牌发送的一切；已经收到的内容保留。已吊销的行可以用 Delete 从列表中移除。

用户与角色

仅管理员可见。三种角色：

  • viewer — 只读。
  • operator — 还可以确认告警。
  • admin — 全部：账户、令牌、保留期、更新检查和许可证。

密码至少 12 个字符；用户名为 3–64 个字符，可用字母、数字和 . _ - @。唯一的管理员不能被降级或删除 — 请先把另一个人提升为管理员。写操作在服务端校验，而不只是在界面上隐藏。用户列表下方的 Audit log 显示最新 50 条记录：登录和登录失败、告警确认、令牌签发和吊销，以及用户、设置和许可证的变更，均记录是谁在何时所做。忘记密码时，在服务器上运行 node src/server.js --reset-password <username> 重新设置（在 Docker 中，前面加上 docker exec -it meshwatch-central）。

Settings

  • Licence — 状态、组织、到期日和剩余天数。管理员粘贴密钥后按 Activate（也有 Replace key 和 Remove key）。试用期或许可证结束后，Central 停止接收代理数据；控制台、已有数据和产品本身照常工作。
  • Data retention — Keep alerts for (days)，1 到 730 天。更早的告警会被删除，由它们构成的事件也随之消失。
  • Updates — 默认关闭：在管理员勾选 Check once a day 之前，Central 不发起任何对外连接。开启后，它每天向 meshwatch.app 请求一个静态文件，不发送任何关于你的部署的信息。可以通过策略锁定为关闭。Central 不会自行更新；请拉取新镜像并重建容器。

所有人都能打开 Settings，但只有管理员能修改。

把它正经跑起来

HTTPS

若可从受信网络之外访问，请在前面加反向代理，然后设置 MWC_SECURE_COOKIES=1。在 HTTPS 就位之前设置该标志会导致无法登录 — 会话 Cookie 被标记为 Secure，浏览器不会在明文 HTTP 上发送它。

备份

所有内容都在数据目录里 — 容器里是 /data（映射到 central-data 卷），Node 版则是你设置的 MWC_DATA_DIR。备份该目录就等于备份了 Central：账户、令牌、告警和审计日志。

保留期

最长可配置到 730 天。需要规划的资源是保存告警所占的磁盘空间，它随接入设备数量和保留时长增长。

如果 Central 停了

不会有任何东西堆积到 Central 无法掌控的服务器上，也没有任何产品依赖 Central 才能完成自己的工作。各产品会像 Central 不存在时那样继续监控；你失去的只是统一收件箱和关联，没有别的。产品会把最近的告警放在一个小队列里，等 Central 恢复后再发送。

排查问题

仪表盘全是 0

还没有接入任何产品，或者接入之后该产品尚未产生告警。过去的告警不会补录。

Incidents 一直为空

再接入第二个产品。生成事件需要两个不同的产品在 30 分钟内报告同一台设备。如果已经接入了两个，请打开 Devices：同一台设备出现在两行，说明各产品对它的叫法不同 — 见告警与事件。

浏览器连不上

先确认是 http:// 而不是 https://。然后确认服务器上 8443 端口已开放，并且从另一台机器访问时用的是服务器地址而不是 localhost。

Test connection 提示 bad-token

令牌输错了，或者已被吊销。请在 Agents 中重新签发。令牌只显示一次，之后无法再读取。

告警被拒绝，提示 “at is N minutes in the future”

告警时间比 Central 的时钟快五分钟以上时，Central 会以 400 拒绝。这说明运行该产品的机器时钟偏快，请校准时钟，最好使用 NTP。消息中附有 Central 的时间以便对照。被拒绝的告警不算作报告，因此代理不会变为 reporting。