5

I have read a few documentations and figured out how to set up readiness and liveness endpoints with Actuator, like this one. But I am not able to figure out how to set-up the endpoint for the 'startup' probe.

My application yml:

management:
  endpoints:
    web:
      exposure:
        include: "*"
  endpoint:
    health:
      show-details: "ALWAYS"
      group:
        readiness.include: readinessProbe, dataStream
        startup.include: readinessProbe, dataStream

My deployment config:

  livenessProbe:
    httpGet:
      path: "/actuator/health/liveness"
      port: "http"
    initialDelaySeconds: 600
    periodSeconds: 15
  readinessProbe:
    httpGet:
      path: "/actuator/health/readiness"
      port: "http"
    periodSeconds: 30
    failureThreshold: 15
  startupProbe:
    httpGet:
      path: "/actuator/health/startup"
      port: "http"
    initialDelaySeconds: 150
    periodSeconds: 10
    failureThreshold: 30

The actuator doesn't seem to provide the URL for the 'startup' probe, or in other words, http://localhost:8080/actuator/health/startup doesn't work. How can I set it up?

rishav
  • 441
  • 9
  • 27

1 Answers1

8

Spring boot does not expose a separate endpoint for the startup probe. You could use the liveness probe for this use case as well. The reasoning to have a different probe in kubernetes is to enable a long timeout for the initial startup of the application, which might take some time. After the first successful startup probe call the liveness probe takes over, having reduced timeout values to quickly detect a failure and restart the application.

Thomas
  • 11,272
  • 2
  • 24
  • 40
  • 2
    I was considering to map it to a readyness probe instead of the liveness. My app takes somewhat time to load a large set of configurations. So while it is loading I fire the events LivenessState.CORRECT and ReadinessState.REFUSING_TRAFFIC, when the load is complete I finally fire ReadinessState.ACCEPTING_TRAFFIC. So the app reports to be accepting requests only when all the configuration is ready. – user1708042 Sep 09 '21 at 06:41
  • 1
    I don't see what situation that would improve. In my perspective the startup probe provides a different configuration for the liveness probe for the startup period of the application to prevent premature container restarts. Even if running it will not receive traffic until the readinessprobe signals that it is ok. – Thomas Sep 09 '21 at 07:24
  • 1
    The load time is somewhat unpredictable so when used in Kubernetes I wanted to avoid that a long standing BROKEN state could trigger an unneeded restart of the pod. On the other side if the problem is real and we get in BROKEN state I don't want to extend the time Kubernbetes waits before to try a restart. – user1708042 Sep 09 '21 at 10:25
  • 1
    That is why you can use a short polling interval and long timeout for the startup probe, afterwards you can use shorter timeouts and perhaps longer interval for the liveness probe. – Thomas Sep 09 '21 at 10:31
  • I concur with the idea of using the readiness probe - the readiness probe is designed to check that all downstream dependencies are OK especially on startup. `an application might need to load large data or configuration files during startup, or depend on external services after startup. In such cases, you don't want to kill the application, but you don't want to send it requests either. Kubernetes provides readiness probes to detect and mitigate these situations` https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes – kellyfj May 06 '22 at 11:18