Skip to content
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.

Sign up for GitHub

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

Add support for gauge metric in static-exporter #1328

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Add support for gauge metric in static-exporter #1328

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6b35473
Add support for gauge metric in static-exporter, keep default as `cou…
gauravgpta93 Sep 4, 2024
0998771
Fix lint
gauravgpta93 Sep 4, 2024
d823f72
Change the variable name from `metricType` to `type`
gauravgpta93 Sep 6, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions static-exporter/main.libsonnet
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ local k = import 'ksonnet-util/kausal.libsonnet';
function(acc, metric)
acc + [
'# HELP %(name)s %(description)s' % metric,
'# TYPE %(name)s counter' % metric,
'# TYPE %(name)s %(metricType)s' % metric,
] + [
metric.name + value
for value in metric.values
Expand All @@ -47,14 +47,17 @@ local k = import 'ksonnet-util/kausal.libsonnet';
}),

metric:: {
new(name, description)::
new(name, description, metricType='counter')::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could set this value below and require withMetricType instead of overloading the constructor.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to prefer that over having all the arguments in the constructor?
I'm not sure I see how metricType is different from description or name except that the library originally only supported counter types.

In other words, why have:

metric.new('NAME', 'DESCRIPTION') + metric.withMetricType('TYPE')

when you can just have:

metric.new('NAME', 'DESCRIPTION, 'TYPE')

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, to help me understand our patterns better. Why does the constructor do:

self.withName(name)
+ self.withDescription(description)
+ self.withMetricType(metricType)

instead of:

{
  name: name,
  description: description,
  type: metricType,
}

I am thinking it's to use the public API presented by the object so that if withName ever does validation, the constructor also does the validation without refactor?
In that case, should we have some convention of indicating that the type, description, and type fields shouldn't be modified except through that public API. Perhaps they should be fields within a hidden _internal field or something?

self.withName(name)
+ self.withDescription(description),
+ self.withDescription(description)
+ self.withMetricType(metricType),

withName(name): { name: name },

withDescription(description): { description: description },

withMetricType(metricType): { type: metricType },

local generateValues(labelMap, value=1) =
local labels = [
key + '="' + labelMap[key] + '"'
Expand Down
Loading