使用运行状况检查监视应用服务实例

本文使用 Azure 门户中的运行状况检查来监视应用服务实例。 运行状况检查通过重新路由来自不正常实例的请求，并替换仍然不正常的实例来提高应用程序的可用性。 它完成此任务的方式是每隔一分钟对所选的 Web 应用程序的路径执行 ping 操作。

请注意，/api/health 只是为了说明而添加的示例。 默认情况下，我们不会创建运行状况检查路径。 应确保选择的路径是应用程序中存在的有效路径

应用服务利用运行状况检查进行哪些方面的监视

• 在应用上给出路径时，运行状况检查将以 1 分钟为间隔在应用服务应用的所有实例上对此路径执行 ping 操作。
• 如果给定实例上运行的 web 应用在 10 次请求后，未响应 200-299（含）之间的状态代码，则应用服务会将其判定为运行不正常，并将其从此 Web 应用的负载均衡器中删除。 被视为运行不正常的实例所需的失败请求数最少可配置为 2 个请求。
• 删除后，运行状况检查将继续对运行不正常的实例执行 ping 操作。 如果实例开始以正常状态代码 (200-299) 进行响应，则实例将返回到负载均衡器。
• 如果实例上运行的 Web 应用在一小时内始终不正常，则该实例将被替换为新的实例。
• 横向扩展时，应用服务将对运行状况检查路径执行 ping 操作，以确保新实例准备就绪。

启用运行状况检查

1. 若要启用运行状况检查，请浏览到 Azure 门户并选择应用服务应用。
2. 在“监视”下，选择“运行状况检查”。
3. 选择“启用”，然后在应用程序上提供有效的 URL 路径，例如 /health 或 /api/health。
4. 选择“保存”。

配置

除了配置运行状况检查选项以外，还可以配置以下应用设置：

身份验证和安全性

运行状况检查与应用服务的身份验证和授权功能相集成。 如果启用了这些安全功能，则不需要其他设置。

如果使用自己的身份验证系统，则必须允许匿名访问运行状况检查路径。 若要保护运行状况检查终结点，应先使用 IP 限制、客户端证书或虚拟网络等功能来限制对应用程序的访问。 在设置好这些功能后，即可检查标头 x-ms-auth-internal-token 并验证它是否与环境变量 WEBSITE_AUTH_ENCRYPTION_KEY 的 SHA256 哈希匹配，从而对运行状况检查请求进行身份验证。 如果匹配，则说明运行状况检查请求是有效的，并且是源自应用服务。

using System;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public Boolean HeaderMatchesEnvVar(string headerValue) {
    var sha = System.Security.Cryptography.SHA256.Create();
    String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return hash == headerValue;
}

from hashlib import sha256
import base64
import os

def header_matches_env_var(header_value):
    """
    Returns true if SHA256 of header_value matches WEBSITE_AUTH_ENCRYPTION_KEY.
    
    :param header_value: Value of the x-ms-auth-internal-token header.
    """
    
    env_var = os.getenv('WEBSITE_AUTH_ENCRYPTION_KEY')
    hash = base64.b64encode(sha256(env_var.encode('utf-8')).digest()).decode('utf-8')
    return hash == header_value

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
import java.nio.charset.StandardCharsets;

public static Boolean headerMatchesEnvVar(String headerValue) throws NoSuchAlgorithmException {
    MessageDigest digest = MessageDigest.getInstance("SHA-256");
    String envVar = System.getenv("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = new String(Base64.getDecoder().decode(digest.digest(envVar.getBytes(StandardCharsets.UTF_8))));
    return hash.equals(headerValue);
}

var crypto = require('crypto');

function envVarMatchesHeader(headerValue) {
    let envVar = process.env.WEBSITE_AUTH_ENCRYPTION_KEY;
    let hash = crypto.createHash('sha256').update(envVar).digest('base64');
    return hash == headerValue;
}

实例数

启用运行状况检查后，可以通过“实例”选项卡重启并监视应用程序实例的状态。“实例”选项卡将显示实例的名称、该应用程序的实例的状态，并提供手动重启实例的选项。

如果你的应用程序实例的状态不正常，则可以使用表中的重启按钮手动重启实例。 请记住，在实例所在的同一应用服务计划上托管的任何其他应用程序也将受到重启的影响。 如果有其他应用程序使用与实例相同的应用服务计划，它们将在重启按钮打开的边栏选项卡中列出。

如果重启了实例且重启过程失败，则系统会提供替换工作进程的选项（每小时只能替换 1 个实例）。 这也会影响使用同一应用服务计划的任何应用程序。

Windows 应用程序还可以选择通过 Process Explorer 查看进程。 这样就可以进一步了解实例的进程，包括线程计数、专用内存和 CPU 总时间。

诊断信息收集

对于 Windows 应用程序，可以选择在“运行状况检查”选项卡中收集诊断信息。启用诊断收集将添加一个自动修复规则，该规则为运行不正常的实例创建内存转储，并将其保存到指定的存储帐户。 启用此选项将更改自动修复配置。 如果存在现有的自动修复规则，我们建议通过 App 服务诊断进行设置。

启用诊断收集后，可以为文件创建或选择现有的存储帐户。 只能选择与应用程序位于同一区域中的存储帐户。 请记住，保存操作将重启应用程序。 保存后，如果连续 ping 后发现站点实例运行不正常，则可以转到存储帐户资源并查看内存转储。

监视

提供应用程序的运行状况检查路径后，可以使用 Azure Monitor 监视站点的运行状况。 在门户的“运行状况检查”边栏选项卡中，选择顶部工具栏中的“指标”。 此操作将打开新的边栏选项卡，可以在其中查看站点的历史运行状况以及新建预警规则的选项。 仅当根据运行状况检查配置将实例视为运行不正常时，运行状况检查指标才会聚合成功的 ping 并显示失败。 有关监视站点的更多信息，请参阅 Azure Monitor 指南。

限制

• 可以为免费和共享应用服务计划启用运行状况检查，以便度量站点运行状况并设置警报，但由于免费和共享站点无法横向扩展，因此不会替换任何不正常的实例。 应纵向扩展到基本层或更高层，以便横向扩展到 2 个或更多实例，并充分利用运行状况检查的优势。 对于面向生产的应用程序，建议这样做，因为这样可提高应用的可用性和性能。
• 应用服务计划每小时最多可替换一个不正常的实例，每天最多替换三个实例。
• 每个缩放单元的运行状况检查替换的实例总数存在不可配置的限制。 如果达到此限制，则不会替换运行不正常的实例。 此值每 12 小时重置一次。

常见问题

如果我的应用在单个实例上运行，会发生什么情况？

如果应用仅扩展到一个实例并且变得不正常，则它将不会从负载均衡器中删除，因为这样会使应用程序完全崩溃。 但是，在连续运行不正常的 ping 一小时后，将替换该实例。 横向扩展到两个或更多实例，以获得运行状况检查的重新路由优势。 如果应用在单个实例上运行，仍可使用运行状况检查的监视功能来跟踪应用程序的运行状况。

为什么 Web 服务器日志中未显示运行状况检查请求？

运行状况检查请求在内部发送到站点，因此请求不会显示在 Web 服务器日志中。 可以在运行状况检查代码中添加日志语句，以保存运行状况检查路径 ping 时的日志。

运行状况检查请求是通过 HTTP 还是 HTTPS 发送？

在 Windows 应用服务上，当站点上已启用仅 HTTPS 时，运行状况检查请求将通过 HTTPS 发送。 否则，将通过 HTTP 发送。 在 Linux 应用服务上，运行状况检查请求仅通过 HTTP 发送，目前无法通过 HTTPS 发送。

应用程序代码后的运行状况检查是否配置了在默认域和自定义域之间重定向？

否，运行状况检查功能正在 ping Web 应用程序的默认域的路径。 如果有从默认域到自定义域的重定向，则运行状况检查返回的状态代码不会为 200，而是重定向 (301)，这会将工作进程标记为不正常。

如果同一应用服务计划上有多个应用，该怎么做？

无论应用服务计划上的其他应用如何，始终会从负载均衡器轮换中删除不正常实例（最大删除百分比为 WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT 中指定的百分比）。 如果一个实例上的某个应用处于不正常状态超过一小时，仅当所有其他已启用运行状况检查的应用也不正常时，该实例才会被替换。 未启用运行状况检查的应用将不会被考虑在内。

示例

假设你有两个启用了运行状况检查的应用程序（或一个带有槽的应用），分别称为“应用 A”和“应用 B”。它们位于同一应用服务计划中，并且该计划已横向扩展到 4 个实例。 如果应用 A 在两个实例上变得运行不正常，负载均衡器将停止向这两个实例上的应用 A 发送请求。 如果应用 B 正常，请求仍将路由到这些实例上的应用 B。 如果应用 A 在这两个实例上处于运行不正常状态超过一小时，仅当应用 B 在这些实例上也运行不正常时，这些实例才会被替换。 如果应用 B 正常，该实例将不会被替换。

如果所有实例都不正常，该怎么办？

如果应用程序的所有实例运行都不正常，应用服务将不会从负载均衡器中删除实例。 在这种情况下，从负载均衡器轮换中删除所有运行不正常的应用实例实际上会导致应用程序出现故障。但是，仍会遵循实例替换。

健康状况检查在应用服务环境中是否正常工作？

是的，运行状况检查适用于应用服务环境 v3，但不适用于版本 1 或 2。 如果你使用的是应用服务环境的较旧版本，可以使用迁移功能将应用服务环境迁移到版本 3。

后续步骤

• 创建活动日志警报以监视订阅上的所有自动缩放引擎操作
• 创建活动日志警报以监视订阅上所有失败的自动缩放缩小/扩大操作
• 环境变量和应用设置参考