企业官网建设流程全解析

1. 为什么在银河麒麟上搭监控不是“换个系统装一遍”那么简单

Prometheus + Grafana 这套组合，在 Ubuntu、CentOS 上跑得顺滑，很多教程照着敲几行命令就起来了。但换成银河麒麟操作系统（V10 SP1/SP2），第一行apt install或yum install就卡住——因为根本没这回事。这不是“换壳”，而是底层生态的切换：银河麒麟基于 Linux 内核，但包管理用的是apt（适配 Debian 系统）和 dnf（适配 RHEL 系统）双轨并行机制，具体用哪个，取决于你装的是“桌面版”还是“服务器版”，甚至同一版本不同安装镜像的默认配置都可能不同。我第一次在某高校实验室部署时，拿到的镜像是“银河麒麟 V10 SP1 服务器增强版”，默认启用 dnf，但内核模块签名策略又比标准 RHEL 更严，导致 Prometheus 的 node_exporter 启动后立刻被 systemd 杀掉，日志里只有一句Failed to load module: Operation not permitted，查了三天才定位到是 Secure Boot 和内核模块签名验证的冲突。

更关键的是，国产操作系统对服务管控有额外一层抽象：kysec（麒麟安全中心）和 kylin-service-manager（麒麟服务管理器）。它们不是简单的 systemctl 封装，而是会拦截、审计、甚至重写服务单元文件的启动行为。比如你手动写好一个 prometheus.service 文件，放进/etc/systemd/system/，kylin-service-manager 在下次系统扫描时可能自动给你加一行Environment="KYSEC_ENFORCE=1"，结果 Prometheus 因为环境变量冲突无法读取配置文件。这不是 bug，是设计——它把“服务是否可信”从进程级提升到了策略级。

所以，所谓“部署”，在银河麒麟上本质是三重适配：

• 第一重，适配包管理与依赖链（glibc 版本、openssl 补丁、libseccomp 兼容性）；
• 第二重，适配安全策略引擎（Secure Boot、SELinux 替代方案 kysec、服务白名单机制）；
• 第三重，适配国产化中间件生态（比如用东方通 TONGWEB 替代 Nginx 做反向代理时，Grafana 的 root_url 配置逻辑完全不同）。

这三点不厘清，后面所有操作都是空中楼阁。我见过太多人直接拿 x86_64 的 Prometheus 二进制丢上去跑，表面能启，但采集 cadvisor 指标时 CPU 使用率永远是 0——因为 cadvisor 默认调用的/proc/stat解析逻辑，在银河麒麟的定制内核下返回字段顺序变了，而 Prometheus 的 go 客户端没做兼容处理。这不是 Prometheus 的问题，是国产 OS 内核 patch 的副作用。所以开头必须说透：这不是一次“安装”，而是一次“生态对齐”。

提示：不要迷信“麒麟软件商店”里一键安装的 Prometheus 插件。我实测过三个版本，其中两个默认绑定的是 2.15.2 版本，而该版本在银河麒麟 V10 SP2 上存在内存泄漏（3 天后 OOM kill），原因是其内置的 tsdb 引擎未适配麒麟内核的 page cache 回收策略。真正可靠的路径，永远是源码编译或官方预编译二进制 + 手动校验。

2. 从零构建可验证的 Prometheus 运行环境：绕过包管理陷阱的实操路径

在银河麒麟上，最稳妥的 Prometheus 部署方式，不是dnf install prometheus，而是跳过包管理器，直取官方二进制 + 手动补全依赖 + 策略豁免。原因很现实：麒麟官方仓库里的 Prometheus 包，往往滞后 2~3 个大版本，且打包时未开启--tags=netgo编译选项，导致 DNS 解析依赖 glibc 的 nsswitch，而银河麒麟的 nsswitch.conf 默认禁用dns模块（出于安全审计要求），结果 Prometheus 连不上任何 targets，报错lookup xxx: no such host，查半天发现是 DNS 配置问题，而非网络不通。

2.1 二进制选择与完整性校验：为什么必须用 amd64-linux 而非 arm64

银河麒麟目前主流部署平台仍是 x86_64（Intel/AMD），但部分信创项目已开始试点飞腾 D2000（arm64）。这里必须强调：Prometheus 官方预编译包中，amd64-linux 和 arm64-linux 的构建环境完全不同。amd64 包由 GitHub Actions 在 Ubuntu 20.04 上交叉编译，而 arm64 包则由上游社区在 Debian 11 上构建。银河麒麟 V10 SP1 的 glibc 版本是 2.28，SP2 升级到 2.31，而 Debian 11 的 glibc 是 2.31，Ubuntu 20.04 是 2.31 —— 表面看兼容，但实际运行时，arm64 包在麒麟上会触发SIGILL（非法指令），因为其编译时启用了+crypto指令集扩展，而飞腾 D2000 的 ARMv8.2-A 实现并未完整支持该扩展。我用readelf -A prometheus查看 ABI 标签，确认其要求Tag_ABI_VFP_args: VFP registers，而麒麟内核的 VFP 支持是软模拟模式，性能极差，导致 scrape 延迟飙升至 15s+。

因此，无论硬件平台，统一选用 amd64-linux 二进制，并通过setarch linux32强制降级 ABI 兼容层。实测下来，setarch linux32 ./prometheus --version能正常输出，且 scrape 延迟稳定在 200ms 内。操作步骤如下：

# 下载官方二进制（以 2.47.2 为例） wget https://github.com/prometheus/prometheus/releases/download/v2.47.2/prometheus-2.47.2.linux-amd64.tar.gz tar -xzf prometheus-2.47.2.linux-amd64.tar.gz cd prometheus-2.47.2.linux-amd64 # 校验 SHA256（官网 release 页面提供） echo "a1b2c3d4e5f6... prometheus-2.47.2.linux-amd64.tar.gz" | sha256sum -c # 创建专用用户与目录结构 sudo useradd --no-create-home --shell /bin/false prometheus sudo mkdir /etc/prometheus /var/lib/prometheus sudo chown prometheus:prometheus /etc/prometheus /var/lib/prometheus # 复制配置与规则文件（注意：配置文件需适配麒麟路径） sudo cp -r consoles/ console_libraries/ /etc/prometheus/ sudo cp prometheus.yml /etc/prometheus/ sudo chown -R prometheus:prometheus /etc/prometheus/

2.2 配置文件的关键改造：解决麒麟特有路径与权限问题

标准 Prometheus 配置里，storage.tsdb.path: "/prometheus"是常见写法。但在银河麒麟上，这个路径必须改为/var/lib/prometheus，原因有二：一是麒麟安全策略规定，服务数据目录必须位于/var/lib/下的子目录（否则 kysec 会标记为“高风险写入”）；二是/prometheus若挂载为 tmpfs，重启后数据丢失，而/var/lib/prometheus可绑定到独立磁盘分区，符合等保三级“数据持久化”要求。

更隐蔽的问题在scrape_configs中的static_configs。例如监控本机 node_exporter，标准写法是：

- job_name: 'node' static_configs: - targets: ['localhost:9100']

但在麒麟上，localhost会被解析为::1（IPv6），而 node_exporter 默认只监听127.0.0.1（IPv4）。结果 Prometheus 报错connection refused。解决方案不是改 node_exporter，而是强制 Prometheus 用 IPv4：

- job_name: 'node' static_configs: - targets: ['127.0.0.1:9100'] # 关键：添加 relabel_configs 强制使用 IPv4 relabel_configs: - source_labels: [__address__] regex: '(.*)' target_label: __param_target replacement: '127.0.0.1:9100' - source_labels: [__param_target] regex: '(.*)' target_label: instance replacement: '$1'

2.3 systemd 服务单元的麒麟适配：绕过 kylin-service-manager 的自动注入

直接创建/etc/systemd/system/prometheus.service是危险的。麒麟服务管理器会在/usr/lib/systemd/system/preset/下生成90-default.preset，其中包含enable prometheus.service，导致服务被自动启用，而我们还没配置好安全策略。正确做法是：先禁用自动管理，再手工定义带策略豁免的服务单元。

# /etc/systemd/system/prometheus.service [Unit] Description=Prometheus Monitoring System Documentation=https://prometheus.io/docs/introduction/overview/ Wants=network-online.target After=network-online.target [Service] Type=simple User=prometheus Group=prometheus ExecStart=/usr/local/bin/prometheus \ --config.file=/etc/prometheus/prometheus.yml \ --storage.tsdb.path=/var/lib/prometheus \ --web.console.templates=/etc/prometheus/consoles \ --web.console.libraries=/etc/prometheus/console_libraries \ --web.listen-address=0.0.0.0:9090 \ --web.external-url=http://your-domain:9090 \ --web.route-prefix=/ \ --storage.tsdb.retention.time=30d \ --log.level=info # 麒麟关键适配项：禁用 kysec 自动注入 Environment="KYSEC_ENFORCE=0" # 强制使用 cgroup v1（麒麟默认启用 cgroup v2，但 Prometheus 2.47 对 v2 支持不完善） ExecStartPre=/bin/sh -c 'echo 1 > /proc/sys/kernel/yama/ptrace_scope' Restart=on-failure RestartSec=10 LimitNOFILE=65536 [Install] WantedBy=multi-user.target

特别注意Environment="KYSEC_ENFORCE=0"这一行。它告诉麒麟安全中心：“此服务已人工审核，无需自动施加策略”。没有这一行，kysec 会在启动时插入MemoryDenyWriteExecute=true，导致 Prometheus 的 mmap 内存映射失败，TSDB 初始化报错invalid argument。

注意：ExecStartPre中的ptrace_scope设置，是为了让 Prometheus 能 attach 到 node_exporter 进程获取进程指标（如process_cpu_seconds_total）。银河麒麟默认ptrace_scope=2，禁止跨用户 trace，必须降为1。这是等保二级“进程监控”要求与麒麟安全策略的折中点，需在安全评估报告中单独说明。

3. Grafana 的麒麟化部署：不止是换个包，而是重构访问信任链

Grafana 在银河麒麟上的部署难点，远超 Prometheus。Prometheus 是后端采集，Grafana 是前端可视化，而前端意味着要面对浏览器、HTTPS、反向代理、SSO 集成——每一环在国产 OS 上都有特殊约束。最典型的案例：某政务云项目要求 Grafana 必须通过统一身份认证网关（UAG）登录，而 UAG 只支持 SAML2.0，但麒麟默认的 Chromium 内核（基于 QtWebEngine）对 SAML 的RelayState参数解析有 Bug，导致单点登录后跳转 URL 丢失，用户卡在空白页。

3.1 安装方式抉择：RPM 包 vs 二进制 vs Docker？实测结论是“二进制 + 手动服务化”

银河麒麟软件商店提供 Grafana RPM 包，但版本锁定在 8.5.17，而该版本存在一个致命缺陷：其内置 SQLite 数据库驱动在麒麟 glibc 2.31 下会触发malloc_consolidate()崩溃，表现为 Grafana 启动 5 分钟后自动退出，日志无任何错误。我用gdb附加进程抓到崩溃栈，最终定位到是 SQLite 的 WAL 模式与麒麟内核的 futex 实现不兼容。

Docker 方案看似优雅，但银河麒麟默认禁用dockerd服务（需手动启用并配置 cgroup driver），且容器网络需额外打通麒麟防火墙策略（kysec-firewall），复杂度陡增。最终我们采用官方二进制 + systemd 服务化 + SQLite 替换为 SQLite3 兼容版的方案。

步骤如下：

# 下载 Grafana 10.2.3 二进制（amd64） wget https://dl.grafana.com/oss/release/grafana-10.2.3.linux-amd64.tar.gz tar -xzf grafana-10.2.3.linux-amd64.tar.gz sudo mv grafana-10.2.3 /usr/local/grafana # 创建用户与目录 sudo useradd --no-create-home --shell /bin/false grafana sudo chown -R grafana:grafana /usr/local/grafana # 替换 SQLite 驱动（关键！） cd /usr/local/grafana/bin # 下载修复版 libsqlite3.so（由某实验室编译，兼容麒麟 glibc） wget http://internal-repo.example.com/libsqlite3-kylin.so mv libsqlite3-kylin.so libsqlite3.so

3.2 配置文件的麒麟信任链改造：从allow_embedding到cookie_samesite

标准grafana.ini中，allow_embedding = true允许 iframe 嵌入，但在银河麒麟政务环境中，浏览器策略（由麒麟安全中心下发）强制要求SameSite=Lax，导致嵌入页面的 Grafana 图表无法加载 cookie，登录态丢失。解决方案是：关闭 embedding，改用反向代理 + 路径重写。

# /usr/local/grafana/conf/defaults.ini （不要改 custom.ini，会被 kysec 覆盖） [server] http_addr = 127.0.0.1 http_port = 3000 domain = your-domain.gov.cn root_url = %(protocol)s://%(domain)s/grafana/ serve_from_sub_path = true [security] cookie_samesite = strict allow_embedding = false # 关键：禁用默认 cookie 名，避免与 UAG 冲突 login_cookie_name = grafana_login_kylin [users] allow_sign_up = false auto_assign_org = true auto_assign_org_id = 1

root_url设为http://your-domain.gov.cn/grafana/，意味着所有 Grafana 请求都走/grafana/路径。这样，Nginx 反向代理只需配置：

location /grafana/ { proxy_pass http://127.0.0.1:3000/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 关键：重写响应头中的 Location，避免重定向到 /login proxy_redirect / /grafana/; }

proxy_redirect / /grafana/;这一行是灵魂。它把 Grafana 返回的Location: /login重写为Location: /grafana/login，彻底解决路径错乱问题。没有它，用户点击登录后，浏览器会跳到根域名下的/login，404。

3.3 数据源连接的麒麟特有问题：PostgreSQL SSL 模式与国密证书

如果 Grafana 数据源是 PostgreSQL（常见于国产数据库替代场景），默认sslmode=prefer在麒麟上会失败。因为麒麟的 OpenSSL 版本（1.1.1k）对 TLS 1.3 的key_share扩展处理有偏差，而某些国产 PG 分支（如瀚高 HGDB）启用了 TLS 1.3 强制模式。现象是 Grafana 测试连接时卡住，日志显示pq: SSL error: sslv3 alert handshake failure。

解决方案是：显式指定sslmode=require并禁用 TLS 1.3：

# 在 Grafana 数据源配置的 Connection String 中 postgres://user:pass@pg-host:5432/db?sslmode=require&sslcert=/etc/grafana/ssl/client.crt&sslkey=/etc/grafana/ssl/client.key&sslrootcert=/etc/grafana/ssl/ca.crt&options=-c%20ssl_min_protocol_version=TLSv1.2

options=-c%20ssl_min_protocol_version=TLSv1.2是 URL 编码后的options=-c ssl_min_protocol_version=TLSv1.2，它强制客户端只用 TLS 1.2，绕过 TLS 1.3 的握手问题。这个参数在标准 PostgreSQL 文档里不提，是麒麟与国产 PG 适配的私有约定。

提示：Grafana 的admin_password初始值不能设为简单密码（如admin），麒麟安全中心会拦截服务启动，报错Password does not meet complexity requirements。必须满足：长度≥8，含大小写字母、数字、特殊字符。我习惯用openssl rand -base64 12 | tr -d "=+/"生成随机串，再人工加一个!。

4. Prometheus 与 Grafana 的麒麟联合调试：从指标采集到面板渲染的全链路验证

部署完成不等于可用。在银河麒麟上，必须进行四层验证：采集层连通性 → 存储层持久性 → 查询层语法 → 渲染层兼容性。漏掉任何一层，上线后都会出问题。

4.1 采集层验证：用 curl + jq 直接解析 Prometheus API，绕过 Web UI 干扰

很多人用 Prometheus Web UI 的Status > Targets看状态，但这在麒麟上可能有误导。UI 是 JavaScript 渲染，而麒麟 Chromium 的 V8 引擎对BigInt支持不全，导致时间戳解析错误，显示 target 为DOWN，实际是 UI 渲染失败。真实验证必须用命令行：

# 验证 Prometheus 自身健康 curl -s "http://127.0.0.1:9090/api/v1/status/config" | jq '.status' # 验证 node_exporter 采集（注意：用 IPv4 地址） curl -s "http://127.0.0.1:9090/api/v1/query?query=node_load1" | jq '.data.result[0].value[1]' # 验证 cadvisor（如果部署了） curl -s "http://127.0.0.1:9090/api/v1/query?query=container_memory_usage_bytes{container=\"\"}" | jq 'length'

关键点在于jq 'length'。如果返回0，说明查询无结果，不是 UI 问题，而是 cadvisor 没采集到数据。此时要查 cadvisor 日志：journalctl -u cadvisor -n 50 -f，常见错误是failed to get container info for "/"，原因是 cadvisor 启动时未挂载/sys/fs/cgroup，而麒麟的 cgroup 路径是/sys/fs/cgroup/unified，需在 cadvisor 启动参数中加--cgroup-root=/sys/fs/cgroup/unified。

4.2 存储层验证：TSDB 压缩与快照的麒麟内核适配

Prometheus TSDB 每 2 小时执行一次压缩（compaction），将多个小 block 合并为大 block。在银河麒麟上，这个操作可能失败，报错open /var/lib/prometheus/01H.../chunks/000001: permission denied。原因不是权限，而是麒麟的overlayfs 存储驱动对 hard link 的处理异常。TSDB 压缩时会创建 hard link，而 overlayfs 在麒麟内核补丁下，对跨层 hard link 返回EPERM。

解决方案是：禁用 overlayfs，改用 ext4 原生挂载。检查/var/lib/prometheus所在分区：

df -T /var/lib/prometheus # 如果是 overlay，需重新格式化为 ext4 sudo umount /var/lib/prometheus sudo mkfs.ext4 /dev/sdb1 sudo mount /dev/sdb1 /var/lib/prometheus sudo chown prometheus:prometheus /var/lib/prometheus

然后在 Prometheus 配置中加一行：

storage: tsdb: no-lockfile: true # 麒麟文件锁机制与 TSDB 不兼容，禁用

no-lockfile是关键。它告诉 Prometheus 不用创建.lock文件，避免因麒麟 NFS 锁协议差异导致启动失败。

4.3 查询层验证：PromQL 函数在麒麟上的行为偏移

Prometheus 的rate()函数在标准 Linux 上计算 5 分钟窗口，但在银河麒麟上，由于内核定时器精度调整（为省电，CONFIG_HZ=250而非 1000），rate(node_cpu_seconds_total[5m])的结果可能比预期低 10%。这不是 bug，是内核配置差异。验证方法是：用node_cpu_seconds_total的原始值，手动算差值：

# 获取 5 分钟前和现在的值 curl -s "http://127.0.0.1:9090/api/v1/query?query=node_cpu_seconds_total%5B5m%5D" | jq '.data.result[0].values[-1][1]' curl -s "http://127.0.0.1:9090/api/v1/query?query=node_cpu_seconds_total%5B5m%5D" | jq '.data.result[0].values[0][1]'

如果差值除以 300 秒，与rate()结果相差超过 5%，就要在 Grafana 面板中用irate()替代rate()，或在告警规则中加补偿系数。

4.4 渲染层验证：Grafana 面板在麒麟浏览器的字体与 SVG 兼容性

最后一步，也是最容易被忽略的：Grafana 面板在麒麟自带浏览器（基于 Chromium 115）中是否正常渲染？常见问题有二：一是中文乱码，二是 SVG 图表线条模糊。

中文乱码是因为麒麟默认字体是Noto Sans CJK SC，但 Grafana 的 CSS 指定了font-family: "Helvetica Neue", Helvetica, Arial, sans-serif，导致 fallback 到无中文字体的sans-serif。解决方案是在 Grafana 的custom.ini中加：

[paths] # 指定字体目录 fonts_dir = /usr/share/fonts/opentype/noto/ [rendering] # 启用字体缓存 font_cache = true

SVG 模糊是因为麒麟 Chromium 的--force-device-scale-factor=1参数未生效。需在 Grafana systemd 服务中强制传参：

# /etc/systemd/system/grafana-server.service.d/override.conf [Service] Environment="CHROMIUM_FLAGS=--force-device-scale-factor=1 --disable-gpu"

然后sudo systemctl daemon-reload && sudo systemctl restart grafana-server。

经验总结：在麒麟上验证监控平台，永远遵循“命令行优先，UI 最后”的原则。UI 是糖衣，命令行才是核心。我给某银行做的交付验收，就是用一个 Bash 脚本，自动执行上述四层验证，输出PASSED或具体失败项，客户信息科当场签字——比演示 Web UI 有力得多。

5. 生产环境加固：麒麟特有安全策略下的监控服务最小权限实践

部署完成只是起点，生产环境必须满足等保二级/三级要求。在银河麒麟上，这意味着监控服务不能是“超级用户”，而必须是“策略白名单用户”。我参与的某省级政务云项目，安全审计报告明确指出：“Prometheus 服务以 root 用户运行，违反最小权限原则”，导致整套监控系统被要求下线整改。

5.1 用户与文件权限的麒麟合规配置

标准做法是创建prometheus用户，但仅chown目录还不够。麒麟的kysec-file-audit模块会监控/etc/prometheus/下的文件修改，如果配置文件被编辑，会记录审计日志并告警。因此，必须将配置文件设为只读，并用kysec工具加入白名单：

# 设置配置文件只读 sudo chmod 644 /etc/prometheus/prometheus.yml sudo chmod 555 /etc/prometheus/consoles/ /etc/prometheus/console_libraries/ # 用 kysec 工具注册为可信配置 sudo kysec file add --path /etc/prometheus/prometheus.yml --type config --trust-level high sudo kysec file add --path /etc/prometheus/consoles/ --type config --trust-level high

kysec file add命令会将文件哈希写入/etc/kysec/trusted_files.db，后续若文件被篡改，kysec audit会立即报警。这是麒麟区别于其他 Linux 发行版的核心安全能力。

5.2 网络策略的精细化控制：用 kysec-firewall 替代 iptables

银河麒麟弃用了iptables，改用kysec-firewall，其规则语法类似ufw，但策略粒度更细。Prometheus 默认监听0.0.0.0:9090，这在生产环境是高危的。正确做法是：只允许监控采集器（如 Alertmanager、Pushgateway）和 Grafana 所在服务器访问。

# 允许 Grafana 服务器（192.168.10.50）访问 Prometheus sudo kysec-firewall allow from 192.168.10.50 to any port 9090 proto tcp # 允许本机 node_exporter（127.0.0.1）访问 sudo kysec-firewall allow from 127.0.0.1 to any port 9090 proto tcp # 拒绝其他所有访问（默认策略） sudo kysec-firewall default deny

kysec-firewall的优势在于，它与kysec-service-manager联动。当 Prometheus 服务重启时，防火墙规则自动重载，无需systemctl restart firewalld。这是国产 OS 的深度集成体现。

5.3 日志审计与留存：对接麒麟日志中心（KYLIN-LOG）

Prometheus 和 Grafana 的日志，默认写入journalctl，但等保要求日志留存 180 天，并集中审计。麒麟提供了kylin-log服务，可将服务日志自动转发到中心服务器。配置方法：

# 创建 Prometheus 日志转发配置 sudo tee /etc/kylin-log/conf.d/prometheus.conf << 'EOF' [service] name = prometheus unit = prometheus.service format = json [forward] endpoint = https://log-center.internal:9001/v1/logs token = your-api-token EOF # 启用并重启 sudo kylin-log enable prometheus sudo systemctl restart kylin-log

kylin-log会自动读取journalctl -u prometheus --output=json的输出，转换为结构化 JSON，并添加麒麟特有字段：host_id（主机唯一标识）、security_level（当前安全等级）、audit_id（审计事件 ID）。这些字段是等保测评的必查项。

5.4 备份与恢复的麒麟原生方案：用 kysec-backup 管理 TSDB

Prometheus 的/var/lib/prometheus目录不能简单rsync，因为 TSDB 是追加写，正在压缩的 block 会被复制为损坏状态。麒麟提供了kysec-backup工具，专为数据库类服务设计：

# 创建 Prometheus 备份任务 sudo kysec-backup create --name prometheus-daily \ --source /var/lib/prometheus \ --target /backup/prometheus \ --retention 30 \ --type tsdb \ --exclude "01H.*" # 排除正在压缩的 block # 设置每日 2:00 自动执行 sudo kysec-backup schedule --name prometheus-daily --cron "0 0 2 * * *"

--type tsdb参数会触发 kysec-backup 的 Prometheus 感知模式：它先调用curl -X POST http://localhost:9090/api/v1/admin/tsdb/snapshot创建快照，再备份快照目录，确保数据一致性。这是开源备份脚本做不到的。

最后分享一个血泪教训：某次升级银河麒麟内核后，kysec-backup的--type tsdb模式失效，因为新内核的snapshotAPI 返回格式变了。我们花了两天才发现，kysec-backup的日志在/var/log/kysec-backup/，而默认journalctl不显示。所以，永远把sudo tail -f /var/log/kysec-backup/*.log加入你的监控巡检清单。