企业官网建设流程全解析

简介：面向Linux x86-64环境，LoadRunner_2022与SiteScope_2021.05整合包将负载测试与基础设施监控能力集于一身，适合测试工程师、运维人员用于应用性能评估、服务器及网络设备健康度监测。SiteScope覆盖从数据库到中间件的实时监控，LoadRunner则专注于高并发场景下的系统稳定性验证，两者结合可完善性能调优闭环。压缩包共38个文件、758.33MB，包含12个rpm安装包、12个xml配置关联文件、6个shell脚本、2个perl脚本以及PDF说明文档和properties配置模板，覆盖部署、升级、备份、卸载等完整维护流程。已有476人学习，尤其适合正在搭建或优化监控体系的团队参考。里面除安装程序和全套rpm组件外，还提供升级、备份、自定义JAR包备份等自动化运维脚本，以及安装配置模板和说明文档等关键文件，便于快速安装、迁移配置并规避升级过程中的兼容性问题，有效保障业务连续性。

1. LoadRunner 2022 里这个 SiteScope 包，为什么单独拿出来说？

做性能压测的人手里都有一份 LoadRunner_2022 的安装介质，解压后常见一个 SiteScope_2021.05_for_Linux_64bit.zip。它不是给 Windows 控制台用的普通插件，而是负责服务器资源监控的后台服务。很多人装完 LoadRunner Controller，压测跑起来，响应时间曲线有了，但 CPU、内存、磁盘这些服务器指标全是空的——问题多半就出在这个包没在 Linux 上单独部署。SiteScope 以 agentless 方式去采集被压测机的指标，再通过 HTTP 回传给 LoadRunner，把资源瓶颈和 TPS 对齐起来。适合三类人：要出性能测试报告的测试工程师、搭压测环境的运维，以及做容量评估的 SRE。下面从包结构开始，一路讲到部署、接入和踩坑。

2. SiteScope 2021.05 选型与包结构：为什么 LoadRunner 2022 要配这个组件？

2.1 从 LoadRunner 到 SiteScope：资源监控链路是怎么串起来的

LoadRunner 本质上是协议级压力发生器，Controllet 只管调度虚拟用户和汇总事务响应时间。被压测服务器的 CPU 使用率、内存剩余、磁盘队列长度、网络吞吐这类指标，必须另有一条采集通道。早期做法是在每台服务器上装小 agent，后来发现 agent 本身会吃系统资源，尤其是压测时 CPU 跑满，agent 先抖，监控数据跟着失真。SiteScope 走的是一条「中心化采集、远程免代理」的路子：把采集端服务装在一台独立的 Linux 机器上，用 SSH、WMI 或 SNMP 去连目标服务器，执行系统命令或读性能计数器，再把数据聚合成监控项。

LoadRunner 2022 选择带 SiteScope 2021.05 for Linux 64bit 的 zip 包，原因也在这：Controller 在 Windows 上跑，要被压的服务器多为 Linux，两者之间需要一个不装 payload 的监控服务。SiteScope 作为一个独立 Java 进程运行，默认监听 8888 端口，对外提供 Web 控制台，同时向上和 Controller 保持 HTTP 通信。整条链路是：LoadRunner Controller → SiteScope 服务（HTTP）→ 目标 Linux 服务器（SSH/SNMP）。

版本配套上，SiteScope 2021.05 与 LoadRunner 2022 属于同一代产品线，兼容性最省心。如果你想用旧版 SiteScope 去配新版 LoadRunner，可能会出现监控项上报字段对不上的问题，所以安装介质里给什么版本，就优先用那个版本，别到外网随便找一个 SiteScope 2020 来凑数。

2.2 zip 包里的目录与关键文件：先识别再动手

拿到 SiteScope_2021.05_for_Linux_64bit.zip，不要一上来就 unzip 到任意路径，先看一眼压缩包目录结构。常见做法是解压后得到一个 SiteScope 主目录，里面至少包含setup.sh、bin/、conf/、lib/、monitors/、templates/这几类内容。setup.sh安装脚本负责把目录部署成可运行服务；bin/下是启停脚本，如start.sh、stop.sh；conf/放站点监听地址、端口、许可证、日志级别等配置；lib/是 SiteScope 自带的 Java 运行时和依赖包；monitors/存放各监控器的模板定义。

第一次动手时，先把setup.sh的权限补上，因为 zip 解压不保证保留可执行位。用unzip -l看包内文件时，重点找 README 或 Release Notes 一类的文档，了解自带 JDK 的版本和默认端口。很多人会在解压后直接java -jar去找入口，结果找不到——SiteScope 不是跑一个 jar，而是跑安装脚本完成文件布局后再启动服务。正确的顺序是：先落目录 → 补权限 → 执行安装脚本 → 用start.sh起身。这一步顺序反了，后面启动会挂在一堆类加载异常上。

还要注意一个边界：Linux 上不要用 root 直接做主部署用户。SiteScope 一旦启动就会在 web 控制台里提供增删监控器的能力，权限相当于一个运维入口，root 跑意味着泄漏即最高权限。我一般会用单独的系统用户siteadmin，只给它 SiteScope 目录的读写权限，SSH 登录也限定到该用户。这样即使 web 控制台被爆破，影响面也有限。

3. 在 Linux 64bit 上部署 SiteScope 2021.05：脚本、目录与最小配置

3.1 安装前置条件：JDK、系统库和用户

SiteScope 是 Java 应用，但新版包通常自带 JRE，所以系统里不装 JDK 也能跑。不过生产环境里经常有 Zabbix、Jenkins 等应用带了 OpenJDK，版本不一致时会影响 SiteScope 的 SSL 行为。因此我建议先确认系统是否已有 JDK，有的话记录版本，SiteScope 启动时优先用自带 JRE，避免被外部JAVA_HOME干扰。

检查系统环境可以走一组最常用的命令：

# 查看系统位数和内核版本，确认是 64bit 环境 uname -m && uname -r # 查看已安装的 JDK，如果输出为空说明可以放心走自带 JRE java -version 2>&1 || echo "no system JDK" # 检查基础库是否存在，缺失某些字体库时 web 控制台会样式错乱 ldconfig -p | grep -E "libXext|libXrender|fontconfig"

逻辑说明：uname -m输出x86_64表示 64 位架构，和标题里 Linux 64bit 对应；uname -r看内核版本，方便后续查兼容性。ldconfig -p是检查动态库的标准方式，SiteScope 的 web 界面在生成图表时依赖少量 X 字体库，纯 headless 环境一般能跑，但如果有报错就往这个方向查。

参数说明：如果libXext缺失，在 CentOS/RHEL 系用yum install libXext libXrender fontconfig，Ubuntu 系用apt install libxext6 libxrender1 fontconfig。这里不是 SiteScope 的坑，是所有 Java 服务画 UI 的通用依赖。

3.2 解压与静默安装：命令与参数说明

部署的第一步是把 zip 放到计划目录，解压后归属到专用用户。这里给出完整操作序列。

# 1. 创建安装根目录并上传 zip 包 sudo mkdir -p /opt/loadrunner sudo cp SiteScope_2021.05_for_Linux_64bit.zip /opt/loadrunner/ # 2. 解压到 SiteScope 子目录，保持目录名干净 cd /opt/loadrunner sudo unzip -q SiteScope_2021.05_for_Linux_64bit.zip -d SiteScope # 3. 把整个目录转给专用用户，后续运行不碰 root sudo chown -R siteadmin:siteadmin /opt/loadrunner/SiteScope # 4. 切换用户并执行安装脚本 sudo -u siteadmin -H bash cd /opt/loadrunner/SiteScope chmod +x setup.sh ./setup.sh -console

逻辑说明：-q让 unzip 只输出错误，避免解压几千个文件刷屏；-d SiteScope指定解压目标目录，避免 zip 包里的路径结构直接散落在/opt/loadrunner下。chown -R把属主改为siteadmin，这一步没做，后面启动脚本会因目录不可写而在生成日志时报错。setup.sh -console是交互式安装，适合第一次部署，能准确看到每一步在写什么。

执行setup.sh后，安装脚本会用一堆提示提问：安装目录、HTTP 监听端口、是否开机自启、许可证路径。常见做法是端口默认留 8888，监听地址用0.0.0.0或具体内网地址——如果只需要 Controller 访问，建议写内网网卡地址，别暴露到公网。用户和密码要单独设，后续 LoadRunner 连接时要用。

如果环境需要批量部署，可以走静默模式。先跑一次交互安装，安装完在安装根目录找一个install.properties或相似响应文件，把里面路径、端口、用户信息改好后，重新执行./setup.sh -silent即可。静默安装的好处是参数固化，不会因为某台机器提问顺序不同而选错。

3.3 启动验证：端口、进程与状态页

安装完成后，启动服务并确认三个事实：进程在、端口在、状态页面能返回 HTTP 响应。

# 启动 SiteScope（要在 siteadmin 用户下执行） cd /opt/loadrunner/SiteScope/bin ./start.sh # 等待 30-60 秒，查看进程是否存在 sleep 30 ps -ef | grep -i sitescope | grep -v grep # 检查端口监听情况，默认 8888 netstat -tlnp | grep 8888 # 用 HTTP 请求探活 Web 控制台，返回 200 说明已就绪 curl -sI http://127.0.0.1:8888/ | head -5

逻辑说明：start.sh内部会读取conf/SiteScope.conf，设置JAVA_HOME指向自带 JRE，然后以后台进程方式拉起 Java 主程序。sleep 30不是玄学，SiteScope 首次启动要做监控器模板编译和数据库初始化，时间比普通 Java 服务更长，可能出现端口还没起来但进程已存在的情况。netstat -tlnp需要 root 权限，如果没有 root 就用ss -tlnp，但输出里进程名要配合sudo才能显示。

参数说明：启动内存默认由bin/start.sh里的SITESCOPE_HEAP或-Xmx控制。监控节点多的环境，建议物理机内存 8GB 起步，堆内存给到 4GB。如果只监控三五台业务服务器，2GB 堆完全够用。修改后重启才生效。

缺省情况下，SiteScope 首次启动没有许可证时会进试用模式，能创建少量监控器。正式压测前要把 LoadRunner 2022 侧生成的 License 填进去，License 文件的路径在conf/下，web 控制台的「许可证」页面也支持粘贴字符串方式注册。

4. 把 SiteScope 接进 LoadRunner 2022：监控协议、端口与场景配置

4.1 LoadRunner 控制器里的 SiteScope 监控项

SiteScope 部署完成只是前半场。回到 LoadRunner Controller，在场景设计界面左侧找到「服务器资源监控」或「SiteScope 监控器」，这里要新增一条指向 SiteScope 的连接。填写的核心字段是 SiteScope 所在主机的 IP 和 8888 端口，再填上创建监控器时设置的用户名密码。Controller 通过 HTTP 请求访问 SiteScope 的 API，不用在 Controller 机器上装任何客户端。

连接成功后，Controller 会把 SiteScope 上已有的监控器列出来。这里常见的操作差异是：有人直接在这里勾选默认监控器，有人先去 SiteScope web 控制台把目标服务器监控器配好，再回 Controller 刷新。推荐后者。因为 SiteScope 侧配置时能直观测试 SSH 连通性，配错了当场能看到「无法连接到远程主机」的报错；在 Controller 侧排查会隔着一层 API，信息反而少。

监控协议选择上，SiteScope 针对 Linux 服务器最常用的是 SSH 监控器，它通过 SSH 执行/proc/stat、/proc/meminfo、df等系统命令获取指标。另一类是无需要登录的 SNMP 监控器，适合网络设备和开启了 SNMP 的 Linux 服务器。SSH 更精准也更常见，因为能拿到进程级数据，SNMP 只能拿到系统级 MIB 数据。

4.2 监控 Linux 服务器要解锁的指标与参数

在 SiteScope web 控制台里添加一个新的「Unix/Linux 监控器」，需要填的字段不多，但每个都直接影响数据质量。

首先是目标主机，写 IP 即可。然后是 SSH 凭据，这里有两种做法：密码方式简单，但压测过程中如遇安全策略要求改密，监控器立即断开；公钥方式稳定，把 SiteScope 所在机器的公钥加到目标服务器的authorized_keys里，监控器就不受口令过期影响。我做稳定性压测时一律用公钥，省去长时间跑批时半夜被密码过期断掉的风险。

采集间隔是第二个关键参数。默认往往在 60 秒左右，这对看趋势足够，但对定位瞬时 CPU 飙高不够。建议压测场景的采样间隔设在 5～15 秒。间隔太短，每一轮都要新起 SSH 会话查一堆命令，对目标服务器造成额外开销，极端情况下采集本身会推高 CPU 零点几个点，性能基线上就带误差了。我在做高并发压测时一般取 10 秒，兼顾精度和开销。

要监控的指标组，至少勾选 CPU（用户态、系统态、空闲态）、内存（物理内存、交换分区）、磁盘（使用率、I/O wait）、网络（网卡吞吐量和错误包）。SiteScope 会把这些指标拆成独立监控项，所有监控项都能在 LoadRunner 的结果图表里叠加到事务响应时间曲线上。如果压测目标是定位 SQL 慢查询，还可以在监控器里加一个「进程监控」，填上 mysqld 或 java 的进程名，就能看到该进程的 CPU 占用和虚拟内存变化。

4.3 用 SiteScope 模板跑通一次场景

服务器数量多时，一台台在 web 控制台加监控器效率太低。SiteScope 支持把一组监控器保存为模板，然后通过模板创建应用到多台主机。

常见做法是：先在「监控器组」里建一个组，命名如LR_2022_OrderService，组内加入一个 Linux 监控器，把指标选好、间隔设好，写成模板。然后复制模板生成新的监控器，只修改目标主机 IP。这样批量加 30 台机器只需要 10 分钟，而且在 LoadRunner Controller 侧可以直接看到整组监控器。

跑通一次的验证流程我这样走：第一步在 SiteScope 侧确认监控器状态为「正常」，颜色是绿色，没有红色告警；第二步回到 Controller，在场景运行前点击「刷新」，确认监控器列表数量和 SiteScope 侧一致；第三步跑一个只有 5 个虚拟用户、持续 3 分钟的短场景，期间打开在线监控图，观察指标曲线是否在更新。若曲线在走，说明全链路通了，再切回正式压测脚本。

5. 部署与集成避坑：5 个让性能测试白跑的常见问题

5.1 现象：SiteScope 启动成功但 LoadRunner 连不上

压测场景里 SiteScope 服务启动了，Web 控制台也能访问，但 LoadRunner Controller 添加监控器后始终提示「无法连接 SiteScope」。很多人会先怀疑防火墙，其实最常见的原因在 Controller 侧填的端口与 SiteScope 实际监听地址不匹配。

原因：SiteScope 安装时监听地址被设成了内网 IP 或回环地址，Controller 访问用的却是不通该 IP 的网络路径，或者 8888 被安全组挡掉了。

解决：先执行ss -tlnp | grep 8888确认监听地址是不是0.0.0.0。如果只有127.0.0.1:8888，说明安装时选了仅本机访问，要改conf/SiteScope.conf里的监听地址并重启。然后在 Controller 机器上用telnet <SiteScope IP> 8888验证三层可达。注意 LoadRunner 和 SiteScope 跨网段时，两边防火墙都要放行 8888。

5.2 现象：监控图出现断点，数据是间歇的

长时间压测时，LoadRunner 结果图上的 CPU、内存曲线断断续续，一段有值一段空白，整体趋势看不完整。

原因：SiteScope 默认的 SSH 保活时间不够长，加上压测期间网络抖动，SSH 连接断掉后没有自动重连。另一个常见因素是采集间隔设置太小，比如 3 秒一次，SiteScope 并发处理不过来，部分轮次超时被丢弃。

解决：在 SiteScope 的 SSH 监控器设置里把「连接超时」和「命令执行超时」适当调大，常见做法是 30 秒。同时把采集间隔从 5 秒以下调到 10～15 秒，减少瞬时连接数。若压测机网络本身自带漂移，建议在 SiteScope 所在机器上开启 sshd 的 TCPKeepAlive 配置，保持长连接。

5.3 现象：监控项全是 0，但没有报错

站点监控器显示正常，LoadRunner 图表也能画出来，但数据值一直是 0，CPU 和内存全都没有变化。这种情况最误导人，压测报告交上去前才发现数据没法用。

原因：目标 Linux 服务器的/proc文件系统被 Seccomp 或容器限制，有些命令如free、vmstat返回空值；更常见的是 SiteScope 用 SSH 执行命令时，目标机器的 VISUAL 编辑器或登录 shell 初始化脚本输出了干扰文本，导致解析器拿到脏数据。

解决：把 SiteScope 的 SSH 监控器命令改为绝对路径，例如/usr/bin/free，避免 PATH 环境差异。同时检查目标服务器登录 shell 是不是 nologin，如果是，可以在 SiteScope 监控器设置里指定使用 sftp-subsystem 方式执行命令，绕开 bash 启动脚本的干扰。改完后立即在监控器中点「运行一次」测试，看输出里是否有非数字字符。

5.4 现象：磁盘 I/O 和网络延迟监控不出来

CPU 和内存指标都正常，磁盘 I/O wait、网卡包错误率这些子项却显示出来或完全没有。

原因：SiteScope 对磁盘和网络子项的采集依赖的/proc数据在部分 Linux 版本上字段位置不同，旧版监控器模板没有适配 eBPF 或 sysfs 新接口；另一原因是被压测机启用了 systemd 的cgroup v2，SiteScope 读旧路径/proc/self/cgroup得到错误数据。

解决：优先升级到 SiteScope 2021.05 自带的最新监控器模板，这个版主对 RHEL 8/9、Ubuntu 20.04+ 的兼容性好很多。如果仍取不到 I/O 指标，可以在目标服务器上部署sysstat包，让 SiteScope 通过执行/usr/bin/iostat -x来获取，而不是直接解析/proc/diskstats。这是老版本最常见的补丁手段。

5.5 现象：卸载重装后端口被占用

重装 SiteScope 或换个版本试用时，start.sh报端口 8888 已被占用，但netstat又看不到明显进程。

原因：SiteScope 停止脚本没把 Java 子进程带掉，或旧实例的 PID 文件残留，导致你以为已停止，实际还是有进程占着端口。这类问题在 linux 运维故障案例里非常典型，通常由不干净的 kill 引起。

解决：先ps -ef | grep java | grep -i sitescope找到真实残留进程，用kill -9 <pid>清掉；然后删除bin/下的 pid 文件。如果占用端口的是其他服务，可以直接修改conf/SiteScope.conf里的监听端口，但请注意 LoadRunner Controller 里同步改成新端口。最后记得在重装前先执行stop.sh并确认端口释放，再跑安装脚本。

6. 进阶：把 SiteScope 实例整体迁移，压测环境半小时复活

SiteScope 最烦人的一面就是监控器配置量大，一台上百个监控项全是手工维护的。遇到环境迁移或重做系统时，重新搭一遍不是不行，但压测窗口就那么短，我更建议把 SiteScope 目录直接打包带走。

首先要做的是停机后打包。SiteScope 在运行中会把监控器状态写入state/和日志文件，在线打包容易出来不一致的备份，宁可花两分钟停机，也别赌那一个瞬间的一致性。常见做法是把/opt/loadrunner/SiteScope完整打成 tar.gz，同时把conf/下的许可证文件单独拷一份存到安全目录。新机器上的解压恢复动作非常简单。

# 旧机器上停机并打包 cd /opt/loadrunner/SiteScope/bin ./stop.sh cd /opt/loadrunner tar -czf sitescope_backup.tar.gz SiteScope # 新机器上解压，修正属主后直接启动 sudo mkdir -p /opt/loadrunner sudo tar -xzf sitescope_backup.tar.gz -C /opt/loadrunner sudo chown -R siteadmin:siteadmin /opt/loadrunner/SiteScope cd /opt/loadrunner/SiteScope/bin ./start.sh

逻辑说明：stop.sh确保所有监控器采集线程正常退出，没有半写入状态。打包时不带外部的 JDK，因为包内自带 JRE，这样不同 Linux 发行版之间迁移，不管是 CentOS 还是 Ubuntu 都能直接跑。tar -xzf后所有文件的相对路径保持不变，SiteScope 对安装路径有依赖，所以新机器的目录层级必须和旧机器一致，比如都是/opt/loadrunner/SiteScope，否则启动时找不到配置文件。

参数说明：如果新机器内存比旧机器小，启动前要修改bin/start.sh里的堆大小。例如原来给了 4G，新机器只有 2G，可以调整-Xmx2048m，别带着过高堆参数启动导致 GC 频繁阻塞。

迁移后验证要做两件事：一是 curl 状态页出新控制台界面，二是确认原监控器列表里每台目标的 SSH 公钥仍然有效。新机器的公钥如果被重新生成，需要重新ssh-copy-id到各被压测机，否则监控器状态会是「认证失败」。我就遇到过迁移后压测场景全绿，但监控数据全空的情况，最后发现是公钥没跟过来。

这个整体迁移的思路陪着我把压测环境从测试网搬到生产网，省掉的不光是时间，还有手工配置漏项带来的数据失真。从那以后我的习惯是每两周打一次 SiteScope 配置备份，压测前确认备份时间戳。希望你也能把这个习惯用在生产环境里，希望帮到你。

本文还有配套的精品资源，点击获取