# Best practice for Kubernetes liveness probe?

**URL:** <https://discuss.elastic.co/t/best-practice-for-kubernetes-liveness-probe/113967>\
**Category:** Logstash\
**Created:** [January 3, 2018, 5:38pm UTC](https://discuss.elastic.co/t/best-practice-for-kubernetes-liveness-probe/113967 "2018-01-03T17:38:25Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![JamesB](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jamesb/32/24343_2.png) [@JamesB](https://discuss.elastic.co/u/JamesB)\
**Post date:** [January 3, 2018, 5:38pm UTC](https://discuss.elastic.co/t/best-practice-for-kubernetes-liveness-probe/113967/1 "2018-01-03T17:38:25Z")

</div>

I'm going to run Logstash in Kubernetes and was wondering what the best practice was for knowing that logstash is alive and functioning? I can then create a liveness and readiness probe in Kubernetes, whether it's HTTP or TCP. I was looking for something like Elasticsearch's cluster green status, but the Logstash monitoring API seems to return more detail. Is it safe to assume that if the monitoring API can't be reached Logstash is dead? Or is that too simplistic? Has anyone else got any best practices on Kubernetes to share?

Cheers.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 31, 2018, 5:38pm UTC](https://discuss.elastic.co/t/best-practice-for-kubernetes-liveness-probe/113967/2 "2018-01-31T17:38:41Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
