maxwo/snmp_notifier

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

franck54730 opened this issue · 5 comments

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

  • System information:

    Not relevant

  • SNMP notifier version:

    The one in the docker image, main branch

  • Alertmanager version:

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
  • Prometheus version:
sh-4.4$ prometheus --version
prometheus, version 2.32.1 (branch: rhaos-4.10-rhel-8, revision: 6e08107deec46c951a975014b175543eb5e44d4a)
  build user:       root@4f9012b22b61
  build date:       20221006-15:29:41
  go version:       go1.17.12
  platform:         linux/amd64
  • SNMP notifier command line:
The one in the Dockerfile
  • Prometheus alert file:
Default Openshift alert file
  • Logs:
No logs yet as we didn't run anythings, we are trying to integrate for now.

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

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.

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

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

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

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.