Record ThreadPool.PendingWorkItemCount Property

[darraghjones]

This seems like a good candidate to record.

https://docs.microsoft.com/en-us/dotnet/api/system.threading.threadpool.pendingworkitemcount?view=netcore-3.1

In fact, running dotnet counters monitor --process-id 123 gives the results below...of which ThreadPool Queue Length is one.

Press p to pause, r to resume, q to quit.
    Status: Running

[System.Runtime]
    % Time in GC since last GC (%)                         0
    Allocation Rate / 1 sec (B)                       66,480
    CPU Usage (%)                                          0
    Exception Count / 1 sec                                0
    GC Heap Size (MB)                                    234
    Gen 0 GC Count / 60 sec                                0
    Gen 0 Size (B)                               200,991,744
    Gen 1 GC Count / 60 sec                                0
    Gen 1 Size (B)                                   385,440
    Gen 2 GC Count / 60 sec                                0
    Gen 2 Size (B)                               210,807,272
    LOH Size (B)                                  74,140,000
    Monitor Lock Contention Count / 1 sec                  0
    Number of Active Timers                              314
    Number of Assemblies Loaded                          272
    ThreadPool Completed Work Item Count / 1 sec          38
    ThreadPool Queue Length                                0
    ThreadPool Thread Count                                9
    Working Set (MB)                                     242

[djluck]

This metric is currently available just indirectly- you could calculate it via dotnet_threadpool_scheduled_total - dotnet_threadpool_scheduling_delay_seconds_count. Really I need to re-work the whole thread pool stats collector- I found a pretty serious bug that meant latency wasn't correctly captured. But I think explicitly including it wouldn't be such a bad idea.