At-least-once, or improved delivery / checkpointing for docker_logs source

[jonaslb]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Use Cases

If structured logs are used downstream (for statistics or investigating which events took place), it would be nice to be able to rely a bit more on the correct delivery of those logs. Currently, vector only has "best effort" for docker_logs, and if I read the docs/source correctly, it always reads the logs from the "now" (at the start) timestamp, and not from the start of the container or indeed from any kind of checkpoint. That means the "best effort" is a quite poor effort, where logs will be lost if vector is restarted. This has kept me from using Vector (other tools like promtail or filebeat do checkpointing - don't know if they integrate that with acknowledgements though).

Attempted Solutions

No response

Proposal

• Introduce checkpointing to the docker_logs source, similar to the file source.
• Optionally integrate checkpointing with acknowledgements

I see that checkpointing hasn't been enough to upgrade the file source from best-effort to at-least-once delivery, which I assume is due to lack of acknowledgement integration. However, checkpoints is still a big upgrade to the reliability of the source, even without acknowledgement integration. But I do think both together would be enough to "upgrade" the classification.

References

No response

Version

0.36.1 (docker)

[jszwedko]

Hi @jonaslb ! Thanks for filing this. I think it is a duplicate of #7358 so I'll close this one, but let me know if you disagree!