You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When naming metrics, I often find need/desire to use camelCase to connect two or more words. It's inconvenient to have the association between those words undone in our OpenMetrics (OM) exporter.
As an example, if I define a metric with name "connectionPool.managedConnections" -- then our current spec dictates that implementations of mpMetrics are expected to change that to snake case.
According to the OM exporter guidelines at https://prometheus.io/docs/instrumenting/writing_exporters/ : Prometheus metrics and label names are written in snake_case. Converting camelCase to snake_case is desirable, though doing so automatically doesn’t always produce nice results for things like myTCPExample or isNaN so sometimes it’s best to leave them as-is.
What I'd like to propose is that we leave it up to the developer to decide whether camel case is appropriate, and just stop requiring any automatic conversion to snake case in our spec.
Metric name in code: connectionPool.managedConnections
Current OM output: connection_pool_managed_connections
Proposed OM output: connectionPool_managedConnections
WDYT?
@brian-brazil , is it safe for us to stop doing camel case -> snake case autoconversion in metric and label names? will that cause any problems for OM?
The text was updated successfully, but these errors were encountered:
That's completely safe, and what I'd recommend these days. I'd not offer an
option for this, as metrics having two different names depending on an
exposition-level option would be annoying to deal with.
On Wed 6 Mar 2019, 12:47 Don Bourne, ***@***.***> wrote:
When naming metrics, I often find need/desire to use camelCase to connect
two or more words. It's inconvenient to have the association between those
words undone in our OpenMetrics (OM) exporter.
As an example, if I define a metric with name
"connectionPool.managedConnections" -- then our current spec dictates that
implementations of mpMetrics are expected to change that to snake case.
According to the OM exporter guidelines at
https://prometheus.io/docs/instrumenting/writing_exporters/ :
*Prometheus metrics and label names are written in snake_case. Converting
camelCase to snake_case is desirable, though doing so automatically doesn’t
always produce nice results for things like myTCPExample or isNaN so
sometimes it’s best to leave them as-is.*
What I'd like to propose is that we leave it up to the developer to decide
whether camel case is appropriate, and just stop requiring any automatic
conversion to snake case in our spec.
Metric name in code: connectionPool.managedConnections
Current OM output: connection_pool_managed_connections
Proposed OM output: connectionPool_managedConnections
WDYT?
@brian-brazil <https://github.com/brian-brazil> , is it safe for us to
stop doing camel case -> snake case autoconversion in metric and label
names? will that cause any problems for OM?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#357>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AGyTdrlQSVZmUpoEmtwyAscBF_qy1cPgks5vT7jGgaJpZM4bgzOE>
.
ok, thanks @brian-brazil -- I agree with your point about not having an option for it as that would just make it hard to create dashboards that depend on consistent metric names across servers.
When naming metrics, I often find need/desire to use camelCase to connect two or more words. It's inconvenient to have the association between those words undone in our OpenMetrics (OM) exporter.
As an example, if I define a metric with name "connectionPool.managedConnections" -- then our current spec dictates that implementations of mpMetrics are expected to change that to snake case.
According to the OM exporter guidelines at
https://prometheus.io/docs/instrumenting/writing_exporters/ :
Prometheus metrics and label names are written in snake_case. Converting camelCase to snake_case is desirable, though doing so automatically doesn’t always produce nice results for things like myTCPExample or isNaN so sometimes it’s best to leave them as-is.
What I'd like to propose is that we leave it up to the developer to decide whether camel case is appropriate, and just stop requiring any automatic conversion to snake case in our spec.
WDYT?
@brian-brazil , is it safe for us to stop doing camel case -> snake case autoconversion in metric and label names? will that cause any problems for OM?
The text was updated successfully, but these errors were encountered: