Giter VIP home page Giter VIP logo

dotnet-monitor's Introduction

.NET Monitor Repo

This repository contains the source code for dotnet-monitor, a diagnostic tool for capturing diagnostic artifacts in an operator-driven or automated manner.

Overview

Running a .NET application in diverse environments can make collecting diagnostics artifacts (e.g., logs, traces, process dumps) challenging. dotnet monitor is a tool that provides an unified way to collect these diagnostic artifacts regardless of where your application is run.

There are two different mechanisms for collection of these diagnostic artifacts:

  • An HTTP API for on demand collection of artifacts. You can call these API endpoints when you already know your application is experiencing an issue and you are interested in gathering more information.
  • Triggers for rule-based configuration for always-on collection of artifacts. You may configure rules to collect diagnostic artifacts when a desired condition is met, for example, collect a process dump when you have sustained high CPU.

Releases

See Releases for the release history.

Docs

Docs - Learn how to install, configure, and use dotnet-monitor.

Survey

Survey - Provide anonymous feedback on your experience using dotnet-monitor.

Building the Repository

See building instructions in our documentation directory.

Reporting security issues and security bugs

Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) [email protected]. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the Security TechCenter.

Also see info about related Microsoft .NET Core and ASP.NET Core Bug Bounty Program.

Useful Links

Blog Post: Announcing dotnet-monitor

See Videos and Tutorials for walkthroughs on how to use dotnet monitor.

.NET Foundation

.NET Monitor is a .NET Foundation project.

There are many .NET related projects on GitHub.

  • .NET home repo - links to 100s of .NET projects, from Microsoft and the community.
  • ASP.NET Core home - the best place to start learning about ASP.NET Core.

This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community. For more information, see the .NET Foundation Code of Conduct.

General .NET OSS discussions: .NET Foundation Discussions

License

.NET monitor is licensed under the MIT license.

dotnet-monitor's People

Contributors

adamsitnik avatar chrisnas avatar clguiman avatar cshung avatar davmason avatar dependabot[bot] avatar dotnet-maestro[bot] avatar github-actions[bot] avatar github-john-doe avatar hoyosjs avatar jander-msft avatar jorive avatar jpdurot avatar jwreford99 avatar kelltrick avatar kkeirstead avatar kouvel avatar mariohewardt avatar mattgal avatar mikem8361 avatar mustakimali avatar noahfalk avatar poppastring avatar schmittjoseph avatar sdmaclea avatar shirhatti avatar stephentoub avatar sywhang avatar vancem avatar wiktork avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dotnet-monitor's Issues

Generate process instance cookie for .NET Core 3.1 applications

The concept of the runtime instance cookie was not introduced until .NET 5. However, there may be enough information for .NET Core 3.1 applications to generate a stable identifier. For example:

  • Windows: Process ID + process start time encoded into a GUID
  • Linux/MacOS: Process ID + diagnostic pipe disambiguator encoded into GUID

Using the process start time on Windows should be allowable because only the same user (or elevated user) can read/write to the pipe and the process must be in the same process namespace as the diagnostic process; the diagnostic pipe likely does not work across two Windows containers because the pipe must be served from the host machine whereas the diagnostic pipe in 3.1 is served from the same environment as the application (the container) and the diagnostic pipe is only implemented as named pipe on Windows.

Enable on demand /metrics endpoint

Currently we only allow prometheus style metrics for a single process based a hieuristic. We should also allow metrics with a json like output for any process on demand.

We want to add support for ?frequency={}&duration={}

Use a Post style api for custom configuration such as custom metrics.

Generate ephemeral API keys

Allow the tool to generate ephemeral API keys to make local easier. Enabled with command line switch and log a warning when enabled. Log key information to console.

dotnet-monitor gives a confusing warning when querying the /logs endpoint without a PID

Description

dotnet-monitor gives a confusing warning when querying the /logs endpoint without a PID and there are multiple dotnet processes. Instead of giving a warning explaining that a PID needs to be specified via /logs/{PID} because there are multiple dotnet processes, dotnet-monitor gives the following warning:

warn: Microsoft.AspNetCore.Mvc.Infrastructure.DefaultOutputFormatterSelector[1]
      No output formatter was found for content type 'application/x-ndjson' to write the response.

This led me to believe there was something wrong with the Accept header, but I got the same warning no matter what I set the request header to:

~/dev$ curl -H "Accept: text/event-stream" http://localhost:52323/logs --no-buffer -v
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 52323 (#0)
> GET /logs HTTP/1.1
> Host: localhost:52323
> User-Agent: curl/7.58.0
> Accept: text/event-stream
>
< HTTP/1.1 406 Not Acceptable
< Date: Mon, 19 Oct 2020 22:46:16 GMT
< Server: Kestrel
< Content-Length: 0
<
* Connection #0 to host localhost left intact

Configuration

$ dotnet tool install -g dotnet-monitor --add-source https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet5-transport/nuget/v3/index.json --version 5.0.0-preview.*
You can invoke the tool using the following command: dotnet-monitor
Tool 'dotnet-monitor' (version '5.0.0-preview.20313.1') was successfully installed.
$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.100-rc.1.20379.10
 Commit:    a87335c7a8

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /home/halter73/dev/dotnet/aspnetcore/.dotnet/sdk/5.0.100-rc.1.20379.10/

Host (useful for support):
  Version: 6.0.0-alpha.1.20428.2
  Commit:  e6b9b48f34

.NET SDKs installed:
  3.1.300 [/home/halter73/dev/dotnet/aspnetcore/.dotnet/sdk]
  5.0.100-rc.1.20379.10 [/home/halter73/dev/dotnet/aspnetcore/.dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.0 [/home/halter73/dev/dotnet/aspnetcore/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.4 [/home/halter73/dev/dotnet/aspnetcore/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0-rc.1.20379.2 [/home/halter73/dev/dotnet/aspnetcore/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.0 [/home/halter73/dev/dotnet/aspnetcore/.dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.4 [/home/halter73/dev/dotnet/aspnetcore/.dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0-rc.1.20371.13 [/home/halter73/dev/dotnet/aspnetcore/.dotnet/shared/Microsoft.NETCore.App]

Dotnet-Monitor returns Http 401 on endpoints other than /metrics

Description

Currently Dotnet-Monitor is returning HTTP 401 Unauthorized for endpoints other than /metrics. We can't find documentation either on what the value the Authorization header should be set, if that is a requirement.

The following endpoints are affected.

/processes
/dump/{pid?}
/gcdump/{pid?}
/trace/{pid?}
/logs/{pid?}

For example:
Request:

GET /gcdump HTTP/1.1
Host: analytics.integration:52323
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1

Response:

HTTP/1.1 401 Unauthorized
Date: Tue, 02 Mar 2021 18:22:05 GMT
Server: Kestrel
Content-Length: 0

Configuration

The dotnet-monitor container configuration within AWS Fargate is as follows:
Image: mcr.microsoft.com/dotnet/nightly/monitor:latest

Entry point ["dotnet-monitor","collect"]
Command ["--urls","http://*:52323","--metricUrls","http://*:52325"]

Regression?

Yes, this worked in a previous build or release

Other information

Duplicate records cause prometheus to complain

Problem: After deployment in Docker environment, the prometheus scraper complains errors like:

Error on ingesting out-of-order samples
Error on ingesting samples with different value but same timestamp

curl 127.0.0.1:52323/metrics shows that there are duplicate records like:

$ curl 127.0.0.1:52323/metrics
# HELP systemruntime_cpu_usage_ratio CPU Usage
# TYPE systemruntime_cpu_usage_ratio gauge
systemruntime_cpu_usage_ratio 2 1599789718453
systemruntime_cpu_usage_ratio 2 1599789728453
systemruntime_cpu_usage_ratio 2 1599789738453
# HELP systemruntime_working_set_bytes Working Set
# TYPE systemruntime_working_set_bytes gauge
systemruntime_working_set_bytes 1017000000 1599789708454
systemruntime_working_set_bytes 1017000000 1599789718454
systemruntime_working_set_bytes 1017000000 1599789728456
# HELP systemruntime_gc_heap_size_bytes GC Heap Size
# TYPE systemruntime_gc_heap_size_bytes gauge
systemruntime_gc_heap_size_bytes 756000000 1599789708454
systemruntime_gc_heap_size_bytes 756000000 1599789718454
systemruntime_gc_heap_size_bytes 756000000 1599789728457
# HELP systemruntime_gen_0_gc_count Gen 0 GC Count
# TYPE systemruntime_gen_0_gc_count gauge
systemruntime_gen_0_gc_count 2 1599789708454
systemruntime_gen_0_gc_count 2 1599789718454
systemruntime_gen_0_gc_count 2 1599789728457
# HELP systemruntime_gen_1_gc_count Gen 1 GC Count
# TYPE systemruntime_gen_1_gc_count gauge
systemruntime_gen_1_gc_count 0 1599789708454
systemruntime_gen_1_gc_count 0 1599789718454
systemruntime_gen_1_gc_count 0 1599789728457
# HELP systemruntime_gen_2_gc_count Gen 2 GC Count
# TYPE systemruntime_gen_2_gc_count gauge
systemruntime_gen_2_gc_count 0 1599789708454
systemruntime_gen_2_gc_count 0 1599789718454
systemruntime_gen_2_gc_count 0 1599789728457

Why there are the duplicate metrics with different values?

My configuration is:

  webapi:
    volumes:
    - dotnet_monitor_data:/tmp

  dnm:
    image: mcr.microsoft.com/dotnet/nightly/monitor:5.0.0-preview.2-alpine
    volumes:
    - dotnet_monitor_data:/tmp
    ports:
    - 52323:52323
    command: --urls http://*:52323

Prometheus config

  - job_name: 'dotnet-mon'
    scrape_interval: 5s
    static_configs:
      - targets: ['172.18.0.1:52323'] # The IP is the host IP, accessed by the prometheus docker.

dotnet-monitor: Verify major version roll-forward to .NET 5 works

When dotnet-monitor was initially created, it was netcoreapp2.1 + ASP.NET Core 2.1 application. Support for netcoreapp3.1 + ASP.NET Core 3.1 was added via major version roll-forward along with several feature testing fixes. Now that dotnet-monitor is a netcoreapp3.1 application, check that major version roll-forward works for .NET 5 and ASP.NET 5 works correctly.

Change default behavior for unspecified process/uid.

Change the default heuristic as a configuration option rather than 'take first process'. 4xx error code if not configured and not specified.

Note this should also affect the process chosen by metrics (and we should consider a separate configuration for metrics process)

Only publish aka.ms latest versions from release branches

Alternative: Set the blob group prefix for the version and hash files to include the preview version to simulate channels. For example, if release branch is building 5.0.0 Preview 4 and main branch is building 5.0.0 Preview 5, then the blob group prefixes can be monitor5.0p4 and monitor5.0p5 respectively. This allows the release branch to stabilize the prior preview version and allows the main branch to continue development. The dotnet-docker repo can use 5.0p4 in nightly until the preview is published in its main and switch the nightly update to 5.0p5

Add async trace profile to dotnet-monitor

Should be used in combination with other data.

dotnet-trace collect -p --providers 'Microsoft-Diagnostics-DiagnosticSource:00000003:5:FilterAndPayloadSpecs="Microsoft.AspNetCore/Microsoft.AspNetCore.Hosting.HttpRequestIn.Start@Activity1Start:-TraceIdentifier;Request.Method;Request.Host;Request.Path;Request.QueryString\r\nMicrosoft.AspNetCore/Microsoft.AspNetCore.Hosting.HttpRequestIn.Stop@Activity1Stop:-TraceIdentifier;Response.StatusCode",System.Threading.Tasks.TplEventSource' 

Proposal: Inability to resolve process should return HTTP 404 or 300

When invoking an endpoint that contains a process ID or runtime instance cookie parameter, if dotnet-monitor is unable to resolve to a single process, the returned status codes should be:

  • 404 when a specific process was specified and it was not found or if the default process was assumed and it was not found.
  • 300 when there are more than one process that share the same specified parameters. The body of the response should list those processes in a structured manner. Bonus would be to provide the URLs for each process that would resolve uniquely to those processes for the specified operation.

dotnet-monitor should return more info for processes

Currently dotnet-monitor for /processes only returns the pid of the process.

I get that this has been mainly deisgned for containers scenarios when you have a single process with pid one, however given it supports more then one process, I think it should return more info to be able to identify the process you are interested to get info from.

Something like the ps command in the other tools would be great:

  • pid
  • process name
  • full exe path

https://github.com/dotnet/diagnostics/blob/05a3ae6f69e5dbb405079abeda88e0abec1328b6/src/Tools/Common/Commands/ProcessStatus.cs#L48

Support for printing thread stack traces and heaps composition in dotnet-monitor

We wrote a much simpler version of dotnet monitor that uses Microsoft.Diagnostics.Runtime to help with high level debugging of remote processes running in Kubernetes. Our implementation returns a stack trace of all threads in a given process, as well as the type composition of all heaps, ordered by object size. This is very convenient to get a feel for what a process is doing without having to download a dump and load it in dotnet analyze.

e.g. In our implementation, http://localhost:52323/dump returns something that looks like

--------------------------------------------------------------------
    STACK TRACE
--------------------------------------------------------------------
Thread - OS 00015910 - Managed 1:
  25aaf7e070 7ffb6af86278 [GCFrame]
  25aaf7e1b8 7ffb6af86278 [HelperMethodFrame_1OBJ]
  25aaf7e2e0 7ffbc9a43725 System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken)
  25aaf7e380 7ffbc9a43052 System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken)
  25aaf7e3f0 7ffbc9a42dcf System.Threading.Tasks.Task.InternalWaitCore(Int32, System.Threading.CancellationToken)
  25aaf7e470 7ffbc9a61604 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
  25aaf7e4a0 7ffbc9a4432d System.Runtime.CompilerServices.TaskAwaiter.GetResult()
  25aaf7e4d0 7ffc275d6585 Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(Microsoft.Extensions.Hosting.IHost)
  25aaf7e500 7ffb6a5a1790 WebApplication2.Program.Main(System.String[])
  25aaf7e788 7ffbca0c6103 [GCFrame]
  25aaf7ed30 7ffbca0c6103 [GCFrame]

Thread - OS 00002a90 - Managed 2:
  25abbffa00 7ffb6af86278 [DebuggerU2MCatchHandlerFrame]

Thread - OS 00008898 - Managed 4:
  25ac37ed18 7ffb6af86278 [HelperMethodFrame]
  25ac37ee10 7ffbc9b2b91b System.Threading.Thread.Sleep(Int32)
  25ac37ee40 7ffb6a5a4535 WebApplication2.Program.DoWork()
  25ac37eeb0 7ffb6a5a40d1 WebApplication2.Program+<>c.<Main>b__0_0()
  25ac37eee0 7ffbc9a47bd3 System.Threading.Tasks.Task.InnerInvoke()
  25ac37ef20 7ffbc9a47b82 System.Threading.Tasks.Task+<>c.<.cctor>b__274_0(System.Object)
  25ac37ef50 7ffbc9a47b02 System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
  25ac37efa0 7ffbc9a477d7 System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef, System.Threading.Thread)
  25ac37f040 7ffbc9a476b3 System.Threading.Tasks.Task.ExecuteEntryUnsafe(System.Threading.Thread)
  25ac37f080 7ffbc9a4764b System.Threading.Tasks.Task.ExecuteFromThreadPool(System.Threading.Thread)
  25ac37f0b0 7ffbc9a4723c System.Threading.ThreadPoolWorkQueue.Dispatch()
  25ac37f160 7ffbc9a4706b System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
  25ac37f570 7ffbca0c6103 [DebuggerU2MCatchHandlerFrame]

[...]

--------------------------------------------------------------------
    HEAPS
--------------------------------------------------------------------

--------------------------------------------------------------------
GENERATION 0
System.String - 764954
System.Byte[] - 735445
System.Security.Cryptography.Oid - 735360
System.Char[] - 419616
System.Security.Cryptography.X509Certificates.X509Extension[] - 201128
System.Security.Cryptography.X509Certificates.X509Extension - 193440
[...]

--------------------------------------------------------------------
GENERATION 1
Free - 288

--------------------------------------------------------------------
GENERATION 2
Free - 768

Would it be feasible or would you be interested in supporting a similar feature? Maybe in two different endpoints /stacktrace and /heap?

Proposal: Allow process selection by process name

Current support for process selection in the HTTP API allows for selection by process ID and runtime instance identifier. Add support for selecting by process name. This may not be useful for processes hosted by the default host (dotnet) but is useful for application hosts that are created when building the application e.g. "WebApplication1.exe"

dotnet-monitor: Allow disabling endpoints

Background and Motivation

Some of the information exposed by dotnet-monitor is highly sensitive, such as memory dumps. So we'd like the option to disable them.

Proposed Feature

Command line arguments to enable/disable each endpoint.

Usage Examples

dotnet-monitor --enable-dump false

Request for always-on/low overhead collection mode

Background and Motivation

I have a program that utilizes a lot of event source tracing. Currently we have a custom tool on Windows that listens to these events using ETW and logs them to rotated files (every 15 min or after a couple of GB). We'd like a cross-platform replacement.

Proposed Feature

dotnet-monitor to have a mode that always collects the configured event sources. Perhaps it could launch without a web server and accept an EventPipeConfiguration from a file. Also accept a RollingFileSystemEgressProvider that provides a way to configure the max output file size, max output duration, and max files to keep.

Usage Examples

dotnet monitor log config.json

config.json:

{ "EventPipeConfiguration":
  {"Providers": [{"Name":"Microsoft-Windows-DotNETRuntime","Keywords":"32769","EventLevel":4,"Arguments":null}]
  "RequestRundown":false,
  "BufferSizeInMB":256
  }
  "EgressProviders": [
{"Type": "RollingFileSystem", "DirectoryPath": "...", "IntermediateDirectory": "..."}]
}

Create release branch

Create release branch from which dotnet-monitor 5.0 will ship previews, GA, and servicing releases.

UI for dotnet-monitor

Proposal

Integrate client application developed to interact with dotnet-monitor endpoints as optional in-built tool.

Repository: https://github.com/SachiraChin/dotnet-monitor-ui

Why?

While going though endpoints of REST endpoints provided by this tool, I found that there are lots features which are not easily accessible for end user without manually enter values in the URL. The POST endpoint for trace is completely inaccessible for user without using different tool.

For an user who wants to access this tool, it is much easier if tool itself provides an interface to interact with APIs. Further more, with an UI, user will be able to understand parameters without having need to go through documentation.

Solution

I have already developed a client application (https://github.com/SachiraChin/dotnet-monitor-ui) to interact with endpoints provided by dotnet-monitor. But as I discussed in dotnet/diagnostics#1346, this application will not work as an external tool without having CORS enabled in app itself. But if we move client application as an endpoint available in tool itself, CORS rules are not required for it to function.

This application is developed using Angular 10 and Angular Material 10. There are no other dependencies were added to this tool. Currently after production build, static files has 739 KB in total size, but I believe this can be further reduced.

Integration

Since APIs for dotnet-monitor built on top of ASP.NET Core IWebHostBuilder, we can use Microsoft.AspNetCore.SpaServices to serve static files as a web application from app itself. If needed, building web-ui application can be integrated to build of dotnet-monitor itself, but this has to managed properly due to the significant delays which can be caused on each time dotnet-monitor debugged from Visual Studio.

Conclusion

If the team would like to consider this integration, I can prepare proof-of-concept with the dotnet-monitor tool to show how it will work in the app. Thank you!

container-to-container dump retrieval

dotnet-monitor always requests that memory dumps be written to $TMPDIR. In the .net5.0 container-to-container configuration, $TMPDIR is not guaranteed to be the shared file mount. In that case, dotnet-monitor needs a solution for specifying where the dump should be created (from the target application's perspective). The location of the dump is sent via the Diagnostic Port to the target process. The requested dump location is resolved by the target application. If the shared file mount is not at the same path in both the target container and the dotnet-monitor container, then dotnet-monitor won't be able to access the dump. dotnet-monitor needs to be made aware of the relative path difference of the shared file mount between the two containers. This becomes complex if there are more than 2 containers in a Pod and each container has mounted the shared file mount to a different path.

CC @wiktork @noahfalk @jander-msft @shirhatti

Add /info endpoint

This should provide dotnet-monitor version, and possibly configuration (w/o PII)

  • Listening mode (+ port)
  • other configuration knobs

Announcement: dotnet monitor will require authentication

dotnet-monitor has been updated in preview4 to require authentication in the default configuration to access the following endpoints:

  • /processes
  • /dump/{pid?}
  • /gcdump/{pid?}
  • /trace/{pid?}
  • /logs/{pid?}

The /metrics endpoint will still be available without authentication on a separately configured metricsUrl.

To protect the API keys sent over the wire as part of authentication, dotnet-monitor will also default to requiring that the underlying channel uses HTTPS.

How to configure dotnet-monitor for authentication?

Step 1: Generate an SSL certificate

To configure dotnet-monitor to run securely, you will need to generate an SSL certificate with an EKU for server usage. You can either request this certificate from your certificate authority or generate a self-signed certificate.

If you are running on a development machine with the .NET SDK installed, dotnet-monitor will default to using the ASP.NET Core HTTPS development certificate. If you wish to generate another self-signed certificate for use on another machine you may do so by invoking the dotnet dev-certs tool.

dotnet dev-certs https -export-path self-signed-certificate.pfx -p <your-password>

Step 2: Pick an authentication scheme

dotnet-monitorsupports both Windows Authentication (Negotiate) and API token-based authentication. Authenticating requests ensure that lower privileged processes aren't allow to use this API to exfiltrate sensitive diagnostic artifacts that you haven't explicitly granted access to.

We recommend using Windows Authentication if you're running dotnet-monitor as a local development tool on a Windows machine. For all other environments, we recommend using API token authentication.

Windows authentication doesn't require explicit configuration. When available dotnet-monitor will authorize any user authenticated as the same user that started the dotnet-monitor process. You can skip the remaining steps if you're using Windows authentication

Step 3: Generate an API token and hashed API token

You need to create a 32-bit cryptographically random secret for use as an API token

$rng = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
$secret = [byte[]]::new(32)
$rng.GetBytes($secret)
$API_TOKEN = [Convert]::ToBase64String($secret)
"Authorization: Bearer $API_TOKEN"

$secretStream = [System.IO.MemoryStream]::new($secret)
$HASHED_TOKEN = (Get-FileHash -Algorithm SHA256 -InputStream $secretStream).Hash
$rng.Dispose()

Write-Output "ApiKeyHash: $HASHED_TOKEN"
Write-Output "ApiKeyHashType: SHA256"

OR

API_TOKEN=`openssl rand -base64 32`
echo "Authorization: MonitorApiKey $API_TOKEN"

HASHED_TOKEN=`$API_TOKEN | base64 -d | sha256sum`
echo "ApiKeyHash: $HASHED_TOKEN"
echo "ApiKeyHashType: SHA256"

OR

>dotnet monitor generatekey

NOTE: The generated API token should be secured at rest. We recommend using a tool such as a password manager to save it.

Step 4: Save these settings

If you're running on Windows, you can save these settings to %USERPROFILE%\.dotnet-monitor\settings.json. If you're on other operating systems, you can save this file to $XDG_CONFIG_HOME/dotnet-monitor/settings.json.

NOTE: If $XDG_CONFIG_HOME isn't defined, dotnet-monitor will fall back to looking at $HOME/.config/dotnet-monitor/settings.json

{
  "ApiAuthentication": {
    "ApiKeyHash": "<HASHED-TOKEN>",
    "ApiKeyHashType": "SHA256"
  },
  "Kestrel": {
    "Certificates": {
      "Default":{
        "Path": "<path-to-cert.pfx>",
        "Password": "<your-cert-password>"
      }
    }
  }
}

Alternatively, you can use environment variables to specify the configuration

DotnetMonitor_ApiAuthentication__ApiKeyHash="<HASHED-TOKEN>"
DotnetMonitor_ApiAuthentication__ApiKeyHashType="SHA256"
DotnetMonitor_Kestrel__Certificates__Default__Password="<your-cert-password"
DotnetMonitor_Kestrel__Certificates__Default__Path="<path-to-cert.pfx>"

NOTE: If you're using environment variables to configure the API Key hash, you will not be able to the API Key without restarting the process

If you're running in Kubernetes, we recommend creating secrets and mounting them into container via a deployment manifest

Creating secrets:

kubectl create secret generic customcert \
	--from-file=customcert.pfx=<path-to-certificate> \
	--from-literal=pass=<your-cert-password> \
	--dry-run=client -o yaml \
	| kubectl apply -f -
	
kubectl create secret generic apikey \
	--from-literal=ApiAuthentication__ApiKeyHash=$hash \
	--dry-run=client -o yaml \
	| kubectl apply -f -

Deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dotnetmonitorsample
  labels:
    app: dotnetmonitorsample
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dotnetmonitorsample
  template:
    metadata:
      labels:
        app: dotnetmonitorsample
    spec:
      volumes:
      - name: sharedtmp
        emptyDir: {}
      - name: apikey
        secret:
          secretName: apikey
      - name: customcert
        secret:
          secretName: customcert
      containers:
      - name: dotnetmonitorsample
        imagePullPolicy: Always
        image: mcr.microsoft.com/dotnet/samples:aspnetapp
        resources:
          limits:
            memory: "256Mi"
            cpu: "500m"
        volumeMounts:
          - name: sharedtmp
            mountPath: /tmp
      - name: dotnetmonitoragent
        env:
          - name: ASPNETCORE_Kestrel__Certificates__Default__Password
            valueFrom:
              secretKeyRef:
                name: customcert
                key: pass
          - name: ASPNETCORE_Kestrel__Certificates__Default__Path
            value: /etc/aspnet/customcert/customcert.pfx
        image: mcr.microsoft.com/dotnet/nightly/monitor:5.0.0-preview.4
        imagePullPolicy: Always
        ports:
          - containerPort: 52325
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        volumeMounts:
          - name: sharedtmp
            mountPath: /tmp
          - name: customcert
            mountPath: /etc/aspnet/customcert
          - name: apikey
            mountPath: /etc/dotnet-monitor

How to use dotnet-monitor for authentication?

If running on Windows with Windows authentication, the browser experience will work as it previously did. The browser handle the Windows authentication challenge.

If you using API Token auth, you will need to specify the token via the authorization header

curl.exe -H "Authorization: MonitorApiKey HdFb8OPkE0Dc5hpu0kAxA7hhNguAah9SNUFftlP2Dk0=" https://localhost:52323/processes

OR

curl -H "Authorization: MonitorApiKey HdFb8OPkE0Dc5hpu0kAxA7hhNguAah9SNUFftlP2Dk0=" https://localhost:52323/processes

Make trace profile names consistent between dotnet-monitor and dotnet-trace

From @noahfalk

Feedback on dotnet-monitor itself: 'Http' could also easily be interpretted as the http client code in the BCL rather than the Http server code in Kestrel. We may want to consider a less generic name.
We should also look at how names here align with names in dotnet-trace --profile. I don't think we want two different sets of named policies.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.