原文：https://devblogs.microsoft.com/dotnet/announcing-dotnet-monitor-in-net-6/
我们于 2020 年 6 月首次dotnet monitor作为实验工具推出，并在去年努力将其转变为生产级工具。今天，我很高兴地宣布dotnet monitor作为 .NET 6 一部分的第一个受支持版本。
dotnet monitor已经在 Linux 上的 Azure 应用服务上为 .NET 应用程序的诊断工具提供支持，我们很高兴现在看到它在此版本的更多环境中使用。
一、什么是dotnet Monitor？
在不同环境中运行 .NET 应用程序会使收集诊断工件（例如，日志、跟踪、进程转储）变得具有挑战性。dotnet monitor是一种工具，它提供了一种统一的方式来收集这些诊断工件，无论您是在台式机上运行还是在 kubernetes 集群中运行。
收集这些诊断工件有两种不同的机制：
- 用于按需收集工件的HTTP API。当您已经知道您的应用程序遇到问题并且您有兴趣收集更多信息时，您可以调用这些 API 端点。
- 基于规则的配置触发器，用于始终在线的工件集合。您可以配置规则以在满足所需条件时收集诊断工件，例如，在您持续使用高 CPU 时收集进程转储。
二、入门
dotnet monitor 可通过两种不同的分发机制获得：
- 作为 .NET CLI 工具；和
- 作为可通过 Microsoft Container Registry (MCR) 获得的容器映像。
2.1.NET 命令行工具
该dotnet monitorCLI工具需要安装为先决条件一个.NET 6 SDK。如果您没有足够新的 SDK，可以从下载 .NET 网页安装一个新的 SDK 。
您可以dotnet monitor使用以下命令下载最新版本：
dotnet tool install -g dotnet-monitor --version 6.0.0
如果您已经dotnet monitor安装并想要更新：
dotnet tool update -g dotnet-monitor --version 6.0.0
2.2容器镜像
该dotnet monitor容器的图像可以用MCR。您可以使用以下命令拉取最新的镜像：
docker pull mcr.microsoft.com/dotnet/monitor:6.0.0
三、HTTP API
dotnet monitor 公开一个 HTTP API 以查询可用进程、收集诊断工件并检查请求工件的状态
dotnet monitor 公开的HTTP API 公开以下 HTTP 端点：
/processes– 获取有关可发现进程的详细信息。/dump– 在不使用调试器的情况下捕获进程的托管转储。/gcdump– 捕获进程的 GC 转储。/trace– 在不使用分析器的情况下捕获进程的痕迹。/metrics– 以 Prometheus 展示格式捕获默认流程的指标快照。/livemetrics– 捕获流程的实时流指标。/logs– 捕获进程日志。/info– 获取有关 dotnet 监视器的信息。/operations– 获取出口操作状态或取消操作。
下面的示例展示了从目标进程在 60 秒的持续时间内从类别dotnet monitor中流式传输Debug级别日志的用法。Microsoft.AspNetCore.Server.Kestrel.Connections
PS> curl.exe -X POST "https://localhost:52323/logs?name=myWebApp&durationSeconds=60" ` -H "Accept: application/x-ndjson" ` -H "Content-Type: application/json" ` --negotiate -u $(whoami)` -d '{"filterSpecs": {"Microsoft.AspNetCore.Server.Kestrel.Connections": "Debug"}}' {"Timestamp":"2021-11-05 08:12:54Z","LogLevel":"Debug","EventId":39,"EventName":"ConnectionAccepted","Category":"Microsoft.AspNetCore.Server.Kestrel.Connections","Message":"Connection id u00220HMD06BUKL2CUu0022 accepted.","State":{"Message":"Connection id u00220HMD06BUKL2CUu0022 accepted.","ConnectionId":"0HMD06BUKL2CU","{OriginalFormat}":"Connection id u0022{ConnectionId}u0022 accepted."}} {"Timestamp":"2021-11-05 08:12:54Z","LogLevel":"Debug","EventId":1,"EventName":"ConnectionStart","Category":"Microsoft.AspNetCore.Server.Kestrel.Connections","Message":"Connection id u00220HMD06BUKL2CUu0022 started.","State":{"Message":"Connection id u00220HMD06BUKL2CUu0022 started.","ConnectionId":"0HMD06BUKL2CU","{OriginalFormat}":"Connection id u0022{ConnectionId}u0022 started."}} {"Timestamp":"2021-11-05 08:12:54Z","LogLevel":"Debug","EventId":9,"EventName":"ConnectionKeepAlive","Category":"Microsoft.AspNetCore.Server.Kestrel.Connections","Message":"Connection id u00220HMD06BUKL2CUu0022 completed keep alive response.","State":{"Message":"Connection id u00220HMD06BUKL2CUu0022 completed keep alive response.","ConnectionId":"0HMD06BUKL2CU","{OriginalFormat}":"Connection id u0022{ConnectionId}u0022 completed keep alive response."},"Scopes":[{"ConnectionId":"0HMD06BUKL2CU"},{"RequestId":"0HMD06BUKL2CU:00000002","RequestPath":"/"}]}
如上例所示，您可以使用dotnet monitor来自目标进程的按需出口诊断工件。除了日志，您还可以从目标进程收集跟踪、内存转储、GC 转储和指标。
四、触发器
dotnet monitor可以配置为根据发现的进程中的条件自动收集诊断工件。当发现新进程时，dotnet monitor如果该进程与规则上的过滤器匹配，则将尝试应用配置的规则。应用的规则将开始监视触发器描述的条件的过程。如果满足该条件，则假定尚未达到指定的限制来执行操作列表。
下面的示例展示了一个示例，dotnet monitor如果检测到超过 80% 的持续高 CPU 使用率持续超过一分钟，则每小时收集的分类转储不超过一次。
{ "CollectionRules": { "HighCpuRule": { "Filters": [ { "Key": "ProcessName", "Value": "MyApp", "MatchType": "Exact" } ], "Trigger": { "Type": "EventCounter", "Settings": { "ProviderName": "System.Runtime", "CounterName": "cpu-usage", "GreaterThan": 80, "SlidingWindowDuration": "00:01:00" } }, "Limits": { "ActionCount": 1, "ActionCountSlidingWindowDuration": "1:00:00" }, "Actions": [ { "Type": "CollectDump", "Settings": { "Type": "Triage", "Egress": "myBlobStorageAccount" } } ] } } }
如上例所示，您可以dotnet monitor根据您为应用程序的异常行为定义的启发式方法来自定义始终在线的诊断工件集合。