Answers: <p>Might be a bit late, but I had a similar issue with running the docker compose setup mentioned here: <a href="https://github.com/dotnet/dotnet-monitor/blob/main/documentation/docker-compose.md" rel="nofollow noreferrer">https://github.com/dotnet/dotnet-monitor/blob/main/documentation/docker-compose.md</a></p>
  <p>Running the example 1:1 on my local machine works fine. But using my own dotnet application, this setup caused for me a very similar issue: /processes showing a process:</p>
  <pre><code>[
      {
          &quot;pid&quot;: 7,
          &quot;uid&quot;: &quot;3ae9c821-830a-4c8c-a684-3423dc7eae44&quot;,
          &quot;name&quot;: &quot;dotnet&quot;,
          &quot;isDefault&quot;: false
      }
  ]
  </code></pre>
  <p>But <code>isDefault</code> is false, so the endpoints /logs etc. all provided no data.</p>
  <p>It's mentioned nowhere in the documentation, but as I did some digging into the docker images of the monitor (<a href="https://github.com/dotnet/dotnet-docker/blob/main/src/monitor-base/8.0/ubuntu-chiseled/amd64/Dockerfile" rel="nofollow noreferrer">https://github.com/dotnet/dotnet-docker/blob/main/src/monitor-base/8.0/ubuntu-chiseled/amd64/Dockerfile</a>), I noticed there are ENV variables explicitly only allowing processes with ID 1 (but in my application it was 7).
  So I went on and changed the ENV variables to:</p>
  <pre><code>    DefaultProcess__Filters__0__Key=ProcessId \
      DefaultProcess__Filters__0__Value=7 \
  </code></pre>
  <p>After this change, everything worked as expected.</p>
  <p>Not sure though whether the process ID is something to rely on... Would be happy about a more robust solution here.</p>
  
Answers: CC BY-SA 4.0
Answers: 2024-11-25T09:49:31.750Z
Answers: 2024-11-25T09:49:31.750Z
Answers: TheDodo
Body: <p>I am having a weird issue with dotnet-monitor.
  One of our developers asked me to prepare in our AKS cluster a dotnet-monitor pod to assess memory counsumption issues with our application. I went with the first hit in Google, which was <a href="https://devblogs.microsoft.com/dotnet/introducing-dotnet-monitor/" rel="nofollow noreferrer">https://devblogs.microsoft.com/dotnet/introducing-dotnet-monitor/</a> and it worked beautifully.</p>
  <p>So I tried the newest option image mcr.microsoft.com/dotnet/monitor. Our application is already .NET 8+.</p>
  <p>The configuration for the whole pod is fsGroup and runAsUser 999. The connection mode is Listen, DefaultSharedPath is set to /diag on the monitor, and the only change to the application configuration is setting DiagnosticPorts to /diag/dotnet-monitor.sock. Basically, the out-of-box config suggested in the git (<a href="https://github.com/dotnet/dotnet-monitor/blob/main/documentation/kubernetes.md" rel="nofollow noreferrer">https://github.com/dotnet/dotnet-monitor/blob/main/documentation/kubernetes.md</a> following example 8+), except setting fsGroup and runAsUser (if I don't, the application never starts - stuck waiting for connection)</p>
  <p>If I go for /processes, I get all the usual information about our process (matching what I get from 5.0.0 preview). if I go to /info, I get the configuration information just fine.
  However, if I try to do a /gcdump, for example, I get that it was &quot;Unable to discover a target process&quot;. If I do a /gcdump/14 (our pid), it gives me 404.</p>
  <p>Any tips?
  Thanks, as always.</p>
  
Tags: <azure-devops><azure-kubernetes-service><dotnet>
Title: dotnet-monitor v5 works ok but v8 can't find processes in AKS Kubernetes
UserDisplayName: Shiunbird
ThreadText: # dotnet-monitor v5 works ok but v8 can't find processes in AKS Kubernetes
  
  (Asked by: username_0 on 2024-04-30)
  
  I am having a weird issue with dotnet-monitor.
  One of our developers asked me to prepare in our AKS cluster a dotnet-monitor pod to assess memory counsumption issues with our application. I went with the first hit in Google, which was <https://devblogs.microsoft.com/dotnet/introducing-dotnet-monitor/> and it worked beautifully.
  
  So I tried the newest option image mcr.microsoft.com/dotnet/monitor. Our application is already .NET 8+.
  
  The configuration for the whole pod is fsGroup and runAsUser 999. The connection mode is Listen, DefaultSharedPath is set to /diag on the monitor, and the only change to the application configuration is setting DiagnosticPorts to /diag/dotnet-monitor.sock. Basically, the out-of-box config suggested in the git (<https://github.com/dotnet/dotnet-monitor/blob/main/documentation/kubernetes.md> following example 8+), except setting fsGroup and runAsUser (if I don't, the application never starts - stuck waiting for connection)
  
  If I go for /processes, I get all the usual information about our process (matching what I get from 5.0.0 preview). if I go to /info, I get the configuration information just fine.
  However, if I try to do a /gcdump, for example, I get that it was "Unable to discover a target process". If I do a /gcdump/14 (our pid), it gives me 404.
  
  Any tips?
  Thanks, as always.
  
  **Tags:** azure-devops, azure-kubernetes-service, dotnet
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-11-25. Score: 0
  
  Might be a bit late, but I had a similar issue with running the docker compose setup mentioned here: <https://github.com/dotnet/dotnet-monitor/blob/main/documentation/docker-compose.md>
  
  Running the example 1:1 on my local machine works fine. But using my own dotnet application, this setup caused for me a very similar issue: /processes showing a process:
  
  ```
  [
      {
          "pid": 7,
          "uid": "3ae9c821-830a-4c8c-a684-3423dc7eae44",
          "name": "dotnet",
          "isDefault": false
      }
  ]
  
  ```
  
  But `isDefault` is false, so the endpoints /logs etc. all provided no data.
  
  It's mentioned nowhere in the documentation, but as I did some digging into the docker images of the monitor (<https://github.com/dotnet/dotnet-docker/blob/main/src/monitor-base/8.0/ubuntu-chiseled/amd64/Dockerfile>), I noticed there are ENV variables explicitly only allowing processes with ID 1 (but in my application it was 7).
  So I went on and changed the ENV variables to:
  
  ```
      DefaultProcess__Filters__0__Key=ProcessId \
      DefaultProcess__Filters__0__Value=7 \
  
  ```
  
  After this change, everything worked as expected.
  
  Not sure though whether the process ID is something to rely on... Would be happy about a more robust solution here.
  
  
  ---
  
  