Document inputs who (can) produce tracking metrics

[Hipska]

Use Case

To have a better view which inputs support this, it should be documented on their README page.

Subtasks

• [x] Identify which plugins are actually able to produce tracking metrics
• [ ] Modify README for plugins indicating they produce tracking metrics

Plugins with tracking metrics

• inputs.amqp_consumer
• inputs.cloud_pubsub
• inputs.directory_monitor (Only for keeping track of number of undelivered metrics)
• inputs.eventhub_consumer (Only for keeping track of number of undelivered metrics, not sure about this)
• intputs.influxdb_v2_listener (Only for keeping track of number of undelivered metrics)
• inputs.kafka_consumer
• inputs.kinesis_consumer
• inputs.mqtt_consumer
• inupts.nats_consumer (Only for keeping track of number of undelivered metrics)
• inputs.nsq_consumer
• inputs.tail (Only for keeping track of number of undelivered metrics)

[Hipska]

@srebhan @mstrandboge @skartikey How should the README file for these be changed. What format should be used?

[srebhan]

I suggest you put up something in docs/includes and then include that file in the plugins supporting tracking metrics like

## Tracking metric support <!-- @/docs/includes/plugin_tracking_metrics.md -->

Running make docs should then embed that file below the heading.

[Hipska]

Aha, good idea. Then a second one needs to exist when the plugin only has tracking just for the purpose of keeping track of number of undelivered metrics? (As others do real acknowledgement of received messages.

[srebhan]

No I think there should be only one document. The way plugins handle tracking metrics should then be detailed in the Configuration section in case it deviates from what you expect.