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
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
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.
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.