[
https://issues.apache.org/jira/browse/BEAM-4775?focusedWorklogId=201126&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-201126
]
ASF GitHub Bot logged work on BEAM-4775:
----------------------------------------
Author: ASF GitHub Bot
Created on: 20/Feb/19 07:40
Start Date: 20/Feb/19 07:40
Worklog Time Spent: 10m
Work Description: ryan-williams commented on pull request #7876:
[BEAM-4775] Clean up metric protos; support integer distributions, gauges
URL: https://github.com/apache/beam/pull/7876#discussion_r258344137
##########
File path:
runners/core-java/src/main/java/org/apache/beam/runners/core/metrics/LabeledMetrics.java
##########
@@ -29,7 +30,7 @@
/**
* Create a metric that can be incremented and decremented, and is
aggregated by taking the sum.
*/
- public static Counter counter(MonitoringInfoMetricName metricName) {
+ public static Counter counter(MetricName metricName) {
Review comment:
Quick explanation for why this changed:
Before this PR, `MetricName.named` allowed creating (user-)metrics from
{namespace,name}, while
[`MonitoringInfoMetricName.named`](https://github.com/apache/beam/pull/7876/files#diff-ba1b936a7d4c8d43789e81a816b9bb90L92)
created metrics from {URN, labels}.
The latter can create user- or system-metrics, but naively creating
`MonitoringInfoMetricName`s for user-metrics is dangerous: they don't
hash/equal the "same" metric created via `MetricName.named`, which I ran into
in tests.
Meanwhile, user code wants to make metrics from arbitrary MonitoringInfos,
so a single API for that makes sense, but it should return a `MetricName`
(AutoValue) for user-URNs, and a `MonitoringInfoMetricName` otherwise; [I've
changed the `MonitoringInfoMetricName` constructor to do that in this
PR](https://github.com/apache/beam/pull/7876/files#diff-ba1b936a7d4c8d43789e81a816b9bb90R106).
That means that it returns a `MetricName`, not a `MonitoringInfoMetricName`.
Ultimately (#7823), I merge these two into something that looks like
`MonitoringInfoMetricName` but is called `MetricName`. In the meantime, there's
little cost to using `MetricName` as the super-type of both.
So, re: your comment here, I could create an additional
`MonitoringInfoMetricName` constructor that's only to be used for system metric
URNs, and have `ElementCountFnDataReceiver` call that
[here](https://github.com/apache/beam/pull/7876/files#diff-85f1cc117121c923d328b4d98374c18aR53)
instead, and then pass the `MonitoringInfoMetricName` it got to
`LabeledMetrics.Counter` here, but I don't think that is worth it.
That new constructor would feel unsafe if it didn't validate that the passed
URN was in fact a system-metric, and that would start to be a lot of overhead,
when `LabeledMetrics.Counter` (and other callers) don't actually care whether
they are dealing with a system- or user-metric.
So that's the whole story 😄 ! lmk what you think.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 201126)
Time Spent: 14h 10m (was: 14h)
> JobService should support returning metrics
> -------------------------------------------
>
> Key: BEAM-4775
> URL: https://issues.apache.org/jira/browse/BEAM-4775
> Project: Beam
> Issue Type: Bug
> Components: beam-model
> Reporter: Eugene Kirpichov
> Assignee: Ryan Williams
> Priority: Major
> Labels: triaged
> Time Spent: 14h 10m
> Remaining Estimate: 0h
>
> [https://github.com/apache/beam/blob/master/model/job-management/src/main/proto/beam_job_api.proto]
> Â currently doesn't appear to have a way for JobService to return metrics to a
> user, even though
> [https://github.com/apache/beam/blob/master/model/fn-execution/src/main/proto/beam_fn_api.proto]
> Â includes support for reporting SDK metrics to the runner harness.
> Â
> Metrics are apparently necessary to run any ValidatesRunner tests because
> PAssert needs to validate that the assertions succeeded. However, this
> statement should be double-checked: perhaps it's possible to somehow work
> with PAssert without metrics support.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
