在 AKS 中监视微服务应用程序

基于 Kubernetes 的体系结构还有其他一些难题：

在 Kubernetes 中，日志记录的标准方法是让容器将日志写入 stdout 和 stderr。 容器引擎将这些流重定向到日志记录驱动程序。 为了便于查询以及在节点停止响应时防止可能的日志数据丢失，通常的方法是从每个节点收集日志并将其发送到中央存储位置。

Azure Monitor 与 AKS 集成以支持此方法。 Monitor 收集容器日志并将其发送到 Log Analytics 工作区。 在此处，可以使用 Kusto 查询语言 跨聚合日志写入查询。 例如，下面是用于显示指定 Pod 的 容器日志的 Kusto 查询 ：

ContainerLogV2
| where PodName == "podName" //update with target pod
| project TimeGenerated, Computer, ContainerId, LogMessage, LogSource
Azure Monitor 是一项托管服务，将 AKS 群集配置为使用 Monitor 是 CLI 或 Azure 资源管理器模板中的简单配置更改。 （有关详细信息，请参阅如何启用 Azure Monitor 容器见解。）使用 Azure Monitor 的另一个优势是，它将 AKS 日志与其他 Azure 平台日志合并，提供统一的监视体验。
Azure Monitor 根据引入到服务中的数据的 GB 单位数量计费。 （请参阅 Azure Monitor 定价。）在量大的情况下，成本可能会成为一个考虑因素。 有许多开源替代项可用于 Kubernetes 生态系统。 例如，许多组织将 Fluentd 与 Elasticsearch 配合使用。 Fluentd 是一个开源数据收集器，Elasticsearch 是用于搜索的文档数据库。 这些方式带来的难题是，它们要求对群集进行额外的配置和管理。 对于生产工作负载，可能需要试验配置设置。 还需要监视日志记录基础结构的性能。
OpenTelemetry
OpenTelemetry 是一项跨行业工作，通过标准化应用程序、库、遥测和数据收集器之间的接口来改进跟踪。 使用通过 OpenTelemetry 检测的库和框架时，通常由基础库处理跟踪操作（属于传统系统操作）的大部分工作，其中包括以下常见场景：
基本请求操作的日志记录，例如开始时间、退出时间和持续时间
上下文传播（例如跨 HTTP 调用边界发送相关 ID）
处理这些操作的基本库和框架会创建丰富的关联范围和跟踪数据结构，并跨上下文进行传播。 在 OpenTelemetry 之前，这些通常只是作为特殊的日志消息注入，或者作为特定于构建监视工具的供应商的专有数据结构注入。 OpenTelemetry 还建议使用比传统的日志记录优先方法更丰富的检测数据模型，并且日志会更加有用，因为日志消息链接到生成日志消息的跟踪和跨度。 这通常使查找与特定操作或请求关联的日志变得简单。
许多 Azure SDK 已使用 OpenTelemetry 进行检测，或者正在实现过程中。
应用程序开发人员可以使用 OpenTelemetry SDK 添加手动检测，以执行以下活动：
在基础库未提供检测的情况下添加检测。
通过添加跨度来扩充跟踪上下文，以公开特定于应用程序的工作单元（例如创建用于处理每个订单行的跨度的订单循环）。
使用实体键扩充现有跨度，以便更轻松地进行跟踪。 （例如，将 OrderID 键/值添加到处理该订单的请求。）这些键由监视工具呈现为结构化值，用于查询、筛选和聚合（无需分析日志消息字符串或查找日志消息序列的组合，而日志记录优先方法通常需要分析日志消息字符串或查找日志消息序列的组合）。
通过访问跟踪和跨度属性传播跟踪上下文，将 traceId 注入响应和有效负载并/或从传入消息读取 traceId，以便创建请求和跨度。
如需详细了解检测和 OpenTelemetry SDK，请参阅 OpenTelemetry 文档。
Application Insights
Application Insights 从 OpenTelemetry 及其检测库收集丰富的数据，并在高效的数据存储中捕获它，以提供丰富的可视化和查询支持。 Application Insights 基于 OpenTelemetry 的检测库（适用于 .NET、Java、Node.js 和 Python 等语言）可轻松将遥测数据发送到 Application Insights。
如果使用 .NET Core，建议也考虑适用于 Kubernetes 的 Application Insights 库。 此库使用其他信息（如容器、节点、Pod、标签和副本集）扩充 Application Insights 跟踪。
Application Insights 将 OpenTelemetry 上下文映射到其内部数据模型：
跟踪 -> 操作
跟踪 ID -> 操作 ID
跨度 -> 请求或依赖项
请考虑以下注意事项：
如果数据速率超过最大限制，则 Application Insights 会限制遥测数据。 有关详细信息，请参阅 Application Insights 限制。 单个操作可能生成多个遥测事件，因此，如果应用程序遇到较大的流量，可能会受到限制。
由于 Application Insights 批处理数据，如果进程失败并出现未经处理的异常，则可能会丢失批处理。
Application Insights 基于数据量计费。 有关详细信息，请参阅在 Application Insights 中管理定价和数据量。
结构化日志记录
若要使日志更易于分析，请尽可能使用结构化日志记录。 使用结构化日志记录时，应用程序以结构化格式（如 JSON）写入日志，而不是输出非结构化文本字符串。 可以使用许多结构化日志记录库。 例如，以下是使用适用于 .NET Core 的 Serilog 库的日志记录语句：
public async Task<IActionResult> Put([FromBody]Delivery delivery, string id)
    logger.LogInformation("In Put action with delivery {Id}: {@DeliveryInfo}", id, delivery.ToLogInfo());
在这里，对 LogInformation 的调用包括 Id 参数和 DeliveryInfo 参数。 使用结构化日志记录时，这些值不会内插到消息字符串中。 日志输出将如下所示：
{"@t":"2019-06-13T00:57:09.9932697Z","@mt":"In Put action with delivery {Id}: {@DeliveryInfo}","Id":"36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef","DeliveryInfo":{...
这是一个 JSON 字符串，其中 @t 字段是时间戳，@mt 是消息字符串，其余键/值对是参数。 使用输出 JSON 格式可以更轻松地以结构化方式查询数据。 例如，以下 Log Analytics 查询（采用 Kusto 查询语言编写）从所有名为 fabrikam-delivery 的容器中搜索此特定消息的实例：
traces
| where customDimensions.["Kubernetes.Container.Name"] == "fabrikam-delivery"
| where customDimensions.["{OriginalFormat}"] == "In Put action with delivery {Id}: {@DeliveryInfo}"
| project message, customDimensions["Id"], customDimensions["@DeliveryInfo"]
如果在 Azure 门户中查看结果，可以看到 DeliveryInfo 是包含 DeliveryInfo 模型的串行化表示形式的结构化记录：
以下是此示例中的 JSON：
  "Id": "36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef",
  "Owner": {
    "UserId": "user id for logging",
    "AccountId": "52dadf0c-0067-43e7-af76-86e32b48bc5e"
  "Pickup": {
    "Altitude": 0.29295161612934972,
    "Latitude": 0.26815900219052985,
    "Longitude": 0.79841844309047727
  "Dropoff": {
    "Altitude": 0.31507750848078986,
    "Latitude": 0.753494655598651,
    "Longitude": 0.89352830773849423
  "Deadline": "string",
  "Expedited": true,
  "ConfirmationRequired": 0,
  "DroneId": "AssignedDroneId01ba4d0b-c01a-4369-ba75-51bde0e76cc9"
许多日志消息标记工作单元的开始或结束，或者将业务实体与一组消息和操作连接，以实现可跟踪性。 在许多情况下，扩充 OpenTelemetry 跨度和请求对象是比只记录该操作的开始和结束更好的方法。 执行该操作会将该上下文添加到所有连接的跟踪和子操作中，并将该信息置于完整操作的范围内。 适用于各种语言的 OpenTelemetry SDK 支持创建跨度或在跨度上添加自定义属性。 例如，以下代码使用 Application Insights 支持的Java OpenTelemetry SDK。 现有父级跨度（例如与 REST 控制器调用相关的、由正在使用的 web 框架创建的请求跨度）可以通过与其关联的实体 ID 进行扩充，如下所示：
import io.opentelemetry.api.trace.Span;
// ...
Span.current().setAttribute("A1234", deliveryId);
此代码设置当前跨度上的键或值，它连接到在该跨度下发生的操作和日志消息。 该值显示在 Application Insights 请求对象中，如下所示：
requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project timestamp, name, url, success, resultCode, duration, operation_Id, deliveryId
当与日志、筛选配合使用并使用跨度上下文批注日志跟踪时，此技术会变得更加强大，如下所示：
requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project deliveryId, operation_Id, requestTimestamp = timestamp, requestDuration = duration  // keep some request info
| join kind=inner traces on operation_Id   // join logs only for this deliveryId
| project requestTimestamp, requestDuration, logTimestamp = timestamp, deliveryId, message
如果使用已通过 OpenTelemetry 检测的库或框架，那么它可以处理创建跨度和请求，但应用程序代码也可能创建工作单元。 例如，循环访问一系列实体并对每个实体执行工作的方法可能会为处理循环的每个迭代创建一个跨度。 有关将检测添加到应用程序和库代码的信息，请参阅 OpenTelemery 检测文档。
分布式跟踪
使用微服务时的难题之一是如何了解跨服务的事件流。 单个事务可能涉及对多个服务的调用。
分布式跟踪示例
此示例通过一组微服务介绍分布式事务的路径。 该示例基于无人机交付应用程序。
在此场景中，分布式事务包括以下步骤：
引入服务在 Azure 服务总线队列上放置消息。
工作流服务从队列中拉取消息。
工作流服务调用三个后端服务来处理请求（无人机计划程序、包和交付）。
以下屏幕截图显示了无人机交付应用程序的应用程序映射。 此映射显示对公共 API 终结点的调用，这些调用导致涉及五个微服务的工作流。
从 fabrikam-workflow 和 fabrikam-ingestion 到服务总线队列的箭头显示发送和接收消息的位置。 无法通过示意图判断哪个服务正在发送消息以及哪个服务正在接收消息。 箭头仅显示这两个服务正在调用服务总线。 但是，详细信息中提供了有关哪个服务正在发送消息以及哪个服务正在接收消息的信息：
由于每个调用都包含操作 ID，因此你还可以查看单个事务的端到端步骤，包括计时信息和每个步骤中的 HTTP 调用。 下面是一个此类事务的可视化效果：
此可视化效果显示了从引入服务到队列、从队列到工作流服务以及从工作流服务到其他后端服务的步骤。 最后一步是工作流服务将服务总线消息标记为已完成。
下面是调用后端服务失败的示例：
此映射表明，在查询期间，对无人机计划程序服务的调用很大一部分 (36% ) 失败。 端到端事务视图显示向服务发送 HTTP PUT 请求时发生异常：
如果进一步钻取，可以看到异常是套接字异常：“没有此类设备或地址”。
Fabrikam.Workflow.Service.Services.BackendServiceCallFailedException: 
No such device or address 
---u003e System.Net.Http.HttpRequestException: No such device or address 
---u003e System.Net.Sockets.SocketException: No such device or address
此异常表明无法访问后端服务。 此时，可以使用 kubectl 查看部署配置。 在此示例中，由于 Kubernetes 配置文件中出现错误，服务主机名无法解析。 Kubernetes 文档中的调试服务一文提供了诊断此类错误的提示。
以下是错误的一些常见原因：
代码 bug。 这些 bug 可能显示为：

异常。 在 Application Insights 日志中查看异常详细信息。
进程失败。 查看容器和 Pod 状态，并查看容器日志或 Application Insights 跟踪。
HTTP 5xx 错误。
资源耗尽：

查找限制 (HTTP 429) 或请求超时。
了解 CPU、内存和磁盘的容器指标。
查看容器配置和 Pod 资源限制。
服务发现。 检查 Kubernetes 服务配置和端口映射。
API 不匹配。 查找 HTTP 400 错误。 如果 API 已进行版本控制，请查看正在调用的版本。
拉取容器映像时出错。 查看 Pod 规范。 此外，请确保群集有权从容器注册表拉取。
RBAC 问题。
详细了解 Azure Monitor 中支持在 AKS 上监视应用程序的功能：
Azure Monitor 容器见解概述
使用 Azure Monitor 容器见解了解 AKS 群集性能
对分布式应用程序进行性能优化
使用域分析对微服务进行建模
设计微服务体系结构
为微服务设计 API