寻找有关衡量使用CDN的高可用性应用程序的建议

我在一家财富500强公司中工作，该公司在为高可用性应用程序（即，具有5秒的页面到页面导航速度而提高了99.5％的应用程序）的性能和可用性进行准确测量的过程中苦苦挣扎。我们将计划内和计划外的停机时间都考虑在内，以确定此可用性数字。但是，我们最近将CDN添加到了组合中，这使我们的指标有些复杂。现在，CDN可以处理大约75％的流量，而其余的则发送到我们自己的服务器。

我们试图衡量我们所谓的“真实用户体验”（即，我们的测试脚本模拟了典型的用户点击应用程序的情况。）这些监视脚本位于我们网络的外部，这意味着CDN达到了75％时间。

管理层已决定我们采用最坏的情况来衡量可用性。因此，如果我们的原始服务器出现问题，但是CDN可以很好地提供内容，那么我们仍然会影响可用性。反之亦然。我的想法是，只要“用户体验”成功，我们就不应不必要地惩罚自己。毕竟，CDN可以改善性能和可用性！

我只是想知道是否有人对其他《财富》 500强公司如何计算其可用性数字有任何了解？例如，我看一下apple.com的店面，该店面使用的CDN似乎从未崩溃（除非即将发布重要产品。）拥有一些真实的事实数据将非常棒，因为我不知道不必相信我们需要在这些指标上不必要地伤害自己。我们正在根据这些数字制定业务决策。

但是，我可以说，鉴于这些指标对管理人员来说是可见的，因此问题可以很快得到解决和解决（请阅读：我们很快就消除了繁文ta节。）不幸的是，作为开发人员，我不希望管理层认为由于某些外部因素（例如CDN）影响数字，因此应用程序启动或关闭。

有什么想法吗？

（我将这个问题错误地发布到了StackOverflow上，对于交叉发布，我事先表示抱歉）

在摘要中，我要指出的是，您应该明确定义什么构成“可用”与“不可用”，并根据它进行衡量。例如，您可能需要一个客户端性能SLA，该位置的“折叠”位置为1秒，完整呈现页面的位置为3秒。如果您没有达到性能SLA，则应将其视为该时间段内的可用性失败。无论您是否点击CDN，都没有关系-用户体验至关重要。

但是，由于您仅每5分钟进行一次测量，因此合理地衡量CDN与主站点的匹配量似乎合理，并计算出CDN的可用性的75％来自主站点，而可用性的25％来自主站点。这里的困难是75％只是一个平均值。为了在给定的时间段内准确分配责任，您需要知道一个站点或另一个站点何时实际上不面向客户，例如，在计划的更改期间或在发现问题后进行手动操作之后。您还需要考虑到主站点或CDN之一关闭时会发生什么。客户获得HTTP 500，还是只是透明地故障转移到工作站点？很大程度上取决于您的负载平衡解决方案。您描述的“最坏情况”指标似乎过于简单。问你自己， ”

关于CDN崩溃时是否应该承担“责备”：绝对。如果您有75％的匹配是CDN，则75％的客户体验取决于它们。您有责任为客户提供良好的体验，因此，如果CDN遇到问题，则需要使用工程资源进行证明并与提供商联系。

另一件事要考虑的是，如果主站点长时间不可用，会发生什么情况。正如您所描述的，听起来CDN是主站点上内容的静态副本。如果主站点长时间关闭，则CDN可能会开始陈旧。因此，也许您的SLA的一部分应该是新鲜的：“折页”仅需1秒，而完全渲染的页面则需3秒，内容不超过15分钟。

我同意user44700，最好将您的服务器与CDN的可用性测试分开，并分别跟踪两者。真正的可用性将是Server Avail * CDN Avail，因为如果其中任何一个发生故障-您都认为您的页面/站点已关闭。这也将使您减少与任何监控供应商的合作的花费。

我不会尝试创建一个浏览器测试并查看哪些项目失败了，尽管它可以正常工作，而且像Catchpoint这样的一些公司都具有“内容可用性”的概念-在这种情况下，这可能并不是您想要的。举例来说，假设您的网页已调用CDN来发送传递404的文件，大多数监控解决方案都会告诉您这是失败的-但是CDN真的失败了吗？该文件甚至重要吗？也许有人只是忘记删除一些用户没有注意到的文物参考。

您可以阅读此博客文章以获取更多想法：http : //blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/

SLA报告应准确反映实际情况。如果从用户角度衡量可用性，而只有进行衡量的服务器出现问题，则在SLA中报告该问题将无法反映用户体验。

我能理解想要保持高标准的源信息，即使不准确，也可能总是报告它，但要注明原因。

如果您无法达成协议，也许有一种技术解决方案可降低测量服务器的可靠性。

如果该信息被报告为中断，而没有，则该报告提供了什么价值？

在我的环境中，我们从多个来源进行报告。外部监视方法可从外部角度报告可用性，并报告我们的内部停机记录系统，该系统是人为输入的，并考虑了最能准确反映情况的多种因素。

Gomez和Keynote是企业接受的解决方案，用于收集您提到的指标类型。Gomez还提供一项服务，可通过搜索google-analytics风格的javascript文件来监视您的最终用户UX。

Pingdom很好：http：//www.pingdom.com/

我们是一家拥有CDN启用站点的《财富》 500强企业，我们使用了许多方法。您已正确确定如果要检测不同的事物，则需要测量不同的事物。我不清楚您具体想要什么-可用性数字可帮助您确定应用程序何时真正关闭，或使您无法管理的数字。无论如何...

1. 外部综合监控-Keynote / Gomez / Webmetrics。我们曾经使用Keynote，现在我们使用Gomez。当然，正如您所注意到的，它还包括CDN以及任何其他外部组件-这对衡量您的整体SLA很有帮助，但对确定应用程序的SLA却不太好。

要获取“ CDN”，您可以使用另一个Keynote / Gomez监视器，而不是使用备用DNS名称或其他名称通过CDN将其指向您的应用程序。但是，由于它仍然具有静态资产，因此对于性能比可用性更有用。它将互联网中断，代理中断等保持在循环中，这仅适用于某些目的，而不适用于其他目的。

2. 真实的用户监控。有基于网络的（Coradiant，Tealeaf）和基于标签的（Jiffy，Gomez）。我们将Coradiant用作网络嗅探器，它确定了托管在我们数据中心的资产的实际用户可见性能-换句话说，是实际应用程序，而不是CDN上的所有静态垃圾。然后，我们编写报告以确定应用程序的错误率和性能，并使用Apdex（apdex.org）作为派生指标。在某些情况下，您不能使用基于网络的协议（流量过多，或者您的资产没有托管在您可以通过网络访问的位置），而基于标签的可靠性就不那么可靠。拥有真正看到最终用户响应时间和错误的巨大优势-设置易于在实际用户遇到的所有情况下都不会出错的综合监视器很容易。

3. 本地综合监控。Nagios / zabbix / sitescope /其他一百个。将监视器指向本地的应用程序（不要通过CDN）。对于可操作的（例如，发送页面以唤醒某人）可用性监视，这是黄金标准。不考虑网络内容。

4. 日志监控。从某种意义上讲，这是贫民区真正的用户监视。但是，如果您真的只是想看看什么时候出错，那就非常方便了。真正的用户监控具有“没有发生的一切”的好处。通常只有可用性，除非您在Web层上记录了花费的时间，在这种情况下，它显示了服务器端花费了多长时间-对面向SLA的用户无济于事，但对于“我们需要处理什么代码非常有用” 。” 使用splunk。

它不是一个，也不是，我们都使用了所有这些，因为您确实想要“最终用户故事”以及“我们需要依靠什么程序员”。

BrowserMob很棒