import java.io.Console;
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 == headerValue;
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 服务器日志中。 这也意味着请求的来源将为 127.0.0.1，因为该请求在内部发送。 可以在运行状况检查代码中添加日志语句，以保存运行状况检查路径 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 正常，该实例将不会被替换。
如果计划（站点 C）中存在未启用运行状况检查的其他站点或槽，则不会考虑对其进行实例替换。
如果所有实例都不正常，该怎么办？
如果应用程序的所有实例都不正常，应用服务会从负载均衡器中删除实例，最大删除百分比为 WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT 中指定的百分比。 在这种情况下，从负载均衡器轮换中删除所有不正常的应用实例实际上会导致应用程序出现故障。
健康状况检查在应用服务环境中是否正常工作？
是的，运行状况检查适用于应用服务环境 v3，但不适用于版本 1 或 2。 如果你使用的是应用服务环境的较旧版本，可以使用迁移功能将应用服务环境迁移到版本 3。
创建活动日志警报以监视订阅上的所有自动缩放引擎操作
创建活动日志警报以监视订阅上所有失败的自动缩放缩小/扩大操作
环境变量和应用设置参考
