通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

AIS 服务登陆区域加速器的操作管理注意事项

  • 项目

本文提供有关使用 AIS 产品/服务时的操作管理和监视的注意事项和建议。

本节中的大多数建议适用于标准 (单租户) 版本的逻辑应用，该版本本身是Azure 应用服务产品/服务的一部分，并共享许多相同的管理功能。

构成 AIS 的许多资源可以配置为将日志、遥测和指标数据存储在 Log Analytics/Application Insights 中，或存储在自定义存储位置， (这些资源包括存储帐户、事件中心和其他) 。

我们可以利用此信息来可视化资源的总体运行状况，并采取适当的管理操作。

定义

  • Azure Monitor 日志 从受监视的资源收集和组织日志和性能数据。 然后，Log Analytics 等工具可以查询或可视化此日志信息，或者允许你在满足某些条件时发出警报。

  • Azure 指标日志 将数字数据从受监视的资源收集到时序数据库中。 然后，Application Insights 等工具可将此数据可视化，帮助你识别性能和运行时问题。

  • Log Analytics 是一种 Azure 监视产品/服务，提供存储日志和性能数据的位置，并提供用于查询这些日志的机制和语言 (Kusto) ;和 提供基于这些日志创建警报和仪表板的功能， () 的其他功能。

  • Application Insights 是一种 Azure 监视产品/服务，能够可视化受监视资源发出的性能数据并发出警报。

  • Kusto 查询语言 (KQL) 是一种功能强大的查询语言，针对查询和设置数据格式进行优化。 例如，它是 Log Analytics 的主要查询语言。

设计注意事项

  • 将监视解决方案视为一个整体：

    • 需要监视哪些资源？

    • 如何跟踪在资源之间流动的消息？

    • 你将连接到哪些外部系统？

    • 需要哪些类型的警报？

  • 考虑需要运行哪些查询。 例如，是否需要知道给定请求花费的时间是否比预期长？ 或者，如果收到单个错误与错误群集？

  • 需要什么级别的跟踪？ 例如，如果消息来自第三方，是否需要通过所有相关资源跟踪该消息？

  • 需要执行哪些管理任务？ 是否需要重新提交消息或文件？

  • 默认情况下，逻辑应用运行历史记录存储在 Azure 存储中，但你也可以选择将指标和日志文件导出到其他源 (，例如 Log Analytics 或外部存储帐户) 。 请考虑如何使用日志记录信息，以及是否使用集中式日志存储。

  • Application Insights 用于提供应用程序性能监视。 它通过从构成解决方案的资源收集指标来执行此操作。

  • Log Analytics 用于查询日志和设置警报，使你能够查看资源的运行状况并了解可能发生的问题。 日志数据可以包含自定义属性 (请参阅下面的) 跟踪 属性 。

  • 有关特定于应用服务的更多注意事项和建议，请参阅App 服务登陆区域加速器管理一文

设计建议

  • 设置 Application Insights ，使其使用 Log Analytics 工作区，因为它是数据源 (称为 基于工作区的资源) 。 这样做可将日志记录和性能数据保存在合并位置。

  • 为所有资源设置警报，以将与单个资源或工作负荷相关的事件通知相应的团队。

  • 将解决方案中的资源链接到 Application Insights（如果支持）。 例如，逻辑应用可以链接到 Application Insights，以便运行时数据和指标可供查询。 有关 示例，请参阅此处。

  • 使用逻辑应用的 clientTrackingId 功能提供自定义跟踪 ID，使你能够跨逻辑应用运行关联事件。 可以使用 x-ms-client-tracking-id 标头通过请求、HTTP 或 HTTP+WebHook 触发器实现此结果。

  • 使用逻辑应用的 跟踪属性 功能将其他数据 (输入或输出) 从操作记录到日志文件中。 然后，当使用 KQL 和 Log Analytics 或其他解决方案查询日志时，可以使用这些属性。

  • 请考虑使用资源标记。 资源标记可帮助管理和组织 Azure 上的资源。 可以使用它们将元数据分配给资源。 可以将此元数据用于各种目的，例如按应用程序或业务部门对资源进行分类、跟踪资源成本，以及确定符合性的资源。

示例 Kusto 查询

以下查询演示如何查询用于 AIS 日志数据的三个main表。 可以从逻辑应用的“监视”部分中的“日志”选项访问其中每个表。

main查询表包括：

  • 异常
    此表包含资源记录的任何异常，例如逻辑应用运行时引发的异常。 它可用于查找在门户中或在代码执行过程中看到的任何问题的根本原因。

  • requests
    此表将逻辑应用运行时对另一资源发出的所有请求记录到工作流中的特定操作。

  • traces
    此表包含大部分逻辑应用运行时日志、有关触发器执行的日志记录详细信息、工作流启动和停止以及操作执行。 如果已从操作中记录任何跟踪属性，则会在 customDimensions 部分找到此数据。 然后，可以在查询中使用 extend 子句将数据添加为查询响应中的列。

包含错误的工作流：

> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions.LogLevel == "Error"

过去 24 小时内跨所有工作流执行的工作流数：

> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions\["EventName"\] == "WorkflowActionStart"
>
> \| where timestamp \> ago(1d)
>
> \| count

触发成功率，随时间推移绘制

> traces  
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"  
> \| where customDimensions\["EventName"\] == "WorkflowTriggerEnd"  
> \|summarize
>
> success = countif(customDimensions\["prop\_\_status"\] ==
> "Succeeded"),
>
> failures = countif(customDimensions\["prop\_\_status"\] == "Failed")
>
> by bin(timestamp, 1m)  
> \| render timechart

后续步骤

查看关键设计领域，为体系结构制定完整的注意事项和建议。

治理

建议的内容