Diagnostics: User Story: Expose .NET Perf Counters in the local machine scenario

[tommcdon]

As a developer for a .Net Core app, I can see metrics egressed to a console UI or file, so that I can quickly assess if I need to do further performance investigation
(dotnet counters)

Work items:

• [x] Named pipe egress (as opposed to file) for EventPipe - https://github.com/dotnet/coreclr/issues/21027
• [x] Design the command-line syntax #109
• [x] Design the dotnet-monitor UI (whatever remaining UI portions weren't already covered in #109)
• [x] Implement dotnet-monitor
• [x] Merge Microsoft/perfview#915
• [x] Publish traceevent package
• [x] Upload dotnet-counters to package server
• [x] Document usage instructions in https://github.com/dotnet/diagnostics/tree/master/documentation
• [x] Implement remaining coreclr counters https://github.com/dotnet/coreclr/issues/20372 [Post-preview5]

[shirhatti]

Work items:

• Produce counters (and aggregation in the runtime)- https://github.com/dotnet/diagnostics/issues/83
• Named pipe egress (as opposed to file) for EventPipe @jorive
• Design the dotnet-monitor UI

[davidfowl]

@shirhatti We're thinking it should be part of dotnet-collect since all of the flags and infrastructure would likely be the same and it should have a "top" like interface.

We'll need to decide what things we show (aggregations and counters)

[shirhatti]

    dotnet-collect - Collect diagnostic information from a .NET process

SYNOPSIS

    dotnet collect [-v, --version] [-h, --help]
                   [-p, --process-id]
                   [-o, --output]
                   <command> [<args>]

OPTIONS

    -v, --version
        Prints the version of the dotnet collect utility.

    -h, --help
        Prints the synopsis and a list of the most commonly used commands. 

    -p, --process-id <PROCESS_ID>
        The process id of the process you want to collect diagnostic information
        from.

    -o, --output <OUTPUT_DIRECTORY>
        The output directory where this diagnostic data should be written to.


================================================================================

NAME

    dotnet-collect-dump - Collect a process dump 

SYNOPSIS

    dotnet collect dump [-h, --help]

DESCRIPTION

    On Windows, dotnet-collect-dump collects a Windows minidump.
    On Linux, dotnet-collect-dump collects a core dump using createdump.

OPTIONS

    -h, --help
        Prints the synopsis and a list of the most commonly used commands. 

================================================================================

NAME

    dotnet-collect-trace - Collect a trace

SYNOPSIS

    dotnet collect dump [-h, --help]
                        [--provider]
                        [--buffer]


OPTIONS

    -h, --help
        Prints the synopsis and a list of the most commonly used commands.

    --provider <PROVIDER_SPEC>
        An EventPipe provider to enable.
        A string in the form '<provider name>:<keywords>:<level>'. 

    --buffer <BUFFER_SIZE_IN_MB>
        The size of the in-memory circular buffer in megabytes.

================================================================================

NAME

    dotnet-monitor

SYNOPSIS

    dotnet monitor [-v, --version] [-h, --help]
                   [--provider]
                   [--buffer]


OPTIONS

    -v, --version
        Prints the version of the dotnet collect utility.

    -h, --help
        Prints the synopsis and a list of the most commonly used commands.

    --provider <PROVIDER_SPEC>
        An EventPipe provider to enable.
        A string in the form '<provider name>:<keywords>:<level>'. 

    --buffer <BUFFER_SIZE_IN_MB>
        The size of the in-memory circular buffer in megabytes.

================================================================================

[noahfalk]

I just captured some of the raw design related comments here into a doc #107

[noahfalk]

I created issue #109 to explicitly capture our console UI design work for the set of scenarios we're after. Although there are several separate scenarios, I think we are going to want a fair amount of shared design work to ensure we build something that has consistent look and feel. I'd suggest we do further design commentary in #109.

[noahfalk]

I'm going to reopen this. We are close but the final work to complete the scenario hasn't been commited yet and there are no instructions written in https://github.com/dotnet/diagnostics/tree/master/documentation.

[davidfowl]

I tried this and couldn’t get it to work, guessing this is why

[sywhang]

Yes, what you saw during the demo is from my own branch which depends on https://github.com/Microsoft/perfview/pull/915 getting merged. Once this gets merged in, I'll merge in my changes along with the documentation.

[sywhang]

Documentation is available in https://github.com/dotnet/diagnostics/blob/master/src/Tools/dotnet-counters/README.md.

I think we can close this as there is a separate issue for tracking additional counters to be added to the runtime - https://github.com/dotnet/coreclr/issues/20372.

[noahfalk]

Can we follow the pattern all the other tools were using and put the docs here: https://github.com/dotnet/diagnostics/tree/master/documentation
Example: https://github.com/dotnet/diagnostics/blob/master/documentation/dotnet-trace-instructions.md

You could link from the README in the source to the docs folder.

[sywhang]

Done - https://github.com/dotnet/diagnostics/pull/246

[noahfalk]

I think its nice to have these user story items that don't get marked done until we've completed the E2E (which includes adding the remaining 3.0 counters) but I moved this out of Preview5. Congrats we now have 0 Preview5 items 👍

[tommcdon]

Removing providing managed APIs for our canonical set of runtime performance counter #83 from this User Story and resolving.