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

本文介绍如何使用 Azure 门户中的运行状况检查来监视应用服务实例。 运行状况检查通过重新路由来自不正常实例的请求，并替换仍然不正常的实例来提高应用程序的可用性。 此操作通过你选择的路径每分钟 ping 一次 Web 应用程序。

请注意，/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;
}

实例

启用运行状况检查后，可以从实例选项卡重启应用程序实例并监视其状态。实例选项卡会显示实例的名称以及该应用程序的实例状态。 也可以从此选项卡手动重启实例。

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

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

对于 Windows 应用程序，还可以通过进程资源管理器查看进程。 这样就可以进一步了解实例的进程，包括线程计数、专用内存和 CPU 总时间。

诊断信息收集

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

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

监视

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

限制

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

常见问题解答

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

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

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

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

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

在适用于 Windows 和 Linux 的应用服务上，当站点启用仅 HTTPS 时，运行状况检查请求将通过 HTTPS 发送。 否则，将通过 HTTP 发送。

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

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

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

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

示例

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

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

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

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

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

后续步骤

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