Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add disk usage to docker input plugin #13858

Closed
R290 opened this issue Sep 2, 2023 · 10 comments · Fixed by #13894
Closed

Add disk usage to docker input plugin #13858

R290 opened this issue Sep 2, 2023 · 10 comments · Fixed by #13894
Labels
feature request Requests for new plugin and for new features to existing plugins

Comments

@R290
Copy link
Contributor

R290 commented Sep 2, 2023

Use Case

I'd like to be able to monitor Docker volume size over time using the Telegraf Docker input plugin.

Expected behavior

A configuration setting for setting the preferred objects to be monitored: containers / images / volumes / build cache (as defined in https://pkg.go.dev/github.com/docker/docker@v24.0.5+incompatible/api/types#DiskUsageObject)

Possibly a few additional settings to include or exclude objects based on their name, preferably with wild card support.

Actual behavior

None of the settings are available; disk usage is not implemented in the Docker input plugin.

Additional info

The Docker client of the existing plugin natively supports querying disk usage. For example, see:

This should make implementation trivial, although there needs to be agreement on the configuration scheme.

@R290 R290 added the feature request Requests for new plugin and for new features to existing plugins label Sep 2, 2023
@powersj
Copy link
Contributor

powersj commented Sep 5, 2023

Hi @R290,

A configuration setting for setting the preferred objects to be monitored: containers / images / volumes / build cache

Are all of these actually interesting?

Adding a storage_objects = [] settings which could take the things we want to collect seems possible. Then if a user wanted to further exclude/include they can use metric filtering. I'd like to avoid needing to have an include/exclude for every object. Thoughts?

Thanks!

@powersj powersj added the waiting for response waiting for response from contributor label Sep 5, 2023
@R290
Copy link
Contributor Author

R290 commented Sep 6, 2023

storage_objects should in this case contain the type of object to monitor (containers / volumes / etc.)? Further filtering would be based on using tagpass / tagdrop on tags like container_name or volume_name or do we use something more generic like storage_object_name?

@telegraf-tiger telegraf-tiger bot removed the waiting for response waiting for response from contributor label Sep 6, 2023
@powersj
Copy link
Contributor

powersj commented Sep 7, 2023

storage_objects should in this case contain the type of object to monitor (containers / volumes / etc.)?

yes that was my proposal

Further filtering would be based on using tagpass / tagdrop on tags like container_name or volume_name or do we use something more generic like storage_object_name?

I'm not sure till we see what data we get back, but either of those is what I was thinking about

Is this something you want to put up a PR for?

@powersj powersj added the waiting for response waiting for response from contributor label Sep 7, 2023
@R290
Copy link
Contributor Author

R290 commented Sep 7, 2023

Yes, I'll put something together and we can go from there.

@telegraf-tiger telegraf-tiger bot removed the waiting for response waiting for response from contributor label Sep 7, 2023
@R290
Copy link
Contributor Author

R290 commented Sep 8, 2023

It seems that we are using quite an old Docker api version:

version = "1.24" // https://docs.docker.com/engine/api/

Somehow, the use of DiskUsageOptions is ignored in the older api version and all storage object types are always returned. Setting the the version to 1.42 (the latest at this moment) seems to resolve this. I don't know if we can just change this? All docker tests pass with 1.42.

@powersj
Copy link
Contributor

powersj commented Sep 8, 2023

Thanks for looking into this further.

I am good with updating the version. Looking through the Engine API version docs there are quite a number of changes, but it does look like they try to keep compatability.

@powersj powersj added the waiting for response waiting for response from contributor label Sep 8, 2023
@telegraf-tiger
Copy link
Contributor

Hello! I am closing this issue due to inactivity. I hope you were able to resolve your problem, if not please try posting this question in our Community Slack or Community Forums or provide additional details in this issue and reqeust that it be re-opened. Thank you!

@powersj powersj reopened this Sep 24, 2023
@telegraf-tiger
Copy link
Contributor

Hello! I am closing this issue due to inactivity. I hope you were able to resolve your problem, if not please try posting this question in our Community Slack or Community Forums or provide additional details in this issue and reqeust that it be re-opened. Thank you!

@R290
Copy link
Contributor Author

R290 commented Sep 25, 2023

The PR is still open, so no need to close the issue.

@telegraf-tiger telegraf-tiger bot removed the waiting for response waiting for response from contributor label Sep 25, 2023
@powersj powersj reopened this Sep 25, 2023
@powersj
Copy link
Contributor

powersj commented Sep 25, 2023

Not sure why the bot tried closing this again :\ hopefully with us commenting on it, it will go away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requests for new plugin and for new features to existing plugins
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants