-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
feat: add some new labels to every container #4324
base: next
Are you sure you want to change the base?
Conversation
I get why this would be needed overall but I have a questions:
|
Because environment variables aren't collected by cAdvisor or anything I think. I suppose there's a way to tweak something, but with labels it works straight away. cAdvisor collects them, and I can use them in my PromQL queries ( Prometheus ) |
Is there anything I can do to help move this PR forward or we just need some time? Let me know if anything is needed 🙂 |
$labels->push('coolify.type=database'); | ||
$labels->push('coolify.databaseId='.$database->id); | ||
$labels->push('coolify.resourceName='.Str::slug($database->name)); | ||
$labels->push('coolify.serviceName='.Str::slug($database->name)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why add a service name for a database?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be consistent with the others containers that have a coolify.serviceName
label.
This way, we can rely solely on coolify.serviceName
everywhere (for example, in our PromQL queries) to fetch metrics about a container. If we don’t add coolify.serviceName
, we’ll be forced to write tedious conditions everywhere: checking for the presence of coolify.serviceName
, and if it’s not available, falling back to coolify.resourceName
.
Also that's why I said coolify.serviceName
might not be the best name. Maybe we can find something better
$labels->push('coolify.databaseId='.$database->id); | ||
$labels->push('coolify.resourceName='.Str::slug($database->name)); | ||
$labels->push('coolify.serviceName='.Str::slug($database->name)); | ||
$labels->push('coolify.projectName='.Str::slug($database->project()->name)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you add a project name, you can also add the environment name.
Changes
I strongly encourage to read the comment that initiated this PR: #3569 (comment)
TL;DR: The main issue is the difficulty in monitoring due to automatically generated container names. Currently, when I look at my Grafana/cAdvisor dashboard tracking CPU usage for each container managed by Coolify, I only see cuid names , which makes it impossible to identify what each container corresponds to.
So we need a way to have "human-readable" names for each container. This PR addresses the issue by adding three new labels to each container managed by Coolify :
coolify.resourceName
: The name of theApplication
orService
coolify.projectName
: The name of the project where the resource livescoolify.serviceName
: This one might be a bit confusing, and perhaps we can find a better name. If the resource is of typeService
, it will be the sub-service name. If it's of typeApplication
, it will be the application name. This label is necessary because, using my monitoring use case as an example, I need metrics/logs for each of my containers. To differentiate them, I need a unique name. If I'm using aService
, I can't rely oncoolify.resourceName
since all the services in my docker-compose file would have the same value. I hope this explanation makes sense.This is my first contribution to Coolify, and I'm not familiar with PHP either, so feel free to point out any corrections or improvements I should made
( And thanks a lot for making Coolify 💙 )
Issues