从0到1搭建.NET监控告警系统
搭建监控告警不用一上来就搞高大上的架构，咱们先选对工具。市面上监控工具不少，但对.NET应用来说，选工具得看三点：是否原生支持.NET、配置复杂度、后期维护成本。我整理了几个常用工具的对比，你可以根据自己的场景选：
| 工具名称 | .NET支持度 | 配置难度 | 适用场景 | 成本 |
|---|---|---|---|---|
| Application Insights | ★★★★★（微软官方，原生集成） | ★★☆（SDK一键集成，无需复杂配置） | 云服务/独立部署的.NET应用 | 免费版有额度限制，付费版按需计费 |
| Prometheus+Grafana | ★★★☆（需Exporter插件，配置稍复杂） | ★★★★（需部署服务器，写PromQL查询） | 容器化部署、需要高度自定义监控 | 开源免费，需自己维护服务器 |
| ELK Stack | ★★★（需Logstash插件处理.NET日志） | ★★★★★（组件多，配置链路长） | 需要深度日志分析的大型应用 | 开源免费，维护成本高 |
如果你是零基础，我 优先选Application Insights（简称AI），微软官方出品，对.NET Framework和.NET Core/Core 5+都有完美支持，不用自己搭服务器，配置步骤简单，而且和Azure云、Visual Studio无缝集成，数据可视化做得也不错。我去年帮一个做电商的朋友搭监控时，他一开始想用Prometheus，捣鼓了两天没配明白Exporter，后来换成AI，半小时就跑通了数据采集，所以新手别给自己找难度，选对工具能省很多事。
选好工具后，接下来要确定监控哪些核心指标。别贪多，一开始监控太多指标反而抓不住重点。我 了4个必看指标，你照着配就行：
确定指标后，就可以开始配置监控采集了。以Application Insights为例，步骤其实很简单，你跟着做：
第一步，在Azure门户创建Application Insights资源（如果没有Azure账号，用微软账号注册就行，有免费额度），记下Instrumentation Key（类似监控项目的ID）。
第二步，在你的.NET项目里安装SDK：如果是.NET Core/.NET 5+，直接用NuGet安装Microsoft.ApplicationInsights.AspNetCore包；如果是.NET Framework，安装Microsoft.ApplicationInsights.Web包。
第三步，修改配置文件：ASP.NET Core项目在appsettings.json里加一行：
"ApplicationInsights": {
"InstrumentationKey": "你的Instrumentation Key"
}
然后在Program.cs（.NET 6+）里加一句builder.Services.AddApplicationInsightsTelemetry();就完事了。
这里插一句经验：很多人配完后发现没数据，大概率是两个原因：一是Instrumentation Key填错了（复制的时候多了个空格或者少了几位），二是没开详细日志等级。你可以在配置文件里把日志等级设为Information（默认可能是Warning），这样AI才能采集到足够数据。我朋友当时就是日志等级太高，只采集到错误日志，正常请求数据都没有，排查半天才发现这个问题。
配置完后启动应用，访问几个接口，等5分钟（AI有延迟），再打开Azure的Application Insights控制台，就能看到实时数据了——是不是很简单？这时候你已经完成了监控的第一步：能看到系统的”心跳”了。
告警策略优化：从”狂轰滥炸”到精准提醒
光有监控还不够，关键是出问题时能及时收到告警。但我见过太多人配置告警后反而更头疼：要么是告警太频繁，半夜被短信吵醒发现是”CPU使用率80%”这种无关痛痒的问题；要么是告警太迟钝，等收到时系统已经崩了半小时。这部分我重点讲怎么优化告警策略，让告警真正帮到你，而不是烦你。
先说说怎么避免告警风暴。新手最容易犯的错就是”一刀切”设阈值：比如CPU超过80%就告警，但实际情况是，你的系统每天10点-12点是访问高峰，CPU经常到85%但业务正常，这时候告警就是噪音。我之前就吃过这个亏，设置”错误率>1%”就告警，结果有天推广活动，流量涨了10倍，虽然错误率1.2%，但绝对数量才5个，根本不影响业务，却收到20多条告警短信，后来优化后就好了很多。怎么优化？分享3个实用技巧：
然后是告警渠道的选择。别只依赖邮件，关键时刻可能被淹没在垃圾邮件里。我推荐至少配置2种渠道：
最后说下收到告警后怎么快速定位问题。光知道”有问题”没用，得知道”哪里有问题”。这时候监控系统采集的日志和调用链就派上用场了。以Application Insights为例，收到”支付接口错误率突增”的告警后，你可以：
这里分享个小技巧：在代码里给重要接口的关键步骤加自定义日志，比如支付接口里，”开始调用微信支付API”、”微信支付返回结果：success”、”订单状态更新成功”，这样出问题时能更快定位到是哪个环节卡住了。我之前就是因为在支付接口加了这些日志，有次告警后2分钟就定位到是微信支付API超时，而不是自己代码的问题，省了大量排查时间。
按照上面的步骤，你现在应该已经搭好了监控，也优化了告警策略——试试跑几天，看看是不是系统问题能提前发现，加班少了很多？其实.NET监控告警没那么神秘，关键是选对工具、抓准指标、优化告警策略，不用追求”大而全”，先做到”小而美”，能解决80%的问题就行。如果你按照这些方法试了，遇到配置问题或者有更好的优化技巧，欢迎在评论区告诉我，咱们一起把.NET监控做得更顺手！
Application Insights免费版对中小项目来说，真的挺够用的，我之前帮一个朋友的项目搭监控时试过，他们是做企业内部管理系统的，日活大概3000左右，接口也就30多个，用免费版跑了三个月，数据量才用了不到2GB，离5GB的免费额度差得远呢。你想啊，免费版每月给5GB的监控数据量，还有100万次请求数的额度，中小项目一般日活1万以内、接口数50个以下，每天用户访问接口的次数撑死也就几万次，一个月下来请求数顶天几十万，完全够。而且免费版不是“阉割版”，该有的核心功能都有，像接口响应时间、错误率、数据库调用耗时这些基础监控数据都能抓到，告警功能也能用，对付日常的系统问题排查完全够了。
要说功能上有没有限制，其实主要是高级分析和数据保留时间，免费版数据只能存90天，付费版能存更久，但中小项目平时查问题最多看最近一周的日志，90天完全够用。真要到了数据量超了的情况，比如电商项目搞大促，那几天请求量可能突然涨到200万次，这时候再开按需付费就行，按实际用的数据量算钱，平时不用就关了，成本特别可控。我一般 大家先从免费版开始试，跑一两个月看看实际数据消耗和功能需求，真不够了再升级，反正切换起来也方便，不用重新配监控，直接在Azure后台调个开关就行，省得一开始就花钱买高级版，结果用不上浪费。
如何根据项目规模选择合适的.NET监控工具？
可参考项目实际情况选择：小型项目或零基础团队优先选Application Insights，无需服务器维护，SDK集成简单，适合快速上手；中型项目且需要容器化部署/高度自定义监控时，可选Prometheus+Grafana，开源免费但需投入人力维护；大型项目若需深度日志分析（如多服务日志关联），可考虑ELK Stack，但配置和维护成本较高。文中工具对比表格已列出各工具的.NET支持度、配置难度和适用场景，可对照选择。
配置监控后没有数据怎么办？
先排查3个常见原因：①检查Instrumentation Key是否正确（复制时注意空格或字符缺失）；②确认日志等级是否过低（.NET项目默认日志等级可能为Warning，需设为Information才能采集详细数据，可在配置文件中修改）；③网络是否通畅（部分企业内网可能限制Azure服务访问，可尝试本地运行项目测试数据是否能上传）。若用Application Insights，可在Azure门户的“实时指标流”查看是否有即时数据，快速定位问题。
告警阈值设置多少才算合理？
没有绝对标准， 结合3个维度：①分时段调整，如业务高峰（9:00-18:00）CPU阈值可设85%-90%，低峰期（0:00-6:00）设70%以下；②参考历史数据，运行一周后观察指标波动范围（如正常CPU波动在30%-60%，阈值可设75%）；③按业务重要性分级，核心接口（如支付）错误率阈值设0.1%，非核心接口（如内部报表）可设1%。避免静态阈值，优先用“持续时间+动态阈值”（如CPU>80%持续5分钟才告警），减少瞬时波动误报。
Application Insights免费版能满足中小项目需求吗？
基本够用。免费版每月提供5GB数据量、100万请求数的额度，中小项目（日活1万以内、接口数50个以下）日常监控完全覆盖。免费版包含核心功能：请求性能、错误追踪、依赖项监控、基础告警，适合初期搭建监控体系。若后期数据量超出（如电商大促期间），可开启按需付费模式（按数据量计费），成本可控， 先从免费版开始测试，再根据实际需求升级。
除了文中提到的核心指标，还有哪些可选的.NET监控指标？
可根据项目特性补充：①GC（垃圾回收）指标：如GC频率、GC暂停时间（.NET应用内存泄漏常伴随GC频繁触发）；②线程状态：监控线程池活跃线程数、等待队列长度（避免线程耗尽导致请求阻塞）；③数据库连接池：连接数、等待时间（防止连接池耗尽引发“超时无法获取连接”错误）；④自定义业务指标：如订单转化率、支付成功率（结合业务目标监控）。注意：新增指标需评估必要性，避免监控过载，优先保障核心指标的准确性。
