你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn 。
Azure Monitor Application Insights 的数据收集基本信息
本文内容
在监视应用程序之前,需要先对其进行检测。
以下部分将介绍 Azure Monitor Application Insights 的一些数据收集基本信息。
检测选项
就基础级别而言,“检测”只是使应用程序能够捕获遥测数据。
有两种检测应用程序的方法:
自动检测通过配置启用遥测数据收集,而不会触及应用程序的代码。 虽然非常方便,但其可配置性较低。 并且只提供部分语言版本。 请参阅自动检测支持的环境和语言 。 当自动检测可用时,这是启用 Azure Monitor Application Insights 的最简单方法。
手动检测 对 Application Insights 或 OpenTelemetry API 进行编码。 在用户的上下文中,它通常是指在应用程序中安装语言特定的 SDK。 这意味着必须自行管理更新到最新包版本的工作。 如果需要进行自定义依赖项调用或 API 调用,而自动检测默认情况下不会捕获这些调用,则可以使用此选项。 手动检测有两种选择:
虽然我们认为 OpenTelemetry 是发展的方向,但没有停止从旧 SDK 收集数据的计划。 还有一段距离才能让 Azure OpenTelemetry 发行版与 Application Insights SDK 实现功能奇偶一致性 。 在许多情况下,客户会在相当长的一段时间内继续选择使用 Application Insights SDK。
遥测类型
遥测数据(为观察应用程序而进行收集的数据)可以分为三种类型或包含三种构成要素:
完整的可观测性故事包括所有三个支柱,Application Insights 根据我们的数据模型 将这些支柱进一步分解为表。 我们的 Application Insights SDK 或 Azure Monitor OpenTelemetry 发行版包括在 Azure 上支持应用程序性能监视所需的一切。 包本身可以免费安装,只需为在 Azure Monitor 中引入的数据付费。
以下源介绍三大支柱:
遥测路由
可以通过两种方式将数据发送给 Azure Monitor(或任何供应商):
直接导出程序会将正在进行的遥测(从应用程序的代码)直接发送到 Azure Monitor 引入终结点。 此方法的主要优点是加入过程非常简单。
当前可用的 Application Insights SDK 和 Azure Monitor OpenTelemetry 发行版依赖于直接导出程序 。
提示
如果计划使用 OpenTelemetry-Collector 进行采样或其他数据处理,则可以在 Azure Monitor 中内置这些相同的功能。 迁移到基于工作区的 Application Insights 的客户可以从引入时间转换 中受益。 要启用,请按照教程 中的详细信息进行操作,跳过显示如何设置诊断设置的步骤,因为在以工作区为中心的 Application Insights 中,已经配置了诊断设置。 如果筛选量不到总容量的 50%,则不会产生额外费用。 50% 之后,会产生费用,但远低于每 GB 收费的标准。
OpenTelemetry
Microsoft 很高兴能够在未来使用 OpenTelemetry 检测遥测数据。 作为我们的客户,你曾要求提供非供应商特定的工具,并且我们很高兴能够与 OpenTelemetry 社区达成合作,跨语言创建一致的 API 和 SDK。
Microsoft 与两个以前常用的开源遥测项目 OpenCensus 和 OpenTracing 的项目利益干系人合作。 我们互帮互助,携手创建了 OpenTelemetry 这一项目。 OpenTelemetry 包括所有主要云和应用程序性能管理 (APM) 供应商发布的内容,并由云原生计算基金会 (CNCF) 运营。 Microsoft 是 CNCF 的白金成员。
有关术语,请参阅 OpenTelemetry 规范中的术语表 。
由于 OpenTelemetry 上的行业整合,Application Insights 中的一些旧术语会引起混淆问题。 下表突出显示这些差异。 OpenTelemetry 术语将替换 Application Insights 术语。
Application Insights
OpenTelemetry
自动收集器
检测库
通道
导出程序
无代码/基于代理
自动检测
跟踪
日志
请求
服务器跨度
依赖项
其他跨度类型(客户端、内部等)
操作 ID
跟踪 ID
ID 或父级操作 ID
Span ID
疑难解答
第 1 步:启用诊断日志记录
Azure Monitor 导出程序使用 EventSource 执行其内部日志记录。 通过选择加入名为OpenTelemetry-AzureMonitor-Exporter
的来源,任何 EventListener 都可以使用导出程序日志。 有关故障排除步骤,请参阅 GitHub 上的 OpenTelemetry 故障排除 。
第 2 步:测试应用程序主机与引入服务的连接
Application Insights SDK 和代理发送遥测,在引入终结点将其作为 REST 调用引入。 请使用 PowerShell 中的 cURL 命令或原始 REST 请求,测试从 Web 服务器或应用程序主计算机到引入服务终结点的连接。 有关更多信息,请参阅排查 Azure Monitor Application Insights 中缺失应用程序遥测的问题 。
已知问题
Azure Monitor OpenTelemetry 导出程序存在以下已知问题:
第 1 步:启用诊断日志记录
Azure Monitor 导出程序使用 EventSource 执行其内部日志记录。 通过选择加入名为OpenTelemetry-AzureMonitor-Exporter
的来源,任何 EventListener 都可以使用导出程序日志。 有关故障排除步骤,请参阅 GitHub 上的 OpenTelemetry 故障排除 。
第 2 步:测试应用程序主机与引入服务的连接
Application Insights SDK 和代理发送遥测,在引入终结点将其作为 REST 调用引入。 请使用 PowerShell 中的 cURL 命令或原始 REST 请求,测试从 Web 服务器或应用程序主计算机到引入服务终结点的连接。 有关更多信息,请参阅排查 Azure Monitor Application Insights 中缺失应用程序遥测的问题 。
已知问题
Azure Monitor OpenTelemetry 导出程序存在以下已知问题:
第 1 步:启用诊断日志记录
默认情况下,会在 Azure Monitor Application Insights 中启用诊断日志记录。 有关更多信息,请参阅故障排除指南:适用于 Java 的 Azure Monitor Application Insights 。
第 2 步:测试应用程序主机与引入服务的连接
Application Insights SDK 和代理发送遥测,在引入终结点将其作为 REST 调用引入。 请使用 PowerShell 中的 cURL 命令或原始 REST 请求,测试从 Web 服务器或应用程序主计算机到引入服务终结点的连接。 有关更多信息,请参阅排查 Azure Monitor Application Insights 中缺失应用程序遥测的问题 。
已知问题
如果从浏览器下载 Application Insights 客户端库进行安装 ,有时下载的 JAR 文件会损坏,并且大约是源文件大小的一半。 如果遇到此问题,请通过运行 curl 或 wget 命令下载 JAR 文件,如以下示例命令调用中所示:
curl --location --output applicationinsights-agent-3.4.11.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download/3.4.11/applicationinsights-agent-3.4.11.jar
wget --output-document=applicationinsights-agent-3.4.11.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download/3.4.11/applicationinsights-agent-3.4.11.jar
以下步骤适用于 Spring Boot 本机应用程序。
第 1 步:验证 OpenTelemetry 版本
在应用程序启动期间,你可能会看到以下消息:
WARN c.a.m.a.s.OpenTelemetryVersionCheckRunner - The OpenTelemetry version is not compatible with the spring-cloud-azure-starter-monitor dependency.
The OpenTelemetry version should be <version>
在这种情况下,必须按照 Spring Boot 入门 中的 OpenTelemetry 文档导入 OpenTelemetry 物料清单。
第 2 步:启用自我诊断
如果某些内容无法按预期工作,则可以在 DEBUG
级别启用自我诊断,获取一些相关见解。 为此,请使用 APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL
环境变量,将自我诊断级别设置为 ERROR
、WARN
、INFO
、DEBUG
或 TRACE
。
若要在运行 Docker 容器时在 DEBUG
级别启用自我诊断,请运行以下命令:
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
注意
将 <image-name>
替换为相应 Docker 映像名称。
第三方信息免责声明
本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。
第 1 步:启用诊断日志记录
Azure Monitor 导出程序将 OpenTelemetry API 记录器用于内部日志。 若要启用记录器,请运行以下代码片段:
const { diag, DiagConsoleLogger, DiagLogLevel } = require("@opentelemetry/api");
const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");
const provider = new NodeTracerProvider();
diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ALL);
provider.register();
第 2 步:测试应用程序主机与引入服务的连接
Application Insights SDK 和代理发送遥测,在引入终结点将其作为 REST 调用引入。 请使用 PowerShell 中的 cURL 命令或原始 REST 请求,测试从 Web 服务器或应用程序主计算机到引入服务终结点的连接。 有关更多信息,请参阅排查 Azure Monitor Application Insights 中缺失应用程序遥测的问题 。
已知问题
Azure Monitor OpenTelemetry 导出程序存在以下已知问题:
依赖项遥测中缺少操作名称。 缺少的操作名称会导致失败,并对性能选项卡体验产生负面影响。
请求和依赖项遥测数据中缺少设备模型。 缺少的设备模型会对设备队列分析产生负面影响。
依赖项名称中缺少数据库服务器名称。 由于不包括数据库服务器名称,OpenTelemetry 导出程序错误地将具有相同名称的表聚合到不同的服务器上。
第 1 步:启用诊断日志记录
Microsoft Azure Monitor 导出程序使用 Python 标准日志记录库 执行其内部日志记录。 针对不规则活动,OpenTelemetry API 和 Azure Monitor 导出程序日志获配严重性级别 WARNING
或 ERROR
。 INFO
严重性级别用于常规活动或成功活动。
默认情况下,Python 日志记录库将严重性级别设置为 WARNING
。 因此,必须更改严重性级别才能查看此严重性设置下的日志。 以下示例代码演示如何将所有严重性级别的日志输出到控制台和文件:
...
import logging
logging.basicConfig(format = "%(asctime)s:%(levelname)s:%(message)s", level = logging.DEBUG)
logger = logging.getLogger(__name__)
file = logging.FileHandler("example.log")
stream = logging.StreamHandler()
logger.addHandler(file)
logger.addHandler(stream)
...
第 2 步:测试应用程序主机与引入服务的连接
Application Insights SDK 和代理发送遥测,在引入终结点将其作为 REST 调用引入。 请使用 PowerShell 中的 cURL 命令或原始 REST 请求,测试从 Web 服务器或应用程序主计算机到引入服务终结点的连接。 有关更多信息,请参阅排查 Azure Monitor Application Insights 中缺失应用程序遥测的问题 。
第 3 步:避免重复遥测
如果创建多个处理器或导出程序实例,则通常会造成重复遥测。 请确保每次只针对每个遥测要素(日志、指标和分布式跟踪)运行一个导出程序和处理器。
以下部分介绍可能导致重复遥测的情况。
Azure Functions 中的重复跟踪日志
如果在 Application Insights 中看到每个跟踪日志的一对条目,则可能已启用以下类型的日志记录检测:
Azure Functions 中的本机日志记录检测
分发中的 azure-monitor-opentelemetry
日志记录检测
若要防止重复,可以禁用分发的日志记录,但在 Azure Functions 中保留本机日志记录检测。 为此,请将 OTEL_LOGS_EXPORTER
环境变量设置为 None
。
“始终可用的”Azure Functions 中的重复遥测数据
如果 Azure Functions 中的“始终可用” 设置为“启用” ,则 Azure Functions 会在每次运行完成后在后台保持运行一些进程。 例如,假设你有一个每次调用 configure_azure_monitor
的五分钟计时器函数。 20 分钟后,可能会有四个同时运行的指标导出程序。 这种情况可能是重复指标遥测数据的来源。
在这种情况下,请将“始终可用” 设置为“关闭 ”,或尝试在每个 configure_azure_monitor
调用之间手动关闭提供程序。 若要关闭每个提供程序,请针对每个当前计量、跟踪器和记录器提供程序运行关闭调用,如以下代码所示:
get_meter_provider().shutdown()
get_tracer_provider().shutdown()
get_logger_provider().shutdown()
Azure 工作簿和 Jupyter Notebook
Azure 工作簿和 Jupyter Notebook 可能会使导出程序进程在后台运行。 若要防止重复遥测,请在调用更多 configure_azure_monitor
之前清除缓存。
第 4 步:确保收集 Flask 请求数据
如果采用 Flask 应用程序,你可能会发现在使用适用于 Python 的 Azure Monitor OpenTelemetry 发行版客户端库 时,无法从 Application Insights 收集请求表数据。 如果未正确构造 import
声明,则可能会出现此问题。 在调用 configure_azure_monitor
函数来检测 Flask 库之前,可能需要导入 flask.Flask
Web 应用程序框架。 例如,以下代码未成功检测 Flask 应用:
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
相反,我们建议将 flask
模块作为一个整体导入,然后调用 configure_azure_monitor
,将 OpenTelemetry 配置为在访问 flask.Flask
之前使用 Azure Monitor:
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
或者,可以在导入 flask.Flask
之前调用 configure_azure_monitor
:
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)
支持
选择所选语言的选项卡,以发现支持选项。
OpenTelemetry 反馈
若要提供反馈,请查看以下内容:
常见问题
在哪里可以找到 Application Insights SDK 版本及其名称的列表?
GITHub 上托管的 SDK 版本和名称的列表。 有关详细信息,请参阅 SDK 版本 。
后续步骤
选择启用方法:
有关详细信息,请查看 Azure Monitor Application Insights 常见问题解答 和 OpenTelemetry 常见问题解答 。