<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>

CC BY-SA 4.0
2024-11-25T09:49:31.750Z
2024-11-25T09:49:31.750Z
TheDodo
<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>

<azure-devops><azure-kubernetes-service><dotnet>
dotnet-monitor v5 works ok but v8 can't find processes in AKS Kubernetes
Shiunbird
# 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.


---

