-
Notifications
You must be signed in to change notification settings - Fork 230
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
feat: remove leading and trailing zeros #119
Changes from 2 commits
cd9e295
888b3a2
a7f019f
63ef992
0f48d3c
1f79729
f3aa27c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -261,6 +261,39 @@ local function construct_bucket_format(buckets) | |
return "%0" .. (max_order + max_precision + 1) .. "." .. max_precision .. "f" | ||
end | ||
|
||
-- Format bucket format when expose metrics. | ||
-- | ||
-- This receives a key, remove leading and trailing zeros and return the cleaner | ||
-- number, in order to make the output more clear, without effect on the increasing | ||
-- order. | ||
-- | ||
-- Args: | ||
-- key: the metric key | ||
-- | ||
-- Returns: | ||
-- (string) the formatted key | ||
local function format_bucket_when_expose(key) | ||
local all_le_string = string.match(key, '(le=".*")') | ||
local part1, bucket, part2 = string.match(key, '(le=")(.*)(")') | ||
if tonumber(bucket) == nil then | ||
return key | ||
Yiyiyimu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
end | ||
|
||
--remove leading zeros | ||
local _ | ||
_, bucket = string.match(bucket, '(0*)(.*)') | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This will remove all leading zeros (e.g. Actually, I think the simplest way to do the number formatting here would be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah that's right! That is faster (regex in pure lua is indeed pretty slow) and way more elegant. Thanks a lot! |
||
|
||
--remove trailing zeros and decimal point | ||
while (bucket:sub(-1) == "0") do | ||
bucket = bucket:sub(1, -2) | ||
end | ||
if (bucket:sub(-1) == ".") then | ||
bucket = bucket:sub(1, -2) | ||
end | ||
|
||
return key:gsub(all_le_string, table.concat({part1, bucket, part2}, "")) | ||
end | ||
|
||
-- Return a full metric name for a given metric+label combination. | ||
-- | ||
-- This function calculates a full metric name (or, in case of a histogram | ||
|
@@ -806,6 +839,7 @@ function Prometheus:metric_data() | |
end | ||
seen_metrics[short_name] = true | ||
end | ||
key = format_bucket_when_expose(key) | ||
-- Replace "Inf" with "+Inf" in each metric's last bucket 'le' label. | ||
if key:find('le="Inf"', 1, true) then | ||
key = key:gsub('le="Inf"', 'le="+Inf"') | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will probably work correctly only if
le
is the last label. Otherwise, it'll match too much. E.g.: forkey='my_metric{le="0.10",z="x"}'
it will return'le="0.10",z="x"'
.Also, it might match incorrectly if there were a label ending with 'le', e.g.:
my_metric{stale="0",le="0.01"}
.I think this function deserves more thorough unit tests...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually
le
would always be the last label in the current implementation, seenginx-lua-prometheus/prometheus.lua
Lines 323 to 333 in 499de49
But the later one is what I missed before. Thanks for remind!
I tried to get the last
le=
, but when talking about sum/count, there would be no labelle
but the others saystale
, so get the last one is not appropriate. Right now I fix this problem by filter both,le="
and{le="
. Do you have some other suggestions?And new unit tests added for 1. label "stale" 2. no labels.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I didn't check the implementation details. So it is probably ok to do it this way, but this assumption should be checked in unit tests (so it doesn't break in future, if someone changes the ordering of labels).
Regarding the checking: You can match both variants at once:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I've added unit tests for these scenarios, thanks for remind!
And thanks for the regex suggestions🆒