我们在2020年6月首次将dotnet monitor ，作为一个实验性工具，并在过去一年中努力将其变成一个生产级工具。今天，我很高兴地宣布，作为.NET 6的一部分，dotnet monitor 的第一个支持版本。
dotnet monitor 这款工具已经为Linux上Azure App Service上的.NET应用程序提供了诊断工具，我们很高兴看到它在这个版本中被用于更多环境。
什么是dotnet monitor ？
在不同的环境中运行.NET应用程序可能会使收集诊断工件（如日志、跟踪、进程转储）变得具有挑战性。dotnet monitor 是一个工具，它提供了一种统一的方式来收集这些诊断工件，无论你是在桌面机器上运行还是在kubernetes集群中运行。
有两种不同的机制来收集这些诊断工件：
- 用于按需收集工件的HTTP API。当你已经知道你的应用程序正在经历一个问题，并且你对收集更多信息感兴趣时，你可以调用这些API端点。
- 基于规则配置的触发器，用于始终收集工件。你可以配置规则，在满足所需条件时收集诊断工件，例如，当你有持续的高CPU时收集一个进程转储。
入门指南
dotnet monitor 可以通过两种不同的分发机制获得：
- 作为一个.NET CLI工具；和
- 通过微软容器注册中心（MCR）提供的容器镜像。
.NET CLI工具
dotnet monitor CLI工具需要安装一个.NET 6 SDK作为前提条件。如果你没有足够新的SDK，你可以从Download .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
容器图像
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 monitor的信息。/operations- 获取出口操作状态或取消操作。
下面的例子展示了使用dotnet monitor ，从Microsoft.AspNetCore.Server.Kestrel.Connections 类别中流式传输目标进程的六十秒内的Debug 级日志：
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 ，如果它检测到持续的高CPU使用率超过80%，持续时间超过1分钟，它将每小时收集不超过一次分流转储：
{
"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 ，根据你定义的启发式方法来定制诊断工件的始终在线收集，什么是你的应用程序的异常行为。要了解更多关于自定义收集的各种方法，请看收集规则的文档。我们很高兴知道你能用dotnet monitor 在生产中解决什么问题。
反馈
让我们知道我们可以做些什么来使你的.NET应用程序更容易诊断出问题。您可以在我们的GitHub仓库中创建问题或关注项目的进展情况。
