Read this article in your language IT | EN | DE | ES
Ранее было представлено dotnet monitor как экспериментальный инструмент для доступа к диагностической информации в процессе dotnet. dotnet monitor перешел на поддерживаемый инструмент в экосистеме .NET. dotnet monitor будет полностью поддерживаться, начиная с нашего первого стабильного выпуска в конце этого года.
Если вы новичок в использовании dotnet monitor, рекомендуем ознакомиться с официальной документацией, которая включает пошаговые инструкции по использованию dotnet monitor на локальном компьютере с Docker и Kubernetes,
В этом сообщении блога подробно описаны некоторые новые основные функции в preview4 dotnet monitor:
• Провайдеры исходящего трафика
• Специальные показатели
• Безопасность и усиление
Начало работы
dotnet monitor доступен через два разных механизма распространения:
• Как глобальный инструмент .NET; а также
• Как образ контейнера, доступный через Microsoft Container Registry (MCR)
Глобальный инструмент .NET
Для работы глобального инструмента dotnet monitor требуется установленный пакет SDK .NET 3.1 или более поздней версии в качестве предварительного условия. Если у вас нет достаточно нового SDK, вы можете установить новый с веб-страницы Download .NET.
Последняя общедоступная версия dotnet monitor доступна на Nuget. Вы можете скачать последнюю версию, используя следующую команду:
dotnet tool install -g dotnet-monitor --version 5.0.0-preview.4.*
Если у вас уже установлен dotnet monitor и вы хотите его обновить:
dotnet tool update -g dotnet-monitor --version 5.0.0-preview.4.*
Образ контейнера
Последняя общедоступная предварительная версия образа контейнера dotnet monitor доступна на MCR. Вы можете получить последний образ, используя следующую команду:
docker pull mcr.microsoft.com/dotnet/monitor:5.0.0-preview.4
Провайдеры исходящего трафика
В предыдущих предварительных версиях единственным способом вывода диагностических артефактов из dotnet monitor был поток ответов HTTP. Хотя это хорошо работает с надежными соединениями, это становится все более сложной задачей для очень больших артефактов и менее надежных соединений.
В preview4 вы можете настроить dotnet monitor для вывода артефактов в другие места назначения: хранилище BLOB-объектов Azure и локальную файловую систему. Можно указать несколько исходящих провайдеров через конфигурацию, как показано в примере ниже:
{
"Egress": {
"Providers": {
"sampleBlobStorageEgressProvider": {
"type": "azureBlobStorage",
"accountUri": "https://contoso.blob.core.windows.net",
"containerName": "dotnet-monitor",
"blobPrefix": "artifacts",
"accountKeyName": "MonitorBlobAccountKey"
}
},
"Properties": {
"MonitorBlobAccountKey": "accountKey"
}
}
}
После настройки во время запуска коллекции артефактов через HTTP-запрос теперь вы можете указать, какой исходящий провайдер использовать. С конфигурацией выше теперь вы можете сделать следующий запрос:
GET /dump/?egressProvider=sampleBlobStorageEgressProvider HTTP/1.1
Более подробные инструкции по настройке исходящих провайдеров см. В документации по исходящей конфигурации.
Специальные показатели
В дополнение к коллекции метрик System.Runtime и Microsoft.AspNetCore.Hosting теперь можно собирать дополнительные метрики (генерируемые через EventCounters) для экспорта в формат экспозиции Prometheus.
Вы можете настроить dotnet monitor для сбора дополнительных метрик, как показано в примере ниже:
{
"Metrics": {
"Providers": [
{
"ProviderName": "Microsoft-AspNetCore-Server-Kestrel"
}
]
}
}
Более подробные инструкции по сбору пользовательских метрик см. В документации по настройке метрик.
Безопасность и усиление
Требование аутентификации - это часть работы по усилению защиты dotnet monitor, чтобы сделать его пригодным для развертывания в производственных средах. Кроме того, для защиты учетных данных, отправляемых по сети в рамках проверки подлинности, dotnet monitor также по умолчанию требует, чтобы базовый канал использовал HTTPS.
В preview4 конечные точки API /processes, /dump, /gcdump, /trace и /logs потребуют аутентификации. Конечная точка /metrics будет по-прежнему доступна без аутентификации на отдельно настроенном metricsUrl для парсинга с помощью внешних инструментов, таких как Prometheus.
В сценарии локального компьютера с уже установленным .NET SDK dotnet monitor по умолчанию будет использовать сертификат разработки ASP.NET Core HTTPS. При работе в Windows также включаем аутентификацию Windows для обеспечения безопасности в качестве альтернативы аутентификации токена API.
Некоторые шаги по безопасной настройке dotnet monitor были опущены для краткости в сообщении блога. Microsoft рекомендуют посмотреть официальную документацию для получения подробных инструкций.
Чтобы начать работу с dotnet monitor в производственной среде, вам потребуется сертификат SSL и токен API.
Создание сертификата SSL.
Чтобы настроить безопасную работу dotnet monitor, вам необходимо сгенерировать сертификат SSL с EKU для использования на сервере.
Если вы хотите создать еще один самозаверяющий сертификат для использования на другом компьютере, вы можете сделать это, вызвав инструмент dotnet dev-certs:
dotnet dev-certs https -export-path self-signed-certificate.pfx -p <your-cert-password>
Создание токена API
Для использования токена API необходимо сгенерировать 32-байтовый криптографически случайный секрет:
dotnet monitor generatekey
Результат должен быть примерно таким:
Authorization: MonitorApiKey H2O2yT1c9yLkbDnU9THxGSxje+RhGwhjjTGciRJ+cx8=
ApiKeyHash: B4D54269DB7D948A8C640DB65B46D2D705A516134DA61CD97E424AC08E5021ED
ApiKeyHashType: SHA256
После создания сертификата SSL и токена API вы можете настроить dotnet monitor для ответа на аутентифицированные HTTP-запросы по безопасному каналу TLS, используя следующую конфигурацию:
{
"ApiAuthentication": {
"ApiKeyHash": "<HASHED-TOKEN>",
"ApiKeyHashType": "SHA256"
},
"Kestrel": {
"Certificates": {
"Default":{
"Path": "<path-to-cert.pfx>",
"Password": "<your-cert-password>"
}
}
}
}
При использовании проверки подлинности Windows ваш браузер автоматически обрабатывает запрос проверки подлинности Windows. Если вы используете ключ API, вы должны указать его через заголовок авторизации в HTTP-запросах.
curl.exe -H "Authorization: MonitorApiKey H2O2yT1c9yLkbDnU9THxGSxje+RhGwhjjTGciRJ+cx8=" https://localhost:52323/processes
Roadmap
Microsoft планирует продолжить итерацию для dotnet monitor с ежемесячными обновлениями, пока не выпустят стабильную версию позже в этом году. dotnet monitor поддерживает .NET Core 3.1, а также .NET 5 и новее.
Источник