提起开源运维监控大家第一反应多半是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按照配置的采集周期抓取指标批量上报给ServerServer写入自带的时序存储引擎同时流式匹配告警规则。Web控制台和API都从Server读取数据不直接跟Agent通信。这个设计的核心优势在于所有被监控主机都不需要暴露额外端口给外部只要Agent能主动访问Server的接收端口就行。对于有安全隔离要求的机房网络这种模型比Server主动拉取的模式省很多事。1.2 单机部署还是分布式部署部署方式我建议按照监控规模来定不要一上来就上集群。参考下表规模建议架构适用场景50台以内单机部署SQLite或内置存储小团队、测试环境、分支机房50-500台单机部署外部数据库生产环境主监控中等规模500台以上Server集群外部时序数据库大型IDC、多云环境汇总监控我第一次部署时直接用了单机版加内置存储管理了一百多台虚拟机跑了快一年都没有遇到性能瓶颈。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/orion2.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控制台端口默认为8040Agent数据上报端口为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 # 采集周期单位秒启动Agentbin/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关键进程存活和资源占用中间件级采集器需要额外配置常见的几类采集器监控对象关键指标nginxNginxqps、活跃连接、5xx错误数mysqlMySQL连接数、慢查询、主从延迟redisRedis内存碎片率、命中率、阻塞客户端jvmJava应用堆内存、GC次数、线程数snmp网络设备端口状态、流量、CPU启用中间件采集器的方式是在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, hostweb-01)意思是查询web-01这台主机的CPU系统使用率平均值。如果想看一组机器的聚合数据mean(cpu.usage.system, groupweb-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替换现有监控栈或者只是想在测试环境先跑起来感受一下遇到任何配置上的问题都欢迎一起交流。我在上面提到的每一个模块几乎都有对应的深挖空间后续可以再展开聊。 
长河君 · 2026/10/9 6:39:28 · 阅读 1.2k 开源监控平台Orion Visor实战：部署、告警治理与权限隔离
提起开源运维监控大家第一反应多半是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按照配置的采集周期抓取指标批量上报给ServerServer写入自带的时序存储引擎同时流式匹配告警规则。Web控制台和API都从Server读取数据不直接跟Agent通信。这个设计的核心优势在于所有被监控主机都不需要暴露额外端口给外部只要Agent能主动访问Server的接收端口就行。对于有安全隔离要求的机房网络这种模型比Server主动拉取的模式省很多事。1.2 单机部署还是分布式部署部署方式我建议按照监控规模来定不要一上来就上集群。参考下表规模建议架构适用场景50台以内单机部署SQLite或内置存储小团队、测试环境、分支机房50-500台单机部署外部数据库生产环境主监控中等规模500台以上Server集群外部时序数据库大型IDC、多云环境汇总监控我第一次部署时直接用了单机版加内置存储管理了一百多台虚拟机跑了快一年都没有遇到性能瓶颈。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/orion2.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控制台端口默认为8040Agent数据上报端口为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 # 采集周期单位秒启动Agentbin/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关键进程存活和资源占用中间件级采集器需要额外配置常见的几类采集器监控对象关键指标nginxNginxqps、活跃连接、5xx错误数mysqlMySQL连接数、慢查询、主从延迟redisRedis内存碎片率、命中率、阻塞客户端jvmJava应用堆内存、GC次数、线程数snmp网络设备端口状态、流量、CPU启用中间件采集器的方式是在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, hostweb-01)意思是查询web-01这台主机的CPU系统使用率平均值。如果想看一组机器的聚合数据mean(cpu.usage.system, groupweb-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替换现有监控栈或者只是想在测试环境先跑起来感受一下遇到任何配置上的问题都欢迎一起交流。我在上面提到的每一个模块几乎都有对应的深挖空间后续可以再展开聊。