Github user zentol commented on the issue:
https://github.com/apache/flink/pull/3833
Finally found time to try this out, and it works great, merging.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user mbode commented on the issue:
https://github.com/apache/flink/pull/3833
I see, makes sense. Finally got around to fixing the dependency and getting
a [Green Travis](https://travis-ci.org/mbode/flink/builds/240926382).
---
If your project is set up for it, you can reply
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/3833
Another thing to consider is that this rule also covers the myriad of
testing utilities that so far did not have to be documented.
---
If your project is set up for it, you can reply to this email
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/3833
I think it is intended. The majority of tests can be (and are) commented
with "Tests for the {@link }.", which is totally OK because it
tells us that this is the general test battery for that class
Github user mbode commented on the issue:
https://github.com/apache/flink/pull/3833
Oh, I broke the stricter checkstyle. To me, it feels a bit weird to have to
put javadoc on tests, is that intended?
---
If your project is set up for it, you can reply to this email and have your
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/3833
Shading looks correct; dependencies are included and the correct jar is
included in flink-dist.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/3833
I'll take a look later today.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and
Github user mbode commented on the issue:
https://github.com/apache/flink/pull/3833
@zentol Would you mind checking that I got the shading right?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/3833
Yu can find an example on how to shade here:
https://github.com/apache/flink/blob/master/flink-metrics/flink-metrics-datadog/pom.xml.
Shading dependencies in reporters/connectors has become a
Github user mbode commented on the issue:
https://github.com/apache/flink/pull/3833
Okay, guava is not used anymore. I am not sure about the shading part.
Would you expect either prometheus clients or nanohttpd to be used in Flink
user code? Or are there other advantages to shading?
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/3833
As it stands a metric can have at most 10 labels, and there aren't any
current plans to extend this set; according to the docs that's still ok. If
this does indeed become a problem we can add a
Github user mbode commented on the issue:
https://github.com/apache/flink/pull/3833
@hadronzoo I tried to keep it as general as possible by exporting all
variables available to the metric group as labels. I am not sure if this might
lead to [label
Github user hadronzoo commented on the issue:
https://github.com/apache/flink/pull/3833
@mbode thanks for working on this!
One thing that I've found useful when exporting Flink's statsd metrics to
Prometheus is to make several of the metric fields tags: like `job_name`,
Github user mbode commented on the issue:
https://github.com/apache/flink/pull/3833
Thanks for looking at it so quickly! I somewhat had the same instinct as
far as your first point is concerned and thought about pulling out a
`DropwizardReporter` without Scheduling but decided
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/3833
I've glanced over this for now but it looks pretty good.
If possible though i would like to not use the DropwizardExports class, for
2 reasons:
1) We now introduce this odd pattern
15 matches
Mail list logo
