[feature] Prometheus (or other TSDB) as data source #18381
Replies: 63 comments 8 replies
-
|
With the name But yeah it should work ok and fits the roadmap. As you said it would behave essentially like a table with a single metric and single time column. It might not be the best experience as a bunch of the fields in the explore view become obsolete, but would allow to have dashboard that mix elements coming from multiple data sources. |
Beta Was this translation helpful? Give feedback.
-
|
The same need for prometheus data source support. |
Beta Was this translation helpful? Give feedback.
-
|
Isn't grafana the de-facto ui for metrics? |
Beta Was this translation helpful? Give feedback.
-
|
@xrmx I have used grafana for a real-time monitor frontend, but I also want a statistics reporter with some metrics aggregation during week or month. Grafana seems not suitable. |
Beta Was this translation helpful? Give feedback.
-
|
@xrmx I would agree for most cases. I quite like the idea of superset being our one-stop-shop for metrics of all sorts together - which means I think it's valuable to support it - at least to the extent that we can get some metrics in and beside metrics from other sources. If those metrics point to something being up, then I imagine reverting back to Grafana for a deeper look would still be a pretty sensible plan. |
Beta Was this translation helpful? Give feedback.
-
|
Notice: this issue has been closed because it has been inactive for 222 days. Feel free to comment and request for this issue to be reopened. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to revive thus issue |
Beta Was this translation helpful? Give feedback.
-
|
+1 for prometheus support. |
Beta Was this translation helpful? Give feedback.
-
|
+1 for prometheus to support SQL :) |
Beta Was this translation helpful? Give feedback.
-
|
I liked the idea of superset as a central point while grafana being a TS monitor. Hopefully someone could bring up a turnkey solution :) |
Beta Was this translation helpful? Give feedback.
-
|
If you guys need timeseries database that support sql, maybe look at timescaledb |
Beta Was this translation helpful? Give feedback.
-
|
@nuhamind2
The TimeScaleDB is not the best option. The marketing specs of it are superior, but the real adoption faces with different struggles. So it is very interesting to get the native support for prometheus. |
Beta Was this translation helpful? Give feedback.
-
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Beta Was this translation helpful? Give feedback.
-
|
+1 support for promql in superset |
Beta Was this translation helpful? Give feedback.
-
|
+1 for Prometheus support |
Beta Was this translation helpful? Give feedback.
-
|
+1 for Prometheus support |
Beta Was this translation helpful? Give feedback.
-
|
+1 for Prometheus support |
Beta Was this translation helpful? Give feedback.
-
|
+1 for Prometheus support |
Beta Was this translation helpful? Give feedback.
-
|
+1 It would be very cool Prometheus / Alertmanager |
Beta Was this translation helpful? Give feedback.
-
|
+1 it will be cool |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 for prometheus as a datasource |
Beta Was this translation helpful? Give feedback.
-
|
+1 for prometheus support |
Beta Was this translation helpful? Give feedback.
-
|
I'd love to see support for Prometheus/PromQL as well! Please get this. |
Beta Was this translation helpful? Give feedback.
-
|
It has been years since this first request. Its not going to happen.
…On Fri, 9 Feb 2024, 11:35 Prudhvi Bade, ***@***.***> wrote:
I'd love to see support for Prometheus/PromQL as well! Please get this.
—
Reply to this email directly, view it on GitHub
<#18381 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF6GENXQ56QAIZMH6IRGKMDYSYCYFAVCNFSM5V5PVOF2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TQNBRG44TGMQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I was one of the people that enthusiastically tried to bump this before, but after adopting the technology I've realized superset isn't really meant for monitoring metrics, and wasn't built for real-time data either. I'm not saying it couldn't be done, but if that's your use case, you'd better go for something like Grafana. There has also been no productive technical discussion. This is likely very far down the backlog. |
Beta Was this translation helpful? Give feedback.
-
|
As written before, Perses might fit license-wise. |
Beta Was this translation helpful? Give feedback.
-
|
+1 for victoria metrics - Timescale db is not an option - OSS version is not enough for High availability deployments |
Beta Was this translation helpful? Give feedback.
-
|
+1 prometheus |
Beta Was this translation helpful? Give feedback.
-
|
Is Prometheus working on some sort of SQL support? Even supporting a limited SQL subset would be sufficient for us to support. Taking a quick look here https://prometheus.io/docs/prometheus/latest/querying/basics/ seems the ingredients would be there. Mix that with Apache Calcite or other SQL toolkit and you have a POC :) |
Beta Was this translation helpful? Give feedback.
-
|
+1 prometheus/victoria metrics |
Beta Was this translation helpful? Give feedback.
-
Currently we have SQLAlchemy and Druid as datasources for Superset.
Would introducing a connection to a time series database like prometheus or graphite be compatible with the roadmap for Superset? There would be value for our use case to have superset as the central point for all our metrics whether or not they live in a SQL-like datastore.
A couple of considerations for implementation:
Do people think this would be a good idea, or something that would actually get in the way more than anything?
Beta Was this translation helpful? Give feedback.
All reactions