Closed franck54730 closed 8 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.
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.
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:
Prometheus version:
SNMP notifier command line:
Prometheus alert file:
Logs:
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