<p>We currently have several microservices running on-premises, and we use shell scripts to monitor their performance, including JVM, heap size, and number of running threads. However, we are planning to move to the cloud using Kubernetes. We want to monitor service level stats like the number of threads open, JVM, heap size, etc., in the cloud. We are planning to use Prometheus, Grafana, and Elasticsearch for this purpose.</p>
<p>Can anyone suggest a way to monitor microservice performance in a Kubernetes cluster using Prometheus, Grafana, and Elasticsearch?</p>
<p>We believe this can be done using Spring Boot Actuator , but don't have clear idea on how it works on kubernetes for multiple services.</p>

<p>Your question requires a series of reflections that you don't do.. for example, which Cloud provider are you going to? Why do you want to create a monitoring (Prometheus/Alertmanager/Grafana) and a logging stack (Elasticsearch/fluentd)?
Is there a particular reason why you want to remain &quot;untied&quot; from the Provider's products?
On most Cloud Service Providers, you already have these tools as a service.</p>
<p>Anyway, for the &quot;monitoring&quot; stack you can use the Prometheus operator; this provides all the tools you need in one solution.</p>
<p><a href="https://prometheus-operator.dev/docs/prologue/introduction/" rel="nofollow noreferrer">https://prometheus-operator.dev/docs/prologue/introduction/</a></p>
<p>On your applications side you will have to export the metrics you want to monitor and add the various &quot;scrape-jobs&quot; to your Prometheus. After that you can have fun creating dashboards of all kinds (you will find a lot of docs online).</p>
<p>For the logging stack, you'll need a tool like fluentd to &quot;fetch&quot; and collect logs from your Kubernetes cluster, and a tool that allows you to intelligently view and process this information like Elasticsearch.</p>
<p>The tools in question are not as closely related as the monitoring ones, so it's up to you to decide how to install them. Surely I would create a single namespace for Logging and consider using the Helm Charts provided by the Vendors.</p>
