Cosmos-sdk: Feature request: Add Prometheus metrics for governance proposals

[mdyring]

Summary

Provide a prometheus metric to monitor/alert on governance proposals.

Problem Definition

Today monitoring for new proposals requires a constant presence in chat rooms and forums. It would be nice to offer a way to monitor for new proposals with less overhead.

Node operators might want to monitor proposals in both the Voting and Deposit phases, so it seems useful to expose both.

Proposal

Export a metric "gaia_governance_in_voting_period" with the following label:
chain_id (example: cosmoshub-2)

Similarly provide a "gaia_governance_in_deposit_period" with same label.

The metrics should count the number of governance proposals that have entered or passed the specific period. For instance, a proposal that have entered the voting period would count in both the deposit and voting metric.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[alexanderbez]

The SDK itself does not have a metrics layer -- Tendermint does. IMHO, these layers should exist on top of the SDK/network (e.g. juno) rather than being baked into the SDK itself.

[mdyring]

I need to read up on Juno (sounds great), but I think there is great value in offering cosmos-sdk observability alongside Tendermint without introducing additional dependencies.

[alexanderbez]

Indeed @mdyring! I agree, I just don't think it belongs in the SDK is all I'm stating. We could have comos/sdk-prom or something to provide such a prometheus layer.

[dlguddus]

Super interested in expanding Prometheus to SDK level data.

[alexanderbez]

It actually may be ideal to expose Prometheus metrics after all. The problem lies in defining which metrics to expose, how to do it generally so it can be extended in the future and how to not have any performance hits in the app (e.g. locks) while collecting metrics.

@mdyring @dlguddus do you have any suggestions on what metrics would be beneficial?

[dlguddus]

I think it should cover most of any available data which is provided by rpc or LCD but exporting configuration can be customized in config.toml. if the range of data can be configured, performance is not a critical problem because users can choose adequate range for themselves.

It would be beneficial to construct a hierarchy of available data so that users can choose specific range of service.

Generalization of this range is important because we will have different kinds of data from different cosmos-sdk base blockchains.

But my idea is quite ideal and it might have some practical barrier such as data type to fit Prometheus export.

[alexanderbez]

++ to configuration

However, we should be clear on that state data ≠ telemetry/(valuable)metrics. That's why I'd like to first layout what areas (preferably exact types/values) of metrics we want to expose and support. e.g. IAVL/store IO is critical, but # proposals/per X...not so much.

[marbar3778]

@fedekunze why did you close this? this is not completed

[marbar3778]

once #6399 is merged then this issue can easily be solved. We welcome contributions.

[alexanderbez]

Closing this issue. We're going to start adding metrics to modules now.