betorvs / sensu-opsgenie-handler

Sensu Go Opsgenie Handler https://sensu.io
MIT License
2 stars 10 forks source link

team parameter not honored #15

Closed crypted256 closed 3 years ago

crypted256 commented 3 years ago

since version 1.0.0 the --team parameter does nothing. The parameter is required for the handler to run, but if i set the parameter isn't passed on to the opsgenie responders attribute.

It also doesn't work if I use the OPSGENIE_TEAM environment variable or the override on the check with "sensu.io/plugins/sensu-opsgenie-handler/config/team"

Example: cat /tmp/alert.json | sensu-opsgenie-handler --team "Test"

cynici commented 3 years ago

Hi @betorvs

I have experienced exactly the same issue using the latest version 1.0.1.

I specified both

sensu.io/plugins/sensu-opsgenie-handler/config/priority
sensu.io/plugins/sensu-opsgenie-handler/config/team

Priority is honored but not Team.

I have tried older versions and found that the problem started when the code switched to use opsgenie sdk-v2 in version 1.0.0

Opsgenie "responders" is propagated correctly in older version 0.0.10 and 0.1.0 but I can't use them because the handler insists on either OPSGENIE_TEAM environment variable or --team. My use-case requires the team value to be set in the alert itself.

betorvs commented 3 years ago

Thanks @cynici I will take a look. Do you have time to work on this fix?

cynici commented 3 years ago

Thanks for your prompt response @betorvs

I wish I could but I don't know Go lang at all. 😰

cynici commented 3 years ago

@betorvs FWIW, comparing the two Opsgenie SDK versions, it seems v2 requires each responder to have an explicit type e.g. user, team, etc. not present in v1 SDK.

https://docs.opsgenie.com/docs/opsgenie-go-api-v2#samples-for-alert-sdk

betorvs commented 3 years ago

Hi @cynici , I'm reading here opsgenie's documentation and I believe they changed the sensu basic integration. Take a look into this page: https://docs.opsgenie.com/docs/sensu-integration It shows old sensu logo. They have a Dynamic Field called Teams: {{teams}}. More info about this: https://docs.opsgenie.com/docs/draggable-fields

My guess is if you add these dynamic fields it will be honoured. My free subscription don't give me this permission. Maybe a Responders field.

I tested with this new line:

diff --git a/main.go b/main.go
index d0144c5..eb546b0 100644
--- a/main.go
+++ b/main.go
@@ -377,6 +377,7 @@ func createIncident(alertClient *alert.Client, event *types.Event) error {
        teams := []alert.Responder{
                {Type: alert.EscalationResponder, Name: plugin.Team},
                {Type: alert.ScheduleResponder, Name: plugin.Team},
+               {Type: alert.TeamResponder, Name: plugin.Team},
        }

        title, alias, tags := parseEventKeyTags(event)

But still not working.

betorvs commented 3 years ago

Since this is not working as expected, i will update it without requiring it to run opsgenie handler. @cynici and @crypted256 what do you think about it? Any new ideas?

betorvs commented 3 years ago

I tested an old release 0.1.0 with my free subscription and it doesn't accept Teams assignment too. I will change it to not require any teams flags.

betorvs commented 3 years ago

About this issue, i found it in Opsgenie Docs If the API Key belongs to a team integration, this field will be overwritten with the owner team. in Json Body Fields in responders line.

Using this new release 1.0.2, I checked in opsgenie Logs that this plugin sent the correct data to Opsgenie but this integration belongs to ops team and when I checked in Opsgenie it was assigned to ops team.

{
  "_result": {
    "alertAction": "create",
    "integrationName": "ops_Sensu",
    "integrationActionName": "Create Alert"
  },
  "alertLogOwner": "Alert API",
  "alertId": "0834fd49-...-1616537835947",
  "_incomingData": {
    "_parsedData": {
      "note": "null",
      "-responders": [
        "sre"
      ],
      "-actions": [],
      "-tags": [
        "webserver01",
        "check-nginx",
        "default",
        "agent"
      ],
      "alias": "webserver01/check-nginx",
      "description": "example output",
      "source": "sensuGo",
      "message": "webserver01/check-nginx",
      "priority": "P5",
      "user": "Alert API",
      "_extraProperties": {
        "hooks_0_disk_space_output": "/dev/mapper/cl-root 230G 150G 80G 66% /\n/dev/nvme0n1p2 1014M 244M 771M 25% /boot\n/dev/nvme0n1p1 200M 12M 189M 6% /boot/efi\nFilesystem Size Used Avail Use% Mounted on",
        "subscriptions": "[testing]",
        "hooks_0_disk_space_label_sensu.io/managed_by": "sensuctl",
        "hooks_0_disk_space_label_sensu.io/workflow": "sensu-flow",
        "interval": "20",
        "hooks_0_disk_space_command": "df -hl -x tmpfs -x overlay -x devtmpfs|sort -r -k 5 -n",
        "status": "1"
      },
      "entity": "webserver01"
    },
    "integrationType": "Sensu",
    "integrationName": "ops_Sensu",
    "incomingDataId": "efc059b6-...ee4d43"
  },
  "alertLogType": "system"
}
betorvs commented 3 years ago

@crypted256 and @cynici I added new flags --escalation-team and --schedule-team, please feel free to test and give me any feedback. As I explain it before, maybe even if we send the correct information to opsgenie, it will overwritten it. Maybe when we create the integration it should be done in a different way and don't use sensu go default one. If anyone of you test it and found a solution, please let me know. I will research it.

cynici commented 3 years ago

Thank you very much @betorvs for version 1.0.2

I have tested by adding both these annotations to my test events, Opsgenie log shows that the responder and priority are received correctly.

      "annotations": {
        "sensu.io/plugins/sensu-opsgenie-handler/config/priority": "P5",
        "sensu.io/plugins/sensu-opsgenie-handler/config/team": "my_team"
      },
crypted256 commented 3 years ago

@betorvs I've also tested our use case and it works as expected. Team selection via --team or via annotations works. Thanks a lot for your work.