大多数 SharePoint 故障是这样被发现的：一个帮助台工单。财务部门某人打不开文档库，接着又有三个工单出现，当管理员团队确认问题时，公司一半的人已经遇到了这个问题。
农场的服务器很可能一直处于“在线”状态。这就是 SharePoint Server 的陷阱。一个页面加载过程涉及 IIS 前端、身份验证链、服务应用程序和 SQL Server。这些层中的任意一层性能下降，而所有基本的正常运行时间检查依然显示正常。
本指南涵盖了 SharePoint 农场上实际需要监控的内容、内置工具的局限、如何设置在第一个工单出现前就触发的警报，以及如何将监控数据转化为管理层可接受的 SLA 报告。
为什么 SharePoint 问题先到达帮助台而不是你
Ping 和端口检查只能回答一个问题：服务器是否可达？而 SharePoint 可能出现的失败，ping 根本无法察觉。
例如一个周一早上登录高峰。上百名员工在上午九点同时进行身份验证，ADFS 服务器处理不过来，通常需要两秒的登录耗时变成四十秒。所有服务器都能响应 ping，IIS 返回 200 状态码。但没人能登录内网，工单便开始出现。
或者更慢的版本：SQL 内容数据库所用磁盘的延迟在一个月内缓慢上升。页面加载时间从一秒变成四秒。没有阈值被触发，因为没人关注那个变化的数字。
两种情况模式相同。失败的层位于“服务器在线”和“用户获得文档”之间，这正是 SharePoint 服务器监控必须涵盖的中间地带。
SharePoint 服务器农场监控什么
你不需要数以百计的计数器。你需要的是那份能预测用户痛点的简短列表，并且持续监控。
| 层级 | 监控内容 | 原因 |
|---|---|---|
| IIS 前端 | 请求队列长度、5xx 错误率、CPU 和内存、应用池回收 | 排队的请求是农场跟不上负载的最早迹象。 |
| SQL Server | 内容数据库卷的磁盘读写延迟、阻塞等待、事务日志增长 | 几乎每个 SharePoint 操作最终都依赖 SQL。磁盘变慢会拖慢一切。 |
| 搜索 | 爬网新鲜度、爬网队列积压、查询延迟 | 陈旧或缓慢的搜索是最常被报告的 SharePoint 问题之一，而且其性能下降往往无声无息。 |
| 计时器作业 | 失败作业数、关键作业最后运行时间 | 失败的计时器作业会悄悄破坏工作流、配置文件同步和使用报告。 |
| 分布式缓存 | 每个运行缓存的服务器上的缓存主机状态、AppFabric 服务健康 | 登录令牌和信息流存在于此，一个坏的缓存主机会引发全农场难以追踪的症状。 |
| 身份验证 | 通过 AD、ADFS 或 Entra ID 的登录往返时间 | 身份验证是农场范围的单点故障，服务器计数器几乎无法反映。 |
| 用户体验 | 登录时间、关键站点集的页面加载时间、搜索响应、文档上传/下载 | 这些是用户感受到的，也是你 SLA 所用的术语。 |
最后一行是大多数 SharePoint 监控配置会跳过的。服务器计数器告诉你组件是否压力过大。只有像用户一样执行登录、打开库、运行搜索的检查，才能告诉你农场是否真正交付了服务。根据农场情况，还要监控服务应用池，如果还有使用旧版工作流，则监控 Workflow Manager。
在设置任何阈值之前，先在正常的一周内为每个指标设定基准。70% 的 CPU 利用率没有意义，除非你知道正常值是 40% 还是 65%。
内置工具能捕捉什么，漏掉什么
SharePoint Server 自带真正的监控机制，你应该加以利用。微软的监控文档涵盖了三个主要部分：
- 健康分析器针对农场配置和已知故障情况运行基于规则的检查，并能自行修复部分问题。
- 诊断（ULS）日志写入详细的跟踪日志，定位根因时非常有用。
- 使用和健康数据收集收集请求和服务统计到使用和日志数据库。
使用 System Center 的团队可以添加 SharePoint 管理包，获得基于事件的警报。
但要注意这些工具的共同点：它们运行在农场内部并报告农场状态。它们无法告诉你负载均衡器是否将用户发送到离线节点，ADFS 端点证书是否过期，或者分支机构访问页面加载耗时九秒。健康分析器的规则也按计划运行，有的每天或每周检查一次，因此问题可能出现在两次运行间未被发现。
内置工具是监控策略的内部部分。外部部分必须由模仿用户方式接近 SharePoint 的检查来完成。
如何监控用户实际体验
外部部分是合成监控：按计划执行的脚本检查，执行真正的 SharePoint 任务。对 SharePoint 农场有用的脚本包括四个步骤：
- 步骤 1：登录。使用具有最低权限的专用监控账户。计时完整的身份验证往返，包括所有 SSO 重定向。
- 步骤 2：加载页面。打开你最繁忙的站点集或内网首页，在真实浏览器中记录加载时间，而非仅仅 HTML 响应。
- 步骤 3：运行搜索。查询一个应返回已知文档的关键词，如未命中检查即失败。这样可捕获服务器端视图不会标记为用户问题的索引滞后。
- 步骤 4：操作文档。从库中打开或下载测试文件，验证通过 IIS、权限和 SQL 的完整路径。
使用 Dotcom-Monitor，这是一项网页应用监控任务，只需用EveryStep 脚本录制一次，随后从任何用户位置回放。对于面向互联网或混合部署，意味着从用户所在区域的外部节点执行。对于仅限内网的农场，私有代理从你的网络内部执行相同的脚本检查，因此本地部署并不免除用户级监控。
身份验证需要有计划而非回避。如果你使用 Entra ID（原 Azure AD），为监控账户设置单独的条件访问策略，将 MFA 换成允许的监控 IP 范围。无论账户放在哪，凭据都存于安全库并按正常计划轮换。如果农场使用 ADFS 或 Entra ID 认证，登录步骤也当作整个链条的健康检查。我们在监控使用 ADFS 的应用中详细介绍了设置细节。
如果你的部分资产位于 Microsoft 365，同样的脚本方法适用。我们关于Office 365 合成监控的指南对此有所阐述。你看不到微软的服务器状态，因此用户级检查是你拥有的 SharePoint Online 唯一度量方法。
如何设置比第一个工单更早触发的警报
目标是明确的竞赛：你的警报必须在第一个帮助台工单之前触达。三条实践决定成败。
对用户感知指标发警报，用服务器指标做诊断。登录时间翻三倍或搜索失败时通知值班人员，因为这就是工单来源。让 CPU 和磁盘指标为警报提供注释，而非发起警报。服务器计数器报警经常会导致团队忽视自己的警报。两个有效的起始规则：登录时间连续两次超过基线两倍时报警，搜索检查未命中已知结果时报警。
验证后再通知。单点位置检查失败可能是网络闪断。两地失败或连续两次失败才视为事故。大多数警报疲劳都源于跳过这一步。Dotcom-Monitor 会自动在第二个地点进行复检后再发出警报。
设置频率符合 SLA 计算。如果你的可用性目标是 99.9%，每月容忍约 43 分钟停机。每 15 分钟检测一次，可能在首次警报前已耗费近三分之一预算。在重要流程上每 1 到 5 分钟执行用户级检查，并在监控工具中安排维护窗口，使补丁时段不触发警报且不污染可用性记录。
如何报告 SharePoint 可用性以符合 SLA
大多数 SharePoint 团队对 SLA 有责任，无论是合同承诺还是对业务的内部承诺。上述监控配置产生证据：每次检查、每次失败和每次响应时间的时间戳记录，独立于农场自身日志。
这种独立性很重要。当农场日志显示“健康”，用户却说“慢”，用户侧第三条记录可以决定争议。它还为混合环境提供微软服务仪表板永远不会给出的东西：跨本地和云的连续可用性数据。
月度 SLA 报告需三项内容：对目标的实际可用率、你编排的用户流程响应时间趋势，以及事件列表及其持续时间和根因。可用性与 SLA 报告可直接从检查历史生成前两项，定期发送给相关人员。趋势线在事件之间发挥价值。页面加载时间从 1 秒升至 3 秒的季度趋势，是你可以提前行动的早期容量预警，有效避免工单洪峰。
哪款 SharePoint 监控工具适合你的环境
不同工具监控问题的不同半边，因此公平的比较是从视角出发。
内置工具（免费）。健康分析器、ULS 日志和使用数据收集。无论你买什么别的，都应使用。它们帮助正确配置农场和支持根因排查，但不会实时警报也无法测量用户体验。
基于代理的基础设施监控。ManageEngine Applications Manager 和 SolarWinds Server & Application Monitor 均附带 SharePoint 模板，收集农场计数器：数据库大小、计时器作业失败、IIS 和 SQL 状态、请求数等。PRTG 包含类似的 Windows、IIS 和 SQL 预置传感器，并可扩展自定义脚本。适合上表中的服务器端监控项，如果你已有针对 Windows 资产的此类工具，指向农场即可。使用 System Center 的环境，SCOM 结合 SharePoint 管理包同样覆盖这些内容。
合成监控平台。Dotcom-Monitor 从用户侧工作：脚本登录、页面加载、搜索和文档操作，通过外部节点或私有代理执行，建立在这些检测基础上的警报和 SLA 报告层。它赢得了比第一个工单更早的竞赛，捕捉代理工具结构上无法捕获的故障，对于 SharePoint Online，这是唯一可用的层级。
大多数做得好的团队会搭配内部工具和外部工具。重要的是两半都存在，因为一个的盲点是另一个的核心覆盖。
结论
SharePoint 服务器监控要覆盖两个层面：解释问题的农场指标，以及检测问题的用户级检查。监控预测痛点的短列表，编写脚本执行四个关键用户操作，对用户感知指标发警报并内置验证，让检查历史同时作为 SLA 报告。
