简介这份资源是LoadRunner 2022配套的SiteScope 2021.05 Linux 64位安装监控工具包面向性能测试工程师、运维人员和IT基础设施管理员。SiteScope可实时监控服务器、数据库、网络设备及应用状态与LoadRunner配合覆盖从压力测试到生产监控的完整链路适用于系统上线前压测、日常健康巡检与故障预警等场景。资源共38个文件以rpm安装包和xml配置描述为主另有sh运维脚本、pl辅助脚本、bin安装引导文件、pdf说明文档及properties参数文件整体体积约758MB。安装引导文件负责部署rpm包拆分不同功能模块脚本主要承担备份、恢复、升级与卸载维护pdf为版本说明。已有476人学习下载。使用这份资料可获得一套相对完整的SiteScope部署与维护基础既包含安装升级脚本和配置备份工具也有官方ReadMe帮助理解版本特性与已知问题适合需要自建监控环境或扩展LoadRunner基础设施监控能力的工程师按需取用。1. 一条奇怪的报错背后LoadRunner 2022 压测机上的 SiteScope 到底解决什么问题很多压测团队第一次碰 SiteScope_2021.05_for_Linux_64bit.zip 这个文件都是因为 LoadRunner 2022 的 Controller 在 Windows 上跑得好好的可监控面板里 Linux 打压机Load Generator简称 LG的 CPU、内存却一片空白。你想手动补监控要么装 SNMP要么在 LG 上再塞一个 agent但都不稳。LoadRunner 2022 发行时配套的监控组件 SiteScope 2021.05就是为这个场景准备的它单独部署在一台 Linux 上把被监控主机的性能数据统一采集回来再喂给 Controller 的去显示。适合谁用给压测环境做基础设施监控的测试开发、运维值班以及不想在每台打压机上折腾 agent 的人。需要先说明的一点是这个 zip 解压后并不能像绿色软件一样双击就完事它有自己的安装流程、JDK 依赖和端口占用逻辑本文就把部署到接入的全过程拆开讲。2. 为什么压测架构里要单独拆一个 SiteScope职责边界与 Linux 版的选型逻辑2.1 监控通道不经过 Controller 进程压测流量和监控数据各走各LoadRunner 2022 自带的 Controller 系统资源监控在跨平台场景下非常挑环境。它能直接读 Windows 的 Perfmon 计数器但读 Linux 的数据往往要先在目标机器上装 RSTAT 服务或配置好 SNMP而且 Controller 与每一台被监控主机建立会话所有数据都挤在 Controller 这条链路上。压测一跑大并发Controller 本机既要调度脚本、收集事务响应时间又要同步拉性能计数器Windows 上偶尔能看到内存和网络延迟直接把监控刷新拖死。SiteScope 加进来之后架构就变成两层SiteScope 部署在一台独立的 Linux 机器上由它去轮询所有被监控主机包括 Linux LG 和应用服务器数据先落在 SiteScope 自己的存储里Controller 只和 SiteScope 单点通信拿汇总后的数据。这样监控压力就从前台的 Controller 挪到后台独立的监控机上压测时脚本跑在 LG 上、业务流量走网络监控采集跑在 SiteScope 上三条通道互不干扰。我见过有团队压测 5000 并发时 Controller 把数据刷到图表卡成幻灯片拆出 SiteScope 后同样场景图表刷新稳定在一秒一帧以内。2.2 Linux 版和 Windows 版 SiteScope 的差别目录结构、服务脚本和权限模型同一个 SiteScope 版本在 Windows 和 Linux 上的落地方式很不一样。Windows 版装完会注册成一个 Windows 服务通过服务管理器启动停止数据目录默认在 Program Files 下服务账号通常用 Local System。Linux 版则是解压后直接以普通用户进程方式运行前台启动脚本是安装目录下 bin 目录里的 run.sh后台常驻则要靠 nohup、systemd 或 init 脚本托管。目录结构上Linux 版解压后根目录里就能看到配置目录conf、日志目录logs和监控定义目录monitors数据文件默认放在安装根目录下不写入系统级 /var/lib这点对权限隔离很友好。权限模型是 Linux 版最容易踩的第一个坑。SiteScope 官方要求用非 root 用户运行很多新手图省事直接 root 启动结果监控任务里执行远程命令时会以 root 身份去连目标机要么被目标机的安全策略拒绝要么带来不必要的越权风险。我一般建议单独建一个 siteuser 用户只给它安装目录的读写权限启动后 SiteScope 的所有出站连接都以这个普通用户身份发起。另外64bit 版本对 glibc 有硬性要求老 CentOS 6 或内核太旧的机器上解压后一启动就可能碰到缺符号或直接段错误这个后面避坑章细说。2.3 2021.05 这个版本号为什么和 LoadRunner 2022 配对出现SiteScope 2021.05 不是独立发布的新版本而是和 LoadRunner 2022 同一批次的配套监控组件。两个产品共用一套登录与授权体系Controller 里填写 SiteScope 的地址和端口后LoadRunner 会用站点的凭据去和 SiteScope 握手License 由 LoadRunner 侧统一管理SiteScope 本身不单独要求额外的授权码。理解这一点对选型很关键。如果你手上只有 LoadRunner 2022 的 License那配套 SiteScope 2021.05 是能直接用的如果你拿的是老版 SiteScope 或者乱配一个更新版版本握手时可能出现协议不兼容Controller 里能看到监控主机但拉不到任何计数器。所以收到 SiteScope_2021.05_for_Linux_64bit.zip 这个包时正确的态度是把它当 LoadRunner 2022 的一部分来对待而不是当成一个孤立工具。3. 把 SiteScope_2021.05_for_Linux_64bit.zip 部署到 Linux完整安装步骤与最小参数配置3.1 部署前检查内核版本、Java 环境与端口规划SiteScope 2021.05 的 Linux 64bit 版对部署主机的软件条件有硬性要求先确认再动手能省掉大半排查时间。需要检查三样东西glibc 版本、可用端口和时区设置。glibc 版本过低会导致二进制文件直接崩溃检查命令是ldd --version一般来说 CentOS 7.6 以上或 Ubuntu 18.04 以上的默认 glibc 都能满足要求。端口方面 SiteScope 默认用 8080 提供 Web 控制台和监控数据接口如果机器上已经跑了 Tomcat、Jenkins 之类的东西8080 很容易被占提前规划一个替代端口更稳妥。# 1. 检查 glibc 版本确认满足 64bit 二进制运行要求 ldd --version | head -n 1 # 2. 检查端口 8080 是否已被占用被占用则后面需要改方案 ss -lntp | grep :8080 # 3. 创建专用系统用户避免用 root 跑监控服务 useradd -m -s /bin/bash siteuser第一行命令输出的版本号如果低于 SiteScope 二进制要求的底线后面启动时会看到version GLIBC_2.14 not found之类的报错这时候不用继续往下装先换一台系统版本更新的机器。第二行ss -lntp如果输出里已经有进程监听 8080建议记下这个冲突点后面启动前要么杀掉旧进程要么改 SiteScope 端口。第三行创建 siteuser 用户是安全习惯SiteScope 的监控逻辑里有一个「远程命令执行」能力如果用它监控 Windows 或 Linux 主机执行脚本监控进程的权限决定了它能做多少事专用低权限用户更可控。3.2 解压、运行安装脚本与启动服务确认完环境后把 zip 包上传到目标机器。上传路径没有硬性规定我一般统一放 /opt 目录下因为 /opt 默认权限清晰也方便后续备份整个安装目录。解压用的 unzip 命令在多数 Linux 发行版上自带少数精简系统需要先yum install unzip或apt install unzip。# 1. 解压安装包到 /opt 目录 cd /opt unzip SiteScope_2021.05_for_Linux_64bit.zip # 2. 进入解压后的目录确认目录结构完整 cd SiteScope_2021.05 ls -la # 3. 给安装目录授予 siteuser 用户读写权限 chown -R siteuser:siteuser /opt/SiteScope_2021.05 # 4. 切换到 siteuser 用户并启动服务 su - siteuser -c /opt/SiteScope_2021.05/bin/run.sh /opt/SiteScope_2021.05/startup.log 21这里有几个关键点要说明。第一步解压后的目录名不固定有的版本包解出来就是SiteScope_2021.05有的是SiteScope第二步的ls -la就是为了确认真实目录名。第三步 chown 必须做否则以 siteuser 启动时无法写入日志和监控数据会出现能启动但监控数据全部落不了盘的情况。第四步启动命令里 startup.log 21是做标准输出重定向因为 run.sh 启动后前台会持续打印运行日志如果不重定向你断开 SSH 终端时进程会收到 SIGHUP 被杀死这就解释了为什么很多人明明启动了一关终端服务就没了。启动后不要急着打开浏览器先用日志确认启动过程正常。配置文件里如果设置过自定义端口需要同步修改 conf 目录下站点配置里的端口号字段这个改动在 Web 控制台里也有对应入口但第一次部署时直接改文件更快。# 查看启动日志尾部确认没有报错 tail -n 100 /opt/SiteScope_2021.05/startup.log # 确认进程常驻 ps -ef | grep -i sitescope # 确认监控端口已监听默认是 8080 ss -lntp | grep 8080第一句看日志是排错的基础操作启动过程中如果有Exception或Error关键字多半是前面环境检查遗漏的问题。第二句确认进程不是那种启动后闪退的状态正常情况下能看到一个常驻的 Java 进程。第三句确认端口监听正常这里看到的监听地址如果是0.0.0.0:8080说明外网可以直接访问控制台如果只需要内网访问建议在配置里把绑定地址改成内网 IP。3.3 控制台初始化和 License 导入启动完成后浏览器访问http://服务器IP:8080会出现 SiteScope 的初始化页面。第一次登录需要创建管理员账号这一步没有默认密码完全由部署者自己设置。初始化完成后会进到许可页面SiteScope 的许可证有两种导入路径一是页面上传 license 文件二是把许可证内容粘贴到输入框。LoadRunner 2022 的场景下许可证由 LoadRunner 侧授权SiteScope 端通常只需要确认版本配对不一定要单独导文件。但如果你在页面里看到 License 状态是「评估模式」或者「剩余 XX 天」说明 License 没有正确关联这时候需要回到 LoadRunner 安装目录下找到许可配置文件把 SiteScope 的地址加进去重启 Controller 再来看。控制台初始化的最后一个步骤是配置邮件告警参数这一步可以跳过后面第 6 章会单独讲告警脚本的价值。这里给出一个建议初始化完成后立刻做一次系统状态快照把ps -ef的结果、监听端口列表和配置文件备份到单独目录后面排障时能对比出什么是「部署时正常的状态」。4. 把 SiteScope 挂进 LoadRunner 2022监控主机添加与计数器采集设置4.1 在 Controller 里注册 SiteScope 服务器SiteScope 部署好之后回到 Windows 上打开 LoadRunner 2022 的 Controller。在菜单栏找到站点监控或联机监控相关的设置入口常见做法是在「系统资源监控」面板中添加新监控服务器类型选择 SiteScope。填写的关键字段有三项SiteScope 服务器地址、端口和管理员账号密码。这里有个细节Controller 填写的账号密码就是第 3 章初始化时创建的管理员账号不是 LoadRunner 的账号。# 验证 LoadRunner Controller 到 SiteScope 的网络连通性 # 在 Controller 机器上执行Windows 用 telnet 或 PowerShell Test-NetConnection telnet SiteScope服务器IP 8080如果 telnet 不通问题通常出在两台机器之间的防火墙或安全组上。SiteScope 默认绑定的端口是 8080Controller 要能正常访问到这个端口双向网络都要放行。另外SiteScope 的 Web 控制台默认会做 HTTPS 重定向如果端口配置的是 8080 但页面自动跳到 8443Controller 注册时要填实际握手用的端口不是浏览器里看到的跳转后端口。这个现象在很多团队第一次接入时都会遇到每次看到「无法连接 SiteScope 服务器」先查端口跳转比查网络更快一步。4.2 在 SiteScope 里创建远程监控组并添加目标主机Controller 注册完成后还需要在 SiteScope 侧把被监控的 Linux 主机加进来。打开 SiteScope 控制台导航到「监控组」或「远程服务器」新建一个监控组然后在组内添加主机监控器。添加时要指定目标主机的 IP、登录方式SSH 或 SNMP和凭据。SSH 方式下 SiteScope 会用它自身的普通用户身份去连目标机的 SSH 服务适合监控 Linux 打压机SNMP 方式则要求目标机已经装好并启动 snmpd 服务适合监控网络设备或不便开放 SSH 的环境。# 在被监控的 Linux 主机上启用 SNMP 服务以 CentOS/RHEL 系为例 yum install -y net-snmp net-snmp-utils systemctl enable snmpd systemctl start snmpd # 修改 snmpd 配置允许 SiteScope 服务器 IP 读取监控数据 echo rocommunity public SiteScope服务器IP /etc/snmpd/snmpd.conf systemctl restart snmpd第一组命令是安装和启动 SNMP 服务net-snmp-utils 里带的 snmpwalk 工具后面排查时会用到。第二组命令里的rocommunity public后面的 IP 要替换成 SiteScope 所在机器的地址这是社区字符串授权只允许这一台监控机读取。这样配置后SiteScope 侧新建 SNMP 监控器时只需要填目标主机 IP、端口 161 和社区字符串 public就能拿到 CPU 和内存的基础计数器。注意社区字符串 public 是明文传输在内网压测环境里问题不大但如果监控跨了网段或你比较在意安全建议改成随机字符串。4.3 监控计数器的关键参数轮询间隔、超时和阈值SiteScope 添加完监控器后每个监控器都有采集参数需要设置这里直接决定监控数据的可用性。三个参数是必调的轮询间隔Polling Interval、超时时间Timeout和连续失败次数Fail Count。轮询间隔默认 5 分钟但压测场景下太粗了。压测持续期间系统状态是秒级变动5 分钟间隔会丢失大量细节我一般会把 CPU、内存监控器的轮询间隔调到 15 秒磁盘和网络调到 30 秒。超时时间默认是 30 秒如果目标主机负载过高导致 SSH 响应慢30 秒内没拿到数据就会记一次失败连续失败 3 次就会把监控器标记为 Down。监控对象采集方式轮询间隔超时时间备注CPU 使用率SSH15s30s关注压测峰值期均值物理内存SSH15s30s关注可用内存低于 10%磁盘 I/OSNMP30s45s日志盘和数据盘分开看网卡吞吐SNMP30s45s注意千兆/万兆网卡上限关键进程数SSH60s45s防止应用进程崩溃未发现参数设置的另一个重点是「连续失败次数」。压测时目标主机如果被压到 CPU 跑满SSH 响应变慢甚至暂时拒绝新连接SiteScope 的采集就会失败。默认连续失败 3 次就把监控器置为 Down常导致压测还没结束监控面板就全红了。我一般会把连续失败次数提高到 5 到 8 次这样短暂抖动能被容忍监控不会频繁误报等压测结束再人工检查失败的监控器。这个设置藏在监控器的「高级设置」或「错误处理」标签页里不同版本叫法略有差异但都没有难度。5. SiteScope 部署与联调避坑五个常见问题的现象、原因与解决路径5.1 两台机器的坑JDK 兼容性导致启动闪退hosts 配置导致控制台打不开现象一安装完成后执行 run.sh 启动脚本终端返回了提示但ps -ef看不到进程查看 startup.log 发现UnsupportedClassVersionError或Unrecognized option这类报错。原因是 SiteScope 2021.05 的启动脚本会自动探测系统里安装的 Java不满足版本要求的 JDK 会导致虚拟机和站点服务无法完成初始化。解决方式不是去下载一个新 JDK 全局替换更稳妥的是在 run.sh 脚本里显式指定 JAVA_HOME 变量让站点用到正确的 JDK。检查系统默认 Java 版本可以用java -version如果系统里装了多个 JDK脚本有可能会选到旧的那个。现象二进程已经常驻端口也显示监听但浏览器访问http://IP:8080时出现「无法访问此网站」。这个坑我在新环境里碰到过两次原因不是端口没起而是目标机器的/etc/hosts文件里主机名被解析到了 127.0.0.1 而不是实际内网 IP。SiteScope 的服务端在绑定地址和做反向解析时会读InetAddress.getLocalHost()如果 hosts 文件里写了127.0.0.1 myhost它就把控制台服务绑定在回环地址上外部机器自然访问不到。解决方式是修改/etc/hosts把主机名映射改成实际内网 IP然后重启服务。这个坑最恼人的地方在于所有常规检查都显示服务正常只有绑定的地址不对。5.2 监控数据采集的坑SNMP 不可达被误判为主机 Down计数器全部为 0 的三种可能现象三SiteScope 里添加好的主机监控器一开始是绿色的压测一开瞬间变成红色 Down点开失败原因显示「SNMP timeout」。原因通常是目标主机 CPU 打满后 snmpd 进程的响应优先级被挤占数据包在网卡队列里排队等到 SiteScope 端已经超时了。这个场景优先尝试两条一是把监控器的超时时间从默认 30 秒调到 45 秒二是检查网卡是否开启了节能模式或队列限制必要时调大 smp_affinity 让 snmpd 不只在单核上跑。现象四监控器状态是绿色但 CPU、内存计数器的值全部是 0历史曲线也是一条直线。这个问题的原因分三种按出现频率排第一种是 SNMP 的 OID 查询权限没给全常见的rocommunity配置只给了部分 MIB 的读权限需要检查/etc/snmpd/snmpd.conf里是否限制了 view第二种是被监控主机的 CPU 架构是 ARM 或老 32 位系统部分 MIB 返回值类型不匹配SiteScope 按 64 位整数解析失败返回 0第三种是监控器选错了类型比如用 SNMP 监控器去测一个只开放 SSH 的主机拿到的数据字段全是空的。排障时在 SiteScope 服务器上手动执行# 在 SiteScope 机器上手动验证 SNMP 能否读到目标主机 CPU 数据 snmpwalk -v2c -c public 目标主机IP .1.3.6.1.4.1.2021.11如果手动执行能返回数据说明是 SiteScope 配置层的问题重新核对监控器里的主机名、端口和社区字符串即可。如果手动执行也返回空说明问题在目标主机的 snmpd 配置层按前面三种原因逐个排。这条命令是排查计数器全为 0 时最高效的第一动作。5.3 重装与平台兼容的坑License 失效和国产 Linux 的 glibc 门槛现象五卸载 SiteScope 后重新安装控制台初始化时提示 License 不可用或被占用。原因是 SiteScope 在首次启动时会把机器指纹写入到安装目录的配置文件和系统级目录中普通卸载删除的只是程序文件系统级的指纹残留还在新安装的实例读到了残留指纹但没读到对应的许可证内容。解决方式是重装之前先停服务删除安装目录后用管理工具清理/etc下遗留的配置文件和/var/log下的旧日志再重装。如果你在重装前手动导出过站点配置导入回来时也要注意 License 字段不要一起导否则容易覆盖新实例的授权。现象六在国产 Linux 系统如统信 UOS、银河麒麟等上部署报错启动日志里出现GLIBC_2.28 not found或类似的符号缺失信息。原因是 2021.05 版 SiteScope 的 64bit 二进制构建时链接的 glibc 版本较新而部分国产 Linux 的兼容层内核版本和 glibc 版本没跟上。解决方式有两档第一档是检查操作系统自带软件源里有没有 glibc 兼容包有的发行版提供了额外兼容库装上即可第二档是确认该发行版是否有官方发布的适配版 SiteScope有的话换用适配版。如果企业内部不允许随意升级内核或 glibc退而求其次的做法是找一台 CentOS 7.x 或 Ubuntu 18.04 的虚拟机部署 SiteScope监控机和被监控的国产 Linux 分开不影响整体链路。判断 glibc 版本只需一句命令# 查看被部署机器的 glibc 版本比对是否满足要求 getconf GNU_LIBC_VERSION6. 进阶用 HTTP 监控和告警脚本把压测环境的可用性短板补上SiteScope 的常用能力还不足以覆盖压测前预检和压测中异常快速通知这两个场景这里介绍两个实用进阶配置。第一个是用 SiteScope 的 HTTP 监控器做压测环境预检。很多团队压测前都出现过「压到一半发现被测服务挂了一个节点」的情况手动 curl 检查太原始。在 SiteScope 里给被测服务的关键 URL 加一个 HTTP 监控器设置 10 秒间隔压测前一天晚上就开启任意节点返回非 200 状态码时监控器会立即变红如果接上邮件告警值班人员第二天一早就能看到异常报告。配置时注意HTTP 监控器的「响应时间阈值」和「状态码匹配规则」是两个最重要的输入项状态码规则不要只写 200很多服务在认证场景下返回 302 或 401 也算正常规则写死反而会误报。第二个进阶配置是告警脚本场景化。SiteScope 自带的告警动作可以调用外部脚本把哨兵逻辑或特定的动作注入。常见做法是写一个 shell 脚本当监控到 CPU 超过 90% 持续 5 分钟时自动抓取压测机上的 top 快照和 jstack 日志方便事后定位是本压测脚本的问题还是系统资源瓶颈。脚本里要处理好参数传递SiteScope 在触发告警时会向脚本传入监控器名称、被监控主机 IP、当前值和阈值等变量脚本第一步是接收并打印这些变量到日志第二步再做业务动作。写这个脚本时建议先手动模拟参数跑一次再挂到告警动作里因为站点服务对标准输入输出的管理有自身逻辑脚本里的交互式提示符会导致挂起。#!/bin/bash # SiteScope 告警触发时采集当时的资源快照 MONITOR_NAME$1 HOST_IP$2 CURRENT_VALUE$3 THRESHOLD$4 # 记录告警上下文到文件避免事后查无实据 echo $(date) $MONITOR_NAME $HOST_IP $CURRENT_VALUE /var/log/sitescope_alert.log # 如果告警对象是 CPU 监控器则抓取下游进程快照 if [ $MONITOR_NAME CPU Monitor ]; then ssh root$HOST_IP top -bn 1 /tmp/top_snapshot.txt cat /tmp/top_snapshot.txt fi这是个简单的示例脚本实际使用中我会把 ssh 命令换成 SiteScope 所在机器与目标主机之间已配置好的免密通道避免告警动作里临时输入密码。这个脚本的价值在于把「监控数据异常」和「现场留存」串联起来压测结束后复盘时不需要再问「当时到底发生了什么」有日志可以直接看。做性能监控这件事数据采集只是第一步真正有用的是异常时刻的上下文快照和通知链路。SiteScope 2021.05 在 LoadRunner 2022 的压测环境里是一个容易被低估的组件但部署好、参数调对、告警接好之后它能让压测团队在监控侧省下大量手工操作的时间。我自己在这套环境上踩过的坑几乎都集中在最基础的部署和连通性上所以强烈建议第一次部署时把第 3 章的环境检查命令逐条执行完再初始化希望这篇笔记能帮到你让你少走一圈弯路、少加一次班。本文还有配套的精品资源点击获取