Running dotnet-counters in the background

[theaeolianmachine]

When trying to run dotnet-counters collect, it appears that it's only wired to run in the foreground, waiting for a key press to terminate. Otherwise, I've been getting the following error:

 Unhandled exception: System.InvalidOperationException: Cannot see if a key has been pressed when either application does not have a console or when console input has been redirected from a file. Try Console.In.Peek.
   at System.Console.get_KeyAvailable()
   at Microsoft.Diagnostics.Tools.Counters.CounterMonitor.Start() in /_/src/Tools/dotnet-counters/CounterMonitor.cs:line 265
   at Microsoft.Diagnostics.Tools.Counters.CounterMonitor.Collect(CancellationToken ct, List`1 counter_list, IConsole console, Int32 processId, Int32 refreshInterval, CountersExportFormat format, String output) in /_/src/Tools/dotnet-counters/CounterMonitor.cs:line 151
   at System.CommandLine.Invocation.CommandHandler.GetResultCodeAsync(Object value, InvocationContext context)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseParseErrorReporting>b__22_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c__DisplayClass8_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseSuggestDirective>b__7_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseParseDirective>b__6_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseHelp>b__20_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass4_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<RegisterWithDotnetSuggest>b__23_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c__DisplayClass5_0.<<UseExceptionHandler>b__0>d.MoveNext()

Is there any way to circumvent this? If not, is there a reason why this tool wasn't written with the ability to be run in the background? We would love to be able to have this run while our application is running as monitoring over a longer refresh interval.

[sywhang]

First of all, thanks for the valuable feedback!

As to why dotnet-counters wasn't written with the ability to run in the background, it was initially designed to be an interactive tool that users would "monitor" as the values are produced. Hence we initially only had the monitor command, and later added the collect command from a request.

To solve your problem, I have two proposed solutions:

1. Adding --duration option to the collect command that would let you specify how long to collect the metrics for, and if this was specified, do not launch the interactive console.

2. Adding --background option that just simply prevents the app from interacting with the console so that you can safely run it in background and bring it to foreground when you need. In this case you won't be able to use the "press p or q to pause or stop" feature, but you should still be able to stop dotnet-counters using ctrl-C.

I might end up adding both because both might be useful in different scenarios and they'd share large part of the code anyway in terms of the implementation side.

Let me know if that would solve your issue; otherwise, I'd be happy to discuss other options :)

[theaeolianmachine]

Thanks for the thoughtful response @sywhang. I think both would be great additions to the tool; I think for us, the --background flag is more useful; we have long running data-munging processes and we're looking to track them over time, where we might not know when exactly resources might get allocated all up or when lock contention takes place. That being said, I could definitely see the --duration flag being great for small snapshots in time, especially when issues are reproducible.