Health, Metrics and Status information is not available When Sidekick Enabled=false

[fbridger]

How can I use Sidekick just for monitoring and metrics using an existing Dapr Sidecar?

I would like to be able to use Dapr Sidekick for health, status and metrics only but avoid launching a Sidecar process.

In other words, is there an option that I can use to just get everything Sidekick offers except for launching the Sidecar process?

Current behaviour

When setting DaprSidekick.Enabled = false all functionality gets disabled (HealthCheck, Dapr Status, Metrics) appsettings.json

{
  "DaprSidekick": {
    "Enabled": false
  }
}

Health API

{
  "status": "Healthy",
  "totalDuration": "00:00:00.0014793",
  "entries": {
    "dapr-sidecar": {
      "data": {

      },
      "description": "Dapr process 'daprd' not available, status is Disabled",
      "duration": "00:00:00.0000316",
      "status": "Healthy",
      "tags": [

      ]
    }
  }
}

Dapr Status

{
  "process": {
    "name": "daprd",
    "status": "Disabled",
    "isRunning": false,
    "isAttached": false,
    "description": "Dapr process 'daprd' not available, status is Disabled"
  }
}

[fbridger]

Found my own response in the README => Non-Windows Platforms

Will not detect existing daprd instance for same AppId and Port

[ewilansky]

Healthcheck and metrics appear to be working for me with dapr 1.3 and the sidekick dapr runtime disabled for a c# dotnet 6 app running in k8. Are you running your solution on OS X or Linux? What kind of application is it? I can provide more detail on my app config once I hear back from you.

[fbridger]

I am running it in a Windows 10 x64 machine. It is an ASP.Net Core app using .Net 5. I am running all of them in a linux docker container using docker compose.

Should this be working?

[badgeratu]

The top-level Enabled property was primarily added to support container deployment scenarios, where you'd want to use Sidekick to simplify lifetime management of daprd for local development, but would be deploying to the K8S platform (or similar) where you'd want Sidekick to get completely out of the way and let K8S handle all sidecar health checks/metrics/lifetime management using the standard injectors and configuration prepared/documented by the Dapr team. In this scenario you wouldn't want to aggregate the sidecar health/metric endpoints into your application. See https://github.com/man-group/dapr-sidekick-dotnet/issues/9.

The other scenario that might apply here is if you launch daprd ahead of time (say using the Dapr CLI) with the same app-id and app-port values as your application is configured with. When you launch your application (and assuming you haven't set the Sidekick Enabled property to false) Sidekick will automatically attempt to detect that existing daprd running process on that machine and "attach" to it as if it had launched the process itself, making the health/metrics available within the application. This only works on Windows though, as .NET doesn't have platform support for determining command-line args from a process so you have to use system native APIs and we only knew the ones for Windows :)

[ewilansky]

Thanks for these important guidelines, @badgeratu. After responding to @fbridger, I see that we are getting health metrics using the MapHealthChecks middleware in Microsoft.AspNetCore.Routing.IEndpointRouteBuilder, so not through Sidekick. Also, I've confirmed @fbridger's finding on the status endpoint returning daprd disabled. As for dapr metrics we are able to get that through the MapDaprMetrics middleware in Microsoft.AspNetCore.Routing.IEndpointRouteBuilder. I realize this has nothing to do directly with Sidekick.

I was unclear on whether Sidekick (beyond the daprd runtime capability) could be useful for typical k8 deployments where daprd runs as a sidecar container in a pod that also hosts its associated application. Also, it sounds like Sidekick isn't useful for non-Windows platforms. Is that right? If so, it would be good if this were clearly stated in the documentation. If I'm wrong, can you clarify exactly what Sidekick features are available in Linux (on metal, in containers or in k8) and running on OS X?

[badgeratu]

I'd say Sidekick is almost as useful on non-Windows platforms as it is on Windows ones, the only scenario it doesn't support AFAIK on non-Windows is the "attach" feature, which is already documented as you pointed out earlier in this thread. In all cases though - WIndows or non-Windows - it doesn't make sense to enable Sidekick in a K8S or container environment where daprd and the application are not running on the same OS/namespace (such as in a pod), and the Dapr team already provide solutions for that. The main value of Sidekick in those scenarios is it allows you to simplify your local development process while getting out of the way when you do an actual K8S deployment.

Sidekick was created to fill a gap between the scenarios envisioned by the Dapr developers of either deploying to a K8S environment or launching Dapr standalone from the CLI. Sidekick provides value for standalone/non-containerized workloads where you would otherwise have to manually launch and manage daprd or provide some other bootstrap techniques, For all other scenarios, the Dapr team have already done a great job of providing appropriate tooling and documentation.