-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
feat: Metrics #995
Comments
As discussed in Slack with @outerlook, we have a need to expose the CometBFT metrics as a part of v0.9. This won't require anything more than adding some configurations to Kwil, however we should be careful how we do it, such that we can avoid making breaking changes when we add more Kwil-specific instrumentation. Below, I have the (potential) new configurations that we can add to Kwil to enable this. With these, we can enable usage of the current CometBFT metrics endpoint, and later add new metrics for Kwil. These generally match CometBFT's config, however I removed the ability to configure namespace, since we will likely want to enforce separate namespaces for comet and Kwil [instrumentation]
# when true, prometheus metrics are served under /metrics
prometheus = true
# listen address for prometheus metrics
prometheus_listen_addr = "tcp://0.0.0.0:26660"
# Maximum number of simultaneous connections.
# 0 - unlimited.
max_open_connections = 1 Adding Kwil-Specific MetricsAfter digging into |
The above message regarding CometBFT metrics was merged, but keeping the issue open since we plan to add Kwil-specific metrics in v0.10 |
A few times now, we have had users request the ability for metrics. We added a basic sort of metrics to
kgw
(this was to allow Truflation to perform analytics on their network and customer usage), but we also should support metrics onkwild
such that node operators can ensure their nodes are running properly. This was suggested in the TSN node operator discord today by @mo-husseini-vc from Validation Cloud, who mentioned that it would be very helpful to have a metrics endpoint that can be integrated with Prometheus.CometBFT has an endpoint for this, which definitely contains some information that would be relevant to us. Some metrics here that I think would be particularly helpful to us:
Additionally, Mo had some suggestions on what else we could track:
A few others that could obviously be helpful:
I don't think we can (or should) add this into v0.9, however we should backlog it for v0.10. Additionally, we should use the TSN testnet as an opportunity to get feedback from validators to see what they expect from this endpoint / what would be helpful for them.
The text was updated successfully, but these errors were encountered: