[
https://issues.apache.org/jira/browse/BEAM-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on BEAM-6265 started by Alex Amato.
----------------------------------------
> Decouple Wire of MetricHttpSink from internal java Metric classes. i.e.
> MetricName
> ----------------------------------------------------------------------------------
>
> Key: BEAM-6265
> URL: https://issues.apache.org/jira/browse/BEAM-6265
> Project: Beam
> Issue Type: New Feature
> Components: java-fn-execution
> Reporter: Alex Amato
> Assignee: Alex Amato
> Priority: Major
>
> I recommend decoupling the MetricName from the MetricResult object which is
> used by MetricHttpSink and other MetricResult classes.
>
> I was trying to enhance MetricName with a naming style more similar to
> MonitoringInfo, by allowing a MonitoringInfoMetricName subclass to define a
> name using a
> * urn - string
> * labels - <string,string> map
> I encountered an issue when adding accessor methods to the base MetricName
> for getUrn and getLabels. The tests in MetricHttpSinkTest fail because
> serialized the JSON of the object using reflection via a call to
> ObjectMapper.writeValuesAsString.
> To decouple this, a Wire format Pojo could be introduced (that does not use
> MetricName) to copy the metric onto first before invoking
> ObjectMapper.writeValuesAsString.
> Then if new capabilities are added to internal MetricName, we won't break the
> MetricHttpSink, we can update it to include new fields as necessary.
>
> Additionally, I will propose a new design for MetricResult soon, as it lacks
> labeling capabilities.
>
> The current MetricResult only supports a single label getStep() at the moment.
> Additionally, it is focused on a name+namespace style metric.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
