Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filtering, multiple SNMP exporters #4

Open
Yannis100 opened this issue Oct 29, 2019 · 3 comments
Open

Filtering, multiple SNMP exporters #4

Yannis100 opened this issue Oct 29, 2019 · 3 comments
Assignees

Comments

@Yannis100
Copy link

Yannis100 commented Oct 29, 2019

Hey !

Just read your blog post regarding Prometheus and Netbox, thanks, very interesting!
I plan to use your project, and I want to add filtering of retrieved devices (including auto-filtering of the master device of Virtual-Chassis devices) based on any field (tenant, region, ...)

We're using Blackboxes as SNMP exporter on each site location, which means the target_label: __address__ replacement should be dynamic based on the device site. I think there is no other solution than multiple jobs.
I would like to include snmp module selection based on device_type + role instead of __snmp_module__ in Netbox prom_labels field

I was considering using jinja templates before I found your more elegant solution.
And also, I want to have the prometheus jobs config file generated automatically, probably the only way if I want 1 job per site / role

What do you think about this?
I'll share my achievements in the following weeks

@NaPs NaPs self-assigned this Oct 30, 2019
@NaPs
Copy link
Member

NaPs commented Oct 30, 2019

Hi Yannis!

I plan to use your project, and I want to add filtering of retrieved devices (including auto-filtering of the master device of Virtual-Chassis devices) based on any field (tenant, region, ...)

Filtering can be implemented using the Prometheus relabeling feature with the "drop" action. Details here: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config. Is this helps you? It would avoid to implement something complex into the project.

We're using Blackboxes as SNMP exporter on each site location, which means the target_label: address replacement should be dynamic based on the device site. I think there is no other solution than multiple jobs.

A solution I imagined (but never implemented) to address this problem is a kind of inheritance of the target_label custom field. The target_label custom field would be also created on tenant / parent / rack / pop / site and precedence between duplicate labels is made on a "most specific" basis (eg: label defined on rack take precedence on the one defined on the site) . This way, you can override the __address__ label for all devices located on a site and all the data (including the SNMP targets IPs) are stored in Netbox and not the Prometheus config.

I would like to include snmp module selection based on device_type + role instead of snmp_module in Netbox prom_labels field

I'm not sure to understand what you want to achieve here, but I prefer to avoid to implement a behavior specific to an exporter or an usage. Is this can be implemented using the relabeling feature?

Antoine

@Yannis100
Copy link
Author

Thanks for your answer!

For the filtering, using 'drop' might help but as our Netbox database is quite big, I would prefer to filter when gathering rather than processing. I don't think it will be too hard to implement, either using argparse or a separated "config file".
The "hard" part is to translate the args to filters but the only line that will change (L.19) is

devices = netbox.dcim.devices.filter(manufacturer=manufacturers, has_primary_ip=True, tenant=filterTenant, status=1)

A solution I imagined (but never implemented) to address this problem is a kind of inheritance of the target_label custom field.

This could be great, we currently "extrapolate" the target_label replacement from site (pop) slug with a template name, but a custom_field can be good too

I'm not sure to understand what you want to achieve here, but I prefer to avoid to implement a behavior specific to an exporter or an usage. Is this can be implemented using the relabeling feature?

The idea is to be able to specify a module name extrapolated from other values than the prom_labels custom field like: {$device_manufacturer}_{$device_role}
I understand you prefer to avoid implementing this kind of specific behavior, it was just an idea to increase flexibility in usage but I'm not sure there is a good way to implement it, I'll let you know.

To help you understand my need, I attached the script we wrote internally
cfgGenerator.zip

@NaPs
Copy link
Member

NaPs commented Jan 7, 2020

Hi Yannis, really sorry for my silence. Hard to find time to work on this project right now. Do not hesitate to propose a PR, I'll take time to review and merge it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants