This message was deleted.

Hi @Eyal Yurman, My 2 cents. Prometheus is common for monitoring other platforms so many Druid implementations use it because they already use it for monitoring other infrastructure. You are correct in that you can emit metrics to a kafka topic and do real-time ingestion into a Druid cluster for real-time analytics on Druid itself. Another thought, that may be obvious, don't put it on the same Druid cluster that you are monitoring because you don't want its workload to interfere with your regular production workloads.

Agreed, I’m fact we can emit simultaneously to both “metrics” Druid and the monitoring solution. There are a few reasons to have a metrics druid (have a test env; use SQL to analyze; compare different clusters). I hope to see here some reasons for a monitoring solution in addition to being a standard.

At Imply we do both approaches: we have a Druid-monitoring-Druid setup (using Pivot, our own UI) and we also feed Druid logs and metrics into a relatively standard monitoring product As others have said, the advantage of a standard monitoring product is you're likely to have a bunch of other stuff monitored there too. The advantage of Druid-monitoring-Druid is that many of Druid "metrics" are actually more like structured logs; especially the

query/time

and other query metrics. We find that using the Pivot UI on a Druid backend provides a better slice and dice experience for these sorts of "loggy metrics" or "metricy logs" than standard monitoring products.