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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/prometheus-users/7d0c3a70-7119-4849-b32a-0bd4b50e0af8n%40googlegroups.com.
