Skip to content

Add support for gauge metric in static-exporter #1328

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

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from
+7 −4
Draft

Add support for gauge metric in static-exporter #1328

Changes from 2 commits
Commits
Show all changes
4 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
19a272c
Merge branch 'master' into add-support-for-gauge-metric-in-static-exp…
nikimanoledaki Mar 19, 2025
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
Contributor

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
Contributor

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
Contributor

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?

Copy link
Contributor

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'll answer with a question: At what point do we stop adding things to the constructor?

My rule of thumb is to only add arguments to the constructor that are strictly required to create the object. Then create functions for changing the default values of the returned object.

Why does the constructor do ?

For small objects it doesn't matter that much I guess, for bigger objects these functions may encapsulate larger chunks of code. Opting to ~always use the functions increases consistency. I'm not too nitty-gritty on that, especially for manually written libraries.

There is a benefit on composability. Let's say the user wants to prefix the name for all instances from a library.

In the object approach, they have to override the constructor:

local prefixLib =
  lib + {
    new(name, description):
      lib.new(name, description) 
      + { name: 'prefix-' + name },
  };

With the function approach:

local prefixLib =
  lib + {
    withName(name):
      { name: 'prefix-' + name },
  };

I prefer to do the latter.

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