[
https://issues.apache.org/jira/browse/BEAM-4775?focusedWorklogId=200905&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-200905
]
ASF GitHub Bot logged work on BEAM-4775:
----------------------------------------
Author: ASF GitHub Bot
Created on: 19/Feb/19 21:49
Start Date: 19/Feb/19 21:49
Worklog Time Spent: 10m
Work Description: ajamato commented on issue #7867: [BEAM-4775] key
MetricResult by a MetricKey
URL: https://github.com/apache/beam/pull/7867#issuecomment-465324701
One thing I don't like about MetricKey, is that its only applicable to user
metrics. Which are identified with the following fields:
- Step Name
- Namespace
- User provided Metric Name
MonitoringInfos are defined by
- URN
- Arbitrary set of Key value pair labels.
- (Doesn't necessarily have a step name at all).
MetricKey is insufficient today to describe any metric which isn't defined
by (step, namespace, metric name).
Take a look at MonitoringInfoMetricName (extends MetricName), which I added.
https://github.com/apache/beam/blob/5b1700db834cf949547a20a30f3ee1270710585a/runners/core-java/src/main/java/org/apache/beam/runners/core/metrics/MonitoringInfoMetricName.java
This can contain a URN and an arbitrary set of key value pair labels. I
think this is the more generalized way to key a Metric and I would like to land
on this in the future. I think we don't really need two separte classed
MetricName and MetricKey either.
We could just have one class in the end similar to which represents the
MetricKey.
The challenge I see with this though, is that querying the metrics and
storing the metrics internally use the same classes today (MetricKey). It
would be better to keep the user facing API more similar to how the user
defines a metric (explicitly being able to access the name and namespace
fields). In the end we might have an internal MonitoringInfoMetricKey separate
from a (User)MetricKey the user can us in the querying API.
If this change unblocks your work now, then I think its fine to proceed. But
I wanted to give a bit more context here on how I think this could be
simplified in the end. I think we have too many classes right now, for
identifying metrics.
----------------------------------------------------------------
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:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 200905)
Time Spent: 8h 20m (was: 8h 10m)
> 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: 8h 20m
> 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)
