之前有朋友在运维群里问过我一个问题同一台 Windows 服务器上能不能同时跑两个 BMC PatrolAgent而且端口要不一样。当时他遇到的情况是一台测试机既要旁路监控生产库的性能又要模拟独立环境给开发联调默认装好的代理只监听 10128 端口第二个实例根本起不来。这个需求听起来不复杂真动手时却踩了不少坑。BMC PatrolAgent 在 Linux/Unix 环境下多实例相对好办无非就是多套配置加不同启动参数换到 Windows 上服务注册、配置库、端口占用、日志路径这些问题交织在一起任何一环没理顺代理要么起不来要么起来之后被控制台误连。这篇文章不打算讲太虚的理论直接把我在 Windows 上折腾多实例的完整过程和复盘记录下来从为什么需要多实例、端口怎么规划到具体怎么注册服务、怎么排查冲突一次性说清楚。1. 为什么要在一台 Windows 上跑多个 PatrolAgent 实例1.1 常见场景与需求拆解很多人第一反应是“一个代理不就能监控一台机器吗搞多个实例干什么”。实际上BMC PATROL 架构里Agent 只是采集端的进程真正把监控策略、应用脚本、告警规则串起来的是 Agent 加载的 PSL 配置和各种 KMKnowledge Module。一台服务器上如果既要监控数据库又要监控中间件还得分隔测试数据和生产告警单个 Agent 虽然能通过加载多个 KM 实现但配置互相耦合会非常痛苦。最常见的几个多实例场景一是测试环境隔离。同一台 Windows 机器上开发环境装一套 Agent预发布环境再装一套两套实例互不干扰各自的告警阈值、日志级别、数据保留策略完全独立。二是多业务线分开管理。比如一个驻点机房里有 A 和 B 两套应用系统虽然跑在同一台物理机上但归属不同运维团队每个团队希望用自己的控制台连接自己的 Agent这时候单实例没法满足管理边界。三是采集能力拆分。某个 Agent 因为加载的监控模块太多轮询周期被拉长把重负载的 KM 拆到独立实例上等于给 CPU 和内存做了分流。这些场景落到技术上本质就是要在 Windows 的进程和服务管理框架下实现多个 PatrolAgent 进程共存。而进程共存最关键的一点就是每个实例必须拥有独立的端口和独立的身份标识否则控制系统无法分辨“谁是谁”。1.2 端口为什么是核心冲突点PatrolAgent 和其他监控代理不太一样它不是一个纯单向上报的组件。PATROL Console、BMC Patrol 控制台服务器、脚本客户端等都会通过 TCP 直接连接 Agent 的监听端口进行数据读取和指令下发。默认情况下PatrolAgent 监听的是 10128 端口这个端口既承担了数据查询请求也承载了控制台管理通道。如果两个 Agent 实例使用同一个端口TCP 层面就会发生 bind 冲突。Windows 上你很快会看到类似“端口已被占用”的报错服务刚启动几秒就自动退出。即便退一步说你通过某种方式让两个实例都监听同一个端口数据包到了之后也没法正确路由到对应的实例控制台连进来之后看到的数据完全是错乱的根本无法用于生产。所以多实例的第一步就是提前把端口资源规划好。我自己的习惯是维护一张端口分配表比如默认实例继续用 10128新增实例从 10130 开始分配按 2 的倍数预留避免和其他监控软件的默认端口冲突。端口规划时还要注意避开 Windows 的“动态端口范围”这块容易被人忽略。2. 启动多实例前的环境准备与目录规划2.1 软件清单与版本确认动手之前先把环境信息摸清楚。我建议至少记录以下几项PATROL 版本号打开 Agent 安装目录找到版本信息文件或者直接在安装目录下运行 patrol -v 之类的命令确认版本。不同版本的参数和服务注册方式有差异老版本 3.x 和较新的 8.x/20.x 行为差别很大。安装路径比如 C:\Program Files\BMC Software\Patrol这个路径是后续定位配置、日志、PSL 脚本的基准。当前运行账号Agent 服务默认可能是 LocalSystem如果涉及网络盘采集、UNC 路径日志读取建议给独立实例建一个专属域账号避免权限互踩。已注册的 Windows 服务名通过 services.msc 或 sc query 确认当前存在的服务比如 “PatrolAgent” 或 “BMC Patrol Agent”后面新实例的服务名不能重复。需要注意我这里说的“BMC”是 BMC Software 的 PATROL 产品体系不是服务器主板上那个带外管理芯片 BMC。两个概念在网络检索时很容易混在一起但接下来的操作完全是围绕 PATROL Agent 进行的。2.2 目录复制还是重新安装两种方案的取舍Windows 上要起第二个实例我见过两类做法。一类是老老实实跑一遍安装程序装第二个实例到不同目录另一类是复制现有安装目录再通过修改配置和注册服务来实现“绿色多实例”。先说说重新安装。这种方式思路最简单安装向导会帮你把目录结构、注册表项、服务条目都理顺而且天然支持多实例。它的主要缺点是耗时较长而且如果你的环境里没有保留安装介质或 License 文件会比较被动。另外两台实例共用同一个 License 或者插件包时安装过程可能需要额外处理。复制目录的方案则灵活得多。把整个 Patrol 安装目录复制一份到新路径比如复制为 C:\Program Files\BMC Software\Patrol_Instance2然后在这个副本上修改配置文件、重新注册服务。这样做的优势是快而且可以在不碰原实例的情况下反复试验。劣势是某些版本会把路径信息写在注册表里副本直接跑会出错你需要额外确认并修正这些注册表项。从我个人的实操经验来看推荐先用复制目录的方式完成验证确认配置无误后再考虑是否正式注册为服务。验证阶段即使搞坏了也只是副本坏了原实例不受影响。生产环境如果条件允许更稳妥的做法还是独立安装第二套实例后续升级维护省心。2.3 关键配置项梳理不管采用哪种方案有几个配置项是所有多实例操作都必须面对的端口参数通常记录在 PATROL 配置库中默认端口是 10128新实例需要改成其他未被占用的端口。实例名称/别名这个标识用于区分不同实例有些版本会体现为运行参数中的实例名。日志路径多个实例如果共用目录日志文件会互相覆盖这是最隐蔽的坑之一。PSL 脚本和 KM 加载路径不同实例加载不同的知识模块时要确保路径指向各自的副本不能共享写操作的文件。控制台连接参数PATROL Console 连接时地址通常是 IP:端口端口不同才能把流量分到不同实例。我习惯把这些信息整理成一个表格贴在服务器旁边或者写进实例目录下的 README 文件里。毕竟 Windows 服务注册成功后很多时候你一眼是看不出它对应哪个端口的全靠文档辅助。3. Windows 下多实例的具体启动步骤3.1 生成独立配置目录先假设你已经有了一个可用的 PatrolAgent 安装目录现在要新增一个实例。第一步不是急着改文件而是先停下来想清楚新实例的文件布局。我的做法是这样的在原安装目录同级创建新目录比如把原目录名从 Patrol 改成 Patrol_Prod1同时复制一份为 Patrol_Prod2。如果你不想动原目录的名字也可以直接复制原目录为 Patrol_Test1原目录保持 Patrol 不变但这样目录名字跟实际用途对不上时间长了会混乱。复制完成后进去检查几个关键子目录bin可执行文件所在目录验证 patrol.exe 或对应的服务封装程序是否都在。psl/config这里存放 Agent 的 PSL 配置脚本是端口参数和监控策略的核心。log确认日志文件路径后续要确保新实例的日志写到新目录里。knowledgeKM 模块包复制完成后如果有动态生成的文件注意保留原权属。这一步最容易出错的地方就是“复制不完整”。Windows 下有些文件被服务占用无法复制有些隐藏文件没复制到等启动时才会暴露问题。所以复制完最好对比一下源目录和副本目录的文件数量尤其是 bin 和 psl 目录别漏文件。3.2 修改端口参数接下来要修改配置。PATROL 的端口参数不是简单地改一行文本就能完事它可能同时存在于配置库注册表、PSL 脚本、甚至启动参数中。三者必须保持一致。在较老的传统 PATROL 版本中可以通过 Pconfig 工具进入代理配置界面找到配置树中的端口项进行修改。常见的配置树路径大致在 Agent 配置节点下有一个描述监听端口的属性。输入新端口后再保存并退出。这种方式比较直观但不同版本界面差异很大没找到对应路径时别硬找直接查阅当前版本的配置手册更高效。在新一些的版本里也可以通过命令行参数强制指定端口。比如启动时追加-p 11128这样的参数具体参数符号以版本为准。这种方式不用动配置库但前提是服务启动命令能带上这个参数。如果你使用 Windows 自带的服务注册方式binPath 里可以把参数写进去。我实际验证过的一种组合方式用文本编辑器打开新的 PSL 配置文件中与端口相关的配置项。将监听端口改成 11128。同时把备用端口或动态端口范围相关的参数也改成不冲突的区间。保存文件后使用配置检查命令或工具做一次语法检查确保配置能被 Agent 正常解析。这一步的核心原则是“配置、参数、实际监听三者一致”但凡遗漏一处后面排查起来就是连环问题。3.3 注册独立 Windows 服务万事俱备最后是把新实例做成 Windows 服务这样能随系统启动、能被 sc 命令统一管理。注册服务前先确认原实例的服务名和显示名比如默认叫 “BMC Patrol Agent” 或 “PatrolAgent”。新实例绝对不能重名。我一般用 sc 命令直接创建服务命令大致如下sc create PatrolAgentTest1 binPath C:\Program Files\BMC Software\Patrol_Test1\bin\patrol.exe -p 11128 -n Test1 start auto DisplayName Patrol Agent Test1需要注意sc 命令的等号后面必须带一个空格这是 Windows 的老规矩写成binPath不带空格会被拒绝执行。如果你拿不准服务程序的完整路径和参数可以直接打开原实例服务的属性查看把启动参数复制过来再替换成新实例路径和端口。有些管理员喜欢直接复制注册表里的服务项再手工改名字和路径。我不推荐这种方式因为服务注册表还包含很多内部标识符手动改容易留下隐患。用 sc create 扫清重来比复制修改要干净。创建完成之后可以用sc query PatrolAgentTest1确认服务状态然后先把“启动类型”设为手动做一次人工启动测试避免开机自启后立刻出问题。3.4 启动与验证服务注册完成后键入以下命令启动新实例net start PatrolAgentTest1启动命令执行后别急着下结论。我给自己定了一个“三步验证法”第一步用任务管理器确认进程存在。多实例环境下进程名可能都一样所以还要看进程对应的命令行参数。Windows 任务管理器默认不显示命令行你可以用 PowerShell 辅助Get-WmiObject Win32_Process -Filter Namepatrol.exe | Select ProcessId, CommandLine看到参数里有-p 11128或对应的新路径才算第一关通过。第二步用 netstat 验证端口监听netstat -ano | findstr 11128如果看到 LISTENING 状态并且对应 PID 落在新实例进程上说明端口绑定成功。如果端口监听的是 0.0.0.0说明 Agent 至少已经起来了。第三步从 PATROL Console 尝试连接新实例。地址填本机 IP端口填新端口。能正常登录并看到监控数据才算端到端验证完成。这一步非常关键因为前面两步只能证明“端口开了”不能证明“代理正常对外服务了”。我刚开始做的时候到了第二步就以为大功告成结果 Console 始终连不上最后发现是防火墙拦了端口白白折腾了半小时。所以建议把第三步作为不可省略的验收环节。4. 端口冲突与服务启动失败的常见问题4.1 服务启动即退出的排查多实例最容易遇到的坑就是服务启动后立刻退出事件日志里只有一句“服务意外终止”其他什么信息都没有。这通常不是什么大问题而是配置里端口没改干净。我遇到过一次特别隐蔽的情况新实例把配置文件里的主端口改了但 PSL 配置库里还有一串“额外监听端口”或“管理端口”配置这些端口还保留着旧值。Agent 启动时先绑定了新端口然后又去绑定旧端口结果旧端口被原实例占用bind 失败Agent 自行退出而日志因为刷新不及时根本不记录失败原因你只能靠排除法定位。排查步骤建议按照“先看进程、再看端口、最后看日志”的顺序启动服务后立即查看进程是否存活。如果秒退用命令行前台方式启动直接把报错输出打到屏幕上。用命令行方式启动时通常会直接显示缺少文件、配置解析失败、端口绑定失败等具体原因。比如patrol.exe -p 11128 -n Test1前台运行一段看到什么样报错再针对性修复。如果还不行看 log 目录下最新生成的日志文件。注意查看时间戳确保你打开的是新实例自己写的日志而不是原实例的日志。4.2 端口被占用与防火墙规则端口被占用是第二个高频问题。Windows 上端口被占的情况分为两种一种是其他进程明确占用了相同端口。这种情况网上一搜一大把不细说。另一种比较坑是端口虽然看起来没人占用但被排除在可监听范围之外。Windows 默认有一段动态端口范围如果你把新实例的端口恰好分配在这段范围内某些系统行为会导致 bind 失败。检查命令如下netsh int ipv4 show excludedportrange protocoltcp如果新端口落在 Excluded Port Range 里需要换一个端口或者用管理员权限重新设置排除范围。我实操中遇到过把端口分配给动态端口范围导致服务一直无法启动的情况查了很多资料最后靠 netstat 和排除端口范围对比才发现。所以规划端口时尽量避开随机动态范围这样最省事。防火墙规则也容易漏。PATROL Console 和 Agent 之间是 TCP 长连接Windows 自带的防火墙默认可能拦截入站连接。如果你的 Windows 服务没有启用“允许应用通过防火墙”的规则或者新端口没有单独加规则从远程控制台连接时大概率超时。创建规则的命令如下netsh advfirewall firewall add rule namePatrolAgentTest1 11128 dirin actionallow protocolTCP localport11128这条规则只针对新实例端口不会影响原有的 10128 端口规则。4.3 配置被覆盖的坑多实例最容易忽略的问题是文件共享导致的配置串扰。如果你用的是复制目录的方案但新实例里某些配置文件仍然通过绝对路径指向了原目录或者某些工具组件默认从注册表读取原目录信息就会出现“你明明改了新实例的配置重启后却变成了旧实例的内容”。我遇到过这么一次新实例复制完成后我把服务注册好了端口也调了启动也正常。第二天重启机器服务起不来了。一查才发现安装包里有个配置工具在服务启动时会自动从注册表读取“最后一个安装的目录”并尝试把默认配置推到这个目录里。新实例启动后实际读取的配置文件反而被写回了旧实例路径。这种问题最阴险因为它完全跳过了你手动修改的文件。我的解决方案是在注册表里查找包含旧路径的键值把所有指向原实例目录的项全部改成新实例目录。当然注册表操作有风险改之前必须备份。不要把操作流程想当然改完了再用重启验证一次。另外多实例共用 License 文件也会有隐患。有些 License 信息绑定的是机器名这种情况多个实例可以共存但如果绑定的是端口或实例名新实例启动时可能因为读不到合法 License 而出错。遇到这种问题检查新实例日志里是否有 License 相关报错把授权信息同样准备好。4.4 常见问题速查表平时排障时我习惯把问题归成一张表方便快速定位。这里直接分享出来你可以直接拿来当参考现象可能原因排查命令/工具解决思路服务启动后秒退配置端口未改全前台运行 Exe看控制台输出搜索配置中全部端口相关项端口 LISTENING 但不是新 PID服务启动参数不对netstat -ano 对比 PID修正服务 binPath 参数控制台远程连接超时防火墙未放行telnet IP 端口添加防火墙入站规则新实例日志写进了旧目录配置文件里有硬编码路径查看日志文件路径全局替换旧路径为新路径服务启动但控制台提示无 LicenseLicense 与实例绑定查看日志 License 报错确认授权方式并重新激活配置改了却总是恢复原状注册表键值指向旧目录reg query 搜索原路径备份并修正注册表路径键值端口绑定失败且排除范围覆盖该端口落入了动态端口区间netsh 查看排除范围更换端口或调整排除范围表格里的思路是我实际用过的不是理论推演基本上照着查都能找到根因。5. 多实例运维的实用技巧5.1 开机自启与故障转移注意事项多实例注册成 Windows 服务后开机自启看似自动搞定实际运行时仍有几个问题建议提前处理。首先服务启动顺序。如果两个 PatrolAgent 服务的启动类型都是自动Windows 启动时会并行拉起虽然通常不会互相影响但如果你的配置文件放在网络共享路径或者某个实例依赖另一个实例生成的文件就可能碰到启动顺序问题。解决办法是把依赖服务的实例启动类型改成“自动(延迟启动)”或者写一个启动脚本在主服务起来之后再启动第二个实例。其次服务崩溃后的自动恢复。我强烈建议给每个实例单独设置服务恢复策略。在服务属性里把“第一次失败”设为“重新启动服务”并加好重启间隔和重置计数。多实例环境里一个实例崩溃通常不会影响另一个但如果没人自动拉起业务监控就断了。最后如果想做故障转移比如 A 实例挂了之后由 B 实例接管端口继续提供服务那就不能靠纯 Windows 服务自愈了。操作层面至少要把端口、配置、启动脚本做成模板配套写一个检测脚本通过计划任务定时探测端口发现异常时自动启动备用实例。这里我还想提醒一句千万别把两个实例配置成同一端口并期望它们做集群容错PATROL 本身不支持这种模式轻则启动失败重则数据混乱。5.2 日志采集与监控验证多实例跑起来之后日志是最宝贵的排障资源。我在每个实例的日志目录里都额外加了保留策略比如只保留最近 10 天日志避免磁盘被写满。Windows 上最简单的做法是写一个清理脚本用计划任务每天跑一次。日志不要太依赖“事后看”。更省心的做法是让两个实例的日志集中到一个统一日志目录再配合文件大小轮转。如果公司有日志采集平台可以把 PATROL 日志目录接入采集器这样多实例的日志就能在同一套查询界面里比对排查跨实例问题时非常方便。还有一类验证要定期做模拟连接。我每隔一段时间会写一个小脚本用 PowerShell 尝试连接各实例端口确认服务不是“假活”。所谓“假活”就是进程在、端口在但 Agent 不响应查询请求。这通常是因为 PSL 配置卡死或 KM 加载异常。脚本里至少要做一次 TCP 连接测试和一次 PATROL 协议握手测试光测端口绝对不够。5.3 版本升级与回滚多实例环境下的升级比单实例复杂因为你要保证两个实例并存时版本兼容。我踩过一次坑把实例 A 升级到新版本实例 B 还留在旧版本结果两边因为共享了部分公共组件升级后实例 B 的行为出现异常排查了两天才定位到是版本混用的问题。所以升级前必须先备份而且是“原目录 配置 注册表服务项”三层备份。升级时尽量按“先停旧服务、替换文件、备份配置、再启动”的标准流程走不要直接在服务运行状态下覆盖文件。如果你用复制目录方案升级只复制到新目录旧目录保持不动回滚时直接改服务路径或重新注册服务即可。有一个技巧很实用升级前把当前服务注册命令和配置关键项记在一个文本里回滚时按文本逐条恢复比临时回忆快得多。我自己的经验是多实例环境下永远不要“裸升级”至少保留两个相邻版本的备份包这样才能确保快速回退。最后再分享一个经验之谈不管你有多熟练多实例配置做完之后一定要重启一次服务器再验证因为 Windows 开机时序、防火墙初始化、服务依赖关系只有冷启动后才能完全验证。我就是因为在“热状态”下测试一切正常结果重启后发现服务起不来才知道配置里藏着依赖路径的坑。提前重启验证能提前暴雷总比生产宕机后再补救强很多。
