docker: strip version from container_image tag

[skyrocknroll]

Feature Request

Opening a feature request kicks off a discussion.

Proposal:

Splitting the docker_container_image tag to * docker_container_image* and * docker_container_image_tag*

Current behavior:

Right now the whole image& tag is sent as a single tag in docker_container_image

Desired behavior:

Splitting the docker_container_image tag to * docker_container_image* and * docker_container_image_tag*

Use case: [Why is this important (helps with prioritizing requests)]

Right now we use build number as docker image tag for each micro service
Ex: authenticate:34 Whenever we deploy the new release the image tags changes to different one like authenticate:35
Because of that we need to edit query every time to see latest image metrics after each deployment. We cannot use container_name because nomad uses it to store {job-name}-{allocation-id}. So every deployment container name going to be random.

In this way it does not break the current functionality also adds ability to unify or distinguish based on image tag

[skyrocknroll]

@sparrc What do you think of this ?

[sparrc]

@skyrocknroll I'm not sure I understand the feature request 100%, but I will say that it is highly recommended that you don't tag metrics with tags that frequently change.

Can you give a more concrete example of your current and desired tags?

[skyrocknroll]

@sparrc I completely agree on your point on don't increase the cardinality unnecessarily.
current tag:
docker_container_image = authenticate:34

required tag:
docker_container_image = authenticate
docker_container_image_tag = "34"

Lets say there are two types of user who uses docker for deployments

• Who uses a different image tag for each deployment (authenticate:34 , authenticate:35 , authenticate:36)

1. In this case the the current docker_container_image is going to change for each deployment. because the current docker_container_image tag is always going to change for each deployment.
2. If we split the current docker_container_image_tag to docker_container_image authenticate and docker_container_image_tag 34 then docker_container_image is not going to change but the docker_container_image_tag will change.

In the above two cases whether we split it or not the cardinality of the tags is going to increase.

• Who uses same image tag for each deployment (authenticate:prod) --> prod image tag will always point to the stable image.

1. In this case the the docker_container_image and docker_container_image_tag is not going to change at all even if we split or don't split it for each deployment.

In the above case whether we split it or not the cardinality of the tags is not going to increase.

So the conclusion is the cardinality is increasing or stay same depends on the type of deployment user is doing and does not depends on splitting or non splitting of the docker image tag.

[sparrc]

why do you add a number to your docker container image? I have never seen that practice and I don't think it's recommended. Do you have a reference that recommends that practice?

[sparrc]

I think what you're asking for is only for a "version" tag, if it exists, is that correct?

Do you think that could actually be a field? That way we can actually reduce the current cardinality.

[skyrocknroll]

@sparrc It is the build number(or version numbers).
We use docker for its immutability. If we tag the latest stable to point to authenticate:prod then when doing the docker ps we don't know what version of code is deloyed, is it actually running latest code in all the machines where the microservice is deployed or some of the machines has old version of the code.

The problem right now we are facing is we use nomad to do the deployment and nomad unless the tag name is changed nomad does not pull the updated image from the repo.

[sparrc]

so are you changing the image name or are you using a version tag?

[skyrocknroll]

@sparrc we change the version tag.
Ex :
we change authenticate:34 to authenticate:35
In the above case image name is same authenticate , only the version tag changes 34 to 35

[sparrc]

@skyrocknroll got it, I thought you were changing the image name, I agree that we should strip the version tag off of the image name in the container_image tag.

making it another tag though worries me in terms of cardinality, would you be opposed to making it a field?

[skyrocknroll]

@sparrc Awesome 🎯 We can put the version tag in field 👍

[sparrc]

@skyrocknroll I've gone ahead and put the version into a tag, as that will keep cardinality the same, and I think it's reasonable assuming users aren't going to be updating the version more than 100,000 times in one measurement ;-)

[skyrocknroll]

@sparrc Awesome 👍