Some metrics in nginxreceiver are defined as Gauge, but they are non-monotonic sums

[bogdandrutu]

E.g. nginx.connections_current

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.

[github-actions]

Pinging code owners for receiver/nginx: @djaglowski. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[lBowlin]

Hi @djaglowski and @bogdandrutu I stumbled upon this change and am curious why it was made? According the nginx documentation reading writing waiting all represent the current values of connections in those states, and go up and down accordingly. This would seem to represent a gauge type metric, and the official nginx-prometheus-exporter also classifies them as gauges.

What inspired this change? Has there been a fundamental change to how the metric is observed from one that can go up or down, to one that can only go up?

[djaglowski]

Hi @lBowlin, there's a subtlety in the OTel data model that was overlooked in this case.

Basically, our notion of sum metric is a bit broader than just counters and can represent realtime values that go up and down. The key idea here is that we subdivide sums into monotonic (counters) and non-monotonic (gauge-like) types, but we ultimately expect non-monotonic sums to be treated as gauges in most backends. (This diagram may be helpful.)

What differentiates a non-monotonic sum from a gauge is that the data points can be meaningfully aggregated. For example, with this metric we could:

• Sum reading writing and waiting for a single server to find a total number of connections.
• Sum waiting data points across multiple servers to determine the total number of waiting connections in a deployment.

This means that gauges are only used for things that cannot be aggregated in a straightforward way. For example, a disk space utilization %.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/nginx: @djaglowski

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.

[djaglowski]

This is essentially completed but still behind a feature gate.