简介本资源是面向Linux系统运维工程师与性能测试工程师的LoadRunner 2022配套监控工具包聚焦于企业级应用性能压测与IT基础设施健康度实时监控两大核心场景。资源主体为SiteScope 2021.05 for Linux 64bit完整安装套件包含12个RPM安装包涵盖主程序、JRE、Failover、OATools等模块、12个XML配置模板用于部署参数化与组件依赖定义、6个Shell/Perl自动化脚本如upgrader.sh升级、backup.sh备份、disableKeyManagement.pl安全配置调整以及ReadMe文档、installer.properties配置文件和卸载导入工具全面支撑部署、升级、备份与故障恢复全流程。压缩包共38个文件大小758.33MB结构规范、职责分明便于团队标准化交付与维护。目前已有475人学习下载读者可直接获取开箱即用的Linux版SiteScope全量安装资产、关键运维脚本及版本适配说明显著降低部署门槛与配置风险。1. LoadRunner 2022 SiteScope 2021.05 for Linux 64bit不是装完就能用的性能监控闭环而是压测引擎与基础设施指标采集的硬耦合实战你手上有LoadRunner_2022和SiteScope_2021.05_for_Linux_64bit.zip这两个包但别急着解压——这根本不是“下载→安装→点开始”就能跑通的玩具组合。它是一套典型的企业级性能工程闭环链路LoadRunner 2022 是压测执行层发请求、控并发、收事务响应而 SiteScope 2021.05 是监控感知层抓 Linux 主机 CPU、内存、磁盘 I/O、网络连接数、Java 进程堆内存、Tomcat 线程池等真实资源水位。两者必须在 Linux 64bit 环境下完成协议级对接不是简单 ping 通就行否则 LoadRunner 报告里永远只有“平均响应时间 237ms”却看不到“第 8 分钟时 /dev/sda 的 await 达到 42ms 导致 DB 响应陡增”这种根因线索。这个组合专治“压测结果诡异但服务器监控面板一片风平浪静”的玄学翻车现场适合正在做金融核心系统、电商大促链路、政务服务平台压测的中高级性能工程师——你得懂 Linux 底层指标含义也得会调 LoadRunner 的 Controller 脚本逻辑更得扛得住生产环境凌晨三点被叫醒排查“为什么 2000 并发下 Redis 连接池打满但监控没告警”的压力。这不是入门工具是把压测从“看数字”推进到“挖根因”的关键跳板。2. 搭建 SiteScope 2021.05 for Linux 64bit不是图形化安装向导而是基于 Java 8u291 和 systemd 的静默部署流水线SiteScope 在 Linux 下没有 GUI 安装器它的安装本质是一套Java 服务容器 预置监控探针 systemd 服务注册的组合。官方只提供.zip包所有路径、端口、用户权限都得手动固化。我一般会跳过官网文档里“解压后运行 setup.sh”的模糊指引直接走静默安装Silent Install——因为图形界面在无桌面的 CentOS 7/8 或 Rocky Linux 9 服务器上根本起不来强行启动 X11 转发反而引入额外故障点。2.1 解压与预检确认 Java 版本、glibc 和文件系统权限三件套先校验你的目标 Linux 主机是否满足硬性门槛。SiteScope 2021.05 明确要求Java 8u291 或 Java 11不能用 Java 17JVM 参数-XX:UseG1GC在新版中已被移除会导致启动失败glibc ≥ 2.17CentOS 7 默认满足但某些定制版国产 Linux 可能卡在 2.14/opt分区剩余空间 ≥ 4GB日志快照插件缓存全堆在这# 检查 Java 版本必须输出 1.8.0_291 或 11.0.x java -version # 检查 glibc输出应为 2.17 或更高 ldd --version # 检查 /opt 空间SiteScope 安装目录默认在此 df -h /opt提示如果java -version输出的是 OpenJDK 17别试图用update-alternatives切换——SiteScope 启动脚本startSiteScope.sh里硬编码了JAVA_HOME路径和-XX:UseG1GC参数。最稳妥的做法是单独安装 JDK 8u291推荐 Adoptium Temurin 8u291-b10并设为JAVA_HOME/opt/java/jdk8u291。2.2 静默安装用 response.varfile 绕过交互式陷阱解压SiteScope_2021.05_for_Linux_64bit.zip后你会看到SiteScope_2021.05_Linux_64bit.bin这个二进制安装包。它不支持--help但支持-i silent模式。关键在于生成一个response.varfile文件把所有安装选项固化进去# 创建响应文件模板注意路径和端口必须与你规划一致 cat /tmp/site-scope-response.varfile EOF # Install directory USER_INSTALL_DIR/opt/HP/SiteScope # HTTP port (default 8080, but avoid conflict with Nginx/Apache) HTTP_PORT8081 # HTTPS port (if enabled) HTTPS_PORT8443 # Admin user and password (must be 8 chars, contain upper/lower/number) ADMIN_USERadmin ADMIN_PASSWORDSiteScope2021! # Java home path (point to JDK 8u291) JAVA_HOME/opt/java/jdk8u291 # Do not start service after install START_SERVICEfalse EOF然后执行静默安装chmod x SiteScope_2021.05_Linux_64bit.bin ./SiteScope_2021.05_Linux_64bit.bin -i silent -f /tmp/site-scope-response.varfile安装完成后验证目录结构ls -l /opt/HP/SiteScope/ # 应看到 bin/ conf/ logs/ plugins/ webapps/ 等标准目录 # 特别检查 conf/server.xml 中的 Connector port 是否为 80812.3 systemd 服务注册告别 nohup pid 文件的手动管理SiteScope 自带startSiteScope.sh和stopSiteScope.sh但它们不处理进程守护、崩溃自启、日志轮转。我一律改用 systemd 管理# 创建 service 文件 cat /etc/systemd/system/sitescope.service EOF [Unit] DescriptionHP SiteScope Monitoring Service Afternetwork.target [Service] Typesimple Usersiteuser Groupsiteuser WorkingDirectory/opt/HP/SiteScope ExecStart/opt/HP/SiteScope/bin/startSiteScope.sh ExecStop/opt/HP/SiteScope/bin/stopSiteScope.sh Restarton-failure RestartSec10 StandardOutputjournal StandardErrorjournal SyslogIdentifierSiteScope [Install] WantedBymulti-user.target EOF # 创建专用用户避免 root 运行 useradd -m -s /bin/bash siteuser chown -R siteuser:siteuser /opt/HP/SiteScope # 启用并启动 systemctl daemon-reload systemctl enable sitescope systemctl start sitescope验证服务状态systemctl status sitescope # 应显示 active (running)且 journalctl -u sitescope -n 20 无 ERROR 级日志 curl -I http://localhost:8081 # 应返回 HTTP/1.1 302 Found重定向到 login.jsp3. LoadRunner 2022 与 SiteScope 的协议级对接不是填个 IP 就行而是打通 SNMPv3 WMI over HTTP 自定义 JMX 的混合认证链LoadRunner 2022 的 Controller 本身不内置 Linux 监控能力它必须通过SiteScope Agent作为中间代理将 Linux 主机指标“翻译”成 LoadRunner 能识别的 MIB OID 或自定义指标路径。这个过程不是简单的“添加监控主机”而是要同时配置三类协议通道并确保它们全部通过 SiteScope 的认证网关。3.1 SiteScope 端启用 SNMPv3 和 JMX 监控模块SiteScope 默认禁用高危协议。进入http://sitescope-ip:8081→ 登录 →Admin System Configuration Monitoring Configuration勾选SNMP v3 Monitoring设置 Engine ID如0x8000000001并创建一个 SNMPv3 用户用户名lr-snmp认证协议 SHA密码LrSnmp2022!隐私协议 AES密码LrSnmp2022Enc!勾选JMX Monitoring设置 JMX 连接端口如9999并上传 JMX 认证文件jmxremote.password和jmxremote.access内容需包含lr-jmx readwrite权限在Monitoring Add Monitor Linux Server中添加目标 Linux 主机 IP选择SNMP v3作为协议输入上述 SNMPv3 用户凭证注意Linux 主机必须已安装并运行snmpd服务且/etc/snmp/snmpd.conf中包含rouser lr-snmp authPriv agentAddress udp:1613.2 LoadRunner Controller 端配置 SiteScope Data Feed 插件LoadRunner 2022 的 Controller 安装目录下有datamart子目录其中plugins文件夹需放入 SiteScope 的数据适配器# 进入 LoadRunner Controller 安装目录如 C:\Program Files\Micro Focus\LoadRunner\datamart\plugins # 将 SiteScope 安装包中的 /opt/HP/SiteScope/plugins/loadrunner/ 下的 .jar 文件复制过来 # 重点文件sitescope-datafeed-2021.05.jar # 修改 datamart 配置文件datamart.properties echo sitescope.urlhttp://sitescope-ip:8081 datamart.properties echo sitescope.usernameadmin datamart.properties echo sitescope.passwordSiteScope2021! datamart.properties echo sitescope.timeout30000 datamart.properties重启 LoadRunner Controller 服务后在 Controller 界面 →Tools Options Monitors中应能看到SiteScope Data Feed监控类型已激活。3.3 在场景中绑定监控用 “Custom Metric Path” 替代模糊的 “CPU Utilization”很多工程师在 Controller 里添加 SiteScope 监控时直接选 “CPU Utilization”结果发现指标始终为 0。这是因为 SiteScope 对 Linux 的 CPU 指标暴露路径是分层的必须用精确的 OID 或路径SiteScope 指标路径对应含义LoadRunner 中填写方式SNMP::1.3.6.1.4.1.2021.11.9.0CPU 5 分钟平均负载SNMP::1.3.6.1.4.1.2021.11.9.0JMX::java.lang:typeMemory/HeapMemoryUsage/usedJVM 堆内存已用字节数JMX::java.lang:typeMemory/HeapMemoryUsage/usedFile System::/dev/sda1/Percent Used根分区使用率File System::/dev/sda1/Percent Used在 Controller 场景中右键 →Add Measurements SiteScope Data Feed在Metric Path栏粘贴上述任一路径不要选下拉菜单里的通用名称——那是旧版兼容模式对 2021.05 不生效。4. 避坑SiteScope 与 LoadRunner 2022 在 Linux 上的 4 个血泪经验这些坑我在三个银行核心系统压测项目里反复踩过每次修复都耗掉至少 4 小时。列在这里省得你再交学费。4.1 现象SiteScope Web 界面能登录但 LoadRunner Controller 报错 “Connection refused: connect”原因SiteScope 的server.xml中 Connector 配置了address127.0.0.1导致外部 IP 无法访问其 REST API 端点Controller 通过 HTTP 调用/SiteScope/rest/...获取指标解决编辑/opt/HP/SiteScope/conf/server.xml找到Connector port8081行改为Connector port8081 address0.0.0.0然后systemctl restart sitescope4.2 现象Controller 中能看到 SiteScope 监控项但所有数值恒为 -1 或 NaN原因Linux 主机的snmpd服务未启用extend指令而 SiteScope 的部分自定义脚本如磁盘 IO 统计依赖snmpd执行 shell 命令返回结果解决在/etc/snmp/snmpd.conf中添加extend diskio /usr/bin/iostat -dx 1 2 \| tail -n 4 \| head -n -1 \| awk {print \$1,\$10}然后systemctl restart snmpd并在 SiteScope 监控配置中启用 “Extend Script” 类型4.3 现象JMX 监控能连上 Tomcat但 HeapMemoryUsage 指标始终为 0原因Tomcat 启动脚本中未配置-Dcom.sun.management.jmxremote参数或配置了但未开放jmxremote.password文件的读取权限解决在CATALINA_OPTS中追加-Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port9999 \ -Dcom.sun.management.jmxremote.authenticatetrue \ -Dcom.sun.management.jmxremote.sslfalse \ -Dcom.sun.management.jmxremote.password.file/opt/tomcat/conf/jmxremote.password \ -Dcom.sun.management.jmxremote.access.file/opt/tomcat/conf/jmxremote.access并确保jmxremote.password文件权限为600属主为tomcat4.4 现象LoadRunner 场景运行中SiteScope 日志疯狂刷 “Authentication failed for user admin”原因Controller 每 5 秒轮询一次 SiteScope API而 SiteScope 默认 session timeout 为 300 秒5 分钟大量并发请求导致 session token 过期后 Controller 仍用旧 token 请求解决编辑/opt/HP/SiteScope/conf/web.xml找到session-config段将session-timeout改为144024 小时重启 SiteScope5. 实战技巧用 SiteScope 的 Custom Script Monitor LoadRunner 的 Auto Correlation实现“指标异常自动终止场景”这才是这套组合拳的终极价值——不让压测跑满 2 小时才发现问题而是让系统在第一个 CPU 突刺时就刹车。我把它拆成两步SiteScope 端写一个实时判定脚本LoadRunner 端用 Auto Correlation 触发动作。5.1 SiteScope 端编写 Python 脚本判定磁盘 IO 异常SiteScope 支持 Custom Script Monitor可执行任意 Shell/Python 脚本并返回数值。我们监控awaitI/O 平均等待毫秒数超过 30ms 即视为异常#!/usr/bin/env python3 # /opt/HP/SiteScope/custom-scripts/disk_await_check.py import subprocess import sys def get_await(): try: # 获取 sda 的 await 值单位毫秒 result subprocess.run( [iostat, -dx, 1, 2], capture_outputTrue, textTrue, checkTrue ) lines result.stdout.strip().split(\n) # 找到 sda 行取第 11 列await for line in lines: if sda in line and sda1 not in line: cols line.split() if len(cols) 11: return float(cols[10]) return 0.0 except Exception as e: print(fError: {e}) return -1.0 if __name__ __main__: await_val get_await() # SiteScope 要求脚本返回 0~100 的整数我们映射0正常100严重 if await_val 10: print(0) elif await_val 30: print(30) else: print(100) # 触发 LoadRunner 的终止条件赋予执行权限并注册为 SiteScope 监控项chmod x /opt/HP/SiteScope/custom-scripts/disk_await_check.py # 在 SiteScope Web 界面Monitoring Add Monitor Custom Script # Script Path: /opt/HP/SiteScope/custom-scripts/disk_await_check.py # Return Value Type: Numeric # Polling Interval: 10 seconds5.2 LoadRunner Controller 端用 Auto Correlation 绑定指标阈值在 Controller 场景设置中 →Scenario Schedule Run-Time Settings Miscellaneous Auto Correlation点击Add→ 类型选SiteScope Data FeedMetric Path填Custom Script::disk_await_check.pySiteScope 会自动注册此路径Condition设为Value 90对应脚本返回 100Action选Stop the scenario这样当iostat检测到await持续超 30msSiteScope 脚本返回 100 → Controller 每 10 秒轮询一次 → 连续两次读到 90 → 立即终止当前场景并在 Results 中标记 “Aborted due to Disk I/O Alert”。5.3 验证与调优用 curl 模拟 Controller 的轮询行为别等压测跑起来才验证用命令行提前测通链路# 获取 SiteScope 的认证 token模拟 Controller 登录 TOKEN$(curl -s -X POST http://sitescope-ip:8081/SiteScope/rest/login \ -H Content-Type: application/json \ -d {userName:admin,password:SiteScope2021!} | jq -r .token) # 轮询自定义脚本指标每 10 秒一次共 5 次 for i in {1..5}; do VALUE$(curl -s -X GET http://sitescope-ip:8081/SiteScope/rest/monitors/Custom%20Script::disk_await_check.py \ -H Authorization: Bearer $TOKEN | jq -r .value) echo [$i] Disk await score: $VALUE sleep 10 done如果返回值稳定在 0~100 之间且await人为制造突增时能跳到 100说明链路已通。我坚持在每个新项目上线前用这套方法做一次“指标熔断演练”手动dd if/dev/zero of/tmp/test bs1M count1000 oflagdirect制造磁盘压力看是否能在 30 秒内触发场景终止。这比写一百页《压测风险预案》都管用——因为它是真正在生产环境节奏下跑通的闭环。希望帮到你。本文还有配套的精品资源点击获取