How to create an email alert?

[jul...@julianberks.com]

Hi,

I'm trying to create a cloudwatch alert to send an email when an alarm condition is breached.

The aws_cloudwatch_log_metric_filter and aws_cloudwatch_metric_alarm functions allow me to create the alarm condition but I can't find any way to create the subsequent action or email group.

The docs say to reference an arn but not how to create that object. Does Terraform have the ability to create an alert email and email recipient group?

[David Adams]

I assume you are looking for aws_sns_topic: https://www.terraform.io/docs/providers/aws/r/sns_topic.html

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terraform-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/cd9295c2-d7d9-48e5-84cc-0cc0af80d771%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jul...@julianberks.com]

On Tuesday, October 18, 2016 at 4:39:39 PM UTC+1, David Adams wrote:

I assume you are looking for aws_sns_topic: https://www.terraform.io/docs/providers/aws/r/sns_topic.html

 

Hi David,

Yes, that was precisely what I was looking for. Thanks

I note that many of these technologies lack worked examples (the docs are little more than cryptic command references) so for anyone else trying to put terraformed cloudwatch alerts together, this is what I ended up with

resource "aws_sns_topic" "xxxx_cloudwatch_notifications" {
  name = "xxxx_cloudwatch_notifications"
}

/*
Email is unsupported - configure the subscription manually.
resource "aws_sns_topic_subscription" "xxxx_cloudwatch_notifications" {
    topic_arn = "${aws_sns_topic.xxxx_cloudwatch_notifications.arn}"
    protocol  = "email"
    endpoint  = "an.o...@gmail.com"
}
*/

resource "aws_cloudwatch_log_metric_filter" "xxxx_api_startup" {
  name = "xxxx-api-startup"
  pattern = "Starting xxxxApplication"
  log_group_name = "${aws_cloudwatch_log_group.xxxx_api_container.name}"

  metric_transformation {
    name = "xxxx-api-startup-counter"
    namespace = "LogMetrics"
    value = "1"
  }
}

resource "aws_cloudwatch_metric_alarm" "xxxx_api_startup" {
    alarm_name = "xxxx-api-startup"
    comparison_operator = "GreaterThanOrEqualToThreshold"
    evaluation_periods = "2"
    metric_name = "xxxx-api-startup-counter"
    namespace = "LogMetrics"
    period = "300"
    statistic = "Sum"
    threshold = "2"
    alarm_description = "This alerts if the xxxx Api container reboots twice in 10 mins"
 alarm_actions = ["${aws_sns_topic.xxxx_cloudwatch_notifications.arn}"]
    insufficient_data_actions = []
depends_on=["aws_sns_topic.xxxx_cloudwatch_notifications"]
}

[David Adams]

If you understand what you want in AWS, the Terraform docs are almost always more than sufficient. It's true that Terraform docs do not explain how AWS resources work, but neither should they. I will admit that AWS-provided docs are almost always very hard to understand and lack important information, but there are other resources such as https://github.com/open-guides/og-aws (I have not looked into this deeply so I don't know how extensive/accurate it actually is). The best way to understand it all, in my experience, is just to try stuff out and see what works and doesn't. That's one of the reasons Terraform is such an amazing tool because it lets you tear down and start over so easily, which is critical to learning how to make all the pieces work together.

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terraform-tool+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/aa585648-88fa-40d7-a8c9-fcc618267031%40googlegroups.com.

[jul...@julianberks.com]

On Wednesday, October 19, 2016 at 2:09:56 PM UTC+1, David Adams wrote:

If you understand what you want in AWS, the Terraform docs are almost always more than sufficient. It's true that Terraform docs do not explain how AWS resources work, but neither should they. I will admit that AWS-provided docs are almost always very hard to understand and lack important information, but there are other resources such as https://github.com/open-guides/og-aws (I have not looked into this deeply so I don't know how extensive/accurate it actually is). The best way to understand it all, in my experience, is just to try stuff out and see what works and doesn't. That's one of the reasons Terraform is such an amazing tool because it lets you tear down and start over so easily, which is critical to learning how to make all the pieces work together.

 

I agree to a point. I've been using terraform for a couple of months now and I agree - once I'm comfortable with which command and what parameters I need it is pretty straight forward. I just find the ref page and walk through the parameters. Where I think the docs fail is where you're not really tuned into what you're doing yet. You're new to terraform and new to AWS. Proprietary tech (I've been working with Oracle tech for many years)  tends to have worked examples that you run with, hack around, break and put back together. With most open source such as Terraform, you know what the parameters are but what some of them relate to -  you're really on your own.

Take a simple case of this example.

The metric transformation has a name. It seemed logical to me that this was an attribute of the log metric filter. So, when referencing the metric name for the alarm, the documentation states "The name for the alarm's associated metric." Not very helpful but fine - that would be aws_cloudwatch_log_metric_filter.xxx_ui_startup.startup_counter. Wrong. Ok but where would I look to find my mistake. Worse, AWS accepts anything without validation so it goes in just fine. A worked example would have shown me immediately where my understanding of what the transformation was wrong and that it's actually a unique entity within the namespace in it's own right. Instead, I had to create manually and compare aspects until it clicked. I accept some of this stuff is obvious to many but when a small misunderstanding creeps in, there is really nowhere to turn.

That said, I also accept that open source projects don't have teams of paid technical writers putting the docs and worked examples together and developers (me included) can often assume a much greater level of understanding on the part of the reader than is truly there.

Sometimes we just need a nudge in the right direction, such as the one you kindly gave me.

cheers

JB