企业官网建设流程全解析

提起开源运维监控，大家第一反应多半是Prometheus加Grafana，或者Zabbix这种老牌选手。我最早也是在那套组合里折腾，时间久了发现两个痛点：一是组件多，链路长，光是告警规则和仪表盘模板的维护就能让人头大；二是想要一个开箱即用、权限模型清晰、告警治理好用的平台，往往要拼凑好几个开源项目才能满足。后来团队里有人引入了Orion Visor，我一开始没当回事，觉得又是一个重复造轮子的项目，直到真正接手用它做了两套环境的全量监控，才意识到这个平台把很多运维日常里最磨人的细节都处理得比较到位。

这篇手册不是官方文档的翻译，也不是照着README念一遍，而是我结合实际部署、使用和排障经验整理出来的完整使用指南。内容覆盖了从架构规划、安装接入、指标采集、告警治理到权限体系和故障排查的完整链路。无论你是刚接触监控的新手，还是打算把现有监控体系迁移过来的老手，应该都能从里面找到直接可用的操作方法和避坑经验。

1. 部署前先把监控架构想清楚

很多人部署监控平台的习惯是先把服务跑起来，装上Agent看到数据，然后才开始思考到底要监控什么。我不太推荐这个顺序。Orion Visor虽然安装很简单，但如果你不提前规划好监控对象、组件边界和数据流向，后面做告警规则和权限隔离时会非常被动。

1.1 Orion Visor的核心组件与数据流向

Orion Visor在逻辑上分成四个核心部分：

• Server端：负责接收Agent上报的数据、存储时序数据、执行告警规则、提供Web API和页面。它是整个平台的中枢，所有配置变更、用户认证、数据查询都走Server。
• Agent端：部署在被监控主机上的轻量进程，负责采集本机CPU、内存、磁盘、网络等基础指标，同时支持通过插件机制采集Nginx、MySQL、Redis这类中间件指标，还可以执行自定义脚本取数。
• Web控制台：基于浏览器的管理界面，用于配置监控项、制作仪表盘、管理告警规则和维护用户权限。
• 告警通道：Server端内置的通知组件，支持邮件、钉钉/企微机器人、Webhook等多种渠道，告警规则命中后会通过这里推送出去。

数据流向非常直白：Agent按照配置的采集周期抓取指标，批量上报给Server，Server写入自带的时序存储引擎，同时流式匹配告警规则。Web控制台和API都从Server读取数据，不直接跟Agent通信。

这个设计的核心优势在于所有被监控主机都不需要暴露额外端口给外部，只要Agent能主动访问Server的接收端口就行。对于有安全隔离要求的机房网络，这种模型比Server主动拉取的模式省很多事。

1.2 单机部署还是分布式部署

部署方式我建议按照监控规模来定，不要一上来就上集群。参考下表：

我第一次部署时直接用了单机版加内置存储，管理了一百多台虚拟机，跑了快一年都没有遇到性能瓶颈。Orion Visor的时序存储做了压缩处理，单机支撑几百台机器的指标存储其实问题不大。真正需要上集群的场景，通常是你有多个机房需要做数据汇总，或者历史数据保留周期特别长。

有一点必须提醒：部署前先确认Server的时钟要跟NTP同步好。监控系统对时间偏差极其敏感，Agent和Server之间时间差超过30秒，就会出现数据点延迟、告警判断错乱这类奇怪问题。这个问题我后面在故障排查章节还会专门说。

1.3 监控指标规划清单

在动手安装之前，我强烈建议先拉一张监控指标清单出来。别看这个动作简单，它能帮你避免两个常见问题：一是装了Agent却不知道该配置哪些监控项，二是告警规则写得乱七八糟。

一份基础的主机监控清单通常包含以下内容：

• CPU使用率、负载、单核使用率
• 内存使用率、Swap使用率、可用内存
• 磁盘空间使用率、Inode使用率、磁盘读写延迟
• 网络流量入/出、TCP连接数、丢包率
• 系统关键进程存活状态
• 系统日志关键错误关键字匹配

中间件的监控项则根据实际组件来定，比如MySQL要关注慢查询数、连接数、主从延迟；Redis要关注内存碎片率、命中率、阻塞客户端数；Nginx要关注活跃连接、qps、5xx比例。

清单不需要一步到位，但至少要列出“哪些机器、哪些角色、必须监控哪些指标”这个层面的规划。有了这张表，后面配置Agent采集和告警规则的时候效率会高很多。

2. 从零安装到第一台主机接入

Orion Visor的安装流程总体比较顺滑，不过有几个细节在官方文档里写得不显眼，实际安装时容易踩坑。这一节按我的操作顺序走一遍完整流程。

2.1 基础环境准备

服务端我建议至少2核4G内存，磁盘根据存储保留策略决定。如果保留90天的监控数据，每台被监控主机大约占用1-2GB存储空间，你可以按照这个基准去估算。操作系统方面，CentOS 7.9、Ubuntu 20.04以上版本都测试过，没遇到兼容性问题。

需要提前安装的依赖很少，主要是Java运行环境。Orion Visor Server端基于Java构建，推荐使用OpenJDK 11或17：

# Ubuntu / Debian apt update && apt install -y openjdk-11-jdk unzip curl # CentOS / RHEL yum install -y java-11-openjdk unzip curl

安装完验证一下版本：

java -version

搞定依赖后，建一个专用的系统用户来跑Orion Visor服务进程。不建议直接用root跑，万一监控平台自身被攻破，root权限会连带放大风险：

useradd -r -s /sbin/nologin orion mkdir -p /opt/orion chown -R orion:orion /opt/orion

2.2 服务端快速安装

从官方仓库下载最新的服务端安装包，我写这篇手册时用的是3.2 LTS版本。下载后解压到/opt/orion目录：

cd /opt/orion tar zxvf orion-visor-server-3.2.0.tar.gz

解压完先别急着启动，编辑conf目录下的orion.yml配置文件。几个重点配置项：

server: addr: 0.0.0.0 port: 8040 storage: type: embedded # embedded / mysql / postgresql data_dir: /data/orion/tsdb retention_days: 90 receiver: port: 8041 # Agent数据上报端口

Web控制台端口默认为8040，Agent数据上报端口为8041。如果服务器上有防火墙，记得放行这两个端口。storage.data_dir建议放到单独的数据盘，不要跟系统盘混在一起，后面数据量大了方便扩容。

首次启动需要初始化数据库和内置账户：

cd /opt/orion/orion-visor-server bin/startup.sh init bin/startup.sh start

启动后访问http://服务器IP:8040，默认管理员账户是admin，初始密码会打印在启动日志里。第一次登录会强制要求修改密码。

提示：初始化这个动作只做一次，重复执行会把已有配置重置掉。如果你在初始化之后重启了服务，不要再去跑init命令。

2.3 Agent部署与主机接入

服务端起来后，接下来就是把被监控主机接入进来。Orion Visor的Agent安装包同样从官方仓库下载，Linux和Windows都有对应版本。

以Linux主机为例：

tar zxvf orion-visor-agent-3.2.0-linux-amd64.tar.gz -C /opt/orion cd /opt/orion/orion-visor-agent

编辑conf/agent.yml，配置Server地址和主机标识：

agent: id: web-01 name: "生产环境Web节点01" server: host: 192.168.10.10 port: 8041 # 鉴权令牌，在Server端控制台生成 token: orion_xxxxxxxxxxxx collect: interval: 30 # 采集周期，单位秒

启动Agent：

bin/startup.sh start

然后回到Web控制台，在“主机管理”页面应该能看到这台Agent已经处于在线状态。如果显示离线，先检查Agent到Server的8041端口网络连通性，再用bin/startup.sh log查看Agent日志定位原因。

Agent接入这一环最容易出问题的就是token。我第一次批量接入几十台机器时，图省事在每台机器上复制了同一份配置，结果后接入的机器把先接入的机器挤下线了。后来才搞清楚，每台Agent必须使用唯一的token，控制台主机管理页面可以批量生成。这个设计其实是为了防止有人拿别人的Agent token冒充主机混进来，生产环境强烈不建议共享token。

2.4 初始化告警通道

主机接入完成以后，先把告警通道配置好，别等到出故障时才想起来没配通知。Orion Visor的告警通道在“设置-通知渠道”里配置，支持邮件、钉钉/企微机器人、飞书、Webhook。

邮件是最通用的，配置SMTP信息就行：

• SMTP服务器、端口
• 发件人邮箱
• 认证用户名和密码或授权码

配完以后建议立刻发一封测试邮件。我遇到过不止一次，SMTP服务器配置看起来没问题，测试邮件也显示发送成功，但实际到不了收件箱——被当成垃圾邮件了。所以测试时要确认收件箱和垃圾箱都检查过。

如果有钉钉或企微，我更推荐配置机器人Webhook。这类渠道的好处是延迟低、不容易被过滤，而且可以按照告警级别分发到不同群组。比如P0级别告警发到值班群并@人，P2级别告警发到技术讨论群，实现告警分流。

3. 采集器与自定义监控项

平台跑通以后，最核心的工作就变成了采集配置。Orion Visor内置的采集器覆盖了大多数常见场景，但真正让它好用的是自定义采集能力。这一节讲清楚两者怎么配合。

3.1 内置采集器清单

Agent内置的采集器分为系统级和中间件级两类，系统级采集器默认开启，中间件采集器需要在Agent配置中显式启用。

系统级采集器包括：

• cpu：整体使用率、每核使用率、上下文切换数
• memory：内存总量、已用、可用、Swap使用率
• disk：挂载点空间使用率、Inode使用率、读写速率
• network：网卡流量、TCP连接状态统计、丢包率
• process：关键进程存活和资源占用

中间件级采集器需要额外配置，常见的几类：

启用中间件采集器的方式是在agent.yml里加上对应段落，以Nginx为例：

collect: interval: 30 plugins: nginx: enabled: true status_url: http://127.0.0.1/nginx_status

采集器底层原理各不相同，比如nginx_status需要Nginx编译时开启stub_status模块，mysql采集走的是SQL查询，snmp走的是SNMP协议。配置之前先确认目标组件已经开启了对应的状态暴露接口，否则采集器连不上，日志里会一直报错。

3.2 自定义指标采集配置

内置采集器覆盖不了的指标，用自定义脚本采集。Orion Visor的机制很简单：Agent周期性地执行一个脚本或命令，解析输出并把结果上报给Server。这个功能在官方文档里叫exec采集器。

配置方式如下：

collections: - name: app_online_count type: exec interval: 30 timeout: 10 script: /opt/orion/scripts/online_count.sh - name: tcp_time_wait_count type: exec interval: 30 script: "ss -s | grep -o 'timewait' | wc -l"

脚本输出的格式有严格约定，必须是指标名 值的纯文本形式，可以一次输出多行：

#!/bin/bash online_users=$(redis-cli keys "session:*" | wc -l) echo "online_users $online_users" order_error_count=$(grep -c "ERROR" /var/log/app/error.log) echo "order_error_count $order_error_count"

写完脚本注意两件事：一是给脚本加执行权限，Agent是以orion用户身份跑的，要确保orion用户有权限读取相关日志或执行相关命令；二是脚本执行时间不要超过采集周期，否则多个脚本会堆积。我见过有人在监控脚本里写了连接远程数据库的逻辑，结果数据库慢查询导致脚本执行几十秒才返回，整个Agent的采集都被拖慢了。

自定义采集器的好处是扩展能力强，但也要有节制。每台机器上脚本数量过多、执行频率过密，本身就是在消耗被监控主机的资源。我的经验是自定义采集尽量控制在5个以内，能合并的脚本就合并成一个。

3.3 仪表盘建设

数据采上来了，下一步就是仪表盘。Orion Visor的仪表盘采用拖拽式布局，数据源来自监控指标的查询语句。它的查询语法跟PromQL有点类似，但更简单直接。

一条基础的指标查询长这样：

mean(cpu.usage.system, host=web-01)

意思是查询web-01这台主机的CPU系统使用率平均值。如果想看一组机器的聚合数据：

mean(cpu.usage.system, group=web-cluster)

这里web-cluster是主机分组名，在主机管理里配置。把同组机器分到一组，做聚合视图就非常方便。

制作仪表盘时我建议按照“业务视角”而不是“机器视角”来组织。比如建一个“订单服务健康总览”的仪表盘，把订单服务的所有机器CPU、内存、QPS、错误率、JVM GC次数都放在一页，出了问题一眼就能看清影响范围。而不要按机器分页，那样每台机器都得单独看一遍，排障效率很低。

仪表盘模板支持导出导入。我们团队每次优化完一套仪表盘，都会导出一份模板放到团队的文档库里，新项目上线直接导入模板改一下主机分组就行，省了重复拖拽的时间。

4. 告警规则引擎与告警治理

监控平台的核心价值不在于“能看到数据”，而在于“能在故障发生的第一时间通知到人”。告警规则配置得好不好，直接决定值班同学的幸福感。Orion Visor的告警引擎在规则层面支持比较细的控制，值得认真研究一下。

4.1 告警规则配置

一条告警规则由四个核心部分组成：

• 监控指标：要判断的数据源，比如cpu.usage.idle
• 触发条件：比如小于20%
• 持续周期：连续几个采集周期都满足条件才触发
• 通知动作：发给谁、走哪个渠道、什么级别

以CPU使用率告警为例，完整的配置过程如下：

在“告警管理-规则”里新建规则，选择指标cpu.usage.idle（空闲CPU百分比），条件设为“< 20”，持续周期设为3。这里的关键就在持续周期上，它要求连续3个采集周期（也就是90秒）都低于20%，说明CPU持续吃紧，而不是某一次瞬时抖动。

为了说清楚持续周期的作用，我举个例子。有个业务做秒杀活动，活动瞬间CPU使用率冲到95%以上，但几十秒后就回落到正常水平。如果不设置持续周期，系统会告警刷屏，值班同学半夜爬起来一看，什么故障都没有。设置了持续周期后，这种瞬时毛刺会被过滤掉，告警的准确率会高很多。

触发后通知形式也可以配置，支持的选项包括：

• 只通知项目负责人
• 通知整个值班组
• 通知全部项目成员
• 按照告警级别分别通知不同对象

配置完规则一定要做一次模拟测试。Orion Visor的规则管理页有“试跑”功能，用最近的历史数据跑一遍当前规则，可以直接看到这条规则在过去几天里会不会触发。这个功能非常实用，能避免上线一条规则马上被历史数据刷爆的尴尬。

4.2 抑制、静默与升级机制

告警治理最关键的三个机制是抑制、静默和升级。

抑制解决的是“因果告警”问题。比如一台机器挂了，会同时引发主机宕机告警、进程存活告警、端口连通性告警、业务错误率告警。实际上根因是同一个，值班同学只需要收到一条“主机宕机”的通知就足够了。在Orion Visor里可以配置抑制规则：当高优先级规则触发时，自动抑制同一主机或同一分组下的低优先级规则。

静默解决的是计划内维护问题。比如凌晨要对数据库做迁移，过程中告警一定会响，但把告警关闭又怕忘记恢复。静默窗口可以提前设置好时间段，在这段时间内屏蔽指定的告警规则，时间到了自动恢复。注意静默窗口一定要设置结束时间，不要用那种“永久静默”的方式关闭告警，这跟把系统报警器拆了没区别。

升级解决的是告警石沉大海的问题。一条P1告警发出去后，如果15分钟内没有人确认，系统自动升级通知到更上一级的负责人。确认动作很重要，值班同学收到告警后应该在控制台点“确认”，表示已经有人接手处理。超过时间没人确认才触发升级，这是比较合理的逻辑。

4.3 防止告警风暴

告警风暴是所有监控平台都会遇到的问题，Orion Visor也不例外。最典型的是机房网络抖动，导致几百台机器同时失联，每个失联主机都触发一条告警，值班手机直接被刷死。

治理告警风暴有几种策略：

• 分组聚合并压缩通知：把同一分组的多条告警合并成一条摘要消息推送，比如“web-cluster有23台主机失联”，而不是推送23条独立消息。
• 设置频率限制：同一规则在5分钟内最多推送一次通知，而非每次都推。
• 合理的持续周期和确认机制：减少瞬时抖动产生的无效告警。

在实际运维中，我把P1级规则的数量控制在不超过10条，只保留那些真正需要立刻处理的问题，比如数据库主从切换、核心服务全挂。其他问题都用P2、P3级别慢慢跟进。告警规则的数量跟质量是反比关系，规则越多，每条规则被重视的程度就越低。

这里分享一个真实案例。有一年我们上线了一套大版本，发布了40多条告警规则，本意是增强监控覆盖度，结果上线当晚就发生了两次误告警。一次是业务阈值设置得太激进，正常波动都触发；另一次是旧版Agent没有上报某关键指标，规则在Server端查不到数据，直接判定为“数据缺失”触发告警。后来我们定了一个规矩：每条新规则先试跑一周，确认无误再正式启用。这之后误告警率直线下降。

5. 权限模型与多团队使用

当监控平台覆盖的主机和业务越来越多，使用的人也会多起来。开发要看自己服务的状态，运维要看全链路，领导层看总览。如果权限不做隔离，所有人都能改配置、看数据，很容易出现误操作事故。

5.1 用户、角色与项目隔离

Orion Visor的权限模型分三层：用户、角色、项目。一个用户属于一个或多个角色，一个角色可以访问多个项目，项目下挂主机和监控配置。

内置的角色有三个：

• 管理员：拥有平台所有权限，包括用户管理、系统配置、全局告警规则维护。
• 运维操作员：可以维护主机、配置指标和告警规则，但不能管理用户和系统级配置。
• 只读访客：只能查看仪表盘和告警，不能做任何修改。

实际使用中，开发团队账号我基本都设置为只读访客，再按项目维度给他们开放对应项目的查看权限。这样开发能自查服务状态，但不会误动生产监控配置。

配置项目隔离时，一台主机可以属于多个项目，但告警规则的生效范围必须显式指定项目。比如“订单服务”项目只有订单相关的机器和告警规则，“支付服务”项目同理。每个项目下的用户只能看到归属自己的监控数据。

这里有一个很容易忽略的细节：告警通知人也跟项目绑定。如果同一个值班同学同时负责订单和支付两个项目，他加入两个项目后可能会收到重复推送。这个在后续版本里做了去重，但老版本确实会重复推。建议配置完权限后实际测试一遍通知接收情况。

5.2 审计与操作留痕

多团队协作场景下，审计日志几乎是必需品。Orion Visor会把所有敏感操作记录下来，包括用户登录、配置变更、告警规则修改、权限调整等。谁在什么时间改了什么配置，一目了然。

审计日志在“设置-审计日志”里查看，支持按操作人、操作类型、时间范围筛选。对于生产环境的监控平台，我建议把审计日志的保留时间设置为至少180天，便于追溯历史变更。

我遇到过一件印象深刻的事：某天生产环境一台重要机器的告警规则被人删了，业务重要指标淹没了三天，谁都没发现。后来排查下来是一个开发同学在界面操作时误删除。虽然开发同学权限是只读访客，但他借用了一位运维同事的账号登录后操作的，最后通过审计日志锁定了具体操作时间和操作人。从那以后我们强制启用了双因素认证权限，并且规定运维账号不得多人共用。

生产环境最好每次操作都走独立账号，配合审计日志，谁操作的一查便知。这不只是为了追责，更重要的是能快速恢复配置，毕竟监控平台自身的故障往往比业务故障更致命。

6. 运维侧高频问题排查

用得久了，Orion Visor也会遇到一些常见问题。这一节把我在实际运维中碰到过的高频问题整理出来，按排查思路过一遍。

6.1 Agent显示离线

Agent离线是监控平台最常见的故障现象。排查链路如下：

第一步，确认网络连通性。在Agent本机执行：

nc -vz <server_ip> 8041

如果端口不通，先查防火墙、安全组、云平台网络策略。特别是云主机，安全组有几层，容易漏放行Agent上报端口。

第二步，检查Agent进程状态。

ps -ef | grep orion

如果进程没跑，看启动日志：

/opt/orion/orion-visor-agent/bin/startup.sh log

第三步，检查token是否有效。如果Agent配置里的token被吊销，Agent启动时会显示认证失败，需要重新生成token并更新配置。

第四步，检查系统时间偏差。上面提到过，Agent和Server时间差超过30秒会出现数据上报异常。用date命令分别查看两个系统的时间，偏差大的先同步NTP，再重启Agent。

我曾经遇到过一台机器Agent反复掉线，前三个排查项都是正常的，最后发现是这台机器上装了双网卡，Agent默认走了错误的网卡IP上报数据，被Server端拒绝。在agent.yml里显式指定上报网卡IP后就恢复正常了。

6.2 数据存储占用增长过快

监控平台跑了半年以后，数据盘占用率开始告警。这个问题的直接原因是历史数据保留策略设置不当。

排查时先看storage.retention_days配了多久，再看实际数据目录的大小：

du -sh /data/orion/tsdb

如果保留时间是365天，但业务规模已经增长了好几倍，数据量翻番再正常不过。解决方式有两种：一是缩短保留时间，90天对多数场景都足够了；二是把存储迁移到独立大容量数据盘。

另外，自定义采集脚本输出太多指标也会加剧存储增长。比如一个脚本循环输出几十个毫无意义的分区指标，虽然每个指标都很小，但乘以30秒的上报频率和长时间保留，数据量非常可观。定期检查一下指标列表，把没用的指标下线，能省不少空间。

6.3 告警邮件发不出去

告警引擎触发了，但邮件没收到，这是最让值班同学抓狂的问题。排查时按三个环节过一遍。

第一，确认规则是否真的触发了。在“告警管理-历史记录”里看有没有对应记录。如果规则都没有触发，邮件自然没有。常见原因是持续周期设置太长，指标只是短暂下降，还没满足条件就恢复了。

第二，确认通知任务状态。在“通知记录”里看发送状态是成功还是失败。如果发送失败，短信或日志里通常有具体原因，比如SMTP认证失败、连接超时。

第三，确认收件人配置。项目成员的邮箱地址是否正确。我遇到过邮箱域名更新后，收件人配置没同步更新，邮件一直发出但全部退信的情况。

邮件发不出去还有一种隐藏情况，就是通知频率限制。Orion Visor默认同一规则10分钟内最多推送两次，中间的告警会被丢弃，但不会显示在失败记录里。如果要保证P1级别的每条告警都推送，可以单独调高对应规则的频率上限。

6.4 升级前必须做的事

Orion Visor版本迭代比较快，每次升级前我建议按这个清单做一遍准备：

• 备份配置文件和数据目录：cp -r /data/orion /data/orion_bak_$(date +%Y%m%d)
• 在测试环境先升级验证，确认兼容性
• 阅读升级说明，特别关注数据库结构变更
• 升级完成后验证Agent上报、告警规则、通知通道三个核心链路

升级本质上是变更，变更就要有回滚方案。监控平台的升级如果出了问题，直接影响整个运维体系的可观测性，所以务必稳妥行事。我见过有人直接在凌晨的生产环境上升级，遇到启动失败又找不到备份，最后花了几个小时手工恢复配置。教训就是：备份永远要做，回滚方案永远要准备好。

写在最后

这套手册写到的内容，都是我从零开始把Orion Visor接入团队监控体系过程中一步步验证过的。最深的感受是，监控平台的价值不在于功能列表有多长，而在于它能不能稳定地把正确信息推给正确的人。Orion Visor在采集、展示、告警、权限这几个核心环节上都做到了足够好的平衡，又保持了开源项目应有的灵活度。

几个从实际运维中沉淀下来的个人建议：告警规则宁可少而准，也不要多而杂；每个仪表盘都应该按业务视角设计，而不是按机器维度堆砌；所有的配置变更都走真实账号操作，配合审计日志才能追溯。另外，如果计划长期使用，建议尽早把“数据保留策略”和“告警通知频率”这两项调到一个符合实际运维节奏的水平，这能避免后面很多麻烦。

如果你正准备用Orion Visor替换现有监控栈，或者只是想在测试环境先跑起来感受一下，遇到任何配置上的问题都欢迎一起交流。我在上面提到的每一个模块，几乎都有对应的深挖空间，后续可以再展开聊。