Skip to content

feat(codecs): Add CEF encoder#17389

Merged
jszwedko merged 8 commits intovectordotdev:masterfrom
deckhouse:cef-encoder
Nov 8, 2024
Merged

feat(codecs): Add CEF encoder#17389
jszwedko merged 8 commits intovectordotdev:masterfrom
deckhouse:cef-encoder

Conversation

@nabokihms
Copy link
Contributor

Connected to #17332
Implemented according to the guide.

@nabokihms nabokihms requested a review from a team May 15, 2023 12:50
@netlify
Copy link

netlify bot commented May 15, 2023

Deploy Preview for vector-project canceled.

Name Link
🔨 Latest commit 0446f38
🔍 Latest deploy log https://app.netlify.com/sites/vector-project/deploys/64632dc2758ab10008c01326

@netlify
Copy link

netlify bot commented May 15, 2023

Deploy Preview for vrl-playground ready!

Name Link
🔨 Latest commit 0446f38
🔍 Latest deploy log https://app.netlify.com/sites/vrl-playground/deploys/64632dc2fb5418000888008f
😎 Deploy Preview https://deploy-preview-17389--vrl-playground.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@github-actions github-actions bot added domain: codecs Anything related to Vector's codecs (encoding/decoding) domain: external docs Anything related to Vector's external, public documentation labels May 15, 2023
@github-actions
Copy link

Regression Detector Results

Run ID: 16b6b5ff-a6ae-40a2-9e45-d224f06a1f18
Baseline: c683999
Comparison: e0dce38
Total vector CPUs: 7

Explanation

A regression test is an integrated performance test for vector in a repeatable rig, with varying configuration for vector. What follows is a statistical summary of a brief vector run for each configuration across SHAs given above. The goal of these tests are to determine quickly if vector performance is changed and to what degree by a pull request.

Because a target's optimization goal performance in each experiment will vary somewhat each time it is run, we can only estimate mean differences in optimization goal relative to the baseline target. We express these differences as a percentage change relative to the baseline target, denoted "Δ mean %". These estimates are made to a precision that balances accuracy and cost control. We represent this precision as a 90.00% confidence interval denoted "Δ mean % CI": there is a 90.00% chance that the true value of "Δ mean %" is in that interval.

We decide whether a change in performance is a "regression" -- a change worth investigating further -- if both of the following two criteria are true:

  1. The estimated |Δ mean %| ≥ 5.00%. This criterion intends to answer the question "Does the estimated change in mean optimization goal performance have a meaningful impact on your customers?". We assume that when |Δ mean %| < 5.00%, the impact on your customers is not meaningful. We also assume that a performance change in optimization goal is worth investigating whether it is an increase or decrease, so long as the magnitude of the change is sufficiently large.

  2. Zero is not in the 90.00% confidence interval "Δ mean % CI" about "Δ mean %". This statement is equivalent to saying that there is at least a 90.00% chance that the mean difference in optimization goal is not zero. This criterion intends to answer the question, "Is there a statistically significant difference in mean optimization goal performance?". It also means there is no more than a 10.00% chance this criterion reports a statistically significant difference when the true difference in mean optimization goal is zero -- a "false positive". We assume you are willing to accept a 10.00% chance of inaccurately detecting a change in performance when no true difference exists.

The table below, if present, lists those experiments that have experienced a statistically significant change in mean optimization goal performance between baseline and comparison SHAs with 90.00% confidence OR have been detected as newly erratic. Negative values of "Δ mean %" mean that baseline is faster, whereas positive values of "Δ mean %" mean that comparison is faster. Results that do not exhibit more than a ±5.00% change in their mean optimization goal are discarded. An experiment is erratic if its coefficient of variation is greater than 0.1. The abbreviated table will be omitted if no interesting change is observed.

No interesting changes in experiment optimization goals with confidence ≥ 90.00% and |Δ mean %| ≥ 5.00%.

Fine details of change detection per experiment.
experiment goal Δ mean % Δ mean % CI confidence
datadog_agent_remap_blackhole ingress throughput +3.32 [+3.22, +3.43] 100.00%
datadog_agent_remap_blackhole_acks ingress throughput +2.27 [+2.17, +2.36] 100.00%
http_text_to_http_json ingress throughput +2.01 [+1.94, +2.07] 100.00%
splunk_hec_route_s3 ingress throughput +0.79 [+0.64, +0.93] 100.00%
syslog_splunk_hec_logs ingress throughput +0.38 [+0.30, +0.46] 100.00%
syslog_loki ingress throughput +0.24 [+0.16, +0.31] 100.00%
socket_to_socket_blackhole ingress throughput +0.20 [+0.16, +0.25] 100.00%
enterprise_http_to_http ingress throughput +0.03 [-0.00, +0.06] 74.49%
http_to_http_noack ingress throughput +0.01 [-0.04, +0.06] 22.49%
splunk_hec_to_splunk_hec_logs_acks ingress throughput -0.00 [-0.06, +0.06] 0.15%
fluent_elasticsearch ingress throughput -0.00 [-0.00, +0.00] 47.54%
splunk_hec_indexer_ack_blackhole ingress throughput -0.01 [-0.05, +0.03] 26.17%
splunk_hec_to_splunk_hec_logs_noack ingress throughput -0.02 [-0.06, +0.03] 41.97%
file_to_blackhole ingress throughput -0.03 [-0.09, +0.03] 46.70%
syslog_log2metric_splunk_hec_metrics ingress throughput -0.35 [-0.43, -0.26] 100.00%
http_to_http_json ingress throughput -0.47 [-0.54, -0.40] 100.00%
http_to_http_acks ingress throughput -1.24 [-2.45, -0.03] 81.18%
datadog_agent_remap_datadog_logs_acks ingress throughput -1.26 [-1.37, -1.16] 100.00%
datadog_agent_remap_datadog_logs ingress throughput -1.50 [-1.59, -1.40] 100.00%
otlp_grpc_to_blackhole ingress throughput -2.29 [-2.40, -2.17] 100.00%
syslog_regex_logs2metric_ddmetrics ingress throughput -2.33 [-2.54, -2.11] 100.00%
otlp_http_to_blackhole ingress throughput -2.88 [-3.04, -2.72] 100.00%
syslog_humio_logs ingress throughput -2.92 [-3.00, -2.83] 100.00%
syslog_log2metric_humio_metrics ingress throughput -3.08 [-3.18, -2.97] 100.00%

@jszwedko jszwedko requested a review from fuchsnj May 15, 2023 16:31
@jszwedko
Copy link
Collaborator

Thanks for this @nabokihms ! Just a quick note that the best reviewer for this is on PTO this week, but we'll get this reviewed more thoroughly this upcoming week.

@jszwedko jszwedko requested a review from neuronull May 15, 2023 16:32
@jszwedko
Copy link
Collaborator

Tagging @neuronull here too since it is somewhat akin to the GELF codec.

@github-actions
Copy link

Regression Detector Results

Run ID: 4b8e05b7-a99d-4edb-8e7c-6c956330d469
Baseline: 9703188
Comparison: b540ef4
Total vector CPUs: 7

Explanation

A regression test is an integrated performance test for vector in a repeatable rig, with varying configuration for vector. What follows is a statistical summary of a brief vector run for each configuration across SHAs given above. The goal of these tests are to determine quickly if vector performance is changed and to what degree by a pull request.

Because a target's optimization goal performance in each experiment will vary somewhat each time it is run, we can only estimate mean differences in optimization goal relative to the baseline target. We express these differences as a percentage change relative to the baseline target, denoted "Δ mean %". These estimates are made to a precision that balances accuracy and cost control. We represent this precision as a 90.00% confidence interval denoted "Δ mean % CI": there is a 90.00% chance that the true value of "Δ mean %" is in that interval.

We decide whether a change in performance is a "regression" -- a change worth investigating further -- if both of the following two criteria are true:

  1. The estimated |Δ mean %| ≥ 5.00%. This criterion intends to answer the question "Does the estimated change in mean optimization goal performance have a meaningful impact on your customers?". We assume that when |Δ mean %| < 5.00%, the impact on your customers is not meaningful. We also assume that a performance change in optimization goal is worth investigating whether it is an increase or decrease, so long as the magnitude of the change is sufficiently large.

  2. Zero is not in the 90.00% confidence interval "Δ mean % CI" about "Δ mean %". This statement is equivalent to saying that there is at least a 90.00% chance that the mean difference in optimization goal is not zero. This criterion intends to answer the question, "Is there a statistically significant difference in mean optimization goal performance?". It also means there is no more than a 10.00% chance this criterion reports a statistically significant difference when the true difference in mean optimization goal is zero -- a "false positive". We assume you are willing to accept a 10.00% chance of inaccurately detecting a change in performance when no true difference exists.

The table below, if present, lists those experiments that have experienced a statistically significant change in mean optimization goal performance between baseline and comparison SHAs with 90.00% confidence OR have been detected as newly erratic. Negative values of "Δ mean %" mean that baseline is faster, whereas positive values of "Δ mean %" mean that comparison is faster. Results that do not exhibit more than a ±5.00% change in their mean optimization goal are discarded. An experiment is erratic if its coefficient of variation is greater than 0.1. The abbreviated table will be omitted if no interesting change is observed.

No interesting changes in experiment optimization goals with confidence ≥ 90.00% and |Δ mean %| ≥ 5.00%.

Fine details of change detection per experiment.
experiment goal Δ mean % Δ mean % CI confidence
syslog_humio_logs ingress throughput +2.85 [+2.77, +2.94] 100.00%
syslog_log2metric_splunk_hec_metrics ingress throughput +2.39 [+2.28, +2.50] 100.00%
splunk_hec_route_s3 ingress throughput +2.13 [+1.99, +2.27] 100.00%
datadog_agent_remap_datadog_logs ingress throughput +0.65 [+0.53, +0.77] 100.00%
syslog_loki ingress throughput +0.50 [+0.39, +0.61] 100.00%
socket_to_socket_blackhole ingress throughput +0.35 [+0.30, +0.41] 100.00%
http_text_to_http_json ingress throughput +0.31 [+0.23, +0.39] 100.00%
http_to_http_json ingress throughput +0.30 [+0.25, +0.35] 100.00%
otlp_http_to_blackhole ingress throughput +0.28 [+0.10, +0.47] 94.56%
otlp_grpc_to_blackhole ingress throughput +0.26 [+0.14, +0.37] 99.57%
file_to_blackhole ingress throughput +0.04 [-0.01, +0.09] 69.37%
enterprise_http_to_http ingress throughput +0.03 [-0.00, +0.06] 76.17%
http_to_http_noack ingress throughput +0.03 [-0.03, +0.08] 48.58%
splunk_hec_indexer_ack_blackhole ingress throughput +0.01 [-0.03, +0.05] 28.25%
fluent_elasticsearch ingress throughput +0.00 [-0.00, +0.00] 17.63%
splunk_hec_to_splunk_hec_logs_acks ingress throughput -0.01 [-0.07, +0.06] 14.86%
splunk_hec_to_splunk_hec_logs_noack ingress throughput -0.02 [-0.06, +0.03] 38.84%
datadog_agent_remap_datadog_logs_acks ingress throughput -0.15 [-0.26, -0.03] 90.82%
http_to_http_acks ingress throughput -0.26 [-1.47, +0.96] 21.33%
syslog_splunk_hec_logs ingress throughput -0.49 [-0.56, -0.41] 100.00%
syslog_log2metric_humio_metrics ingress throughput -0.67 [-0.78, -0.56] 100.00%
datadog_agent_remap_blackhole ingress throughput -0.93 [-1.05, -0.82] 100.00%
syslog_regex_logs2metric_ddmetrics ingress throughput -2.51 [-2.84, -2.19] 100.00%
datadog_agent_remap_blackhole_acks ingress throughput -3.09 [-3.19, -2.98] 100.00%

@github-actions
Copy link

Regression Detector Results

Run ID: 0237d43c-f539-48ac-99de-ca14dac27755
Baseline: 9703188
Comparison: 7274562
Total vector CPUs: 7

Explanation

A regression test is an integrated performance test for vector in a repeatable rig, with varying configuration for vector. What follows is a statistical summary of a brief vector run for each configuration across SHAs given above. The goal of these tests are to determine quickly if vector performance is changed and to what degree by a pull request.

Because a target's optimization goal performance in each experiment will vary somewhat each time it is run, we can only estimate mean differences in optimization goal relative to the baseline target. We express these differences as a percentage change relative to the baseline target, denoted "Δ mean %". These estimates are made to a precision that balances accuracy and cost control. We represent this precision as a 90.00% confidence interval denoted "Δ mean % CI": there is a 90.00% chance that the true value of "Δ mean %" is in that interval.

We decide whether a change in performance is a "regression" -- a change worth investigating further -- if both of the following two criteria are true:

  1. The estimated |Δ mean %| ≥ 5.00%. This criterion intends to answer the question "Does the estimated change in mean optimization goal performance have a meaningful impact on your customers?". We assume that when |Δ mean %| < 5.00%, the impact on your customers is not meaningful. We also assume that a performance change in optimization goal is worth investigating whether it is an increase or decrease, so long as the magnitude of the change is sufficiently large.

  2. Zero is not in the 90.00% confidence interval "Δ mean % CI" about "Δ mean %". This statement is equivalent to saying that there is at least a 90.00% chance that the mean difference in optimization goal is not zero. This criterion intends to answer the question, "Is there a statistically significant difference in mean optimization goal performance?". It also means there is no more than a 10.00% chance this criterion reports a statistically significant difference when the true difference in mean optimization goal is zero -- a "false positive". We assume you are willing to accept a 10.00% chance of inaccurately detecting a change in performance when no true difference exists.

The table below, if present, lists those experiments that have experienced a statistically significant change in mean optimization goal performance between baseline and comparison SHAs with 90.00% confidence OR have been detected as newly erratic. Negative values of "Δ mean %" mean that baseline is faster, whereas positive values of "Δ mean %" mean that comparison is faster. Results that do not exhibit more than a ±5.00% change in their mean optimization goal are discarded. An experiment is erratic if its coefficient of variation is greater than 0.1. The abbreviated table will be omitted if no interesting change is observed.

No interesting changes in experiment optimization goals with confidence ≥ 90.00% and |Δ mean %| ≥ 5.00%.

Fine details of change detection per experiment.
experiment goal Δ mean % Δ mean % CI confidence
datadog_agent_remap_datadog_logs ingress throughput +3.47 [+3.37, +3.56] 100.00%
syslog_regex_logs2metric_ddmetrics ingress throughput +2.34 [+2.06, +2.63] 100.00%
http_text_to_http_json ingress throughput +1.43 [+1.38, +1.49] 100.00%
http_to_http_json ingress throughput +1.36 [+1.30, +1.42] 100.00%
syslog_splunk_hec_logs ingress throughput +1.30 [+1.23, +1.38] 100.00%
otlp_http_to_blackhole ingress throughput +0.88 [+0.70, +1.07] 100.00%
syslog_humio_logs ingress throughput +0.80 [+0.71, +0.89] 100.00%
syslog_log2metric_splunk_hec_metrics ingress throughput +0.61 [+0.52, +0.70] 100.00%
datadog_agent_remap_datadog_logs_acks ingress throughput +0.59 [+0.47, +0.70] 100.00%
splunk_hec_route_s3 ingress throughput +0.38 [+0.25, +0.52] 99.98%
syslog_loki ingress throughput +0.28 [+0.17, +0.38] 99.93%
http_to_http_acks ingress throughput +0.26 [-0.96, +1.48] 21.19%
file_to_blackhole ingress throughput +0.05 [-0.00, +0.10] 79.18%
enterprise_http_to_http ingress throughput +0.03 [-0.01, +0.07] 67.99%
http_to_http_noack ingress throughput +0.03 [-0.03, +0.09] 47.85%
splunk_hec_to_splunk_hec_logs_acks ingress throughput +0.00 [-0.06, +0.07] 2.01%
fluent_elasticsearch ingress throughput -0.00 [-0.00, +0.00] 4.33%
splunk_hec_indexer_ack_blackhole ingress throughput -0.00 [-0.04, +0.04] 1.23%
splunk_hec_to_splunk_hec_logs_noack ingress throughput -0.01 [-0.06, +0.03] 28.74%
otlp_grpc_to_blackhole ingress throughput -0.08 [-0.19, +0.02] 69.99%
datadog_agent_remap_blackhole ingress throughput -0.89 [-1.02, -0.75] 100.00%
socket_to_socket_blackhole ingress throughput -0.92 [-0.99, -0.85] 100.00%
syslog_log2metric_humio_metrics ingress throughput -2.21 [-2.31, -2.11] 100.00%
datadog_agent_remap_blackhole_acks ingress throughput -3.82 [-3.94, -3.70] 100.00%

@github-actions
Copy link

Regression Detector Results

Run ID: e86c3f6b-86b0-4f11-b003-86edecbe6b20
Baseline: 6088abd
Comparison: 0446f38
Total vector CPUs: 7

Explanation

A regression test is an integrated performance test for vector in a repeatable rig, with varying configuration for vector. What follows is a statistical summary of a brief vector run for each configuration across SHAs given above. The goal of these tests are to determine quickly if vector performance is changed and to what degree by a pull request.

Because a target's optimization goal performance in each experiment will vary somewhat each time it is run, we can only estimate mean differences in optimization goal relative to the baseline target. We express these differences as a percentage change relative to the baseline target, denoted "Δ mean %". These estimates are made to a precision that balances accuracy and cost control. We represent this precision as a 90.00% confidence interval denoted "Δ mean % CI": there is a 90.00% chance that the true value of "Δ mean %" is in that interval.

We decide whether a change in performance is a "regression" -- a change worth investigating further -- if both of the following two criteria are true:

  1. The estimated |Δ mean %| ≥ 5.00%. This criterion intends to answer the question "Does the estimated change in mean optimization goal performance have a meaningful impact on your customers?". We assume that when |Δ mean %| < 5.00%, the impact on your customers is not meaningful. We also assume that a performance change in optimization goal is worth investigating whether it is an increase or decrease, so long as the magnitude of the change is sufficiently large.

  2. Zero is not in the 90.00% confidence interval "Δ mean % CI" about "Δ mean %". This statement is equivalent to saying that there is at least a 90.00% chance that the mean difference in optimization goal is not zero. This criterion intends to answer the question, "Is there a statistically significant difference in mean optimization goal performance?". It also means there is no more than a 10.00% chance this criterion reports a statistically significant difference when the true difference in mean optimization goal is zero -- a "false positive". We assume you are willing to accept a 10.00% chance of inaccurately detecting a change in performance when no true difference exists.

The table below, if present, lists those experiments that have experienced a statistically significant change in mean optimization goal performance between baseline and comparison SHAs with 90.00% confidence OR have been detected as newly erratic. Negative values of "Δ mean %" mean that baseline is faster, whereas positive values of "Δ mean %" mean that comparison is faster. Results that do not exhibit more than a ±5.00% change in their mean optimization goal are discarded. An experiment is erratic if its coefficient of variation is greater than 0.1. The abbreviated table will be omitted if no interesting change is observed.

No interesting changes in experiment optimization goals with confidence ≥ 90.00% and |Δ mean %| ≥ 5.00%.

Fine details of change detection per experiment.
experiment goal Δ mean % Δ mean % CI confidence
datadog_agent_remap_datadog_logs_acks ingress throughput +1.80 [+1.71, +1.89] 100.00%
http_text_to_http_json ingress throughput +1.80 [+1.74, +1.86] 100.00%
syslog_log2metric_humio_metrics ingress throughput +1.56 [+1.47, +1.65] 100.00%
datadog_agent_remap_datadog_logs ingress throughput +1.41 [+1.32, +1.50] 100.00%
datadog_agent_remap_blackhole ingress throughput +1.07 [+0.99, +1.16] 100.00%
http_to_http_acks ingress throughput +0.93 [-0.29, +2.15] 66.93%
splunk_hec_route_s3 ingress throughput +0.67 [+0.55, +0.80] 100.00%
enterprise_http_to_http ingress throughput +0.07 [+0.03, +0.11] 98.20%
syslog_log2metric_splunk_hec_metrics ingress throughput +0.06 [-0.01, +0.13] 70.18%
splunk_hec_to_splunk_hec_logs_acks ingress throughput +0.00 [-0.06, +0.06] 1.71%
http_to_http_noack ingress throughput +0.00 [-0.06, +0.06] 1.31%
fluent_elasticsearch ingress throughput -0.00 [-0.00, +0.00] 23.37%
splunk_hec_indexer_ack_blackhole ingress throughput -0.00 [-0.04, +0.04] 1.87%
http_to_http_json ingress throughput -0.00 [-0.04, +0.04] 6.21%
splunk_hec_to_splunk_hec_logs_noack ingress throughput -0.01 [-0.06, +0.03] 30.59%
file_to_blackhole ingress throughput -0.01 [-0.07, +0.04] 24.67%
syslog_loki ingress throughput -0.74 [-0.80, -0.67] 100.00%
socket_to_socket_blackhole ingress throughput -1.02 [-1.07, -0.98] 100.00%
syslog_splunk_hec_logs ingress throughput -1.15 [-1.22, -1.08] 100.00%
otlp_grpc_to_blackhole ingress throughput -1.54 [-1.65, -1.43] 100.00%
otlp_http_to_blackhole ingress throughput -1.86 [-2.02, -1.70] 100.00%
datadog_agent_remap_blackhole_acks ingress throughput -2.01 [-2.09, -1.93] 100.00%
syslog_humio_logs ingress throughput -2.17 [-2.23, -2.11] 100.00%
syslog_regex_logs2metric_ddmetrics ingress throughput -3.78 [-3.99, -3.57] 100.00%

Copy link
Contributor

@neuronull neuronull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution @nabokihms !

Didn't quite review all of it but wanted to post what I have as a start.

let device_version = if let Some(device_version) = self.cef.device_version.clone() {
device_version
} else {
String::from("0") // Major version. TODO(nabokihms): find a way to get the actual vector version.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will want to remove calling out specific GH users to the TODO comments, if any of them are intended to be merged in with the changes.
As it is they are triggering the CI spell checker.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed my name from all TODO

Comment on lines +271 to +275
return Err(format!(
"severity must be a number from 0 to 10: actual {}",
severity
)
.into());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The returning of errors in this encoder could be more cleanly handled with snafu , see lib/codecs/src/encoding/format/gelf.rs for an example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now all errors are handled with snafu, thanks. Fixed here.

Comment on lines +14 to +32
/// Device event identity.
#[derive(Debug, Clone)]
pub struct DeviceSettings {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just struck me as odd that the doc comment "event identity" doesn't match "settings" .
Is there one or the other that makes more sense to call it and sync the doc comment to that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed description

Comment on lines +56 to +60
let device_vendor = if let Some(device_vendor) = self.cef.device_vendor.clone() {
escape_header(device_vendor)
} else {
String::from("Datadog")
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For these, you could pass a reference in instead of cloning, see comment below for the change to the helper function.

Suggested change
let device_vendor = if let Some(device_vendor) = self.cef.device_vendor.clone() {
escape_header(device_vendor)
} else {
String::from("Datadog")
};
let device_vendor = if let Some(device_vendor) = self.cef.device_vendor.as_ref() {
escape_header(device_vendor)
} else {
String::from("Datadog")
};

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@nabokihms
Copy link
Contributor Author

@neuronull thanks for reviewing! I'm on PTO this week. All the suggestions will be answered or fixed next week.

@jszwedko jszwedko added the meta: awaiting author Pull requests that are awaiting their author. label Jun 15, 2023
@zamazan4ik
Copy link
Contributor

@nabokihms any update on this PR? :)

@Freakachoo
Copy link

@nabokihms are there any updates on this PR? If it's possible to finish and merge it would be very cool! The feature is really needed.

@jszwedko jszwedko requested review from a team as code owners October 3, 2024 18:54
Copy link
Contributor

@jhgilbert jhgilbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with suggestions for style and grammar, I just flagged the first instance of everything since I know these are generated. Thank you!

@nabokihms
Copy link
Contributor Author

Thanks, folks. I have rebased patch for this codec so I would like to continue working on merging this.

https://github.com/deckhouse/deckhouse/blob/main/modules/460-log-shipper/images/vector/patches/cef-encoder.patch
There is the patch, I will try to update the PR this week.

@github-actions github-actions bot added the domain: sinks Anything related to the Vector's sinks label Oct 30, 2024
@nabokihms
Copy link
Contributor Author

@jszwedko @neuronull I updated the PR and applied fixes according to comments and currently waiting for another round of review 🙏

@jszwedko jszwedko requested review from pront and removed request for fuchsnj October 30, 2024 22:21
@pront
Copy link
Member

pront commented Oct 31, 2024

@jszwedko @neuronull I updated the PR and applied fixes according to comments and currently waiting for another round of review 🙏

Hi @nabokihms, thank you!

I will review this PR. It is a big one, so please bear with me while I go through the code :)

@pront pront self-assigned this Oct 31, 2024
@pront pront enabled auto-merge November 6, 2024 23:01
auto-merge was automatically disabled November 7, 2024 09:04

Head branch was pushed to by a user without write access

@pront
Copy link
Member

pront commented Nov 7, 2024

@nabokihms
Copy link
Contributor Author

@pront I tried to fix the error but probably made it worth... Could you please guide me what is the issue? It seems like it is not in my code.

@pront
Copy link
Member

pront commented Nov 7, 2024

@pront I tried to fix the error but probably made it worth... Could you please guide me what is the issue? It seems like it is not in my code.

Sorry, this was broken on master. You can ignore it.

@pront
Copy link
Member

pront commented Nov 7, 2024

@nabokihms can you apply this deckhouse#447?

Or you can manually do:

  1. git revert 90de69b
  2. git merge origin master

@pront
Copy link
Member

pront commented Nov 7, 2024

Sorry for the friction here, but this conflicts with the spell checker fix on master. Please revert the changes to:

  • .github/workflows/spelling.yml
  • .github/actions/spelling/expect.txt

You can just git checkout origin/master -- .github/actions/spelling/expect.txt .github/workflows/spelling.yml where origin assumes you pull from vectordotdev/vector

Signed-off-by: maksim.nabokikh <max.nabokih@gmail.com>
Signed-off-by: maksim.nabokikh <max.nabokih@gmail.com>
Signed-off-by: maksim.nabokikh <max.nabokih@gmail.com>
Signed-off-by: maksim.nabokikh <max.nabokih@gmail.com>
Signed-off-by: maksim.nabokikh <max.nabokih@gmail.com>
Signed-off-by: maksim.nabokikh <max.nabokih@gmail.com>
Signed-off-by: maksim.nabokikh <max.nabokih@gmail.com>
Signed-off-by: maksim.nabokikh <max.nabokih@gmail.com>
@pront pront enabled auto-merge November 7, 2024 21:34
@pront pront added this pull request to the merge queue Nov 7, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Nov 8, 2024
@nabokihms
Copy link
Contributor Author

test-misc / test-misc failed, but it seems like it was not affected by the PR. Just a flake.

@jszwedko jszwedko added this pull request to the merge queue Nov 8, 2024
Merged via the queue into vectordotdev:master with commit ac1e975 Nov 8, 2024
@nabokihms
Copy link
Contributor Author

nabokihms commented Nov 8, 2024

Thanks to all who worked on this PR.

@pront
Copy link
Member

pront commented Nov 8, 2024

Thanks to all who worked on this PR.

🎉 Thank you @nabokihms!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain: codecs Anything related to Vector's codecs (encoding/decoding) domain: external docs Anything related to Vector's external, public documentation domain: sinks Anything related to the Vector's sinks meta: awaiting author Pull requests that are awaiting their author.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants