3. Application Insights入门与配置

Application Insights（简称 App Insights）是 Azure Monitor 体系中的应用程序性能监控（APM）服务。它通过在应用代码中嵌入 SDK 或启用无代码自动插桩，采集请求、依赖调用、异常、跟踪日志、性能计数器与页面浏览等遥测数据，并在 Azure 门户中提供事务搜索、应用地图、失败分析、性能分析和实时指标等视图。理解它的第一步，是分清“数据从哪里来、发到哪里去、保留多久、采样掉多少”这四个问题，本节就围绕它们展开。

一、先理解数据模型：一条遥测记录长什么样

App Insights 的所有数据都归入一个 Application Insights 资源，资源由“订阅 + 资源组 + 名称 + 区域”唯一确定。SDK 采集到的每条遥测都带有统一的上下文字段，例如 cloud_RoleName（服务名）、operation_Id（关联一次分布式事务）、operation_ParentId（父级跨度）、client_IP、session_Id 等。正是这些字段让“一次用户请求 → 多个微服务 → 多次 SQL 调用”能被串成一条完整链路。常见遥测类型包括：

• requests：服务端接收的 HTTP 请求，含响应码、耗时、成功标志。
• dependencies：应用对外发起的调用，如 SQL、HTTP、Redis、Service Bus。
• exceptions：未处理异常及堆栈，含问题 ID 用于聚合。
• traces：通过 ILogger/TelemetryClient.TrackTrace 写入的结构化日志。
• pageViews / customEvents / metrics：前端浏览、自定义业务事件与自定义指标。

下图展示了一次典型请求在 App Insights 中的信号链：从浏览器或客户端发起，经服务端请求、依赖调用，最终汇聚为可查询的遥测记录，并受采样与保留策略影响。

二、启用方式：代码插桩与自动插桩

启用 App Insights 有两条主流路径。第一条是代码插桩：在 .NET 应用中安装 Microsoft.ApplicationInsights.AspNetCore 包，在 Program.cs 中注册服务并读取连接字符串。第二条是自动插桩（Auto-instrumentation）：对 Azure App Service、AKS、Azure Functions 等托管环境，只需在门户或配置中开启，无需改代码即可采集请求、依赖与异常。对于容器化场景，还可以通过 OpenTelemetry 的 Azure Monitor Exporter 将数据发送到 App Insights。

以 ASP.NET Core 为例，典型配置如下（示例参数，需替换为实际值）：

// appsettings.json
{
  "ApplicationInsights": {
    "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000;IngestionEndpoint=https://chinaeast2-0.in.applicationinsights.azure.cn/"
  }
}

// Program.cs
builder.Services.AddApplicationInsightsTelemetry();
builder.Services.AddSingleton<ITelemetryInitializer, CloudRoleNameInitializer>();

连接字符串取代了早期的 Instrumentation Key，它同时包含采集端点和密钥，是 SDK 找到目标资源的唯一凭据。若连接字符串为空，SDK 会静默丢弃数据，这是“配置了却看不到数据”的最常见原因之一。

三、采样：控制数据量与成本的关键旋钮

采样（Sampling）决定实际保留多少遥测记录。默认情况下，ASP.NET Core SDK 启用自适应采样，目标约为每秒 5 条记录，并根据流量自动调整比率。采样分为两类：

• 自适应采样：SDK 自动调节，适合大多数生产环境，能在流量突增时保护后端与成本。
• 固定速率采样：手动设定比例，例如 SamplingPercentage = 20 表示保留 20%。

采样是“按操作”进行的：同一次请求及其依赖、异常会一起被保留或丢弃，因此不会出现“有请求没依赖”的断裂链路。但要注意，采样后指标（如请求数）会按比例还原，而日志查询中的明细条数会减少。若某类关键异常必须全量保留，可通过 ITelemetryProcessor 排除特定遥测不参与采样。

四、数据保留与成本

App Insights 的日志数据默认保留 90 天，可在资源“使用情况和估算成本 → 数据保留”中按表调整（30～730 天）。指标数据保留 90 天。保留期越长，存储成本越高。常见做法是：明细日志保留 30～90 天，长期趋势通过连续导出或诊断设置归档到存储账户或 Log Analytics 工作区。

五、基本监控项与验证

启用后应优先确认以下监控项是否正常上报：请求量与失败率、依赖调用耗时与失败、异常数量与问题 ID、服务器响应时间、以及自定义业务指标。验证方法是打开“实时指标”观察约 1 秒延迟的请求流，或在“日志”中执行 KQL：

requests
| where timestamp > ago(30m)
| summarize 请求数 = count(), 失败数 = countif(success == false), P95耗时 = percentile(duration, 95)
  by cloud_RoleName, name
| order by 请求数 desc

若查询结果为空，按顺序排查：连接字符串是否正确、SDK 是否注册、采样是否把数据全部丢弃、网络是否允许访问采集端点、以及是否在错误的资源中查询。下表给出常见配置项与推荐起点（示例值，需按实际调整）：