Open shric opened 3 months ago
@shric the plugin has no way to propagate tags to the stats which are collected at model level so defining an alias is the only way to disambiguate the two instances... Is there any reason not to use the alias
mechanism?
There is no reason not to use the alias
mechanism. The bug is that the produced metrics without alias
are useless. A number of solutions spring to mind:
I consider this to be a bug, so I filed it as an FYI. We worked around it with aliases, but that doesn't mean it's not a bug. If you don't consider it a bug, that is fine. Thanks for taking a look.
@shric I agree with you that this might be useless for multiple instances without an alias as the metrics might also collide occasionally... However, we cannot change the current layout as this might break things for existing users, otherwise I would have added the unique, auto-generated plugin id to the metrics...
How about adding a clear statement to inputs.internal
recommending to add an alias and prepare to pass through the plugin-id but disable it for now?
Hi @srebhan, that sounds like a good idea, thanks for giving this some thought. It isn't causing any problems for us, just thought I'd point out the issue.
Relevant telegraf.conf
Logs from Telegraf
System info
telegraf-1.31.3-1.x86_64, Alma Linux 8.8
Docker
No response
Steps to reproduce
Expected behavior
Separate
internal_write_buffer_size
metrics for eachoutputs.http
instance. An additional url tag, for example, could disambiguate.Actual behavior
metrics such as
internal_write_buffer_size{output="http"}
will randomly report either 0 (for the reachable output) or a nonzero value (for the unreachable output) against the same metric.Additional info
If you provide an e.g.
alias="one"
andalias="two"
in the above config, then you do get two unique metrics. However, it would seem to be a bug to allow telegraf to produce a single useless metric that flaps ambiguously between multiple values if aliases aren't defined.