Closed maxpain closed 1 year ago
Yes, please!!!
Any updates?
I am searching for the same, any update ? :)
Up this..
If Hasura based on.. idk, PHP/Java/Node/Go I will properly contribute this monitoring to them. But Haskell...need to learn this strange language hahaha
It would be greate if Hasura could support Prometheus
It would be great if hasura published Prometheus metrics but in the mean time, i've created a Hasura Exporter for prometheus, currently it exports metrics about
Nice @zolamk I also created an hasura exporter based on the json logs: https://github.com/afitzek/hasura-metric-adapter.
It currently supports:
Nice @zolamk I also created an hasura exporter based on the json logs: https://github.com/afitzek/hasura-metric-adapter.
It currently supports:
* request metrics * query execution times * active websockets * websocket operations
Very nice, it would be great if hasura could expose Prometheus metrics it self or expose the metrics through the metadata
api. perhaps we could consider pulling together our efforts into making a community project that exposes all important metrics
Prometheus metrics is now available on Hasura Cloud Standard and the Hasura Enterprise editions. At the moment, we don’t plan to include support for it in Hasura CE (Community Edition). However, please do feel free to share any how-tos and exporters that you’re using along with Hasura CE on this thread!
@rishi-div is there a reason for not including it on Hasura CE?
Sadly observing yet another "How a great project opensource oriented become a profit oriented project"
@soubinan I understand your point of view because I'm a big lover of open source and free usage of community project. However, everything cannot be free. If you take Hasura as example, the main part of the project is open and free. I use it in every project to start and it saves me a lot of time. I'm really sad to discover that some feature are not available with community version but on other hand I think it is a good think to see the project evolving. There were different business model about software and last year the model "free and pay for more" has exploded in video game and open source project. I think it is fair (maybe there is exception). If Hasura is profitable, it will continue. If Hasura reduces or closes its sources, the community can fork. But would the community have the time to continue this project?
It is just my opinion, premium features should exist for a project that can't have another revenue. However, I'm just a lover of the project, not inside Hasura organization. I do not know what happens and how they think it.
Note: as you can see, "sponsoring" gain popularity on GitHub and real question about this become bigger : how can open source's workers can have a paid time for their work?
@Tchoupinax Yes I totally agree with you, It is absolutely normal to have some profit from this fantastic work that made the hasura team However, as a swe and sre, observability is something so essential that it is kind of non sens to me to not have it as a part of opensource, expecially for prometheus, another opensource project. I would agree if other integrations was not free (splunk, dynatrace, newrelic, datadog....) But on prometheus... Sorry, I can not still understand where is the profitability for hasura, since this point was a good opportunity for guys like me to convince theirs teams wanted something more observable in the stack to integrate hasura in the roadmap...
And besides, Prometheus integration is in the free tier for the cloud version, which makes even less sense then. They aren't using it to drive profit, but just to have feature separation between the self-hosted and the managed version.
We currently use logs from Loki to get graphs in Grafana, which is slow and cannot trigger alerts in Alertmanager, so we don't have any observability beyond checking whether the Hasura container is running or not. It's annoying that Hasura is the only service that we cannot properly monitor.
I agree. Promotheus is vital for monitoring but convincing the team to open it in Hasura Core is maybe not easy since they have their own business scenario.
+1
Hasura is amazing! Really love it!
Just provide another workaround solution which is using Traefik as reverse proxy in a sidecar container and expose the metrics.
Because anyway we need something like reverse proxy to do rate limiting, which I posted the solution at
https://github.com/hasura/graphql-engine/issues/2151#issuecomment-1118264484
Here is the metrics from @afitzek 's https://github.com/afitzek/hasura-metric-adapter which is also a sidecar solution, you can compare the difference.
Bonus: As Traefik is a reverse proxy. In my case, I am also using hasura-metric-adapter, so I can use Traefik to combine hasura-metric-adapter's /metrics
endpoint with Hasura GraphQL Engine's endpoints for this) 😊
In my case, I have three containers in one pod
/metrics
endpoint with Hasura GraphQL Engine's endpoints, providing its own /metrics
, etc.)All Kubernetes YAML files are at https://github.com/Hongbo-Miao/hongbomiao.com/tree/main/kubernetes/manifests/hasura
Hopefully it gives people who have same issue some ideas in the future!
Hey everyone, please also check out Andreas' presentation on hasura-metric-adapter at one of our community calls: https://youtu.be/lxgcjOUAbjE?t=2294
Thank you everyone for your comments. Closing this issue as we have released Prometheus metrics as noted above:
(Cloud) https://hasura.io/docs/latest/observability/integrations/prometheus/
(Enterprise) https://hasura.io/docs/latest/enterprise/metrics/
There will be an easy way to try the feature in Hasura Enterprise trials soon.
Please use the other exporters as discussed above for Hasura CE.
Will it be implemented?