SNMP Support

[cfredericksen]

Any plans to add support for SNMP monitoring? Or am I missing something?

[sa-ChristianAnton]

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

[cfredericksen]

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?

[sa-ChristianAnton]

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

[aeciopires]

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: []

[sa-ChristianAnton]

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.

[nunodsfernandes]

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.

[q1x]

I'm also interested in this feature