No effect of sanitize_name_method from inputs.statsd

Telegraf
1

Hi team!

Hope everyone doing well.

I’m having this parsing errors:

2024-04-04T14:11:20Z E! [inputs.statsd] Splitting ‘|’, unable to parse metric: web_login,status=success,reason=success,ip_address=2804:99:8888:b777:b666:55a5:aae4:a2dc,user_id=123456,tsa_active=False:1|c

I’ve found this argument that sanitize names:

## Sanitize name method
## By default, telegraf will pass names directly as they are received.
## However, upstream statsd now does sanitization of names which can be
## enabled by using the "upstream" method option. This option will a) replace
## white space with '_', replace '/' with '-', and remove characters not
## matching 'a-zA-Z_\-0-9\.;='.

Already tried it, but maybe it doesnt work to values but only metric names.

Is there an easy way to use the same logic to metric values and avoid this parsing errors at Telegraf side?

2

The issue is with your ip address tag. The StatsD protocol relies on the ‘:’ character to separate the metric name from the metric value. Your metric has colons in the IP address tag, which is a signal to the statsd parser to read the actual value. For example, in your metric the value is signaled by :1|c, but you have a :99 that comes first in the IP Address.

3

Hi jpowers!

Thanks for the attention and your kind reply.
Is there a way to replace the whole metric (from colons to dots, for example) every time some app send with colon to Telegraf?
I can’t control this at app side, but at least I could control this at Telegraf side if possible.

tyvm

4

Hmm nothing directly comes to mind looking at the options in statsd.

That value is completely invalid statsd, so it will never get parsed correctly by the statsd parser or input plugin.

If I were to suggest another input to collect the data, you would have to keep it as a string, use a processor (after inputs have collected it), to parse it out yourself and then convert it somehow into a metric. Which may still not get you what you need.

1 Like
5

Hi @jpowers

Thanks again for the reply.

My initial ideia was to use the processor to normalize the metric and avoid this parsing error.

Now, it’s pretty clear to me that I can’t use a processor before this error occur, due to the pre-parsing that this input plugin does.

Thanks for the patience to bring the information and the additional suggestion.

1 Like