Missing documentation for mysq plugin

[danielmotaleite]

As per bug #4401 , the mysql plugin have a interval_slow that can create gaps in metrics. The solution is adding a [[output.prometheus_client]] with a higher expiration interval than the scape interval

This information is important and should be placed in the readme, so users aren't first faced with the problem and only finding any info about in in a old closed ticket

[danielnelson]

This could affect any input plugin, so I don't think we should document it in the input. Perhaps we can improve the documentation of the prometheus output though.

Here is what we have now:

  ## Expiration interval for each metric. 0 == no expiration
  # expiration_interval = "60s"

Would something like this help?:

  ## Duration of time until metrics without updates are removed.  Set this
  ## value higher than the longest input collection interval.  If set to 0,
  ## old metrics will never be removed.
  # expiration_interval = "60s"

[danielmotaleite]

the updated text is better, but still, inputs like the mysql, where they use 2 different intervals, should still warn about it, when setting up a mysql plugin, we aren't reading the output documentation :)

... but wait...

looking back to this, i'm thinking that the the mysql plugin may really be the problem, if the interval is 10s and the slow interval is 1h, it should still report the (stale) slow data values every 10s, not once every hour. The slow interval is 1h, it should not reset with the normal interval.
Setting a expiration_interval of 1h may break many other metrics, one server will only be reported one hour later, so that fix is really breaking other metrics, as it applies globally

So i now think that this isn't really a documentation problem, the mysql main interval should not affect the slow interval, the main interval is updated every 10s, the slow is updated every hour, but still exists during all that hour and not disappear after the 10s.

What do you think?

[danielnelson]

Setting a expiration_interval of 1h may break many other metrics, one server will only be reported one hour later, so that fix is really breaking other metrics, as it applies globally

Sorry, I don't quite follow this. But I think to do what you are proposing would require adding a lifetime to the metric, instead of what we currently have where the prometheus output owns a single lifetime. This is a good idea, but I'm unsure if it would be worth the memory overhead since only the prometheus output plugins would care.

If we can find a way to redesign our internal metric type to more metadata types, perhaps based on the outputs that are enabled, without creating much cost for plugins that don't use the data, then perhaps this sort of information could be incorporated. This could be part of #3670.

[sjwang90]

Let's follow this in: #3670