1. Hermes Web UI 是什么？它真能替代你每天手动刷日志、查状态、点按钮的重复劳动？

“2026保姆教程 Hermes Web UI 安装配置汉化一站式教学”——这个标题里藏着三个关键信号：时间锚点（2026）、用户身份（新手/运维/开发者）、核心诉求（零门槛落地）。它不是在讲一个冷门工具，而是在回应一个正在快速扩大的现实痛点：越来越多团队开始用 Hermes 作为轻量级 Agent 管理中枢，但官方 Web UI 仍停留在极简原型阶段——没有中文界面、没有向导式配置、没有环境依赖提示、甚至默认端口和 MySQL 表结构都得翻源码注释才能确认。我去年在给一家做边缘设备监控的客户做 PoC 时就踩过这个坑：他们运维团队平均年龄48岁，没人愿意天天敲curl -X POST http://localhost:8080/api/v1/agents/restart，更别说记hermes-gateway和hermes-webui的启动顺序了。最后我们硬是把 Web UI 的前端 i18n 配置项从en-US改成zh-CN，又在后端加了 MySQL 连接池自动重试逻辑，才让整个面板真正“能用”。所以这根本不是个“安装教程”，而是一份面向真实生产环境的适配说明书——它解决的从来不是“能不能装”，而是“装完能不能让非技术人员也敢点、敢改、敢排查”。

Hermes Web UI 本质是一个基于 Vue 3 + TypeScript 构建的管理控制台，它不处理业务逻辑，只做三件事：连接 Hermes Gateway 的 REST API、可视化 Agent 状态拓扑、提供配置下发与日志检索入口。它的轻量体现在两个地方：第一，它不自带数据库，所有元数据（如 Agent 分组、自定义标签、告警规则）必须存到你指定的 MySQL 实例中；第二，它不打包 Node.js 运行时，你得自己准备node和npm环境，再通过npm run build编译成静态资源，最后用 Nginx 托管。这种设计让它能无缝嵌入现有运维体系——比如你可以把它和 Grafana 放在同一台服务器上，用 Nginx 反向代理统一走/hermes路径，连登录鉴权都能复用你已有的 OAuth2 流程。但代价也很明显：它把环境适配的复杂度完全交给了使用者。网上那些“5分钟搞定”的教程，往往默认你已装好 Node.js 18+、MySQL 8.0、Git 2.35+，且系统 PATH 里能直接调用mysql命令——而现实中，很多企业内网服务器连curl都要手动编译，更别说npm install时卡在node-sass编译失败上。所以本篇不讲“标准流程”，只讲你在 Windows 10 内网机、CentOS 7 离线服务器、Mac M1 开发机这三种最典型场景下，如何绕过所有预设陷阱，让页面真正弹出来。关键词里的“汉化”也不是简单替换语言包，而是要解决zh-CN.json文件加载失败、日期格式本地化错乱、表格列宽被英文撑爆等具体渲染问题。现在，我们直接进入实战。

2. 环境准备：别急着 clone 仓库，先确认你的系统是否“已中毒”

很多人装 Hermes Web UI 失败，90% 的原因出在环境检查环节被跳过。官方文档写的是“Requires Node.js >= 16.14.0”，但没告诉你Node.js 的 ABI 版本必须和你系统 glibc 兼容。我在某银行信创云环境部署时就遇到过：他们用的是麒麟 V10 SP1，内核 4.19，glibc 2.28，而 Node.js 18.17.0 的预编译二进制包要求 glibc 2.34+，结果npm install直接报GLIBC_2.34 not found。这种错误不会出现在日志里，只会让你卡在node_modules下载一半不动。所以第一步，不是打开终端，而是执行三组诊断命令，把输出结果抄下来：

# 检查系统基础信息（Linux/macOS） uname -a && lsb_release -a 2>/dev/null || cat /etc/os-release 2>/dev/null # 检查 glibc 版本（关键！） ldd --version | head -1 # 检查 Node.js 是否真可用（注意：不是 node -v，而是验证 ABI） node -p "process.versions.modules"

Windows 用户请打开 PowerShell，运行：

# 获取系统版本 Get-ComputerInfo | Select-Object WindowsProductName, OsArchitecture, OsBuildNumber # 检查 Node.js 模块 ABI（重点看数字） node -p "[process.versions.modules]"

这里的关键是process.versions.modules输出的数字——它代表 Node.js 的 ABI（Application Binary Interface）版本号。常见对应关系如下表所示：

如果你的系统 glibc 版本低于 Node.js 要求，绝对不要强行升级 Node.js。正确做法是降级 Node.js 到匹配的版本。例如 CentOS 7（glibc 2.17）必须用 Node.js 16.x，你可以用 nvm 安装：

# CentOS 7 离线安装 nvm（需提前下载 nvm.sh） curl -o nvm.sh https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh bash nvm.sh source ~/.bashrc nvm install 16.20.2 # 明确指定 ABI 93 版本 nvm use 16.20.2

提示：nvm在 Windows 上不可用，PowerShell 用户请改用nvm-windows，但要注意其最新版仅支持 Node.js 18+，所以 CentOS 7 场景下必须用 Linux/macOS 方式处理。

MySQL 的坑更隐蔽。Hermes Web UI 要求 MySQL 5.7+，但默认字符集必须是 utf8mb4，且排序规则为 utf8mb4_unicode_ci。很多企业 MySQL 实例是 utf8（即 utf8mb3），导致 Agent 标签名含 emoji 时插入失败，Web UI 加载列表直接白屏。验证方法：

-- 登录 MySQL 后执行 SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%'; -- 正确输出应包含： -- character_set_server: utf8mb4 -- collation_server: utf8mb4_unicode_ci

如果不对，别碰my.cnf—— 生产库改错配置可能引发主从同步中断。安全做法是在 Hermes Web UI 启动前，用 SQL 初始化脚本显式指定字符集：

CREATE DATABASE IF NOT EXISTS hermes_webui DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci;

Git 的要求常被忽略。Hermes Web UI 仓库使用了 Git LFS（Large File Storage）管理前端构建产物，如果你用的是旧版 Git（< 2.20），git clone会拉下空的.gitattributes文件，后续npm run build会因缺少dist/目录报错。验证 Git LFS 是否就绪：

git lfs install 2>/dev/null || echo "Git LFS not installed" git lfs version

实测发现，Windows 10 自带的 Git for Windows 2.33+ 默认启用 LFS，但 CentOS 7 的 yum 源里 Git 1.8.3 不支持 LFS，必须手动编译或换用 AppStream 仓库：

# CentOS 7 启用 AppStream（需 root） yum config-manager --enable crb yum install git-all -y

这些检查看似繁琐，但能帮你避开 80% 的“安装失败”问题。我见过太多人花三天调试npm run serve报错，最后发现只是 Node.js ABI 不匹配。记住：环境不是前置条件，而是第一道防线。现在，当你确认node -p "process.versions.modules"输出的数字和系统 glibc 匹配，MySQL 字符集正确，Git LFS 就绪，我们才真正开始克隆仓库。

3. 仓库克隆与依赖安装：为什么npm install总在 node-sass 上卡死？

克隆 Hermes Web UI 仓库本身很简单：

git clone https://github.com/hermes-org/hermes-webui.git cd hermes-webui

但接下来npm install的成败，取决于你是否理解 npm 的依赖解析机制。Hermes Web UI 的package.json中依赖项node-sass是个编译型包，它需要在安装时下载对应平台的二进制文件（.node文件）。这个下载地址由SASS_BINARY_SITE环境变量控制，默认指向 GitHub Releases，而国内网络经常超时。更糟的是，node-sass已于 2020 年停止维护，Hermes Web UI 未升级到sass（Dart Sass），所以你无法用npm install sass替代。解决方案不是换包，而是精准劫持二进制下载源。

首先，确认你当前使用的node-sass版本（查看package.json中"node-sass": "^x.y.z"）：

grep -A 1 '"node-sass"' package.json

假设是^7.0.3，那么它对应的二进制文件 URL 是：

https://github.com/sass/node-sass/releases/download/v7.0.3/darwin-arm64-115_binding.node # Mac M1 https://github.com/sass/node-sass/releases/download/v7.0.3/win32-x64-108_binding.node # Win10 x64 https://github.com/sass/node-sass/releases/download/v7.0.3/linux-x64-108_binding.node # CentOS 7 x64

其中darwin-arm64-115的115就是前面process.versions.modules的值。必须确保版本号严格匹配，否则require()时会报Module version mismatch。

国内用户请设置镜像源：

# 临时生效（推荐，避免污染全局） npm install --sass-binary-site=https://npmmirror.com/mirrors/node-sass/ # 或永久配置（谨慎） npm config set sass_binary_site https://npmmirror.com/mirrors/node-sass/

注意：npmmirror.com是淘宝 NPM 镜像的官方域名，2024 年已弃用registry.npm.taobao.org，用错地址会导致 404。

但即使有镜像，node-sass在某些环境下仍会编译失败。这时要启用“无编译模式”——强制使用预编译二进制：

npm install --ignore-scripts=false --no-optional

--ignore-scripts=false确保node-sass的install.js脚本执行，--no-optional跳过可选依赖（如fsevents，它在 Linux 上无用却常导致失败）。

另一个高频问题是core-js版本冲突。Hermes Web UI 使用 Vue 3，但部分插件依赖core-js@2，而npm install默认会解析出core-js@3，导致Promisepolyfill 错乱，页面白屏。解决方案是在package.json的resolutions字段强制锁定：

"resolutions": { "core-js": "2.6.12" }

然后执行：

npx npm-force-resolutions npm install

npm-force-resolutions是个神器，它会在node_modules安装后，扫描resolutions并覆盖冲突版本。没有它，你得手动删node_modules/core-js再重装，效率极低。

最后，验证依赖是否真正就绪：

npm list node-sass core-js vue # 应输出类似： # └─┬ node-sass@7.0.3 # └── core-js@2.6.12 deduped # └─┬ vue@3.3.8

如果看到UNMET PEER DEPENDENCY或EACCES错误，说明权限或缓存问题。此时不要sudo npm install（危险！），而是重置 npm 权限：

mkdir ~/.npm-global npm config set prefix '~/.npm-global' export PATH=~/.npm-global/bin:$PATH # 写入 ~/.bashrc 或 ~/.zshrc

这套组合拳下来，npm install成功率从 30% 提升到 95%。我在线下培训时让学员现场操作，平均耗时 4 分钟完成依赖安装，比盲目重试快 10 倍。记住：npm install不是魔法，它是可预测的工程行为。每个报错背后都有明确的 ABI、网络、权限线索，抓住它，你就掌控了主动权。

4. 构建与汉化：从zh-CN.json到真正可用的中文界面

npm install成功后，很多人直接npm run serve，结果浏览器打开一片空白，F12 控制台报Failed to load resource: net::ERR_CONNECTION_REFUSED。这是因为npm run serve启动的是开发服务器（Webpack Dev Server），它默认监听http://localhost:8080，但 Hermes Web UI 的前端代码需要和后端hermes-gateway通信，而hermes-gateway默认跑在http://localhost:8081。开发模式下，Vue CLI 会自动配置 proxy，但前提是vue.config.js里的devServer.proxy配置正确。打开vue.config.js，找到这一段：

devServer: { proxy: { '/api': { target: 'http://localhost:8081', // ← 这里必须和你的 hermes-gateway 端口一致 changeOrigin: true, pathRewrite: { '^/api': '' } } } }

如果你的hermes-gateway跑在 9090 端口（常见于 Docker 部署），这里必须改成'http://localhost:9090'。改完保存，重启npm run serve。

但开发模式只适合调试，生产环境必须用npm run build生成静态文件，再用 Nginx 托管。构建前，先解决汉化这个核心需求。Hermes Web UI 的国际化基于vue-i18n，语言包存放在src/locales/目录下。zh-CN.json文件看起来完整，但实际有三个致命缺陷：

1. 日期格式未本地化：moment.js的 locale 配置缺失，导致2024-06-15T08:30:00Z显示为英文Jun 15, 2024；
2. 表格列宽计算错误：中文字符宽度被按英文计算，导致“状态”列文字被截断；
3. API 错误消息直出英文：如Agent not found未映射到中文。

修复方案分三步：

4.1 修复日期本地化

在src/main.js中，Vue.use(VueI18n)之后，添加 moment 本地化：

import moment from 'moment' import 'moment/locale/zh-cn' // 必须显式引入 moment.locale('zh-cn') // 激活 // 然后在 i18n 实例中注册过滤器 const i18n = new VueI18n({ locale: 'zh-CN', messages, dateTimeFormats: { 'zh-CN': { short: { year: 'numeric', month: 'short', day: 'numeric' }, long: { year: 'numeric', month: 'long', day: 'numeric', weekday: 'short', hour: 'numeric', minute: 'numeric' } } } })

4.2 修复表格列宽

Hermes Web UI 使用element-plus的el-table，其列宽由width属性控制。在src/components/AgentList.vue中，找到<el-table-column>标签，将width="120"改为min-width="120"，并添加show-overflow-tooltip：

<el-table-column prop="status" label="状态" min-width="120" show-overflow-tooltip />

min-width让列宽随内容自适应，show-overflow-tooltip鼠标悬停显示完整文字，彻底解决中文截断。

4.3 补全 API 错误映射

在src/utils/request.js中，service.interceptors.response.use的错误处理块里，添加中文映射：

if (error.response?.data?.message) { const msgMap = { 'Agent not found': 'Agent 不存在', 'Invalid token': '令牌无效，请重新登录', 'Database connection failed': '数据库连接失败，请检查 MySQL 配置' } Message.error(msgMap[error.response.data.message] || error.response.data.message) }

做完这三处修改，执行构建：

npm run build

生成的静态文件在dist/目录。此时不要急着启动 Nginx，先检查dist/index.html是否真的加载了中文资源：

grep -A 5 '<script' dist/index.html # 应看到类似：<script src=/js/app.xxx.js></script> # 而不是 <script src=js/app.xxx.js></script>（缺少前缀 /）

如果路径没/前缀，说明vue.config.js中publicPath配置错误。打开vue.config.js，确保：

module.exports = { publicPath: '/', // 必须是 '/'，不是 './' 或 '' outputDir: 'dist', // ... }

publicPath: '/'表示所有资源从根路径加载，这样 Nginx 配置location /hermes { alias /path/to/dist/; }才能正常工作。如果设成./，Nginx 会尝试加载/hermes/js/app.js，但文件实际在/js/app.js，404。

最后，验证汉化效果：用浏览器打开dist/index.html（直接双击），F12 查看 Network 标签页，确认zh-CN.json、app.xxx.js、chunk-vendors.xxx.js全部 200 OK。此时页面应显示完整中文，且鼠标悬停“状态”列能看到完整文字。这才是真正可用的汉化成果，不是简单替换 JSON 文件就能实现的。

5. MySQL 初始化与 Nginx 部署：让静态文件“活”起来的最后两步

npm run build生成dist/目录后，Hermes Web UI 还只是“尸体”——它需要 MySQL 存储 Agent 元数据，并通过 Nginx 暴露给用户访问。这两步看似简单，却是线上故障最高发环节。

5.1 MySQL 初始化：一张表决定你能否看到 Agent 列表

Hermes Web UI 不自带建表语句，它依赖hermes-gateway的数据库 schema。但hermes-gateway的初始化 SQL 分散在多个文件中，最核心的是agent表。你必须手动创建，否则登录后 Agent 列表永远为空。连接 MySQL，执行：

USE hermes_webui; -- 创建 agent 表（精简版，仅含 Web UI 必需字段） CREATE TABLE IF NOT EXISTS `agent` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `name` varchar(255) NOT NULL DEFAULT '' COMMENT 'Agent 名称', `ip` varchar(45) NOT NULL DEFAULT '' COMMENT 'IP 地址', `port` int(11) NOT NULL DEFAULT '0' COMMENT '端口', `status` enum('online','offline','unknown') NOT NULL DEFAULT 'unknown' COMMENT '状态', `last_heartbeat` datetime DEFAULT NULL COMMENT '最后心跳时间', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='Agent 主表'; -- 插入一条测试数据，确保列表不为空 INSERT INTO `agent` (`name`, `ip`, `port`, `status`, `last_heartbeat`) VALUES ('test-agent', '127.0.0.1', 8080, 'online', NOW());

注意：ENGINE=InnoDB和CHARSET=utf8mb4必须显式声明，否则 MySQL 5.7 默认用 MyISAM，不支持外键和事务，后续扩展会出问题。

执行后，用SELECT * FROM agent;确认数据存在。这是 Web UI 能显示 Agent 列表的唯一前提——没有这张表，前端请求/api/v1/agents会返回空数组，页面就是空白。

5.2 Nginx 部署：为什么location / { root dist; }会 404？

Nginx 配置是另一个深坑。网上教程常写：

server { listen 80; location / { root /path/to/hermes-webui/dist; index index.html; } }

这会导致所有路由（如/agents、/settings）直接 404，因为 Vue Router 是 history 模式，它依赖 HTML5 History API，需要 Nginx 将所有非资源请求重写到index.html。正确配置是：

server { listen 80; server_name hermes.local; # 建议用域名，避免端口冲突 # 静态资源直接返回 location / { root /path/to/hermes-webui/dist; try_files $uri $uri/ /index.html; # 关键！所有请求 fallback 到 index.html } # API 请求反向代理到 hermes-gateway location /api/ { proxy_pass http://127.0.0.1:8081/; # 注意末尾的 /，必须有！ proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

try_files $uri $uri/ /index.html是核心：当请求/agents时，Nginx 先找dist/agents文件（不存在），再找dist/agents/目录（不存在），最后返回dist/index.html，由 Vue Router 解析/agents路由。没有这行，Nginx 直接 404。

proxy_pass http://127.0.0.1:8081/末尾的/更关键。如果写成http://127.0.0.1:8081（无斜杠），Nginx 会把/api/v1/agents原样转发，hermes-gateway收到的路径是/api/v1/agents，但它期望的是/v1/agents，导致 404。加了/，Nginx 会自动 strip/api前缀，转发/v1/agents，完美匹配。

配置完成后，重载 Nginx：

nginx -t && nginx -s reload

5.3 终极验证：三步确认部署成功

打开浏览器，访问http://hermes.local（或你的 IP），执行三步验证：

1. 检查 Network：F12 → Network，刷新页面，确认：

   • index.html200 OK
   • js/app.xxx.js、css/app.xxx.css200 OK
   • locales/zh-CN.json200 OK
   • api/v1/agents200 OK，响应体包含test-agent数据

2. 检查 Console：无Failed to load resource、Uncaught ReferenceError等错误

3. 检查页面：左上角显示“Hermes Web UI”，Agent 列表显示“test-agent”，状态为“在线”，鼠标悬停“状态”列显示完整文字

如果三步全通过，恭喜，你已成功部署一个真正可用的 Hermes Web UI。这不是玩具，而是能立刻接入你现有hermes-gateway的生产级控制台。后续只需把hermes-gateway的地址填到 Nginx 的proxy_pass，再在 MySQL 里插入真实 Agent 数据，它就能开始工作。

6. 常见问题排查链路：当页面白屏、API 404、中文乱码时，你该查什么？

部署完成后，90% 的问题集中在三个现象：白屏（Blank Screen）、API 404、中文乱码（Mojibake）。它们不是随机发生，而是有清晰的排查链路。下面以真实案例还原排查过程，教你像老手一样快速定位。

6.1 白屏问题：从 Network 到 Source Map 的逐层穿透

现象：浏览器打开http://hermes.local，页面纯白，F12 Console 空白，Network 标签页只有index.html200，其他资源全 404。

排查链路：

1. 查 Network → index.html：右键index.html→ Open in Sources，搜索<script src=，确认路径是/js/app.xxx.js还是js/app.xxx.js。如果是后者，说明vue.config.js的publicPath错了，回到第 4 节修正。
2. 查 Network → js/app.xxx.js：如果 404，检查 Nginxroot路径是否指向dist目录的父级。例如root /opt/hermes-webui;，则dist必须在/opt/hermes-webui/dist，Nginx 才能找到/js/app.js。
3. 查 Console → Uncaught SyntaxError：如果app.xxx.js200 但报语法错误，说明npm run build时 Babel 配置错误。检查babel.config.js，确认@vue/cli-plugin-babel已安装，且presets包含@vue/app。
4. 查 Source Map：在 Sources 标签页，展开webpack://，找到main.js，设置断点在new Vue({})前，刷新。如果断点不触发，说明app.xxx.js未加载，回到步骤 1；如果触发但i18n初始化失败，说明zh-CN.json加载失败，检查src/locales/路径和 Nginx 静态资源配置。

关键技巧：白屏几乎 100% 是资源加载失败，永远先看 Network，而不是 Console。Console 的错误往往是结果，Network 的 404 才是根源。

6.2 API 404 问题：代理、跨域、路径的三重校验

现象：页面显示“Hermes Web UI”，但 Agent 列表为空，Network 中/api/v1/agents返回 404。

排查链路：

1. 查 Network → /api/v1/agents：点击该请求 → Headers → 查看Request URL。如果是http://hermes.local/api/v1/agents，说明 Nginx 代理生效；如果是http://hermes.local:8081/v1/agents，说明proxy_pass配置错误，Nginx 未接管。
2. 查 Nginx Error Log：tail -f /var/log/nginx/error.log，发起请求，看是否有connect() failed (111: Connection refused)。如果有，说明hermes-gateway未运行，或端口不对。
3. 直连 hermes-gateway：在服务器上执行curl http://127.0.0.1:8081/v1/agents。如果返回数据，说明 gateway 正常；如果 404，检查 gateway 的application.yml，确认server.servlet.context-path是否为/（不能是/gateway）。
4. 查 CORS：如果curl正常但浏览器 404，可能是跨域拦截。在 Nginx 的location /api/块中添加：

   add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE'; add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';

关键技巧：API 问题永远先curl直连，绕过浏览器和 Nginx，快速定位是 gateway 问题还是代理问题。

6.3 中文乱码问题：字符集、编码、字体的三层防御

现象：页面显示“Hermes Web UI”，但 Agent 名称显示为????，或日期显示为Jan 01, 2024。

排查链路：

1. 查 MySQL 字符集：SHOW VARIABLES LIKE 'character_set%';，确认character_set_client、character_set_connection、character_set_database全为utf8mb4。如果不是，执行SET NAMES utf8mb4;临时修复，再检查应用连接字符串是否带?charset=utf8mb4。
2. 查 Nginx 静态文件编码：file -i dist/index.html，输出应为charset=utf-8。如果不是，用 VS Code 以 UTF-8 无 BOM 重新保存index.html。
3. 查浏览器字体：在 Chrome 设置 → 外观 → 自定义字体，确认“标准字体”设为“微软雅黑”或“PingFang SC”。Linux 用户需安装fonts-wqy-zenhei：

   sudo apt-get install fonts-wqy-zenhei # Ubuntu/Debian sudo yum install wqy-zenhei-fonts # CentOS/RHEL

关键技巧：中文乱码必查三层：存储层（MySQL）、传输层（Nginx/HTTP Header）、渲染层（浏览器字体）。漏掉任何一层，都会出现?或方块。

这三条链路覆盖了 95% 的线上问题。记住：每个错误都是线索，不是障碍。当你习惯按链路排查，而不是凭感觉重装，你就真正掌握了 Hermes Web UI 的部署逻辑。

7. 进阶配置：如何让 Hermes Web UI 与你的现有运维体系无缝集成？

部署成功只是起点。真正的价值在于集成——让 Hermes Web UI 不是孤立的面板，而是你现有运维体系的有机部分。以下是三个高价值、低门槛的集成方案，全部基于 Hermes Web UI 的原生能力，无需修改源码。

7.1 单点登录（SSO）集成：用 OAuth2 复用你已有的登录系统

Hermes Web UI 默认使用 Basic Auth，但企业级环境必须对接 LDAP/OAuth2。它通过vue.config.js中的VUE_APP_AUTH_PROVIDER环境变量支持。假设你用 Keycloak 作为认证中心，配置如下：

1. 在vue.config.js中添加：

   module.exports = { defineConfig: { VUE_APP_AUTH_PROVIDER: 'keycloak', VUE_APP_KEYCLOAK_URL: 'https://auth.example.com/auth', VUE_APP_KEYCLOAK_REALM: 'hermes', VUE_APP_KEYCLOAK_CLIENT_ID: 'hermes-webui' } }

2. 在src/utils/auth.js中，login()方法替换为 Keycloak 初始化：

   import Keycloak from 'keycloak-js' const keycloak = Keycloak({ url: process.env.VUE_APP_KEYCLOAK_URL, realm: process.env.VUE_APP_KEYCLOAK_REALM, clientId: process.env.VUE_APP_KEYCLOAK_CLIENT_ID }) export function login() { return keycloak.init({ onLoad: 'login-required' }) }

3. 构建时，npm run build会自动注入环境变量，生成的dist/index.html会加载 Keycloak JS，并在用户访问时自动跳转登录页。

优势：用户用同一套账号密码登录 Hermes Web UI 和 Jenkins、Grafana，审计日志统一，权限策略集中管控。

7.2 日志聚合：将 Agent 日志实时推送到 ELK

Hermes Web UI 的日志检索功能较弱，但它的/api/v1/agents/{id}/logs接口支持流式响应。你可以用 Filebeat 监听 Agent 本地日志文件，再通过 Logstash 过滤后推送到 Elasticsearch：

# logstash.conf input { file { path => "/var/log/hermes/agents/*.log" start_position => "end" } } filter { grok { match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{JAVACLASS:class} %{GREEDYDATA:message}" } } } output { elasticsearch { hosts => ["http://es:9200"] index => "hermes-logs-%{+YYYY.MM.dd}" } }

然后