helm-zabbix
helm-zabbix copied to clipboard
SNMP Support
Any plans to add support for SNMP monitoring? Or am I missing something?
Hi @cfredericksen,
I don't get the point. What do you mean by "adding support for SNMP monitoring"? Zabbix is a monitoring tool and of course able to monitor not only via the Zabbix agent but using a wide variety of protocols, methods, etc. and SNMP is definitely in between them.
But as this is a Helm Chart to actually INSTALL and maintain Zabbix inside a Kubernetes/Openshift Cluster, it might be you are referring to something completely different?
Can you enlighten me?
Christian
Thanks for replying. My question is specific to the zabbix helm chart. I dont see any reference to port 161 (SNMP) in any of the docker images used or any of the kubernetes services. How can I send traps to a port that doesnt exist on a docker container?
Oh, I get the point. You are not speaking about SNMP but about SNMP traps, which would be receiving them using port 162 UDP. Software wise, this is a flow of data that needs of additional software:
- net-snmp's snmptrapd
- snmptt or a Perl script provided by Zabbix There is a container image from Zabbix achieving the above mentioned part: https://hub.docker.com/r/zabbix/zabbix-snmptraps. As of now, we have not worked with this yet, but it looks like this can be easily integrated by just adding this container image as a sidecar container to the Zabbix server Pod, and sharing a volume with Zabbix Server using an emptyDir volume. The only thing missing would then be an additional service, or an additional port for the existing Zabbix Server service, to receive those traps.
I may invest some time into this within the next weeks, but cannot promise to provide a working example within short time. I would rather like to see pull requests containing an extenstion of the examples provided within this helm chart and in case it would be necessary the needed extensions to make it work (service, ingress, ...)
Hi @sa-ChristianAnton!
Reading issues #22 and #20, perhaps we can resolve the three issues by setting zabbix-agentd2 to be installed even if zabbix-server and zabbix-proxy are disabled and adding the following helm values ββto add the other container for snmptraps according to the necessity . What do you think?
# -- Extra environment variables. A list of additional environment variables. See example: https://github.com/zabbix-community/helm-zabbix/blob/master/charts/zabbix/docs/example/kind/values.yaml
extraEnv: []
# -- annotations to add to the statefulset
statefulSetAnnotations: {}
# -- annotations to add to the containers
containerAnnotations: {}
# -- additional volumeMounts to the zabbix proxy container
extraVolumeMounts: []
# -- additional containers to start within the zabbix proxy pod
extraContainers: []
# -- additional init containers to start within the zabbix proxy pod
extraInitContainers: []
# -- additional volumes to make available to the zabbix proxy pod
extraVolumes: []
# -- additional specifications to the zabbix proxy pod
extraPodSpecs: {}
# -- extra volumeClaimTemplate for zabbixproxy statefulset
extraVolumeClaimTemplate: []
Agent is completely irrelevant for this one. But I agree with you that we could add some vars to both sections: zabbixserver and zabbixproxy to add the above mentioned image https://hub.docker.com/r/zabbix/zabbix-snmptraps container as a sidecar container to either of them, plus according and configurable services (ClusterIP, NodePort, ...). Regarding #22 and #20 I will answer there.
Hi all,
Also interested in having snmp trap support on the helm chart. I was using Zabbix in a VM, but I needed to migrate everything to K8s. As of now, I'm attempting to bypass it by working with Telegraf and InfluxDB. However, this adds a layer of complexity and it will require major adaptation on outside infra by introducing another agent.
I'm also interested in this feature
This subject has been discussed for some time I see, was there a resolution achieved ? I, too, am very interested with adding SNMP-trap to the deployment. ;-)
(very good work on the helmchart, in any case ππ»
I think if we add snmptraps as a side-car containers then there will be challenges with scaling of proxies, especially in upcoming zabbix 7 where we have some great features of load-balancing and proxy-grouping.
It may be better to add a deployment of a pod containing proxy & snmptrap which is dedicated for this purpose with shared volume in ReadWriteOnce Mode (snmptrap with write access and zabbix-proxy only read). That way we can export a new service with ports 10051 and 162 to receive inbound traffic. Depending on the load, we will be able to increase replicas.
For now, I created similar dedicated proxy with snamptrap manually with deployment files instead of helm chart.
Hey guys!
This feature has not evolved. Personally, I don't have the expertise to implement it or the equipment to test it. If anyone has enough knowledge and can open a Pull Request with the solution, I will be happy to do the code review.