opsgenie.yaml

---
systems:
  opsgenie:
    description: |
      This system enables Honeydipper to integrate with `opsgenie`, so Honeydipper can
      react to opsgenie alerts and take actions through opsgenie API.

    meta:
      configurations:
        - name: API_KEY
          description: The API key used for making API calls to `opsgenie`
        - name: token
          description: >
            A token used for authenticate incoming webhook requests, every webhook request
            must carry a form field **Token** in the post body or url query that matches the value
        - name: path
          description: The path portion of the webhook url, by default :code:`/opsgenie`

      notes:
        - For example
        - example: |
            ---
            systems:
              opsgenie:
                data:
                  API_KEY: ENC[gcloud-kms,...masked...]
                  token: ENC[gcloud-kms,...masked...]
                  path: "/webhook/opsgenie"
        - Assuming the domain name for the webhook server is :code:`myhoneydipper.com', you should
          configure the webhook in your opsgenie integration with url like below
        - |
          .. code-block::

             https://myhoneydipper.com/webhook/opsgenie?token=...masked...

    data:
      API_KEY: _place_holder_
      token: _place_holder_
      path: "/opsgenie"

    functions:
      snooze:
        driver: web
        rawAction: request
        parameters:
          URL: https://api.opsgenie.com/v2/alerts/{{ .ctx.alert_Id }}/snooze?identifierType=tiny
          header:
            Content-Type: application/json; charset=utf-8
            Authorization: GenieKey {{ .sysData.API_KEY }}
          method: POST
          content:
            endTime: '{{ now.UTC.Add ( duration (default "+20m" .ctx.duration) ) | ISO8601 }}'
            user: honeydipper
            source: honeydipper
            notes: snoozed due to honeydipper automation
          retry: 2
        export:
          result: $data.json.result

        description: >
          This function will snooze the alert with given alert ID.

        meta:
          inputs:
            - name: alert_Id
              description: The ID of the alert to be snoozed
            - name: duration
              description: For how long the alert should be snoozed, use golang time format
          exports:
            - name: result
              description: The return result of the API call

          notes:
            - See below for example
            - example: |
                ---
                rules:
                  - when:
                      source:
                        system: opsgenie
                        trigger: alert
                    do:
                      if_match:
                        alert_message: :regex:test-alert
                      call_function: opsgenie.snooze
                      #  alert_Id is exported from the event

      schedules:
        driver: web
        rawAction: request
        parameters:
          URL: https://api.opsgenie.com/v2/schedules{{ with .ctx.scheduleId }}/{{ . }}?identifierType={{ default "name" $.ctx.scheduleIdType }}{{ end }}
          method: GET
          header:
            Authorization: GenieKey {{ .sysData.API_KEY }}
          form:
            limit: "100"
          retry: 2
        export:
          schedule: $data.json.data
          schedules: $data.json.data

        meta:
          description:
            - This function list all on-call schedules or fetch a schedule detail if given a schedule identifier.
            - highlight: This function only fetches first 100 schedules when listing.
              type: important

          inputs:
            - name: scheduleId
              description: The name or ID or the schedule of interest; if missing, list all schedules.
            - name: scheduleIdType
              description: The type of the identifier, :code:`name` or :code:`id`.
          exports:
            - name: schedule
              description: For fetching detail, the data structure that contains the schedule detail
            - name: schedules
              description: For listing, a list of data structure contains the schedule details

          notes:
            - See below for example
            - example: |
                ---
                workflows:
                  steps:
                    - call_function: opsgenie.schedules

      whoisoncall:
        driver: web
        rawAction: request
        parameters:
          URL: https://api.opsgenie.com/v2/schedules/{{ .ctx.scheduleId }}/on-calls
          method: GET
          header:
            Authorization: GenieKey {{ .sysData.API_KEY }}
          form:
            identifierType: $ctx.scheduleIdType,"name"
            flat: $ctx.flat,"true"
          retry: 2
        export:
          result: $data.json.data

        meta:
          description:
            - This function gets the current on-call persons for the given schedule.
            - highlight: Use the `opsgenie_whoisoncall`_ workflow instead.
              type: important

          inputs:
            - name: scheduleId
              description: The name or ID or the schedule of interest, required
            - name: scheduleIdType
              description: The type of the identifier, :code:`name` or :code:`id`.
            - name: flat
              description: If true, will only return the usernames, otherwise, will return all including notification, team etc.
          exports:
            - name: result
              description: the data portion of the json payload.


          notes:
            - See below for example
            - example: |
                ---
                workflows:
                  steps:
                    - call_function: opsgenie.whoisoncall
                      with:
                        scheduleId: sre_schedule

      users:
        driver: web
        rawAction: request
        parameters:
          URL: https://api.opsgenie.com/v2/users{{ with .ctx.userId }}/{{ . }}{{ end }}
          method: GET
          header:
            Authorization: GenieKey {{ .sysData.API_KEY }}
          form:
            offset: $ctx.opsgenie_offset,"0"
            query: $ctx.query,""
            order: $ctx.order,"asc"
            sort: $ctx.sort,""
          retry: 2
        export:
          user: $data.json.data
          users+: $data.json.data
          opsgenie_offset: '{{ with .data.json.paging }}{{ with .next }}{{ splitList "offset=" . | rest | first | splitList "&" | first }}{{ end }}{{ end }}'

        meta:
          description:
            - This function gets the user detail with a given ID or list all users

          inputs:
            - name: userId
              description: The ID of the user for which to get details; if missing, list users
            - name: offset
              description: Number of users to skip from start, used for paging
            - name: query
              description: >-
                :code:`Field:value` combinations with most of user fields to make more advanced searches.
                Possible fields are :code:`username`, :code:`fullName blocked`, :code:`verified`, :code:`role`,
                :code:`locale`, :code:`timeZone`, :code:`userAddress` and :code:`createdAt`
            - name: order
              description: The direction of the sorting, :code:`asc` or :code:`desc`, default is :code:`asc`
            - name: sort
              description: >-
                The field used for sorting the result, could be :code:`username`, :code:`fullname` or
                :code:`insertedAt`.
          exports:
            - name: user
              description: The detail of user in a map, or a list of users
            - name: users
              description: The detail of user in a map, or a list of users
            - name: opsgenie_offset
              description: The offset that can be used for continue fetching the rest of the users, for paging

          notes:
            - See below for example
            - example: |
                ---
                workflows:
                  steps:
                    - call_function: opsgenie.users
                      with:
                        query: username:foobar

      contact:
        driver: web
        rawAction: request
        parameters:
          URL: https://api.opsgenie.com/v2/users/{{ .ctx.userId }}/contacts
          method: GET
          header:
            Authorization: GenieKey {{ .sysData.API_KEY }}
          retry: 2
        export:
          contacts: $data.json.data

        description: >
          This function gets the user's contact methods

        meta:
          inputs:
            - name: userId
              description: The ID of the user for which to get contact methods
          exports:
            - name: contacts
              description: The detail of user's contact method in a map, or a list of user's contact methods

          notes:
            - See below for example
            - example: |
                ---
                workflows:
                  steps:
                    - call_workflow: do_something
                    - call_function: opsgenie.contact
                      with:
                        userId: username@example.com

      heartbeat:
        driver: web
        rawAction: request
        parameters:
          URL: https://api.opsgenie.com/v2/heartbeats/{{ .ctx.heartbeat }}/ping
          method: GET
          header:
            Authorization: GenieKey {{ .sysData.API_KEY }}
          retry: 2
        export:
          result: $data.json.result

        description: >
          This function will send a heartbeat request to opsgenie.

        meta:
          inputs:
            - name: heartbeat
              description: The name of the heartbeat as configured in your opsgenie settings
          exports:
            - name: result
              description: The return result of the API call

          notes:
            - See below for example
            - example: |
                ---
                workflows:
                  steps:
                    - call_workflow: do_something
                    - call_function: opsgenie.heartbeat
                      with:
                        heartbeat: test-heart-beat

    triggers:
      alert:
        driver: webhook
        if_match:
          method: POST
          form:
            token: $sysData.token
          url: '/opsgenie'
        export:
          alert_message: $event.json.alert.message
          alert_alias: $event.json.alert.alias
          alert_Id: $event.json.alert.tinyId
          alert_system: "opsgenie"
          alert_url: "https://opsg.in/a/i/{{ .event.json.alert.alertId }}"
          _event_id: $event.json.alert.tinyId
          _event_detail: |-
            ```{{ .event.json.alert.message }}
            {{ .event.json.alert.alias }}```
          _event_url: "https://opsg.in/a/i/{{ .event.json.alert.alertId }}"

        description: This event is triggered when an opsgenie alert is raised.
        meta:
          matching_parameters:
            - name: .json.alert.message
              description: This field can used to match alert with only certain messages
            - name: .json.alert.alias
              description: This field is to match only the alerts with certain alias
          exports:
            - name: alert_message
              description: This context variable will be set to the detailed message of the alert.
            - name: alert_alias
              description: This context variable will be set to the alias of the alert.
            - name: alert_Id
              description: This context variable will be set to the short alert ID.
            - name: alert_system
              description: This context variable will be set to the constant string, :code:`opsgenie`
            - name: alert_url
              description: This context variable will be set to the url of the alert, used for creating links
          notes:
            - See below snippet for example
            - example: |
                ---
                rules:
                  - when:
                      source:
                        system: opsgenie
                        trigger: alert
                      if_match:
                        json:
                          alert:
                            message: :regex:^test-alert.*$
                    do:
                      call_workflow: notify
                      with:
                        message: 'The alert url is {{ .ctx.alert_url }}'

workflows:
  opsgenie_users:
    steps:
      - call_function: opsgenie.users
      - while:
          - $?ctx.opsgenie_offset
        steps:
          - call_function: opsgenie.users

    meta:
      description:
        - This workflow wraps around the :code:`opsgenie.users` function and handles paging to get all users from Opsgenie.

  opsgenie_whoisoncall:
    description: get opsgenie on call table
    steps:
      - call_function: opsgenie.schedules
      - call_workflow: opsgenie_users
      - export:
          email_lookup: |
            :yaml:---
            {{ range .ctx.users }}
            "{{ .username }}": {{ .fullName }}
            {{ end }}
      - iterate: $ctx.schedules
        iterate_as: schedule
        steps:
          - if_any:
              - '{{ empty .ctx.schedule_pattern }}'
              - '{{ contains (lower .ctx.schedule_pattern) (lower .ctx.schedule.name) }}'
            call_function: opsgenie.whoisoncall
            with:
              scheduleId: $ctx.schedule.id
              scheduleIdType: id
            export:
              on_call_table: |
                :yaml:---
                {{ .ctx.schedule.name }}: {{ $sep := "" }}{{ range .ctx.result.onCallRecipients }}
                  {{- $sep }}
                  {{- if hasKey $.ctx.email_lookup . }}{{ index $.ctx.email_lookup . }}{{ else }}{{ . }}{{ end }}{{ $sep = "," }}
                {{- end }}
    no_export:
      - schedules
      - users
      - email_lookup

    meta:
      description:
        - This workflow wraps around multiple api calls to :code:`opsgenie` and produce a `on_call_table` datastructure.
      inputs:
        - name: schedule_pattern
          description: Optional, the keyword used for filtering the on call schedules.
      exports:
        - name: on_call_table
          description: A map from on call schedule names to lists of users.
      notes:
        - This is usually used for showing the on-call table in response to slash commands.
        - For example
        - example: |
            ---
            workflows:
              show_on_calls:
                with:
                  alert_system: opsgenie
                no_export:
                  - '*'
                steps:
                  - call: '{{ .ctx.alert_system }}_whoisoncall'
                  - call: notify
                    with:
                      notify*:
                        - reply
                      response_type: in_channel
                      blocks:
                        - type: section
                          text:
                            type: mrkdn
                            text: |
                              *===== On call users ======*
                              {{- range $name, $users := .ctx.on_call_table }}
                              *{{ $name }}*: {{ join ", " $users }}
                              {{- end }}