-
Notifications
You must be signed in to change notification settings - Fork 77
feat: Update nginx receiver to use LoggingReceiverMacro
#1978
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Update nginx receiver to use LoggingReceiverMacro
#1978
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
ddcddd7 to
75a6108
Compare
confgenerator/testdata/goldens/logging-receiver_nginx/golden/windows-2012/fluent_bit_main.conf
Outdated
Show resolved
Hide resolved
.../testdata/goldens/logging-receiver_nginx/golden/windows/4a885f78c2b41df75250528bf3ea0c2c.lua
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note : This is just a comment to say that updates in files golden.csv, feature_tracking_otlp.json and features.yaml are expected when updating a receiver.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: One way of verifying the resulting updated implementation of the ngnix_access (or any other) receiver is working as expected is that make transformation_test should produce exactly the same output_fluentbit.yaml before and after the code update to nginx.go.
No change in output_fluentbit.yaml implies that the behaviour of the receiver/processors is preserved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very good to know!
61a21c2 to
7e0f0fc
Compare
363bb43 to
fad195e
Compare
transformation_test/testdata/ops_agent_test-TestLogEntrySpecialFields/output_otel.yaml
Outdated
Show resolved
Hide resolved
88eed45 to
62f59ef
Compare
|
This PR is looking good. Thank you for all the updates @Caleb-Hurshman ! I added one last comment. Let's also wait for integration tests to run to see if everything is working correctly. |
|
@franciscovalentecastro 3 of the integration tests are failing. Looking at the logs, I don't see any direct relation to my changes. Do you have any advice for diagnosing these failures? |
05184e3 to
018664c
Compare
| // TODO: rename to genericAccessLogParser once the old version is removed | ||
| // genericAccessLogParserAsInternalLoggingProcessor is an internal logging processor that parses access logs. | ||
| // It will eventually replace genericAccessLogParser, as it returns a slice of InternalLoggingProcessor rather than fluentbit.Component, making it more flexible. | ||
| func genericAccessLogParserAsInternalLoggingProcessor(ctx context.Context, processorType string) []confgenerator.InternalLoggingProcessor { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: A teammate (@quentinmit) suggested an improvement of this function by converting genericAccessLogParserAsInternalLoggingProcessor into an InternalLoggingProcessor (1. Creating a struct, 2. Defining this function as its Expand() method).
We can do this in a followup PR when updating any of the other receivers (apache, tomcat, ...) that use this. I just wanted to keep a note on this idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Added a Note: of an idea we can address in a followup PR.
There doesn't seem to be any relation to your changes. For example :
After the this last test run, i will re-rerun the tests and merge the PR if the result still looks unrelated to this PR. I will |
|
Mentioned in previous #1978 (comment) about the unrelated test failures to the changes in this PR. Both failures ( |
b92a4e4
into
GoogleCloudPlatform:master
Description
Refactor the nginx receiver logging to be sub-agent agnostic.
Draft stage, creating this PR to run transformation tests until they are running locally.
Related issue
How has this been tested?
Checklist: