Closed seifer44 closed 4 years ago
I've been trying for an hour, and I can't seem to get that solution to work. Besides, you could run into the following situation.
agent.yml
to include Team 1 and PM 1 in the to
field.@maratsal that issue is from a different plugin actually and wouldn't work for this plugin, as the logic for that plugin isn't built into this one. @seifer44 there are ways to achieve the workflow you're looking for using contact routing, but I'm kind of hung up on this bit:
However, this workaround still sends individualized emails to recipients, which doesn't work very well for everyone. It's nice to know who received the alert, and an email chain can easily get started based on the remediation of that alert.
Can you elaborate on that? ^ That sort of workflow sounds like you're asking for read receipts to me. Is there something out there that you've seen that does this sort of thing?
If the To
field for a single email message, through this plugin, consists of:
To: team1@example.com; team2@example.com; user1@example.com
Then everyone can easily be on the same page when someone uses Reply All. The same logic can be applied if you add in the CC
field.
@seifer44 and @maratsal Did anyone of you got multiple recipients running in Sensu go?
If I use an array (as suggested by @maratsal) I get the following error when executing sensuctl create -f test-check.yaml
:
resource 0: error parsing spec: json: cannot unmarshal array into Go struct field ObjectMeta.metadata.annotations of type string
Error: in definitions/checks/test-check.yaml: some resources couldn't be parsed
Using semicolons resulted in a runtime error of sensu-email-handler
.
I'm willing to give this a shot. I like to have a CC on all my alert emails and using filters with a routing logic is ok in a pinch but defeats the reason why I am CCing.
I actually have done an email client like this before in Go, however it was using "github.com/go-mail/mail". I would need try and test using the net/smtp and net/mail.
Also, I have used viper before so we could use a string slice and be able to just multiple of the same flag: -t user1@email.com -t user2@email.com.
When I did this before I did go for comma delimited -t "user1@email.com, user2@email.com" because the tool I was using sent the data that way. Having multiple -t is a little bit slicker. You guys have any preference? I'm not sure if you can use tokens in handlers or if there is any plan to but that would be a scenario where comma delimited might be better.
sensu-email-handler -t user1@email.com -t user2@email.com -t user3@email.com vs sensu-email-handle -t "user1@email.com, user2@email.com, user3@email.com"
I do think we should stick with coma vs semi colon. Coma is rfc822 which is what net/mail is following. rfc822
Destination address fields
The destination fields of a message consist of three possible fields, each of the same form: The field name, which is either "To", "Cc", or "Bcc", followed by a comma-separated list of one or more addresses (either mailbox or group syntax).
to = "To:" address-list CRLF
cc = "Cc:" address-list CRLF
@seifer44 PR in for multiple recipients via multiple -t flags and/or commas. For your other idea using annotations, I would suggest opeingn a separate issue if you think it is still needed? Otherwise it might get buried.
Issue #22 touched on this briefly, but was closed, as another user suggested utilizing separate handlers for each contact. However, this workaround still sends individualized emails to recipients, which doesn't work very well for everyone. It's nice to know who received the alert, and an email chain can easily get started based on the remediation of that alert.
The ability to have multiple recipients in the
to
andcc
fields (and maybe evenbcc
while we're at it) would be beneficial. I don't really understand why this wasn't a feature from the start.On top of it, the ability to allow users to "subscribe" to all alerts from a host (when they normally only go to another team), by CCing them through annotations on the host, would be great.