-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend OpenMetrics by a stability data type #199
Comments
Nice idea. What if we recommended to put the hint in the HELP string, rather than add another field? |
This is definitely an option as well, I didn't want to assume a specific workflow and/or break existing workflows when it comes to consuming HELP fields, that's why I suggested a separate one. |
In general, I question the utility of this as in practice it's quite difficult to predict how software subsystems might evolve over time - and thus that their metrics might also become obsolete. Different types of software (many of which will co-exist inside one application) have very different meanings, lifecycles, and velocities associated with "stability". Accordingly documentation within each respective project would seem a better approach overall, rather than trying to formalise some of the fundamental complexities of software engineering into a metrics standard. |
This has the same utility as SNMP's OID |
If it is just mentioned in
|
In order to improve metrics experience, I would like to propose two fields to be added to the spec.
As an example:
This could allow consumers to warn when an unstable metric is used and improve metrics lifecycle. We currently see issues where e.g. grafana dashboards use a deprecated metric and users only figure out when the metric is gone on the consumer side.
This is similar to #189 but with a clearer focus on lifecycle.
The text was updated successfully, but these errors were encountered: