-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Add config for custom metrics tags #2971
Conversation
5ab4e96
to
e3a1799
Compare
"Invalid config value for '%s'. value: %s. reason: %s", | ||
KsqlConfig.KSQL_CUSTOM_METRICS_TAGS, | ||
tags, | ||
e.getMessage())); |
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.
Wouldn't be better to catch this error early in the KsqlContext
?
I feel we should pass the tags to the KsqlEngineMetrics
already parsed into a Map. Also, it makes sense to have one place where the KsqlConfig.KSQL_CUSTOM_METRICS_TAGS
is used instead of having 1 in KsqlContext to get the tags, and another in the metrics to throw the exception.
Better yet, would it make sense to have a KsqlConfig
method that parses these key/value pairs? It might be useful in future configs with similar values. Like Map<String, String> getKeyValues(String key)
or a different name.
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.
LGTM! I agree with @spena's comment (though you could also do that in the ServiceInfo
class that I suggested.
@@ -66,14 +66,15 @@ public KsqlEngine( | |||
final ServiceContext serviceContext, | |||
final ProcessingLogContext processingLogContext, | |||
final FunctionRegistry functionRegistry, | |||
final String serviceId | |||
final String serviceId, |
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.
nit: I think we should couple serviceId
and custommetricsTags
into a ServiceInfo
class so that piping this type of information down will be easier in the future (also I imagine that serviceId
might be valuable for metrics as well)
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.
Mostly lgtm. Agree with @spena on parsing the config string early on. We should decouple the config format from the rest of the engine.
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.
Also, any reason not to use the LIST type from AbstractConfig here? Then, you can provide the tags as a comma-seperated list and have the existing config stuff do some of the parsing for you. Plus its more consistent with other configs that list stuff.
No strong reason but if we were to use the LIST type we'd still have to parse the individual tags into name-value pairs, and add in logic to throw an error if tag names are duplicated since |
Yes I think so. I think this config is pretty useful, and we should try and keep it consistent with the rest of cp.
Yes, we should add it to both. |
Thanks for the reviews, all! Added two commits. First one should be uncontroversial:
The second commit introduces the ServiceInfo object @agavra suggested. Feels a little overkill at the moment but I do think it's cleaner. Happy to hear what others think, can easily back it out. |
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.
Looks good @vcrfxia (+1)
I left two minor comment.
docs/changelog.rst
Outdated
@@ -18,6 +18,9 @@ KSQL 5.4.0 includes new features, including: | |||
Avro record or JSON object, depending on the format in use, or as an anonymous value. | |||
For more information, refer to :ref:`ksql_single_field_wrapping`. | |||
|
|||
* A new config `ksql.metrics.tags.custom` for adding custom tags to emitted JMX metrics. |
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.
is it to emit
or with emitted
?
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.
I have a slight preference for "adding ... to" versus "adding ... with" but I don't feel too strongly.
public Map<String, String> getStringAsMap(final String key) { | ||
final String value = getString(key).trim(); | ||
try { | ||
return value.equals("") |
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.
Check for the NULL value as well. I think if you set a config like config=
without a value, then the value returned will be null. I recalled seen this null value in some tests with configs.
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.
Hm, I tried setting ksql.metrics.tags.custom=
just now and got the empty string. Are you able to reproduce getting a null value?
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.
Perhaps it was a different configuration that has NULL as default.
docs/changelog.rst
Outdated
@@ -18,6 +18,9 @@ KSQL 5.4.0 includes new features, including: | |||
Avro record or JSON object, depending on the format in use, or as an anonymous value. | |||
For more information, refer to :ref:`ksql_single_field_wrapping`. | |||
|
|||
* A new config `ksql.metrics.tags.custom` for adding custom tags to emitted JMX metrics. |
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.
* A new config `ksql.metrics.tags.custom` for adding custom tags to emitted JMX metrics. | |
* A new config ``ksql.metrics.tags.custom`` for adding custom tags to emitted JMX metrics. |
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.
Thanks for the catch @JimGalasyn ! I updated an earlier line in the changelog with the same fix while I was at it.
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.
LGTM!
Description
Adds a new config
ksql.metrics.tags.custom
which allows users to add custom tags to KSQL engine metrics. The value of the config is a string of comma-separated key-value pairs of tags to add. For example, passing the valuekey1:value1,key2:value2
adds two tags to each metric, one with namekey1
and valuevalue1
, the other with namekey2
and valuevalue2
. The default value for the config is the empty string which results in no custom tags being added.The config currently only applies to the new metrics format (see #2831), but if preferable I can add the custom tags to the old format as well.
Also unsure whether this change is worth adding to the either the changelog or the server config docs. Thoughts?
Testing done
Updated unit tests.
Reviewer checklist