HealthIndicator always returning UNKNOWN status even if connected

Hey there !

I’m experiencing an issue with Spring Cloud Stream, the Kafka Stream Binder, and the auto configured Health Indicator for the Actuator.

Here is a sample minimal project that reproduces my issue. You’ll need a Kafka running (I’m working with an older 2.2.0 version, which constraints me to keep the Hoxton.SR8 and avoid Hoxton.SR9 and further) with two topics, IN and OUT. Just startup the application (after adapting the broker’s address/port of course), you may try to send it a message and see that it goes through without issue.

I’m then calling the Health endpoint, which returns me the following:

{
  "status": "UP",
  "components": {
    "binders": {
      "status": "UNKNOWN",
      "components": {
        "enricherKStreamBinder": {
          "status": "UNKNOWN"
        }
      }
    },
    "diskSpace": {
      "status": "UP",
      "details": {
        "total": 499963174912,
        "free": 344081379328,
        "threshold": 10485760,
        "exists": true
      }
    },
    "ping": {
      "status": "UP"
    }
  }
}

As the application is working as properly and can talk to Kafka, I would have expected to see a $.component.binders.status and $.component.binders.components.enricherKStreamBinder set to UP.

When debugging, I see that the code goes through org.springframework.cloud.stream.config.BindersHealthIndicatorAutoConfiguration.BindersHealthContributor#getContributor(), called with an empty Map as argument, causing it to return the static private static final HealthIndicator UNKNOWN = () -> {return Health.unknown().build();};. I naively would expect the map to not be empty there, but I’m no expert.

Hoping you can help, it may only be a configuration issue. Thanks a lot for your work !

And of course feel free to redirect me if i’m in the wrong repo, or anything.

[sobychacko]

@mborgraeve There was an issue in the way health indicators were configured when using an application with a multi-binder context. This is now addressed on both master and 3.0.x branches. Thanks for pointing out this issue.

[mborgraeve]

Ahh I see, no worries. SR8 is the spring-cloud-dependencies train version, Hoxton.SR8, it’s in the pom.xml (I corrected my initial post).