feat: Implement byte matching in TCP query responses #1112
Conversation
tacho
force-pushed
the
fix-postgres-tls-probes
branch
from
21d61c5 to
ac9bb34
Compare
|
Is there any ETA for this PR merge? |
|
I was wondering the same - it's been two months without any reaction. Is this project dead, or abandoned? |
|
+1 on this PR, we have the same issue which will be fixed after the merge |
|
+1 on this PR too, would be nice to have this builtin |
|
+1 if we can use blackbox exporter also for postgres |
|
FYI, here's a demo code to get Postgres cert info via TrustManager when connecting to the server https://github.com/Raymondmax/PostgresCert/blob/main/main.java |
Currently the exporter only supports lines, which breaks byte-oriented protocols such as the PostgreSQL StartTLS handshake. We also give a working example for Postgres in the sample configuration. Signed-off-by: Stanislav Grozev <[email protected]>
tacho
force-pushed
the
fix-postgres-tls-probes
branch
from
ac9bb34 to
6cd70e8
Compare
| @@ -159,6 +160,31 @@ func ProbeTCP(ctx context.Context, target string, module config.Module, registry | |||
| probeFailedDueToRegex.Set(0) | |||
| send = string(qr.Expect.Regexp.Expand(nil, []byte(send), scanner.Bytes(), match)) | |||
| } | |||
| if qr.ExpectBytes != "" { | |||
There was a problem hiding this comment.
This looks OK to me.
I would prefer to have stronger validation in the configuration, because as this section of the code shows, it's possible to specify both a regular expression and the sequence of bytes to be read, and I'm not sure how that's going to play together. If you think specifying both at the same time makes sense, I would like to see an example (and also a test).
My hunch is that it has to be either the regular expression or the specific sequence of bytes, but not both at the same time.
There was a problem hiding this comment.
Yeah, makes sense it would be one or the other - protocols are either line oriented or not. I'll adjust the patch soon.
There was a problem hiding this comment.
It would be awesome if we get this MR merged and release :)
There was a problem hiding this comment.
I would also want expect and expect_bytes to be mutually exclusive.
protocols are either line oriented or not. I'll adjust the patch soon.
@tacho is this done? I am happy to give it another review once the comments are addressed.
|
Any update on this? |
|
+1 would be great to be able to check my PG cert expiry via blackbox_exporter |
| @@ -159,6 +160,31 @@ func ProbeTCP(ctx context.Context, target string, module config.Module, registry | |||
| probeFailedDueToRegex.Set(0) | |||
| send = string(qr.Expect.Regexp.Expand(nil, []byte(send), scanner.Bytes(), match)) | |||
| } | |||
| if qr.ExpectBytes != "" { | |||
There was a problem hiding this comment.
I would also want expect and expect_bytes to be mutually exclusive.
protocols are either line oriented or not. I'll adjust the patch soon.
@tacho is this done? I am happy to give it another review once the comments are addressed.
| @@ -182,9 +182,11 @@ regexp: <regex>, | |||
| [ source_ip_address: <string> ] | |||
|
|
|||
| # The query sent in the TCP probe and the expected associated response. | |||
| # expect_bytes does exact byte-by-byte match. | |||
There was a problem hiding this comment.
can we mention that expect and expect_bytes are mutually exclusive?
we do mention it for body and body_file in http_probe, and few other places.
Currently the exporter only supports lines, which breaks byte-oriented protocols such as the PostgreSQL StartTLS handshake.
We also give a working example for Postgres in the sample configuration.
Fixes: #801