服务器无事件信息,监视无服务器事件处理 - Azure Architecture Center | Microsoft Docs

最新推荐文章于 2023-12-21 19:27:28 发布

weixin_39573535

最新推荐文章于 2023-12-21 19:27:28 发布

阅读量309

点赞数

文章标签：服务器无事件信息

您现在访问的是微软AZURE全球版技术文档网站，若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站，请访问 https://docs.azure.cn.

监视无服务器事件处理

06/25/2021

本文内容

本文提供有关监视无服务器事件驱动体系结构的指导。

监视提供对系统行为和运行状况的见解。它可帮助你构建环境的整体视图，检索历史趋势，关联各种因素，并度量性能、消耗或错误率的变化。当发生可能会影响服务质量的条件或特定环境特别感兴趣的条件时，可以使用监视来定义警报。

本文演示如何使用Azure Monitor 监视使用事件中心构建的无服务器应用程序，Azure Functions。其中讨论了要监视的有用指标，介绍了如何与应用程序集成Insights捕获自定义指标，并提供代码示例。

假设

本文假设你有一个体系结构，如无服务器事件处理参考体系结构中所述的体系结构。基本上：

事件到达Azure 事件中心。

触发函数应用以处理事件。

Azure Monitor可用于体系结构。

来自 Azure Monitor

首先，我们需要确定需要哪些指标，然后才能开始构建有关体系结构的有用见解。每个资源执行不同的任务，并生成不同的指标。

事件中心的这些指标对于捕获有用的见解非常有用：

传入请求

传出请求

受限制的请求数

成功的请求

传入消息

传出消息

捕获的消息

传入字节数

传出字节数

捕获的字节数

用户错误

同样，这些来自 Azure Functions指标对于捕获有用的见解也很有用：

函数执行计数

连接

数据位于

数据出

HTTP 服务器错误

请求

应用程序队列中的请求

响应时间

使用诊断日志记录捕获见解

一起分析时，可以使用上述指标来制定和捕获以下见解：

事件中心处理的请求速率

由用户处理的请求Azure Functions

事件中心吞吐量总计

用户错误

持续时间Azure Functions

端到端延迟

每个阶段的延迟

丢失的消息数

多次处理的消息数

为了确保事件中心捕获所需的指标，我们必须先启用诊断日志 (默认情况下禁用) 。然后，我们必须选择所需的日志，并配置正确的 Log Analytics 工作区作为它们的目标。

我们感兴趣的日志和指标类别包括：

OperationalLogs

AutoScaleLogs

KafkaCoordinatorLogs (Apache Kafka工作负荷)

KafkaUserErrorLogs (Apache Kafka工作负荷)

EventHubVNetConnectionEvent

AllMetrics

Azure 文档提供有关如何为 Azure 事件中心设置诊断日志的说明。以下屏幕截图显示了一个示例诊断设置配置面板，该面板选择了正确的日志和指标类别，并设置了 Log Analytics 工作区作为目标。 (如果使用外部系统来分析日志，可以改为使用"流式传输到事件中心"选项。)

备注

若要利用日志诊断来捕获见解，应在不同的命名空间创建事件中心。这是因为 Azure 中存在约束。

给定事件中心命名空间中设置的事件中心以Azure Monitor维度下的指标表示 EntityName 。在Azure 门户中，通常可以在事件中心的实例上查看特定事件Azure Monitor。但是，当指标数据路由到日志诊断时，当前无法通过筛选维度来查看每个事件中心 EntityName 的数据。

作为一种解决方法，在不同的命名空间创建事件中心有助于查找特定中心的指标。

使用 Application Insights

可以启用应用程序Insights从应用程序捕获指标和自定义Azure Functions。这样，你可定义适合自己用途的分析，从而提供另一种方法来获取无服务器事件处理方案的重要见解。

此屏幕截图显示了应用程序服务中的自定义指标和遥测Insights：

默认自定义指标

在应用程序Insights中，Azure Functions自定义指标存储在 customMetrics 表中。它包括以下值，跨不同函数实例的时间线：

AvgDurationMs

MaxDurationMs

MinDurationMs

Successes

Failures

SuccessRate

Count

这些指标可用于有效地计算运行中调用的多个函数实例的聚合平均值。

此屏幕截图显示了在应用程序服务中查看这些默认自定义指标Insights：

自定义消息

使用 (在 Azure 函数代码中记录的) 消息从 Application ILogger Insights traces 表中获取。

该表 traces 具有以下重要属性 (其他属性) ：

timestamp

cloud_RoleInstance

operation_Id

operation_Name

message

下面是自定义消息在应用程序接口接口中Insights的示例：

如果传入的事件中心消息或作为此自定义消息的一部分记录，则也会在应用程序服务中 EventData[] ILogger Insights。这非常有用。

对于无服务器事件处理方案，我们将记录从事件中心收到的 JSON 序列化消息正文。这样，我们可捕获原始字节数组，以及、 SystemProperties x-opt-sequence-number 和 x-opt-offset x-opt-enqueued-time 等。若要确定事件中心何时收到每条消息， x-opt-enqueued-time 使用属性。

示例查询：

traces

| where timestamp between(min_t .. max_t)

| where message contains "Body"

| extend m = parse_json(message))

| project timestamp = todatetime(m.SystemProperties.["x-opt-enqueued-time"])

示例查询将返回类似于以下示例结果的消息，默认情况下，该消息在 Application Insights。的属性可用于查找和捕获每个、和 Trigger Details 接收的消息 PartitionId Offset 的其他见解 SequenceNumber 。

示例查询的示例结果：

"message": Trigger Details: PartitionId: 26, Offset: 17194119200, EnqueueTimeUtc: 2020-11-03T02:14:01.7740000Z, SequenceNumber: 843572, Count: 10,

警告

使用时，Azure Java Functions 库当前出现阻止访问 PartitionID 和 PartitionContext 的问题 EventHubTrigger 。有关详细信息，请GitHub问题报告。

将事务 ID 与应用程序服务一起跟踪Insights

在应用程序Insights中，可以通过对事务的值执行事务搜索查询来查看与特定事务相关的所有 Operation Id 遥测数据。当事务在事件流管道中移动时，这对于捕获消息的平均时间百分位值特别有用。

以下屏幕截图显示了应用程序服务接口中的一Insights搜索。在查询字段中输入所需的，使用放大镜图标进行标识 (此处以红色框 Operation ID) 。在主窗格底部，选项卡 Results 按顺序显示匹配的事件。在每个事件条目中， Operation ID 该值以深蓝色突出显示，方便验证。

为特定操作 ID 生成的查询将如下所示。请注意 Operation ID ，GUID 是在第三行的子句中 where * has 指定的。此示例进一步缩小了两个不同之间的查询 datetimes 范围。

union isfuzzy=true availabilityResults, requests, exceptions, pageViews, traces, customEvents, dependencies

| where timestamp > datetime("2020-10-09T06:58:40.024Z") and timestamp < datetime("2020-11-11T06:58:40.024Z")

| where * has "1c8c9d7073a00e4bbdcc8f2e6570e46"

| order by timestamp desc

| take 100

下面是查询及其匹配结果在 Application Insights 的屏幕截图：

从数据捕获自定义Azure Functions

.NET 函数

结构化日志记录在 .NET Azure 函数中用于捕获 Application Insights 跟踪表中的自定义维度。然后，这些自定义维度可用于查询数据。

例如，下面是 .NET 中的 log 语句 TransformingFunction ：

log.LogInformation("TransformingFunction: Processed sensorDataJson={sensorDataJson}, " +

"partitionId={partitionId}, offset={offset} at {enqueuedTimeUtc}, " +

"inputEH_enqueuedTime={inputEH_enqueuedTime}, processedTime={processedTime}, " +

"transformingLatencyInMs={transformingLatencyInMs}, processingLatencyInMs={processingLatencyInMs}",

sensorDataJson,

partitionId,

offset,

enqueuedTimeUtc,

inputEH_enqueuedTime,

processedTime,

transformingLatency,

processingLatency);

在 Application Insights上创建的日志包含上述参数作为自定义维度，如以下屏幕截图所示：

可以按如下所示查询这些日志：

traces

| where timestamp between(min_t .. max_t)

// Function name should be of the function consuming from the Event Hub of interest

| where operation_Name == "{Function_Name}"

| where message has "{Function_Name}: Processed"

| project timestamp = todatetime(customDimensions.prop__enqueuedTimeUtc)

备注

为了确保我们不会影响这些测试的性能，我们已使用文件为 Application Insights启用 Azure 函数日志的采样 host.json 设置，如下所示。这意味着从日志记录捕获的所有统计信息都被视为平均值，而不是实际计数。

host.js示例：

"logging": {

"applicationInsights": {

"samplingExcludedTypes": "Request",

"samplingSettings": {

"isEnabled": true

}

Java 函数

目前，Java Azure 函数不支持结构化日志记录来捕获 Application Insights跟踪表中的自定义维度。

例如，下面是 Java 中的 log 语句 TransformingFunction ：

LoggingUtilities.logSuccessInfo(

context.getLogger(),

"TransformingFunction",

"SuccessInfo",

offset,

processedTimeString,

dateformatter.format(enqueuedTime),

transformingLatency

);

在 Application Insights上创建的日志在消息中包含上述参数，如下所示：

可以按如下所示查询这些日志：

traces

| where timestamp between(min_t .. max_t)

// Function name should be of the function consuming from the Event Hub of interest

| where operation_Name in ("{Function name}") and message contains "SuccessInfo"

| project timestamp = todatetime(tostring(parse_json(message).enqueuedTime))

备注

host.js示例：

"logging": {

"applicationInsights": {

"samplingExcludedTypes": "Request",

"samplingSettings": {

"isEnabled": true

}