Thanks for sharing your ideas. Chris Siebenmann schrieb am Montag, 19. Februar 2024 um 21:08:02 UTC+1:
> > In our DataCenter we have different security zones. In each zone I > > want to place a blackbox_exporter. The goal is that each > > blackbox_exporter monitors the same destinations eg. same DNS Server > > or same webserver. All exporters are controlled by one single > > prometheus server. > > > > If someone complains that something is wrong, slow or whatever I want > > to have the possibility to compare each blackbox_exporter to > > understand if there was an issue with the service (destnation) or the > > newtwork or something else. > > > > I will have 26 blackbox exporter system in the DC. Each should use the > > same destinations, protocols, etc. Is there a way to simplify my > > configuration to not have 26 different configuration parts but merge > > this into one part? > > > > at the moment the configuration is only different in three places: > > - job name > > - custom label > > - replacement (IP of blackbox_exporter) > > > > Here an example which would result in 26 different configuration parts > > and ideally I only want to have one configuration part because if I > > want to add another test then I need to edit all 26 files again. > > It's possible to do somewhat better than what you've got today, but I > don't think there's any native Prometheus way out of having 26 different > stanzas, one for each Blackbox exporter, because there's no way of > either iterating over something in a stanza or nesting service discovery > (as far as I know). Doing better would require additional tools to > automatically generate something. > > The simple way to improve things is to list all of the targets to be > checked in a service discovery file. If you have multiple checks you > want to do against each target, you can also include the module as a > label: > > - targets: > - https://hostname1.domain/ > - https://hostname2.domain/ > # hopefully this works, if not add a label rewrite for > # 'module' or something > labels: > __param_module: http_post_2xx > > (Don't trust the exact YAML indentation here, I'm hand-writing it.) > > Then each blackbox DC job would look like: > - job_name: 'blackbox_job_02' > file_sd_configs: > files: > - yourstuff/blackbox-list.yaml > relabel_configs: > - source_labels: [__address__] > target_label: __param_target > - source_labels: [__param_target] > target_label: instance > - target_label: __address__ > replacement: blackbox_job_02.domain:9115 > > Then at least you can add additional targets to be checked in some way > in one place (the 'blackbox-list.yaml' file), instead of having to > update all of the blackbox DC job configurations. But if you want to add > or remove another blackbox DC instance, you'd still have to edit it in > or out by hand. > > If you're in a position to automate generating the 'blackbox-list.yaml' > file, you could also put the blackbox DC target in an additional label > (say 'dc_blackbox: blackbox_job_02.domain:9115') and have a single > Blackbox configuration stanza, which would set __address__ at the end > with a label rewrite that would look something like this: > - target_labels: [dc_blackbox] > replacement: __address__ > > You need to automatically generate the blackbox-list.yaml file because > you're going to be repeating all of the targets N times, one for each > blackbox DC. > > - cks > -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/d866f1c7-23e4-42e2-8e3b-246f5d91074cn%40googlegroups.com.
