Windows Azure 网站自愈

编辑人员注释：本文章由
Windows Azure 网站团队的项目经理Apurva Joshi
撰写。

您有多少次在半夜被叫醒去解决一个仅需重新启动网站即可解决的问题？要是可以自动检测一些状况并自动恢复该有多好！

随着 Windows Azure
网站 (WAWS)
最新更新的推出，我们已尝试解决这些问题。我们在
“始终可用”功能之上新增了一些增强功能。通过这些增强功能，系统可以自动回收托管您的
Web 应用程序的 worker
进程。我们称之为“自愈”功能。下面说明了该功能的工作原理：

您仅需在网站的根 web.config
文件中定义触发器，并配置这些触发器被触发时要执行的操作即可。大致上配置部分的结构如下：

注意：
此功能与“始终可用”功能一样，仅适用于标准实例。

我们来分解下每个场景的可用选项。

（本文末尾提供了所有支持元素和属性的详细说明。）

场景 1 –“基于请求计数回收”

设想以下场景：您的应用程序已处理 X
个请求，您需要在 Y
时间内自动回收该应用程序。您知道短时间内涌入大量请求会导致您的应用程序伸缩性下降。您希望能够检测到此情况，并且自动回收 worker
进程和记录事件日志。

您仅需编辑应用程序的根 web.config
文件，以下提供了配置示例。（如果已存在 web.config
文件，请将<monitoring>部分复制到现有
<system.webServer> 部分下）

有了以上配置,
若10分钟内处理了1000个请求,
worker 进程将被回收。它还会在 eventlog.xml
文件（可从您的 Web
根目录的 Logfiles
文件夹中获取）中记录事件日志。记录事件日志可以帮助您查找自愈网站的发生次数，并且为故障排除或根源分析提供重要取证。收到第一个请求时，我们会启动 timeInterval
定时器，然后启动发生次数计数。如果在 timeInterval
过期之前该计数超过最大值，我们将采取措施。如果
timeInterval 过期，我们将重置该定时器和计数。在以上配置下，这样做可能会出现以下情况：

00:00:00 –
第一个请求到达

00:09:59 – 998
个请求得到处理

00:10:00 –
定时器过期，重置为 0

00:10:01 – 999
个请求得到处理

在此场景下，第一个或第二个 timeInterval
窗口中并未发生 1000
个请求，因此未采取任何措施。

注意：如果您的网站有多个实例，仅会重新启动触发此触发器的实例，而不是全部实例。

eventlog.xml
文件中记录的事件示例

场景 2 –“基于缓慢请求回收”

设想以下场景：您的应用程序的性能开始下降，并且几个页面的显示速度开始减缓。您希望可以检测此情况，并且自动回收 worker
进程。

您仅需编辑应用程序的根 web.config
文件，以下提供了配置示例。（如果已存在 web.config
文件，请将<monitoring>部分复制到现有
<system.webServer> 部分下）

当检测到最后2分钟内20
个请求的执行时间超过
45 秒时，以上配置将回收该
worker 进程。必须注意的一点是，slowRequest
的触发器在每个请求执行结束时进行评估，因此将 timeInterval
设置为大于 timeTaken
的值也同等重要。

注意：如果您的网站有多个实例，仅会重新启动触发此触发器的实例，而不是全部实例。

eventlog.xml
文件中记录的事件示例

场景 3 –“基于
HTTP 状态代码记录事件（或回收）”

设想以下场景：当您的网站开始抛出特定的 HTTP
状态代码、子状态代码或 win32
状态代码时，您希望收到有关此情况的通知。您可以选择回收或仅需在 eventlog.xml
文件（可从您网站内容根目录的 Logfiles
文件夹中获取）中记录事件

您仅需编辑应用程序的根 web.config
文件，以下提供了配置示例。

当30秒内检测到
10 个请求导致出现
HTTP 状态代码 500
和子状态代码 100
时，以上配置将在
eventlog.xml 文件中记录该事件。

注意：如果您的网站有多个实例，仅会记录触发此触发器的实例的事件，而不是全部实例。或者，也可以选择回收，而不仅仅是记录事件。默认情况下，回收会记录事件。

eventlog.xml
文件中记录的事件示例

场景 4 –“基于内存限制采取自定义操作（或回收/日志记录）”

设想以下场景：您正在对您网站中的内存泄露进行故障排除并且要执行以下自定义操作：生成内存转储、发送电子邮件通知，或生成内存转储并回收进程等。

您仅需编辑应用程序的根 web.config
文件，以下提供了配置示例。

当检测到 worker
进程已达到
800 MB
专用字节时，以上配置会执行自定义操作以运行 procdump.exe，并且生成迷你内存转储。自愈功能不会触发某些来自
http.sys（内核驱动程序，不会因为请求而成为 worker
进程管道）的 HTTP
错误代码。此类状态代码的示例包括 304、302、400（很多但并非全部）、503，等等。

注意：如果您的网站有多个实例，仅会为触发此触发器的实例生成内存转储，而不是全部实例。或者，也可以

选择执行发送电子邮件等自定义操作。此外还要注意，默认情况下，procdump.exe
在您网站的根目录 (d:\home)
下是不存在的–
您的网站进行 xcopy
部署时需要将它复制过去。

用于回收操作类型的 eventlog.xml
文件中记录的事件示例

最后，如果您想要配置特定页面/URL
上的触发器，可以使用我们的 FREB
模块。配置步骤如下面博客中所述：

http://thenextdoorgeek.com/post/Windows-Azure-Web-Sites-(WAWS)-Collecting-dumps-of-the-worker-process-(w3wpexe)-automatically-whenever-a-request-takes-a-long-time

此方法会带来 5-10%
的性能损失，并且需要启用 FREB。

注意：以上方法同样仅在标准模式下有效，因为在共享和免费模式下
1 小时后我们会自动禁用 FREB。

以下是支持的配置及其含义的列表。

本文翻译自：

http://blogs.msdn.com/b/windowsazure/archive/2014/02/06/auto-healing-windows-azure-web-sites.aspx