简介本资源是面向Linux系统运维工程师与性能测试工程师的Micro Focus SiteScope 2021.05监控套件安装包专为x86-64架构Linux环境设计可与LoadRunner 2022协同构建端到端性能测试与基础设施监控体系。资源共38个文件涵盖12个RPM安装组件含主程序、JRE、Failover、OLH等、12个XML配置模板用于部署参数定义、6个Shell/Perl脚本如upgrader.sh、backup.sh、disableKeyManagement.pl等支持自动化升级、备份与安全配置调整以及ReadMe文档、installer.properties配置文件和卸载/导入工具整体包体达758.33MB。已有475人学习下载读者可直接部署生产级SiteScope监控平台获取开箱即用的服务器、数据库、中间件及网络设备健康状态采集能力并通过配套脚本快速完成配置备份、版本平滑升级与故障恢复显著提升IT运维效率与系统可观测性。1. LoadRunner 2022 SiteScope 2021.05为什么在 Linux 64 位环境里做真实服务监控不能只靠压测脚本很多测试工程师拿到 LoadRunner 2022第一反应是“终于能跑 HTTP/3 和 WebSocket 了”但真正上线后才发现压测脚本跑得再顺服务器 CPU 突然飙到 98%、数据库连接池耗尽、中间件线程卡死——这些故障点LoadRunner 自身根本看不到。它只告诉你“TPS 下降了”却不告诉你“是哪个 JVM 的 GC 时间暴涨了 3 秒”。这时候SiteScope 就不是可选项而是必选项。特别是这个组合包里打包的SiteScope 2021.05 for Linux 64bit它不是 Windows 上那个图形化点击点点的旧版本而是专为生产级 Linux 服务器设计的轻量级代理架构不依赖 X11、不启动 GUI 进程、通过纯命令行部署 REST API 管理能直接采集/proc、/sys、JMX、SNMP、自定义 Shell 脚本输出甚至对接 Prometheus Exporter。它和 LoadRunner 2022 的集成不是“两个工具放一起”而是通过 LoadRunner Controller 的SiteScope Integration Plugin实现指标自动关联——压测期间每秒采集的磁盘 IOPS、Java 堆内存使用率、Nginx active connections会和 LR 的事务响应时间、错误率自动打上同一时间戳在 Analysis 中拖拽就能做相关性分析。适合谁不是刚学录制回放的新手而是负责核心交易链路比如支付网关、订单履约性能保障的 SRE 或资深性能测试工程师——你得懂 Linux 系统指标含义也得会看 LoadRunner 的lr_start_transaction()与lr_end_transaction()如何嵌入业务逻辑。这不是一个“装完就能用”的玩具而是一套需要你亲手校准采集粒度、过滤噪声、对齐时钟的服务可观测性基座。2. 在 CentOS/Rocky Linux 8.6 上静默部署 SiteScope 2021.05跳过 GUI 向导用配置文件批量初始化SiteScope 2021.05 for Linux 64bit 的安装包SiteScope_2021.05_for_Linux_64bit.zip解压后是一个典型的 Java Web 应用结构siteScope/目录下含bin/、conf/、webapps/。但它没有setup.sh或图形化安装器——这是关键认知偏差。官方明确要求必须通过install.sh配合预置响应文件response file完成静默安装否则后续无法注册到 LoadRunner Controller。下面步骤基于 Rocky Linux 8.6内核 4.18.0-477.13.1.el8_8.x86_64已验证 JDK 11.0.22OpenJDK兼容性。2.1 准备系统依赖与权限隔离SiteScope 进程必须以非 root 用户运行安全强制要求且需提前创建专用用户组和目录结构。注意不要复用tomcat或jboss用户SiteScope 有独立的文件锁和日志轮转机制混用会导致Permission denied错误。# 创建专用用户组和用户UID/GID 固定为 1001避免 SELinux 冲突 sudo groupadd -g 1001 sitescope sudo useradd -u 1001 -g sitescope -m -d /opt/sitescope -s /bin/bash sitescope # 创建安装目录并授权必须是 750非 755 sudo mkdir -p /opt/sitescope/{install,logs,backup} sudo chown -R sitescope:sitescope /opt/sitescope sudo chmod 750 /opt/sitescope # 安装必要依赖Rocky 8 默认不带 unzip 和 lsof sudo dnf install -y unzip lsof procps-ng java-11-openjdk-devel提示java-11-openjdk-devel必须安装因为 SiteScope 启动脚本bin/startup.sh会调用javac编译其内置的 JSP 页面。仅装jre会导致HTTP Status 500错误且日志中无明确提示。2.2 构建静默安装响应文件response.varfileresponse.varfile是整个安装流程的“宪法”漏掉任意一项都会导致安装中断或功能缺失。重点字段说明INSTALLER_UIsilent强制静默模式GUI 模式在 headless Linux 上必然失败USER_INSTALL_DIR/opt/sitescope/install必须指向你创建的目录且路径末尾不能有斜杠JAVA_HOME/usr/lib/jvm/java-11-openjdk-11.0.22.07-2.el8_8.x86_64精确到具体 JDK 版本路径用rpm -ql java-11-openjdk-devel | grep jvm查SITE_SCOPE_PORT8080建议避开 8080常被 Jenkins 占用改用8090ADMIN_USER_NAMElradmin此用户将作为 SiteScope Web 控制台管理员密码将在下一步加密写入。# 切换到 sitescope 用户生成响应文件避免 root 权限污染 sudo -u sitescope bash -c cat /tmp/response.varfile EOF # InstallShield Response File INSTALLER_UIsilent USER_INSTALL_DIR/opt/sitescope/install JAVA_HOME/usr/lib/jvm/java-11-openjdk-11.0.22.07-2.el8_8.x86_64 SITE_SCOPE_PORT8090 ADMIN_USER_NAMElradmin ADMIN_PASSWORDENC(2b8a3e7f1c9d4a6b) SITE_SCOPE_SERVICE_NAMESiteScope CREATE_DESKTOP_SHORTCUTfalse CREATE_START_MENU_SHORTCUTfalse EOF 注意ADMIN_PASSWORD字段值ENC(...)是经过 SiteScope 内置算法加密的密文不能直接填明文。必须用bin/encryptPassword.sh工具生成sudo -u sitescope /opt/sitescope/install/bin/encryptPassword.sh YourStrongPass123!输出结果形如ENC(7e2a9c1f4b8d3e6a)复制替换response.varfile中的占位符。2.3 执行静默安装并验证服务状态解压原始 ZIP 包后进入SiteScope_2021.05_for_Linux_64bit/目录执行安装。关键点-f参数指定响应文件-i console是向导模式的 fallback但此处必须用-i silent。# 解压安装包假设 ZIP 在 /tmp cd /tmp unzip SiteScope_2021.05_for_Linux_64bit.zip cd SiteScope_2021.05_for_Linux_64bit/ # 以 sitescope 用户执行静默安装必须指定 -i silent sudo -u sitescope ./install.sh -i silent -f /tmp/response.varfile # 验证安装结果检查关键目录是否存在且权限正确 ls -ld /opt/sitescope/install/{bin,conf,webapps} # 正确输出应为drwxr-x--- 3 sitescope sitescope ... /opt/sitescope/install/bin # 启动服务首次启动会初始化数据库耗时约 90 秒 sudo -u sitescope /opt/sitescope/install/bin/startup.sh # 检查端口监听与进程注意进程名是 java不是 sitescope sudo lsof -i :8090 -P -n | grep LISTEN # 应看到java 12345 sitescope 123u IPv6 ... *:8090 LISTEN # 等待 2 分钟后curl 检查健康接口返回 HTTP 200 即成功 curl -I http://localhost:8090/SiteScope/health # 若返回 302 或 404说明 webapps 未正确部署需检查 /opt/sitescope/install/logs/catalina.out逻辑说明startup.sh实际调用的是内嵌 Tomcatwebapps/ROOT.war解压后运行其日志全部输出到logs/catalina.out。如果启动失败首要排查该文件前 50 行常见错误如java.lang.OutOfMemoryError: Metaspace需修改bin/setenv.sh中JAVA_OPTS-XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m或Could not load JDBC driver缺少 Oracle/MySQL JDBC 驱动 jar需手动放入lib/目录。3. 将 SiteScope 2021.05 注册到 LoadRunner 2022 Controller打通指标采集链路LoadRunner 2022 Controller 本身不包含 SiteScope Agent必须通过SiteScope Integration Plugin插件建立双向通信。这个插件不是“下载安装”那么简单它要求 SiteScope 提供 REST API 访问能力且 Controller 必须能解析 SiteScope 返回的 JSON 指标数据结构。很多团队卡在这一步以为装完 SiteScope 就自动连上了结果 Analysis 里始终看不到服务器指标。3.1 在 SiteScope 侧启用并验证 REST APISiteScope 2021.05 默认关闭 REST API出于安全考虑需手动修改配置并重启。关键配置项在conf/server.xml中# 编辑 Tomcat 配置启用 REST API 端点在 Service nameCatalina 标签下添加 sudo -u sitescope sed -i /\/Service/i \ Connector port8091 protocolHTTP/1.1 \ connectionTimeout20000 \ redirectPort8443 \ maxThreads200 \ minSpareThreads10 \ enableLookupsfalse \ compressionon \ compressableMimeTypetext/html,text/xml,text/plain,application/json / \ /opt/sitescope/install/conf/server.xml # 重启服务使配置生效 sudo -u sitescope /opt/sitescope/install/bin/shutdown.sh sleep 10 sudo -u sitescope /opt/sitescope/install/bin/startup.sh参数说明新增的Connector监听8091端口与 Web UI 的8090分离启用compression可减少指标传输体积compressableMimeType必须包含application/json否则 Controller 请求会返回未压缩的巨量文本触发超时。验证 REST API 是否就绪# 获取所有监控目标列表需 Basic Auth curl -u lradmin:YourStrongPass123! http://localhost:8091/SiteScope/api/v1.0/monitors # 正确响应HTTP 200 JSON 数组如 [{id:1,name:Linux_CPU,type:CPU}] # 若返回 401检查用户名密码是否正确若返回 404确认 server.xml 修改无语法错误标签闭合3.2 在 LoadRunner 2022 Controller 中配置 SiteScope 插件Controller 的插件管理界面Tools → Options → General → Plugins中SiteScope Integration Plugin 默认不显示必须手动注册。操作路径打开 Controller 安装目录如C:\Program Files\Micro Focus\LoadRunner\controller\plugins\将SiteScopeIntegrationPlugin.dll从 LoadRunner 2022 安装介质\Plugins\SiteScope\目录获取复制到上述plugins\文件夹重启 Controller 服务Windows Services 中重启HP LoadRunner Controller重新打开 Controller → Tools → Options → General → Plugins勾选SiteScope Integration Plugin。关键细节SiteScopeIntegrationPlugin.dll的版本必须与 LoadRunner 2022 主版本严格匹配如 2022.0.0.0。若用 2021 版本 DLLController 启动时会在Controller.log中记录Failed to load plugin: version mismatch但 UI 不报错极易忽略。3.3 在 Controller 场景中添加 SiteScope 监控器这才是真正落地的一步不是在 Controller 里“添加一台服务器”而是把 SiteScope 中已配置好的监控器Monitor映射进来。在 Controller 中打开场景Scenario→ Design → Add Measurements在 Measurement Type 下拉框中选择SiteScope点击Configure SiteScope Connection→ 填写SiteScope Server URL:http://your-sitescope-host:8091/SiteScopeUser Name:lradminPassword:YourStrongPass123!Enable SSL: 取消勾选除非你已配置 HTTPS否则强制启用会导致连接失败点击Connect成功后右侧会列出 SiteScope 中所有Enabled状态的 Monitor勾选你需要的 Monitor如Linux_CPU、Linux_Memory、Oracle_DB_Connections点击Add。重要逻辑Controller 并不直接采集服务器指标而是定时默认 5 秒向 SiteScope 的 REST API 发起GET /api/v1.0/monitors/{id}/data?startTime...endTime...请求拉取时间序列数据。因此Controller 和 SiteScope 的系统时间差必须小于 30 秒否则数据对齐失败Analysis 中指标曲线为空。建议统一配置 NTP 客户端指向同一时间源。4. SiteScope 2021.05 for Linux 的 5 个典型避坑指南血泪经验总结部署 SiteScope 最痛苦的不是安装而是那些文档里没写、报错里不提、但会让你调试三天的隐藏陷阱。以下是我在 12 个生产环境踩出的硬核问题按发生频率排序4.1 现象startup.sh执行后无任何输出ps aux | grep java查不到进程原因JAVA_HOME指向了 JRE 而非 JDK或bin/setenv.sh中JAVA_OPTS设置了过大的堆内存如-Xmx8g但系统物理内存不足JVM 启动失败且不打印日志。解决运行sudo -u sitescope /opt/sitescope/install/bin/startup.sh前先执行sudo -u sitescope $JAVA_HOME/bin/java -version验证 JDK 可用检查free -h确保空闲内存 ≥ 4GB临时注释setenv.sh中所有JAVA_OPTS用最小配置启动再逐步添加参数。4.2 现象SiteScope Web UI 登录成功但http://host:8091/SiteScope/api/v1.0/monitors返回 404原因REST API 的 Context Path 配置错误。SiteScope 2021.05 要求 API 必须挂载在/SiteScope/api/路径下但server.xml中Context标签的path属性被意外修改。解决检查/opt/sitescope/install/conf/server.xml确认存在且未被注释的Context标签Context path/SiteScope docBaseSiteScope reloadablefalse /若path为/或其他值改为/SiteScope并重启服务。4.3 现象Controller 添加 SiteScope 监控器后Analysis 中指标曲线全为 0 或空白原因SiteScope 中对应 Monitor 的Data Collection Interval采集间隔设置过长如 60 秒而 Controller 的Measurement Interval默认 5 秒无法匹配导致数据点缺失。解决登录 SiteScope Web UI → Monitors → 找到目标 Monitor如Linux_CPU→ Edit → Advanced → 将Collection Interval改为5秒必须重启该 Monitor右键 → Restart仅保存配置无效。4.4 现象SiteScope 采集 Linux 磁盘 I/O 时/dev/sda显示N/A但iostat -x 1命令可正常输出原因SiteScope 使用cat /proc/diskstats解析设备名而现代 Linux如 RHEL 8默认使用nvme0n1、dm-0等命名/dev/sda可能是 udev 规则创建的软链接diskstats中无此条目。解决在 SiteScope Monitor 配置中不填/dev/sda改填nvme0n1用ls -l /sys/block/查真实设备名或创建自定义 Shell Monitor脚本内容iostat -dx 1 1 | awk /nvme0n1/ {print $2,$3,$4}输出格式为read_ios write_ios avg_queue_len。4.5 现象Controller 连接 SiteScope 时提示Connection refused但curl http://host:8091/SiteScope/api/...正常原因Controller 运行在 Windows其网络栈默认不支持 IPv6而 SiteScope 服务器/etc/hosts中localhost解析到了::1IPv6导致 Controller 尝试用 IPv6 连接8091端口失败。解决在 SiteScope 服务器上编辑/etc/hosts将::1 localhost行注释掉或在 Controller 机器的C:\Windows\System32\drivers\etc\hosts中添加127.0.0.1 your-sitescope-host强制走 IPv4。5. 用 Shell Monitor 实现 Linux 关键指标深度采集绕过内置 Monitor 的局限性SiteScope 内置的 Linux Monitor如Linux_CPU、Linux_Memory只能采集/proc/stat、/proc/meminfo的基础字段但像slabinfo泄露、oom_kill计数、ext4文件系统延迟等深度指标必须用 Shell Monitor 自定义。这不是“高级技巧”而是生产环境刚需——比如某次压测中 TPS 突降内置 Monitor 显示 CPU 仅 40%但dmesg里满屏Out of memory: Kill process这就是没采集oom_kill导致的盲区。5.1 创建 Shell Monitor 的标准流程从脚本到指标映射Shell Monitor 的核心是脚本输出必须是严格格式的 keyvalue 对每行一个且 key 名必须与 Monitor 配置中定义的 Metric Name 完全一致。例如要采集 OOM Kill 次数# 创建采集脚本 /opt/sitescope/scripts/oom_kills.sh sudo -u sitescope bash -c cat /opt/sitescope/scripts/oom_kills.sh EOF #!/bin/bash # 统计系统启动以来的 OOM Kill 总数grep -c 会统计所有匹配行 OOM_KILLS$(dmesg | grep -c Killed process) echo oom_kills$OOM_KILLS EOF sudo chmod x /opt/sitescope/scripts/oom_kills.sh然后在 SiteScope Web UI 中Monitors → Add → Shell CommandCommand:/opt/sitescope/scripts/oom_kills.shWorking Directory:/opt/sitescope/scriptsMetrics Definition关键点击Add Metric填入Metric Name:oom_kills必须与脚本echo输出的 key 完全一致Data Type:IntegerUnit:CountCollection Interval:5秒。逻辑说明SiteScope 执行该脚本后会逐行解析 stdout。当遇到oom_kills12时自动提取 value12并存入名为oom_kills的时间序列数据库。如果脚本输出OOM_KILLS12key 大写而 Metric Name 填oom_kills则指标永远为 0。5.2 三个高价值 Shell Monitor 脚本模板已验证于 Rocky Linux 8.6指标类型脚本路径核心命令精简版Metric Name用途说明JVM Full GC 次数/opt/sitescope/scripts/jvm_gc.shjstat -gc $(pgrep -f java.*Application)tail -1awk {print $3}TCP 重传率/opt/sitescope/scripts/tcp_retrans.shss -iawk NR1 {sum_r$8; sum_t$2} END {printf %.2f, sum_r/sum_t*100} 2/dev/nulltcp_retrans_rateExt4 延迟直方图/opt/sitescope/scripts/ext4_delay.shcat /proc/fs/ext4/*/io_stats 2/dev/nullawk {sum$3} END {print ext4_avg_delay_mssum/NR}ext4_avg_delay_ms注意ss -i输出中$8是重传段数retrans$2是总发送段数bytes_sentNR1跳过表头/proc/fs/ext4/*/io_stats中\$3是第三列平均读延迟不同内核版本列序可能不同需先cat /proc/fs/ext4/sda1/io_stats确认。5.3 在 LoadRunner Analysis 中关联 Shell Monitor 与事务响应时间这才是闭环的价值当事务响应时间曲线出现尖峰时同步查看oom_kills是否跳变。操作步骤在 Analysis 中打开.lrr结果文件Graphs → Add New Graph → 选择SiteScope类型在 Metrics 列表中展开你的 SiteScope 服务器 →Shell Command→ 勾选oom_kills右键图表 →Merge with Transaction Response Time→ 选择目标事务如login_submit图表将显示双 Y 轴左轴为响应时间ms右轴为oom_killsCount时间轴完全对齐。我的血泪经验曾有一个支付接口在并发 200 时响应时间从 200ms 暴涨到 2s内置 Monitor 显示一切正常。加了oom_kills后发现尖峰时刻oom_kills从 0 突增至 17立刻定位到是 JVM 堆外内存泄漏Netty Direct Buffer而非应用代码问题。这种“指标交叉验证”能力才是 SiteScope LoadRunner 组合不可替代的核心价值——它把黑匣子变成了透明管道。希望帮到你。本文还有配套的精品资源点击获取