If you want to minimize your work, you can write a test as a one-shot standalone program in any language of your choice, and either: 1. Run it from cron, write the results to a file, and pick them up by node_exporter textfile collector; OR 2. Run it on demand from exporter_exporter <https://github.com/QubitProducts/exporter_exporter> using the "exec" method; OR 3. Run it as a nagios plugin under nrped, and query it from nrpe_exporter <https://www.robustperception.io/nagios-nrpe-prometheus-exporter/>
Options 1 and 2 involve generating openmetrics output, which is very simple. Option 2 is good if you want the check to be triggered on every scrape. Option 1 is good if the check is expensive and you don't want to overload the target. I wouldn't choose option 3 unless you're already deep into nagios plugins. There are issues with the ancient crypto used to talk to nrped. On Saturday, 14 December 2024 at 07:51:59 UTC Stewart Webb wrote: > Hi folks, > > At my workplace we have been working recently with Fluentbit and its > Fluent Forward protocol, which is an efficient binary msgpack protocol for > transmitting string or key-value logs with timestamps - see > https://github.com/fluent/fluentd/wiki/Forward-Protocol-Specification-v1.5 > . > > I've been hoping to set up a blackbox-style status check for Fluent > Forward endpoints. However after some research, it turns out the current > blackbox_exporter repo can't cater to this need because it doesn't really > have a probing module in it that will work for this. The tcp module almost > gets me there, but the request/response probing support it has only works > for newline-delimited protocols like SMTP. See > https://github.com/nuclearpidgeon/fluent-forward-blackbox-testing for a > writeup I've done on the details here. > > Now, I can fork blackbox_exporter and add my own prober for the Fluent > Forward protocol, but maintaining a fork would be a pain, and I also feel > like the main blackbox_exporter project probably wouldn't really want to > host and maintain an extra prober type that's so specific to one particular > program/protocol, given the currently supported protocols are really > generic ones like HTTP, ICMP, DNS, and gRPC. > > My current approach is trying to fork blackbox_exporter down into a > complete shell version that has none of the existing generic probers in it > and then just adding back in my one new probe to that shell, with the plan > of being able to publish this as a standalone project that can accomplish > what we need while being something that I wouldn't have to worry much about > pulling in upstream updates into. > > In theory the TCP module in blackbox_exporter could alternatively be > updated to support specifying binary-protocol request/response probing, but > I feel like a generic feature like that might be a lot harder to build and > get right, especially if any semantic parsing of the response is required. > > If anyone here has some advice for my mild dilemma here, it'd be great to > hear from you. (and if any maintainers of blackbox_exporter are around here > it'd be *really* great to hear from you...) > > Cheers, > Stewart Webb > -- 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 prometheus-users+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/prometheus-users/7d0c3a70-7119-4849-b32a-0bd4b50e0af8n%40googlegroups.com.
