Fluent-bit: Rename or alias in_docker

[PettitWesley]

As far as I can tell, the in_docker plugin is released but un-documented. Is there any way it's name can be changed or aliased?

Reasoning:

1. docker is a very generic name. The plugin obtains container resource utilization metrics. It is potentially confusing since Fluent Bit has multiple ways of obtaining docker logs (reading docker log files or via the fluentd docker log driver). I anticipate user confusion. container_metrics would be a more descriptive name.
2. The plugin reads cgroup files, this could potentially be extended to other container runtimes like containerd.
3. Docker is technically a company. While "Docker" and "containers" are synonymous to many, there are other popular ways to run containers.

[edsiper]

@PettitWesley thanks for raising this concern.

Do you know if the file config.v2.json is Docker specific or its also used by other container engines ?

container_metrics makes sense to me and by default operates in docker mode

[PettitWesley]

if the file config.v2.json is Docker specific

Yeah it's docker specific AFAIK.

[sonofachamp]

Along the lines of renaming the in_docker plugin I'm looking into extending this plugin to be able to use it in a container as well as potentially on Kubernetes for scraping container metrics.

There are some challenges in the existing implementation:

• The /sys/fs/cgroup paths are not configurable
• Kubernetes has more complex cgroup directory structures for pods based on the Quality of Service (QoS) class

I'm not yet sure that extending this plugin into a Kubernetes container metrics scraper is the right way to go, but that's what I'm looking into. If that's something worth considering then it would make sense to consider a plugin name that is container runtime agnostic such as in_container_metrics or in_cgroup with some configurable modes.

[edsiper]

@PettitWesley @sonofachamp @ashutoshdhundhara

so we have an agreement. we will rename this from in_docker to in_container_metrics.

I think a rename makes more sense and a refactor or rewrite along the way, I don't want to include a plugin that we will deprecate because another one will support different backends.

So in_container_metrics supports 'docker' by default "for now"

[sonofachamp]

@edsiper What's the general approach to doing a plugin rename? Should we just straight up rename it or is there a friendlier way so we don't break folks that depend on in_docker?

[edsiper]

my apologies, I got totally confused and for a minute I assumed the plugin was not in stable mode. Of course, we won't break our users.

A new plugin makes sense even if it duplicates some features of in_docker. Once this new plugin is available we decide an EOL for in_docker if required with proper deprecation notice.