Normalizing Metric Identifies for Reporting Systems

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Normalizing Metric Identifies for Reporting Systems

Joseph Lorenzini

Hi all,

 

I am implementing a metric reporter for newrelic. I’d like it to support a job’s operator metrics that come with the flink framework out of the box. In order to ensure each metric is unique you can’t use the metric name, you need to use the metric identifier. However, I am not sure the best way to present metric identifiers to newrelic. Here’s the format for an operator.

 

<host>.taskmanager.<tm_id>.<job_name>.<operator_name>.<subtask_index>

 

Here’s an example:

 

ip.taskmanager.19ebf992ecc26eed8269da120a17c20a.NorvaxWordCount.CHAIN DataSource (at get(TextInput.java:63) (org.apache.flink.api.java.io.CollectionInputFormat)) -> FlatMap (TokenizerFlatMap) -> Combine (SumTheFields).0.isBackPressured

 

What’s currently tripping me up is the value of the operator:

 

CHAIN DataSource (at get(TextInput.java:63) (org.apache.flink.api.java.io.CollectionInputFormat)) -> FlatMap (TokenizerFlatMap) -> Combine (SumTheFields).

 

I can’t realistically make that part of the newrelic metric name. That wouldn’t be usable in the UI or for querying and NR has length restrictions on metric names. What I am looking for is a way to normalize this as part of the metric name such that it’s both useful for a human to consume and something that a system like newrelic can consume.

 

Thanks,

Joe

 

 

Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it.
Reply | Threaded
Open this post in threaded view
|

Re: Normalizing Metric Identifies for Reporting Systems

Chesnay Schepler
One thing you could do is take the first N characters and hash the remaining ones; I don't think there is a better solution at the moment.
The size of job/task/operator names is a rather fundamental issue that makes a lot of things complicated (metrics, logging, UI), but we haven't made any progress on transitioning to more sane names.

Note that if NR or the user need truly unique metric names then you cannot rely on operator names, and should rather use their IDs.

On 1/8/2021 3:16 PM, Joseph Lorenzini wrote:

Hi all,

 

I am implementing a metric reporter for newrelic. I’d like it to support a job’s operator metrics that come with the flink framework out of the box. In order to ensure each metric is unique you can’t use the metric name, you need to use the metric identifier. However, I am not sure the best way to present metric identifiers to newrelic. Here’s the format for an operator.

 

<host>.taskmanager.<tm_id>.<job_name>.<operator_name>.<subtask_index>

 

Here’s an example:

 

ip.taskmanager.19ebf992ecc26eed8269da120a17c20a.NorvaxWordCount.CHAIN DataSource (at get(TextInput.java:63) (org.apache.flink.api.java.io.CollectionInputFormat)) -> FlatMap (TokenizerFlatMap) -> Combine (SumTheFields).0.isBackPressured

 

What’s currently tripping me up is the value of the operator:

 

CHAIN DataSource (at get(TextInput.java:63) (org.apache.flink.api.java.io.CollectionInputFormat)) -> FlatMap (TokenizerFlatMap) -> Combine (SumTheFields).

 

I can’t realistically make that part of the newrelic metric name. That wouldn’t be usable in the UI or for querying and NR has length restrictions on metric names. What I am looking for is a way to normalize this as part of the metric name such that it’s both useful for a human to consume and something that a system like newrelic can consume.

 

Thanks,

Joe

 

 

Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it.