You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, liveness and readiness probes are configured with initialDelaySeconds set to 30s which is fairly high value. However, in case of the container crash, Pyroscope server may need even longer time to recover the storage (it is hard to estimate the procedure duration, but a minute or two is what we may expect).
A proper solution would be to separate implementations of the readiness and liveness checks:
liveness probe starts serving requests in the very beginning of the server initialisation (before any other component)
readiness probe starts serving requests only when all the components finished the initialisation
Increasing initialDelaySeconds further by default for readiness probe might be undesirable because it will introduce noticeable unconditional delay between the server start and the moment when it actually starts serving requests.
As a workaround, I think we may adjust the default settings so that the pod has at least 90s to finish initialisation, but does not prevent server from handling requests if it managed to complete initialisation sooner:
readinessProbe:
enabled: truehttpGet:
path: /healthzport: 4040initialDelaySeconds: 5periodSeconds: 10timeoutSeconds: 30failureThreshold: 10successThreshold: 1# Despite the fact that the initial delay is 60 seconds, if the pod crashes# after initialisation (this is the only realistic reason why the probe may fail),# it will be restarted.## Note that livenessProbe does not wait for readinessProbe to succeed. livenessProbe:
enabled: truehttpGet:
path: /healthzport: 4040initialDelaySeconds: 60periodSeconds: 10timeoutSeconds: 30failureThreshold: 3successThreshold: 1
The current config:
readinessProbe:
# -- Enable Pyroscope server readinessenabled: truehttpGet:
# -- Pyroscope server readiness check pathpath: /healthz# -- Pyroscope server readiness check portport: 4040# -- Pyroscope server readiness initial delay in secondsinitialDelaySeconds: 30# -- Pyroscope server readiness check frequency in secondsperiodSeconds: 5# -- Pyroscope server readiness check request timeouttimeoutSeconds: 30# -- Pyroscope server readiness check failure threshold countfailureThreshold: 3# -- Pyroscope server readiness check success threshold countsuccessThreshold: 1livenessProbe:
# -- Enable Pyroscope server livenessenabled: truehttpGet:
# -- Pyroscope server liveness check pathpath: /healthz# -- Pyroscope server liveness check portport: 4040# -- Pyroscope server liveness check intial delay in secondsinitialDelaySeconds: 30# -- Pyroscope server liveness check frequency in secondsperiodSeconds: 15# -- Pyroscope server liveness check request timeouttimeoutSeconds: 30# -- Pyroscope server liveness check failure thresholdfailureThreshold: 3# -- Pyroscope server liveness check success thresholdsuccessThreshold: 1
The text was updated successfully, but these errors were encountered:
Currently, liveness and readiness probes are configured with
initialDelaySeconds
set to 30s which is fairly high value. However, in case of the container crash, Pyroscope server may need even longer time to recover the storage (it is hard to estimate the procedure duration, but a minute or two is what we may expect).A proper solution would be to separate implementations of the readiness and liveness checks:
Increasing
initialDelaySeconds
further by default for readiness probe might be undesirable because it will introduce noticeable unconditional delay between the server start and the moment when it actually starts serving requests.As a workaround, I think we may adjust the default settings so that the pod has at least 90s to finish initialisation, but does not prevent server from handling requests if it managed to complete initialisation sooner:
The current config:
The text was updated successfully, but these errors were encountered: