Remove default team tag (or overwrite it)
BetterToAutomateTheWorld opened this issue · 17 comments
Hi,
First of all, thank you for this great, well done and complete TF module to create Datadog monitors based on resources tags ! I'm really happy to find it :)
My issue :
I'm trying to use your module to create different monitors, but i noticed we can add tags (using "X_extra_tags" parameter), with the same name, but without the possibility to remove the default "team:claranet" tag or overwriting it, or I didn't find how to do it, can someone help me ? Or tell me what I missed :/
Example code, to reproduce :
module "datadog-monitors-cloud-aws-rds-common-xxx" {
source = "claranet/monitors/datadog//cloud/aws/rds/common" // AWS RDS PostgreSQL DB
version = "4.6.0"
environment = "PRD"
prefix_slug = "ABC"
message = "test - message RDS alert"
// filter_tags_custom Tags used for custom filtering when filter_tags_use_defaults is false string "*" no
// filter_tags_custom_excluded Tags excluded for custom filtering when filter_tags_use_defaults is false string "" no
// filter_tags_separator Set the filter tags separator (, or AND) string "," no
filter_tags_use_defaults = false
filter_tags_custom = "name:xxx" // "team:ABC" OR "*"
# CPU
cpu_enabled = true
cpu_extra_tags = ["team:ABC-ops", "service:subteam01"]
cpu_message = "cpu_message2"
cpu_threshold_critical = "90" // CPU usage in percent (critical threshold)
cpu_threshold_warning = "80" // CPU usage in percent (warning threshold)
# Diskspace
diskspace_enabled = true
diskspace_extra_tags = ["team:ABC-ops", "service:subteam01"]
diskspace_message = "diskspace_message"
diskspace_threshold_critical = 10 // Disk free space in percent (critical threshold)
diskspace_threshold_warning = 20 // Disk free space in percent (warning threshold)
diskspace_time_aggregator = "min"
diskspace_timeframe = "last_5m"
evaluation_delay = 300
# Replicalag
replicalag_enabled = false
replicalag_extra_tags = ["team:ABC-ops", "service:subteam01"]
# Connection Variance
connection_variance_enabled = false
connection_variance_extra_tags = ["team:ABC-ops", "service:subteam01"]
}
With this code example, I can see this on Datadog Platform :
Do we have a way to simply get ride of this "team:claranet" tag to put our team tag instead ? :)
Thank you !
Hi all,
Any news on this issue ?
@Aohzan @claranet We are prepared to help you with the Azure modules if this is an acceptable suggestion.
We think that all the default tags should be overridable. Our suggestion would be to move the set of default tags to a variable:
["env:${var.environment}", "type:cloud", "provider:azure", "resource:app-gateway", "team:claranet", "created-by:terraform"]
var default_tags {
type = list(string)
default = ["env:${var.environment}", "type:cloud", "provider:azure", "resource:app-gateway", "team:claranet", "created-by:terraform"]
}
#...
#in definitions:
tags = concat(var.default_tags, var.status_extra_tags)
Thoughts @BetterToAutomateTheWorld ?
hello, sorry I didn't this issue (thanks for the ping), I fix that
sorry for the time...it should be ok now, just set ŧeam = "ABC-ops"
@Aohzan Thank you very much for this 4.9.0 version with the team tag fix !
Your version 4.9.0 adds also the common locals/inputs, but i don't find any README about it, it seems my terraform init / plan are crashing on this new version, probably something i'm doing wrong :
My deployment is as following :
module "dd-monitors-dbxxxxxxx4508" {
source = "claranet/monitors/datadog//cloud/aws/rds/common"
version = "4.9.0"
environment = "PRD - dbxxxxxxx4508" // WTG Quant AWS PRD RDS (dbxxxxxxx4508) PostgreSQL DB
prefix_slug = "ABC"
message = "message RDS alert"
tags = [
"type:cloud",
"provider:aws",
"resource:rds"
]
team = "abc-ops"
common_tags = ["env:PRD - xxx", "team:abc-ops", "created-by:terraform"]
filter_tags_use_defaults = false
filter_tags_custom = "name:dbxxxxxxx4508" // "team:ABC" OR "*"
// filter_tags_custom_excluded = "" // Tags excluded for custom filtering when filter_tags_use_defaults is false string "" no
// filter_tags_separator = "" // Set the filter tags separator (, or AND) string "," no
# Database Connection Anomaly
connection_variance_enabled = false
connection_variance_extra_tags = ["team:abc-ops", "service:some-team"]
connection_variance_message = "Monitor triggered \n \n Notify : @teams-some-team-Data-Pipeline-Alerts"
# CPU Utilization
cpu_enabled = true
cpu_extra_tags = ["team:abc-ops", "service:some-team"]
cpu_message = "Monitor triggered \n \n Notify : @teams-some-team-Data-Pipeline-Alerts"
cpu_threshold_critical = "90" // CPU usage in percent (critical threshold)
cpu_threshold_warning = "70" // CPU usage in percent (warning threshold)
# Storage Utilization
diskspace_enabled = true
diskspace_extra_tags = ["team:abc-ops", "service:some-team"]
diskspace_message = "Monitor triggered \n \n Notify : @teams-some-team-Data-Pipeline-Alerts"
diskspace_threshold_critical = 10 // Disk free space in percent (critical threshold)
diskspace_threshold_warning = 20 // Disk free space in percent (warning threshold)
diskspace_time_aggregator = "min"
diskspace_timeframe = "last_5m"
evaluation_delay = 300
# Replicalag (Only for Cluster type)
replicalag_enabled = false
}
Looking at the common module inputs and locals : https://github.com/claranet/terraform-datadog-monitors/blob/master/common/module/inputs.tf
--> It seems it's hooking up to environment & tags I already defined
Also, i tried to add a common module block before the cloud/monitors/rds one, and it doesn't change anything (in case this common module is working like the alerting-message one :
module "datadog-common" {
source = "claranet/monitors/datadog//common/module"
version = "4.9.0"
environment = "PRD - xxx"
team = "abc-team"
}
But it doesn't change the result (same issue)
Do you have any idea how could I fixed this issue ?
are you on windows ? it looks like the symlink doesn't work 🤔
(you don't have to set the common_tags variable)
Yes, that's correct, as a testing purpose, i'm running a local terraform init / plan / apply on this shitty OS (windows) :/ (targetting a sandbox environment)
I can try with our GNU/Linux pipeline, but it means if 4.9.0 is used in our repository, all of our colleagues on Windows trying to run local TF deployment (to sandbox) will be blocked :'(
Is adding an option to deactivate the common/modules symlink even possible ? (since it's inside the repo, even if deactivated it will try to get it, i guess ?)
can you run in WSL or in a container ?
Not possible in my company network/security policy (for local/dev laptops), and even if it was, I'm not really sure we want it since it's a solution that disrupt way of working for hundreds of people :/
I didn't find a way to solve this for Windows' users, except duplicate the file x times but it's not really acceptable
There is some "solution" online: https://stackoverflow.com/questions/5917249/git-symbolic-links-in-windows
Otherwise, if it's only to local testing, maybe you can script to copy the common/module/inputs.tf and locals.tf to every module directory you use as common-module.tf and common-locals.tf ?
Yeah, none of the solutions are possible, or it's possible but extremely over complicated for something that simple as a symlink...
I guess we will stay on v4.8.0 and never move up, or choose another DD/Monitoring module if the tag is annoying us in the future (and i'm sad to say it 😢), It also means we can never move to 4.9.0 and above, to get new features/bugfixes, because local tests for 95% of our sandbox devs won't work anymore
(and doing a fork isn't acceptable, we use community module in the first place to avoid doing our own version of each module)
Don't worry, it's not your fault here, it's this shitty OS (Windows), your new common module feature was great (even if it doesn't bring any big improvements in our case, and we wouldn't have used it)
try with git clone -c core.symlinks=true https://github.com/claranet/terraform-datadog-monitors.git
Hi @Aohzan,
Sorry for my late answer ;
I don't really know what you want me to do with this git clone command, we're using the module as direct remote source from Terraform, using a module call similar to below :
module "datadog-monitors-cloud-aws-rds-common-xxx" {
source = "claranet/monitors/datadog//cloud/aws/rds/common" // AWS RDS PostgreSQL DB
version = "4.6.0"
[...]
}
From my understanding, this command can be useful only if we were using local module source, and therefore cloning using this command, right ?
you add the option in your global git config, and you will get smylink working on your local Windows
Hi @Aohzan,
Still not working following your instructions, and even following this step-by-step guide : https://devcoops.com/enable-symlinks-in-windows-vscode-git/
And i can follow these steps because i'm administrator (gitbash re-install with symlinks option checked, instead of using company store, etc.) on my Windows workstation, it's not the case for all of my coworkers... Again, it's a company laptop (OS image, GPOs, etc.), i doubt this symlinks enablement can be painlessly done all companies... (at least, it seems not in mine)
I started dropping your module since this morning for new Datadog interactions we needed, again, it's a shame...
I appreciate your help and possible solutions you gave us, even if it's not working in our side, thank you ! :)
Helloes! Just wanting to reopen this issue as the changes made to override the team:claranet tag for Datadog/Cloud/aws/rds/common has not been applied/fixed. I can open a new issue if need be.
FYI @Aohzan
I have made a PR #54
Script came through just fine
❯ ./scripts/auto_update.sh cloud/aws/rds/common
Check requirements
- Check command "terraform" exists and in right version
- Check command "terraform-docs" exists and in right version
- Check command "terraform-config-inspect" exists and in right version
- Check command "jq" exists and in right version
Generate terraform outputs.tf files for every monitors modules
- Generate outputs.tf for module: ./cloud/aws/rds/common
Generate symlinks files when does not exist for every monitors modules
Update global README.md
Update README.md for every monitors modules
- Generate README.md for module: ./cloud/aws/rds/common
README.md updated successfully@BetterToAutomateTheWorld hopefully this helps you too! :)