Update keepalived config generation

[hhromic]

This PR refreshes the Keepalived config generation, i.e. MIB files from upstream (latest stable version 2.2.7).

Summary of changes:

• updated KEEPALIVED-MIB and VRRP-MIB MIB URLs to latest version from upstream
• added support for VRRPv3-MIB MIB from upstream (new vrrpv3StatisticsTable walk)
• regenerated keepalived section in snmp.yml using the above changes

These changes were tested with a production instance of Keepalived exposing SNMP metrics.

---

Changes for KEEPALIVED-MIB:

-     LAST-UPDATED "202006120001Z"
+     LAST-UPDATED "202109230001Z"

+     REVISION "202109230001Z"
+     DESCRIPTION "add twos LVS scheduler"
+     REVISION "202109090001Z"
+     DESCRIPTION "correct syntax of vrrpInstanceIndex"
+     REVISION "202109040001Z"
+     DESCRIPTION "add vrrp multicast address"
+     REVISION "202106050001Z"
+     DESCRIPTION "add snmp_name for virtual and real servers"

Changes for VRRP-MIB: unchanged from upstream

[SuperQ]

Nice, thanks.

Do you think it would be useful to use type: EnumAsStateSet for vrrpv3StatisticsNewMasterReason?

[SuperQ]

The mixin error is likely unrelated to this.

[hhromic]

Nice, thanks.

Happy to contribute to the project!

Do you think it would be useful to use type: EnumAsStateSet for vrrpv3StatisticsNewMasterReason?

I'm definitively not an expert on SNMP data and its exposure as Prometheus metrics. In fact, keepalived is the only application I needed to use the SNMP exporter because it doesn't have a native Prometheus exporter.

That being said, it looks like vrrpv3StatisticsNewMasterReason is not the only metric in the keepalived configuration that has state enumerations (i.e. being a "reason"). I can see other metrics (even previously existing) that could benefit as well. So, for consistency, those could also be typified as EnumAsStateSet. I'm not sure how much of a breaking change that would be.

For that reason, perhaps that would be better suited in another PR? Especially from someone with more experience than me?

Btw, a slightly off-topic question, is there a new version of the SNMP exporter planned in the near future that could include this change and other updates to the snmp.yml file? At the moment we are forced to build a custom image of the SNMP exporter that includes this file :(

[SuperQ]

Yes, it's fine to make that a separate PR.

There is no reason you need to wait for a new release to use these changes. You don't need to build a new image to change the file.

For Docker, you only need to use a volume mount to map in a custom config file.

[hhromic]

Yes, it's fine to make that a separate PR.

Sounds good! Thanks!

There is no reason you need to wait for a new release to use these changes. You don't need to build a new image to change the file.

For Docker, you only need to use a volume mount to map in a custom config file.

Yes, we are well aware of Docker basic functionality such as volume mounts. However, we use the SNMP exporter inside a cluster with an orchestrator (Swarm mode in our case), not a simple Docker container. This means that mounting a file into a service is quite cumbersome and requires either keeping the file in all nodes or pinning the container to a specific node. Sadly, none of these options is a good idea for maintainability and/or high availability.

The alternative would be to deploy the file as a configuration in the orchestrator and then reference it into the stack compose file. However, the snmp.yml is very large and greatly surpasses the content limit in Docker for configs (500kb). Thus this is also not possible for us.

Therefore, the only feasible alternative for us (and probably others that run the SNMP exporter in an orchestrator) is to create a custom image with the updated snmp.yml file inside :(

Hope the above helps the argument of releasing a new version of the official image at least with the snmp.yml file refreshed.

[SuperQ]

I wasn't aware that Swarm clusters had such limitations.

Either way, no, we it doesn't really change our release plans. The included generator.yml / snmp.yml is mostly meant as an example config. Not something meant for general production use. We cut releases for code/binary changes.

[hhromic]

Either way, no, we it doesn't really change our release plans. The included generator.yml / snmp.yml is mostly meant as an example config. Not something meant for general production use. We cut releases for code/binary changes.

No problem! Your release policy makes sense.
I was mostly asking about a release to set our expectations and plan accordingly. Now that this PR is merged (thanks!), we can document our temporary solution indicating that, when the next version is released, we can go back to the official image, whenever that happens. No rush!

And thanks for all the work you guys do in Prometheus et al. It is much appreciated.