-
Notifications
You must be signed in to change notification settings - Fork 32
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
[RFE] Add detector notification_policy for BigPanda #339
Comments
Hello @drissamri
these attributes are free and you can configure the value you want while you respect the signalfx provider format: https://registry.terraform.io/providers/splunk-terraform/signalfx/latest/docs/resources/detector#notification-format in your case and from your example, you should be able to use something like: locals {
alerts_notifications = "Team,${var.sfx_team_id}","BigPanda,${var.bigpanda_credentialsid}"
notifications = {
critical = local.alerts_notifications
major = local.alerts_notifications
minor = local.alerts_notifications
warning = local.alerts_notifications
info = ["Team,${var.sfx_team_id}"]
} does it make sens ? |
I can misunderstand but in your case I think the real problem is the lack of bigpanda integration support in the signalfx provider. So you basically cannot retrieve the bigpanda credentials id from Terraform. In contrast, PagerDuty has:
In general, we (at Claranet) use a Terraform module which take care of configuring the alerting integration and we reuse its ID in notifications variables for detectors in this repo. For example for pagerduty we have the following output https://github.com/claranet/terraform-signalfx-integrations/blob/master/alerting/pagerduty/outputs.tf#L13 which is ready to be append in For BigPanda I am afraid you will have:
|
About your usage of I would like to suggest to give a look to https://github.com/claranet/terraform-signalfx-detectors/wiki/Tagging-convention. So I recommend in general to use a tagging convention (either the default on this repo or your custom one) and rely on this policy to import only once the module which will monitor all functions respecting this convention. From this way you have a dynamic monitoring and any new function added to your aws account (with the right tags of course) will be added to monitoring without the need to update you variable list manually. That said you can have plenty of good reasons that I ignore to do that and it works but I generally do not "multi instance" a same module until I need to have different configuration for different resources (thresholds, notifications recipients ...): https://github.com/claranet/terraform-signalfx-detectors/wiki/Guidance#Multi-instantiation |
Thank you for your quick response, I will take this up with our SignalFX support people to see if we can get this integrated inside their terraform module! Thank you. 🥇 |
I did not know that, thanks for letting me know. I have forwarded this to our company team owning our terraform set up to take a better look at this! 👍 |
Is your feature request related to a problem? Please describe.
Add a notification policy to forward detector alerts from SignalFX to BigPanda
Describe the solution you'd like
Additionally next to the team notification policy I'd like to add a BigPanda policy too
Additional context
https://docs.splunk.com/Observability/admin/notif-services/bigpanda.html#step-3-add-a-bigpanda-integration-as-a-detector-alert-recipient-in-observability-cloud
The text was updated successfully, but these errors were encountered: