Alertmanager: opsgenie: propagate label k/v to opsgenie details

Created on 2 Apr 2017  路  10Comments  路  Source: prometheus/alertmanager

See discussion in: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/prometheus-users/Jmpxr8O5fXI/JTdlyfjBDAAJ

By default map k/v labels to the details in opsgenie alert api: https://www.opsgenie.com/docs/web-api/alert-api#createAlertRequest

It makes sense to use this part of the api as the k/v style of labels maps nicely over to their API, as well as leaving more room for data (8k, vs tags which is max 20 tags, each 50 char =聽20x50=1000).

The more/better data is structured to opsgenie messages, the easier it is to route, and the richer the semantics of the messages will be.

areusability componennotify kinenhancement prioritPmaybe

Most helpful comment

I think it makes sense.

Or if we (@brian-brazil) are concerned that we don't want to populate the OpsGenie details field with random labels coming from alerts because they might have special semantics within an organization's context, we could still put the entire labelset under a top-level labels property in there: "details": { "labels": {"foo": "bar", "biz": "buz"} }. So it wouldn't pollute the entire details object with random properties. Really, as long as this is overrideable, I don't care too much either way...

All 10 comments

It makes sense to use this part of the api as the k/v style of labels maps nicely over to their API, as well as leaving more room for data (8k, vs tags which is max 20 tags, each 50 char = 20x50=1000).

This may make sense for you, does it make sense for all potential users?

I don't think it's safe to assume that a random label added by a developer to some /metrics should automatically appear here, as that label name may have special semantics in how that organisation uses opsgenie.

It does not necessarily match all users - but could at least match severals (as you see in the thread there was at least one picking up on it) - so having it as an option (a flag to activate it) would be nice - I can's see that it breaks anything at least.

@juliusv thoughts?

I think it makes sense.

Or if we (@brian-brazil) are concerned that we don't want to populate the OpsGenie details field with random labels coming from alerts because they might have special semantics within an organization's context, we could still put the entire labelset under a top-level labels property in there: "details": { "labels": {"foo": "bar", "biz": "buz"} }. So it wouldn't pollute the entire details object with random properties. Really, as long as this is overrideable, I don't care too much either way...

It will be pretty cool if i can decide what should be sent to opsgenie.
Current default should be changed from string: template to just template.
especially after group_all decision made

Hey guys :) Are you going to do this?
It'll be pretty cool to have something like:

    - name: opsgenie-general
      opsgenie_configs:
      - api_key: xxxxx
        message: XXX
        description: XXX
        teams: XXX
        priority: XXX
        labels_to_details: ['dashboard', 'action', 'system', 'service', 'server_role']

instead of:

    - name: opsgenie-general
      opsgenie_configs:
      - api_key: xxxxx
        message: XXX
        description: XXX
        teams: XXX
        priority: XXX
        details:
          dashboard: '{{- if .CommonLabels.dashboard -}}{{- .CommonLabels.dashboard -}}{{- end -}}'
          action: '{{- if .CommonLabels.action -}}{{- .CommonLabels.action -}}{{- end -}}'
          system: '{{- if .CommonLabels.system -}}{{- .CommonLabels.system -}}{{- end -}}'
          service: '{{- if .CommonLabels.service -}}{{- .CommonLabels.service -}}{{- end -}}'
          server_role: '{{- if .CommonLabels.server_role -}}{{- .CommonLabels.server_role -}}{{- end -}}'

@juliusv Is there any update on this?

I stand by my opinion https://github.com/prometheus/alertmanager/issues/682#issuecomment-310246499, but I'm not an Alertmanager maintainer. /cc @simonpasquier @stuartnelson3

I see how it can be useful but I'm not sure what's the best way to handle it in the configuration.

So far it seems that we have 2 slightly different requests:

  • append all of the common labels to the details field.
  • append a subset of the common labels.

Is this still open or closed fellas?
Also
Is there some sort of documentation on how to achieve this (Labels in prometheus to tags in Opsgenie)? I am trying to set it up in my environment and I dont find any sort of documentation available online.

Was this page helpful?
0 / 5 - 0 ratings