我为一家财富500强公司工作，该公司正在努力准确衡量高可用性应用程序的性能和可用性（例如，5秒页面到页面导航的应用程序可达99.5％）。 我们考虑计划和计划外宕机时间来确定这个可用性数字。 不过，我们最近又join了CDN，这使我们的指标变得复杂一些。 CDN现在可以处理大约75％的stream量，同时将余下的数据发送到我们自己的服务器。
我们试图测量我们所说的“真正的用户体验”（即，我们的testing脚本模拟一个典型的用户点击应用程序）。这些监控脚本位于我们的networking之外，这意味着我们正在使用CDN的约75％时间。
pipe理层决定，我们采取最坏的情况来衡量可用性。 所以，如果我们的原始服务器有问题，但是CDN服务内容还不错，我们仍然会受到影响。 反过来也是如此。 我的想法是，只要“用户体验”成功，我们就不应该不必要地惩罚自己。 毕竟，CDN有提高性能和可用性！
我只是想知道，如果有人知道其他财富500强公司如何计算他们的可用性数字？ 例如，我看着一个使用CDN的店面（apple.com），这个店面使用的CDN似乎从来没有出现过（除非将要成为一个重要的产品宣告）。拥有一些硬性的，事实的数据是件好事，因为我不喜欢我们不相信我们需要在这些指标上不必要地伤害自己。 我们正在根据这些数字做出商业决定。
但是，我可以说，鉴于pipe理层可以看到这些指标，问题得到解决和快速解决（阅读：我们快速地浏览了繁文</s>节）。不幸的是，作为开发人员，我不希望pipe理层思考由于某些外部因素（即CDN）正在影响这些数字，所以应用程序已经启动或closures。
思考？
（我错误地在StackOverflow上发布了这个问题，对于交叉post提前抱歉）
抽象地说，我应该说你应该清楚地界定“可用”与“不可用”之间的关系，然后衡量自己的反对意见。 例如，您可以在1秒内将“客户端性能SLA”设置为“折叠”，对于完全呈现的页面，客户端性能SLA可以达到3秒。 如果您不符合性能SLA，则应将此作为该时间段内的可用性故障计算。 不pipe你是否打CDN，用户体验都是重要的。
但是，由于您每5分钟只进行一次测量，所以对CDN和主站分别进行点击测量似乎是合理的，并且计算出75％的可用性来自CDN，25％来自主机。 这里的难点是75％只是一个平均值。 要在给定的时间段内准确地分摊责任，您需要知道何时一个或另一个站点实际上不是面向客户的，例如，在计划的更改期间，或者在检测到问题时的手动操作之后。 您还需要考虑主站点或CDN中的一个发生故障时发生的情况。 客户是否得到HTTP 500，或者他们是否透明地故障转移到工作站点？ 很多取决于您的负载平衡解决scheme。 你所描述的“最坏情况”指标看起来太简单了。 问问自己：“我们的客户经历了什么？”
至于在CDN宕机时是否应该“责怪”：绝对是。 如果你的点击中有75％是去CDN，那么你的客户体验的75％是依赖于他们的。 您有责任为您的客户提供良好的体验，因此，如果CDN出现问题，您需要使用您的工程资源来certificate这一点，并跟踪供应商。
还有一件事要考虑的是当主站点长时间不可用时会发生什么情况。 正如你所描述的，这听起来像CDN是主站点上的内容的静态副本。 如果主站点长时间停机，CDN可能会变得过时。 所以也许你的SLA的一部分应该是新鲜的：1秒钟的“折叠”和3秒的完全呈现的页面，内容不超过15分钟。
我同意user44700，最好将你的服务器的可用性testing与CDN分开，并且独立地跟踪两个独立的。 您的真实可用性将为服务器可用性* CDN可用性，因为如果发生任何一种情况 – 您认为您的网页/网站已closures。 对于任何监控供应商来说，这也会降低你的成本。
我不会去创build一个浏览器testing的路线，看看哪些项目失败，而它可以工作，像Catchpoint这样的公司有一个概念“内容可用性” – 这可能不是你想要的这种情况。 比方说，你的网页有一个CDN调用提供404的文件，大多数监控解决scheme会告诉你这是一个失败 – 但是它真的是CDN失败了吗？ 那个文件更重要吗？ 也许有人忘记删除一些没有用户注意的文物参考。
你可以阅读这个博客文章的一些更多的想法： http : //blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/
SLA报告应该准确地反映现实。 如果从用户的angular度来衡量可用性，并且只有进行测量的服务器遇到问题，则在SLA中报告此问题将不会反映用户体验。
我可以理解，要把源信息保持在一个很高的标准，也许总是报告，即使不准确，但有一个说明为什么。
如果你不能达成一致意见，也许有一种技术解决scheme可以使测量服务器的可靠性降低。
如果信息被报告为中断，那么报告提供了什么价值？
在我的环境中，我们从多个来源报告。 外部监测方法，从外部angular度报告可用性，并报告我们的内部停电logging系统，这是人类input的，考虑了多种因素，最准确地反映这种情况。
Gomez和Keynote是企业接受的解决scheme，用于收集您提到的指标types。 Gomez还有一项服务，通过searchgoogle-analytics-esque的JavaScript文件来监控您的最终用户UX。
Pingdom很好： http ：//www.pingdom.com/
我们是拥有CDNfunction的财富500强网站，我们使用了几件事情。 如果你想检测不同的东西，你已经正确地确定你需要测量不同的东西。 我不清楚你特别想要什么 – 可用性数字来帮助你确定一个应用程序实际上什么时候停止，或者是什么数字让你的pipe理得到回应。 无论如何…
为了获得“CDN”，你可以使用另一个Keynote / Gomez监视器，而不是通过CDN使用替代的DNS名称或类似的东西指向你的应用程序。 但是由于它仍然具有静态资产，因此性能比可用性更有用。 而且它使得互联网中断，代理中断等在循环中，这适用于某些目的而不是其他的。
真正的用户监控。 有基于networking（Coradiant，Tealeaf）和标签（Jiffy，Gomez）。 我们使用Coradiant作为networking嗅探器，它决定了在我们的数据中心托pipe的资产的真正用户看到的性能 – 换句话说，实际的应用程序，而不是CDN上的所有静态垃圾。 然后，我们编写了报告来确定应用程序错误率和性能，并使用Apdex（apdex.org）作为派生指标。 在某些情况下，您不能使用基于networking的stream量（stream量太多，或者您的资产没有托pipe在networking上），而基于标签的stream量并不可靠。 实际看到最终用户的响应时间和错误具有巨大的好处 – 在真实用户所做的所有情况下，build立一个不会出现错误的合成监视器很容易。
本地综合监测。 Nagios / zabbix / sitescope /一百个。 在您的应用程序本地指向监视器（不要通过CDN）。 对于可操作的（如发送页面来唤醒某人）可用性监控，这是黄金标准。 不考虑networking的东西。
日志监视。 从某种意义上说，这是贫民窟真正的用户监控。 但是如果你真的只是想看看什么时候出现错误，那就太方便了。 有真正的用户监控的“真的没有这个事情”的好处。 通常只有可用性，除非您在Web层上logging时间，在这种情况下，它会显示您的服务器端花了多长时间 – 对面向用户的SLA没有帮助，但对“我们需要处理什么代码非常有帮助“。 使用splunk。
这不是一个，或者，我们使用所有这些，因为你需要“最终用户的故事”，以及“我们需要依靠什么程序员”。
BrowserMob是伟大的