fix(kafka sink): Use rdkafka::client::Client instead of Consumer #21129
Conversation
|
|
984830c to
df464ab
Compare
There was a problem hiding this comment.
Thank you @belltoy !
I think the only thing this is missing is a changelog entry describing the fix for users. Do you mind adding one? You can see https://github.com/vectordotdev/vector/blob/master/changelog.d/README.md for what this looks like. In this case I'd say something like:
The `kafka` sink no longer emits warnings due to applying rdkafka options to a consumer used for the health check. Now it uses the producer client for the health check.
authors: belltoy
|
Thanks @belltoy ! |
Head branch was pushed to by a user without write access
36b1f5e to
8e6a0ca
Compare
|
I've force pushed to fix the code style |
Regression Detector ResultsRun ID: d9894925-a8b0-4ee2-ba8f-6dc1e1a0d7a1 Metrics dashboard Baseline: 82fd2a5 Performance changes are noted in the perf column of each table:
Significant changes in experiment optimization goalsConfidence level: 90.00%
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | links |
|---|---|---|---|---|---|
| ➖ | file_to_blackhole | egress throughput | +0.29 | [-6.53, +7.10] |
Fine details of change detection per experiment
| perf | experiment | goal | Δ mean % | Δ mean % CI | links |
|---|---|---|---|---|---|
| ✅ | otlp_http_to_blackhole | ingress throughput | +6.02 | [+5.90, +6.14] | |
| ➖ | socket_to_socket_blackhole | ingress throughput | +3.87 | [+3.81, +3.92] | |
| ➖ | syslog_humio_logs | ingress throughput | +3.24 | [+3.11, +3.38] | |
| ➖ | splunk_hec_route_s3 | ingress throughput | +2.94 | [+2.61, +3.27] | |
| ➖ | http_text_to_http_json | ingress throughput | +2.34 | [+2.19, +2.50] | |
| ➖ | syslog_loki | ingress throughput | +2.28 | [+2.19, +2.36] | |
| ➖ | fluent_elasticsearch | ingress throughput | +2.16 | [+1.66, +2.66] | |
| ➖ | datadog_agent_remap_datadog_logs_acks | ingress throughput | +1.72 | [+1.51, +1.92] | |
| ➖ | syslog_log2metric_tag_cardinality_limit_blackhole | ingress throughput | +1.63 | [+1.47, +1.79] | |
| ➖ | datadog_agent_remap_blackhole_acks | ingress throughput | +1.39 | [+1.27, +1.51] | |
| ➖ | syslog_regex_logs2metric_ddmetrics | ingress throughput | +1.39 | [+1.22, +1.56] | |
| ➖ | syslog_log2metric_splunk_hec_metrics | ingress throughput | +0.99 | [+0.87, +1.12] | |
| ➖ | http_to_http_acks | ingress throughput | +0.86 | [-0.46, +2.18] | |
| ➖ | syslog_splunk_hec_logs | ingress throughput | +0.40 | [+0.31, +0.49] | |
| ➖ | file_to_blackhole | egress throughput | +0.29 | [-6.53, +7.10] | |
| ➖ | otlp_grpc_to_blackhole | ingress throughput | +0.15 | [+0.04, +0.27] | |
| ➖ | http_to_http_noack | ingress throughput | +0.10 | [+0.03, +0.17] | |
| ➖ | http_to_http_json | ingress throughput | +0.02 | [-0.01, +0.06] | |
| ➖ | splunk_hec_to_splunk_hec_logs_noack | ingress throughput | +0.02 | [-0.08, +0.13] | |
| ➖ | splunk_hec_indexer_ack_blackhole | ingress throughput | -0.01 | [-0.09, +0.07] | |
| ➖ | splunk_hec_to_splunk_hec_logs_acks | ingress throughput | -0.02 | [-0.16, +0.11] | |
| ➖ | http_to_s3 | ingress throughput | -0.03 | [-0.30, +0.24] | |
| ➖ | datadog_agent_remap_blackhole | ingress throughput | -0.27 | [-0.39, -0.16] | |
| ➖ | datadog_agent_remap_datadog_logs | ingress throughput | -0.31 | [-0.51, -0.11] | |
| ➖ | http_elasticsearch | ingress throughput | -1.05 | [-1.23, -0.88] | |
| ➖ | syslog_log2metric_humio_metrics | ingress throughput | -2.07 | [-2.22, -1.91] |
Explanation
A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".
For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:
-
Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
-
Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.
-
Its configuration does not mark it "erratic".
…tordotdev#21129) * fix(kafka sink): Use rdkafka::client::Client instead of Consumer for Kafka sink healthcheck Discussed in vectordotdev#20510 * style(kafka sink): Use string interpolation in error string formatting * docs: add changelog fragment
Use
rdkafka::client::Clientinstead of Consumer in Kafka sink healthcheckDiscussed in #20510