maxwo / snmp_notifier

A webhook to relay Prometheus alerts as SNMP traps, because sometimes, you have to deal with legacy
Apache License 2.0
53 stars 33 forks source link

Configure the docker image to set the SNMP destination via environment variable #172

Closed franck54730 closed 8 months ago

franck54730 commented 9 months ago

What did you do? We are trying to use this snmp_notifier docker image to send Prometheus Alert (In an Openshift cluster) to a Solarwind instance

What did you expect to see? I would expect to have a environment variable to set the SNMP destination, I don't understand why it's not the case, so I wonder if this use case is managed.

What did you see instead? Under which circumstances?

I saw four env variables to setup the snmp_notifier run in the docker image :

SNMP_NOTIFIER_COMMUNITY SNMP_NOTIFIER_AUTH_USERNAME SNMP_NOTIFIER_AUTH_PASSWORD  SNMP_NOTIFIER_PRIV_PASSWORD

I wonder if we could modify the file configuration.go in order to override the snmp.destination value as it's done for the four others

Environment Openshift container Plateform 4.10

sh-4.4$ alertmanager --version
alertmanager, version 0.23.0 (branch: rhaos-4.10-rhel-8, revision: 65e93ba8e0ee8d9a09df2d682e7d170560d05b86)
  build user:       root@4f9012b22b61
  build date:       20221006-15:26:42
  go version:       go1.17.12
  platform:         linux/amd64

I don't know what is the good approch here, should I rebuild an image with the destination configurable ? is there any reason to not do it ?

I guess that the http server was design to be put at the same place than the SNMP Server at the beginning, and that the docker part came on top, but as it's a guess I would like to know if there is technical reason to wont do.

Kr,

Franck

maxwo commented 9 months ago

Hi Franck,

Environment variables support have been added to the image and tool to avoid credentials leaks, and use OpenShift/Kubernetes secrets natively.

Given you are using an OpenShift deployment, it should be possible to specify a --snmp.destination=$(DESTINATION) command in your deployment, then, inject a DESTINATION environment variable that contains your actual destination if you really want to use an environment variable. (Although I still think it is easier to specify a --snmp.destination=my.destination:162 directly into your deployment, as there is no secret about it).

It is rather designed to be placed anywhere, and configurable to take several cases into account, including a server sharing the same machine as the destination, or not. So your use-case is actually managed. It is possible to specify any destination, and any other argument, from the command line.

Unless there is something I am missing, I think there should be no problem about your use-case: the arguments of the Docker container are forwarded to the actual snmp_notifier binary inside the container.

franck54730 commented 9 months ago

First of all, many thanks for your quick reply :)

Indeed I didn't think about that solution, I think it would be a good idea to add a /openshift (Or /kubernetes) folder and put a sample of deployment.yml to do such things.

I will make a try in my context, and if I can give you some anonymized sample I will.

Good day

franck54730 commented 9 months ago

I was able to run a pod with such deployment.yml

kind: Deployment
apiVersion: apps/v1
metadata:
  name: example
  namespace: test-snmp-notifier
spec:
  replicas: 1
  selector:
    matchLabels:
      app: snmp-notifier
  template:
    metadata:
      labels:
        app: snmp-notifier
    spec:
      volumes:
        - name: description-template-volume
          configMap:
            name: snmp-notifier-description-template
            items:
              - key: description-template
                path: description-template.tpl
            defaultMode: 420
      containers:
        - resources: {}
          terminationMessagePath: /dev/termination-log
          name: httpd
          ports:
            - containerPort: 8080
              protocol: TCP
          imagePullPolicy: Always
          volumeMounts:
            - name: description-template-volume
              mountPath: /var/description-template.tpl
              subPath: description-template.tpl
          terminationMessagePolicy: File
          image: >-
            maxwo/snmp-notifier:latest
          args:
            - '--web.listen-address=:8080'
            - '--snmp.destination=127.0.0.56:162'
            - '--snmp.trap-description-template=/var/description-template.tpl'

With that CM :

kind: ConfigMap
apiVersion: v1
metadata:
  name: snmp-notifier-description-template
  namespace: test-snmp-notifier
data:
  description-template: |-
    {{- if .Alerts -}}
    {{ len .Alerts }}/{{ len .DeclaredAlerts }} alerts are firing:

    {{ range $severity, $alerts := (groupAlertsByLabel .Alerts "severity") -}}
    Status: {{ $severity }}

    {{- range $index, $alert := $alerts }}
    - Alert: {{ $alert.Labels.alertname }}
      Summary: {{ $alert.Annotations.summary }}
      Description: {{ $alert.Annotations.description }}
    {{ end }}
    {{ end }}
    {{ else -}}
    Status: OK
    {{- end -}}

I could not setup a end to end test for now as I requiered some Firewall to be open, but when it's done I will confirm that all is ok.

(Only things that I will check further is why I don't have the default template, I need to put it in a config map to make it work)

Again many thanks for your help

maxwo commented 9 months ago

Actually, you should consider using or inspire from that helm chart for deploying into a Kubernetes-like cluster: https://github.com/prometheus-community/helm-charts/tree/main/charts/alertmanager-snmp-notifier

I regularly do end-to-end tests when updating the helm chart, so, it should fit your use-case. Let me know if you encounter issues with the notifier.

maxwo commented 9 months ago

Note: the template is located in /etc/snmp_notifier/description-template.tpl in the default image. Since you are overriding the default image arguments, I think you can use the following arguments:

          args:
            - '--web.listen-address=:8080'
            - '--snmp.destination=127.0.0.56:162'
            - '--snmp.trap-description-template=/etc/snmp_notifier/description-template.tpl'

And get rid of the extra ConfigMap.