如何监控您网站上的嵌入式 PDF 查看器

最后更新:

浏览器窗口显示一个网页,其中嵌入的PDF查看器区域未能渲染文档

您的正常运行时间监视器报告200 OK。页面加载了。客户来阅读的合同却在文档应该出现的地方显示为一个灰色矩形。

嵌入式PDF查看器的故障是页面级检查永远看不到的。容器页面是健康的,但其中的查看器却不是。没人提交工单,因为访问损坏页面的用户都认为是他们的浏览器问题,于是离开了。

本指南涵盖了什么会故障,为什么标准的正常运行时间检查会遗漏它,以及如何建立检测机制,在读者发现之前提前知道。

本指南内容

什么算作嵌入式PDF查看器?

三种设置涵盖了您在企业网站几乎能遇到的所有情况。

浏览器原生嵌入。 一个指向PDF网址的 <iframe><embed><object> 标签。Chrome、Edge、Firefox 和 Safari 各自用内置查看器渲染,且表现稍有不同。

Adobe PDF Embed API。 Adobe 提供的免费JavaScript库。您的页面加载 https://acrobatservices.adobe.com/view-sdk/viewer.js,传入客户端ID,并调用 previewFile() 载入文档URL。Adobe 提供四种嵌入模式:全窗口、指定大小容器、内联和灯箱。

第三方查看器库。 PDF.js、Apryse WebViewer、Nutrient 和类似SDK,渲染页面至您控制的canvas元素。

这三者有一点共通:文档不会在交付页面的响应里出现。文档是在之后单独获取,有时由浏览器自带查看器下载,有时由您从第三方加载的JavaScript获取,且通常来自不同于页面的主机。

为什么标准正常运行时间检查会漏掉损坏的查看器

HTTP正常运行时间检查请求页面并读取响应。它得到200状态和一个包含空的 <div id="adobe-dc-view"> 的HTML块。检查通过。只要页面返回HTML,这个检查每五分钟都会继续通过。

但决定读者是否看到文档的一切动作都发生在响应之后:

  1. 浏览器从第三方主机获取查看器脚本。
  2. 脚本初始化并占用其容器元素。
  3. Adobe 验证客户端ID与您注册的域名是否匹配。
  4. 查看器请求PDF,通常来源于与页面不同的源。
  5. 首页内容渲染到容器中。

HTTP检查看不到这些。这与第三方内容监控常见的盲区相同。页面中您没有构建的部分是您监控最不可能覆盖的。

示意图比较HTTP正常运行时间检查所见(200响应+空容器div)和读者所见(失败的PDF查看器)
HTTP检查验证容器页面,读者则看到加载到其中的文档。

嵌入式PDF查看器是如何失败的

文档URL失效

常见且戏剧性最小的原因。一次CMS迁移更改了文件路径。有签名的S3或Azure Blob URL过期了。有人整理存储桶。页面仍然能渲染,查看器仍然初始化,但请求返回404,出现在您的CDN日志和浏览器控制台,却没人留意。

CORS阻止下载

Adobe 官方文档警示:当您传入PDF内容为URL,且查看器必须从其他域下载文件时会出现CORS问题。解决办法是页面和文档托管在同一域,或在PDF资源上启用CORS头。无论哪种情况,安全审查收紧文档主机上的头信息,都可能在不修改页面代码的情况下破坏网站上的所有嵌入查看器。

客户端ID不再匹配域名

这点常让团队措手不及。Adobe在开始渲染时验证客户端ID,如果ID用于未注册域名,预览会被阻止并显示错误信息。启动新子域、转向新营销站或推广带有预发布客户端ID的测试版本,就会导致查看器在刚发布的页面上失败。

查看器脚本未加载

您的页面依赖于他人CDN上的脚本。内容安全策略更新、企业代理、广告拦截器或脚本主机故障都会导致容器为空。如果您的CSP是原因,通常要检查的指令是查看器脚本的 script-src 以及文档抓取的 frame-srcconnect-src

文档后端的认证失效

登录后访问的文档根据查看器不同访问方式不一:签名URL、通过凭据传递的会话cookie,或SDK支持时放在自定义头中的承载令牌。纯 <iframe> 完全无法附加自定义头,因此认证文档通常都采用签名URL。无论哪种方式,令牌会过期,SSO迁移更改cookie作用域后,查看器会收到401,表现为无内容显示。这里同样需要与需要身份验证的应用监控相同的细致处理。

PDF使用了查看器不支持的功能

Adobe PDF Embed API不支持XFA表单、数字签名字段、条码字段及运行JavaScript计算的表单字段。这些情况常出现在仍使用XFA的政府申请、保险理赔、以及Adobe LiveCycle多年以前构建的法律文档。这些文档在桌面Acrobat中打开正常,但在网页嵌入时会给读者显示警告对话框而非可用表单。Adobe还限制文件渲染时长为五分钟,超过后查看器显示Preview Rendering Failed错误。

损坏的PDF查看器会在哪些方面造成损失

大部分故障发生在发布高峰期,恰恰是文档最重要的时刻。

投资者关系。 季度财报在固定时间上线。新闻稿页正常发布。下面嵌入的10-Q文件指向一个财务团队一小时前更改的路径。

福利与保险。 每年开放报名期仅几周。计划总结、表单和保障文件批量重新发布,一次存储权限更改能瞬间使数百个嵌入查看器失效。

政府及公共部门。 许可申请、税务表格和公共通知承载最多遗留表单功能,并由通常无法查看网站错误日志的团队发布。

受监管产品文档。 安全数据表、设备手册和分析证书常属合约义务。查看器停止渲染不仅是用户体验问题,还是合规风险。

品牌与销售材料。 产品介绍页、案例研究和品牌指南PDF放在着陆页和合作伙伴门户,发布后很少有人回访,但重建频率远高于列表中其他内容。一个更新的logo或新模板意味着新文件、新路径,而嵌入代码依然指向旧版本。

如果文档每年只有两周流量,全年运行的检测是唯一能在第七个月发现它坏掉的方式。

如何监控嵌入式PDF查看器

你需要两层检测:一个廉价的文档文件检查,和一个真实浏览器检测以证明查看器已渲染。以下是构建步骤。

步骤1:清点嵌入文档的页面。 在代码库或CMS中搜索 adobe-dc-viewviewer.jspreviewFile<embed<object 和iframe中的 .pdf。同时检查CMS组件设置,因为很多企业网站是从字段生成文档URL,而非硬编码标记。多数团队发现嵌入远超预期,包括无人管理的页面。

步骤2:直接监控文档URL。 用HTTP检测指向PDF文件并断言响应。200状态是基础。加上体积下限,以防零字节文件或HTML错误页通过检测;如果可能断言主体以 %PDF- 起头,而不是依赖 Content-Type 头,因为许多文档主机将PDF标为 application/octet-stream。用GET而非HEAD,因为一些存储端点拒绝HEAD请求。

步骤3:用真实浏览器加载容器页面。 HTTP检查不能执行JavaScript,查看器无法初始化。Dotcom-Monitor的网页监控在真实浏览器中加载页面,提供完整请求时间线,能精确看到查看器脚本和文档请求是如何发起的。时间线捕捉单独文件检查无法检测的失败:CORS拒绝、被阻请求及cookie因SameSite变更失效。

步骤4:断言查看器生成的内容。 这一步赋予检测意义,也是最细致的步骤,因为PDF查看器以不同方式隐藏内容。PDF.js暴露文本层可直接断言。Adobe SDK 和基于canvas的查看器将页面渲染为图像,应该断言外围内容:页数指示、工具栏或渲染页面容器。浏览器原生 <iframe> 嵌入几乎没有DOM暴露,需回退到网络结果检测PDF请求,并结合区域视觉检测。用EveryStep网页录制工具录制页面,添加负断言捕捉错误状态,如“Preview Rendering Failed”或“Failed to load PDF document”文本标记检测失败。Dotcom-Monitor的内容断言支持这两种情况。

步骤5:分开监控认证路径。 如果文档需登录,录制登录和文档浏览作为一个多步骤浏览器事务监控。凭据存于安全保管库而非脚本。对于无法公网访问的内部门户,用私有代理在内网执行相同步骤。

步骤6:监控您不拥有的依赖。 对查看器脚本URL进行HTTP检测,若文档来自对象存储或文档服务,在端点上加上API监控。嵌入查看器失败时,这能区分第三方故障和自身变动。对文档主机加上SSL证书监控,因为独立文件域的证书过期会导致抓取失败,主站却显示正常。

步骤7:设定渲染时间阈值,而非只监测页面加载。 40MB扫描文档用了25秒才显示,从读者角度看是破损的。用几次成功加载的瀑布图找出正常渲染时间,超出合理偏差时报警。

步骤8:将告警发送给文档负责人。 内容团队发布PDF,通知他们。配置告警规则同时通知IT,且要求两次连续失败才通知,以防单次慢渲染打扰人员。

示意四个监控检查点:容器页面、查看器脚本、文档请求与渲染输出
页面级检查覆盖第一跳,后面三跳才是嵌入文档真正发生故障的位置。

需要断言什么及断言频率

频率应根据文档的重要性和希望多快得知故障调整。

检测对象 检测类别 断言内容 建议间隔
PDF文件本体 HTTP 200状态,%PDF-头部,大小下限 5分钟
查看器脚本可用性 HTTP 200状态,响应时间上限 5分钟
公开文档页面 真实浏览器 查看器元素存在,无错误文本 15分钟
认证文档页面 浏览器事务 登录成功,文档渲染 30分钟
文档主机证书 SSL 有效链,30天到期预警 每天

把这些间隔作为起点,根据财报周、报名期和招标截止日等文档重要期收紧。

从多个地点执行浏览器检查。通过CDN分发的文档在弗吉尼亚节点访问正常,在法兰克福边缘节点可能丢失,单地点检查永远发现不了。运行合成监控的全球网络,助您发现某地区读者无法打开其他地区可访问的文件。

总结

嵌入式PDF查看器是站内的小应用,自带脚本依赖、文档请求、认证和各种失败模式。单靠页面的HTTP响应检查完全覆盖不了。

五条建议解决此问题。用廉价HTTP检测关注文档URL。用真实浏览器加载页面并断言查看器产物。针对已知错误字符串加负断言。覆盖认证路径和第三方脚本。告警发给发布文档者。

照此操作,下次存储策略变更导致网站所有嵌入合同空白时,您分钟内即获通知,不必等到三周后客户投诉。

看看您的读者究竟看到什么

Dotcom-Monitor从全球网络运行真实浏览器检查,帮您在嵌入文档停止渲染时第一时间获知,而非等客户反馈。录制登录,断言查看器产物,告警发给发布团队。

立即开启Dotcom-Monitor免费试用,今天就开始监控您的第一个嵌入文档。

常见问题解答

标准的正常运行时间监控能检测嵌入的损坏PDF吗?
不。标准的 HTTP 正常运行时间检查只读取页面响应并停止在那里。查看器脚本、文档获取和渲染都是在浏览器中随后发生的。您需要一个真正的浏览器检查来运行 JavaScript 并检查最终显示在屏幕上的内容。
监控 PDF 文件和监控查看器有什么区别?
监控文件确认文档可访问且确实是 PDF。监控查看器确认读者可以查看它。两者都可能独立失败:如果客户端 ID 与域不匹配,即使文件完好也不会显示;如果文件不存在,正常工作的查看器也不会显示任何内容。请同时运行两者。
Adobe 的状态页面涵盖此内容吗?
Adobe 在其状态页面上发布了 PDF Embed API 的可用性,值得订阅。但它只涵盖 Adobe 方面的情况。它并未涉及您的文档 URL、您的 CORS 头、您的客户端 ID 配置或您的身份验证,这些通常是故障的起点。
如何监控登录后才能访问的文档?
将完整路径编写为一个事务:登录,导航到文档页面,等待查看器渲染,断言结果。将凭据保存在安全保险库中,而不是脚本中,如果门户无法从公共互联网访问,则从私有代理运行检查。
这些检查应该多久运行一次?
每5分钟对文件和查看器脚本进行HTTP检查,每15到30分钟进行真实浏览器检查。在关键发布窗口期间(如财报发布或开放注册),缩短检查间隔。
Matthew Schmitz
About the Author
Matthew Schmitz
Dotcom-Monitor 负载与性能测试总监

作为 Dotcom-Monitor 的负载与性能测试总监,Matt 目前领导着一支由优秀工程师和开发人员组成的团队,共同为最严苛的企业需求打造先进的负载与性能测试解决方案。

Latest Web Performance Articles​

如何监控电话号码

防止电话线路无声中断。了解运营团队如何使用SIP检查和内部拨号测试来保持客户线路的顺畅运行。

立即免费启动Dotcom-Monitor

无需信用卡