[BEAM-6265] Decouple Wire of MetricHttpSink from internal java Metric classes. i.e. MetricName

• Type: New Feature
• Status: Resolved
• Priority: P2
• Resolution: Fixed
• Fix Version/s: 2.7.1
• Component/s: java-fn-execution
• Assignee: Alex Amato
• Reporter: Alex Amato
• Created: 18/Dec/18 18:54
• Updated: 16/May/20 13:36
• Resolved: 03/May/19 17:43

Description

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.