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
Any metrics for pull/push container image cost time? #4318
Comments
Do you mean how long it takes to pull an image, or when an image was pulled/pushed? An image is made up of multiple layers, some of which the client may or may not already have, so the registry is limited to what information is can provide - it doesn't know what the client is doing. |
So could registry know when the last layer of one image was pulled by client? Is it possible? Since the manifest would be pulled firstly, then the layers, could registry server get the last layer download time by the signed url? |
The client could pull the layers in any order, and may already have some layers and not pull them at all. There isn't a way for the registry to know how it happened. |
You can configure registry to emit notifications (aka events) for specific actions: https://distribution.github.io/distribution/about/notifications/ Then process that somehow async; another thing is, the latest release has tracing instrumentation so you can get some info from the captured traces |
@milosgajdos This notification seems to mean the image manifest pulled time. Could we know the whole layers of one image pulled events? |
No, we can't and never will be as we can't track every single API request. Distribution is a StATELESS content addressable proxy_. We do not maintain any state. You'll have to assemble the events belonging to the same "PUSH/PULL" async by some processing job. |
Description
Developers would like to know the pull/push time of an image tag, is any idea to share this metrics in distribution?
btw, kubelet's support for pulling image cost time is a good job, but it is not applicable to other container clients, such as docker cli/podman cli, etc.
The text was updated successfully, but these errors were encountered: