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

Allow filtering Source IP #45

Open
Kilobyte22 opened this issue Apr 24, 2024 · 1 comment
Open

Allow filtering Source IP #45

Kilobyte22 opened this issue Apr 24, 2024 · 1 comment

Comments

@Kilobyte22
Copy link

Kilobyte22 commented Apr 24, 2024

Currently this importer exports all received Reports in its metrics. However, in larger environments you may only be interested in reports caused by your own infrastructure. This is especially useful in combination with alerts to avoid situations where you get alerted but can't do anything about it.

I therefore propose one of the following two options:

  1. Provide a config setting of CIDRs. Only if the sender_ip is within one of these CIDRs, it will be reflected in the metrics
  2. Provide a config setting to classify certain IP ranges, adding another label to the metrics. For example you could configure something like "network-map": {"own-network": { "addrs": ["192.0.2.0/24"] } }, which would then add a label source_class="own-network" to any reports originating from 192.0.2.0/24, but set it to some default value for any other reports.

Option 2 would provide much flexibility and not ignore reports, but also has two downsides:

  • Even more labelsets, this exporter already creates quite a few in larger setups
  • More complexity for the implementation (though, probably not by much)

I am unsure if that's worth the tradeoff.

I may be able to provide a patch to address this, but no guarantees at this point.

@jgosmann
Copy link
Owner

jgosmann commented Apr 26, 2024

Some initial thoughts without having spend much time on this:

  • Mapping IP ranges to labels feels to me a bit like something that doesn't quite belong into dmarc-metrics-exporter. It seems a bit too complex to support a specific use case.
  • I think I'd be ok with exposing the source_ip as an additional label in theory. However, as you also mention, this would increase the cardinality of the metrics even more (at least if you've got multiple mail servers). Another problem is likely that it isn't convenient to filter for the desired IP ranges in PromQL.
  • Filtering by source_ip before aggregating metrics seems ok to me.
  • But I wonder whether this should be thought more generally, i.e. to have the option to filter on different fields of the report? Or some mechanism to configure what you want your metrics labeled with ... that would allow one to configure the desired cardinality depending on the use case. But it would still need some mechanism to declare how to put subnets into buckets for your use case and I'm not sure how that would look.

Edit: I'll be on vacation the next weeks. I might not respond again until I'm back.

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