Skip to content

Graphite tag support #1806

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

Merged
merged 13 commits into from
Jan 27, 2020
Merged

Conversation

fitzoh
Copy link
Contributor

@fitzoh fitzoh commented Jan 18, 2020

Super Janky Quite reasonable (@jkschneider edit) support for #491.

Adds an alternative dimensional name mapper and naming convention for graphite that supports tagging.

@jkschneider jkschneider changed the title WIP Graphite tag support Graphite tag support Jan 25, 2020
@jkschneider jkschneider merged commit f2f559f into micrometer-metrics:master Jan 27, 2020
@jkschneider
Copy link
Contributor

Thanks for the cool feature @fitzoh!

@jkschneider jkschneider added this to the 1.4.0 milestone Jan 27, 2020
@shakuzen shakuzen modified the milestone: 1.4.0 Jan 28, 2020
@shakuzen shakuzen added registry: graphite A Graphite Registry related issue release notes Noteworthy change to call out in the release notes labels Jan 28, 2020
@davide-baldo
Copy link

This PR seems broken, it always generate broken names due to DropWizard behavior.

From DropWizard, GraphiteReporter [1]:
graphite.send(prefix(name, type.getCode()), format(value), timestamp);
where
name="my.metric;tag=value"
type.getCode() = "p99"

final string sent to graphite: "my.metric;tag=valuep99"

Unless we patch DropWizard side i can't see how this code may work

[1] https://github.com/dropwizard/metrics/blob/v4.1.7/metrics-graphite/src/main/java/com/codahale/metrics/graphite/GraphiteReporter.java#L351

@shakuzen
Copy link
Member

shakuzen commented May 8, 2020

@workless could you please open a new issue so we can take a look at it? /cc @fitzoh

j-sandy added a commit to j-sandy/kayenta that referenced this pull request Sep 12, 2022
…g-boot to 2.3.12

While upgrading the spring-boot by transitively upgrading the orca version in kayenta and enforcing the dependencies, the kayenta-integration-tests:GraphiteStandaloneCanaryAnalysisTest failed with below error:

```
java.lang.AssertionError: 1 expectation failed.
JSON path executionStatus doesn't match.
Expected: is "SUCCEEDED"
  Actual: TERMINAL

	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
	at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:72)
	at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:59)
	at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor(ConstructorSite.java:84)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:277)
	at io.restassured.internal.ResponseSpecificationImpl$HamcrestAssertionClosure.validate(ResponseSpecificationImpl.groovy:493)
	at io.restassured.internal.ResponseSpecificationImpl$HamcrestAssertionClosure$validate$1.call(Unknown Source)
	at io.restassured.internal.ResponseSpecificationImpl.validateResponseIfRequired(ResponseSpecificationImpl.groovy:674)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAcc
```

The root cause for this issue is upgrade of io.micrometer:micrometer-registry-graphite from 1.3.16 to 1.5.14 as transitive dependency of spring-boot. In the newer version of micrometer-registry-graphite, there is addition of native Graphite tag support and making it as default behaviour from 1.4+ version. Now the legacy hierarchical tag names need to be explicitly enabled by disabling native graphite support.
https://github.com/micrometer-metrics/micrometer/releases/tag/v1.4.0
micrometer-metrics/micrometer#1806
Based on the discussions [here](micrometer-metrics/micrometer-docs#123) spring-boot has also exposed the property to disable the native graphite tag support, and implemented in 2.3.x [here](spring-projects/spring-boot#20834).

To fix this issue, explicitly specifying this property `management.metrics.export.graphite.graphite-tags-enabled=false` in test environment and in kayenta config.
mergify bot pushed a commit to spinnaker/kayenta that referenced this pull request Sep 12, 2022
…g-boot to 2.3.12 (#909)

While upgrading the spring-boot by transitively upgrading the orca version in kayenta and enforcing the dependencies, the kayenta-integration-tests:GraphiteStandaloneCanaryAnalysisTest failed with below error:

```
java.lang.AssertionError: 1 expectation failed.
JSON path executionStatus doesn't match.
Expected: is "SUCCEEDED"
  Actual: TERMINAL

	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
	at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:72)
	at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:59)
	at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor(ConstructorSite.java:84)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:277)
	at io.restassured.internal.ResponseSpecificationImpl$HamcrestAssertionClosure.validate(ResponseSpecificationImpl.groovy:493)
	at io.restassured.internal.ResponseSpecificationImpl$HamcrestAssertionClosure$validate$1.call(Unknown Source)
	at io.restassured.internal.ResponseSpecificationImpl.validateResponseIfRequired(ResponseSpecificationImpl.groovy:674)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAcc
```

The root cause for this issue is upgrade of io.micrometer:micrometer-registry-graphite from 1.3.16 to 1.5.14 as transitive dependency of spring-boot. In the newer version of micrometer-registry-graphite, there is addition of native Graphite tag support and making it as default behaviour from 1.4+ version. Now the legacy hierarchical tag names need to be explicitly enabled by disabling native graphite support.
https://github.com/micrometer-metrics/micrometer/releases/tag/v1.4.0
micrometer-metrics/micrometer#1806
Based on the discussions [here](micrometer-metrics/micrometer-docs#123) spring-boot has also exposed the property to disable the native graphite tag support, and implemented in 2.3.x [here](spring-projects/spring-boot#20834).

To fix this issue, explicitly specifying this property `management.metrics.export.graphite.graphite-tags-enabled=false` in test environment and in kayenta config.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
registry: graphite A Graphite Registry related issue release notes Noteworthy change to call out in the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants