Skip to content

Conversation

@Caleb-Hurshman
Copy link
Collaborator

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:

  • Unit tests
    • Unit tests do not apply.
    • Unit tests have been added/modified and passed for this PR.
  • Integration tests
    • Integration tests do not apply.
    • Integration tests have been added/modified and passed for this PR.
  • Documentation
    • This PR introduces no user visible changes.
    • This PR introduces user visible changes and the corresponding documentation change has been made.
  • Minor version bump
    • This PR introduces no new features.
    • This PR introduces new features, and there is a separate PR to bump the minor version since the last release already.
    • This PR bumps the version.

@google-cla
Copy link

google-cla bot commented Jul 16, 2025

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.

@Caleb-Hurshman Caleb-Hurshman force-pushed the feat/nginx-otel-logging branch 3 times, most recently from ddcddd7 to 75a6108 Compare July 17, 2025 17:32
@franciscovalentecastro franciscovalentecastro marked this pull request as ready for review July 17, 2025 17:59
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Very good to know!

@franciscovalentecastro franciscovalentecastro added the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 18, 2025
@stackdriver-instrumentation-release stackdriver-instrumentation-release removed the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 18, 2025
@Caleb-Hurshman Caleb-Hurshman added the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 18, 2025
@stackdriver-instrumentation-release stackdriver-instrumentation-release removed the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 18, 2025
@Caleb-Hurshman Caleb-Hurshman force-pushed the feat/nginx-otel-logging branch from 88eed45 to 62f59ef Compare July 18, 2025 19:19
@Caleb-Hurshman Caleb-Hurshman added the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 18, 2025
@stackdriver-instrumentation-release stackdriver-instrumentation-release removed the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 18, 2025
@franciscovalentecastro
Copy link
Contributor

franciscovalentecastro commented Jul 18, 2025

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.

@Caleb-Hurshman Caleb-Hurshman added the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 18, 2025
@stackdriver-instrumentation-release stackdriver-instrumentation-release removed the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 18, 2025
@Caleb-Hurshman
Copy link
Collaborator Author

@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?

@Caleb-Hurshman Caleb-Hurshman force-pushed the feat/nginx-otel-logging branch from 05184e3 to 018664c Compare July 21, 2025 14:38
@Caleb-Hurshman Caleb-Hurshman added the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 21, 2025
@stackdriver-instrumentation-release stackdriver-instrumentation-release removed the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 21, 2025
// 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 {
Copy link
Contributor

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.

Copy link
Contributor

@franciscovalentecastro franciscovalentecastro left a 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.

@franciscovalentecastro
Copy link
Contributor

@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?

There doesn't seem to be any relation to your changes. For example :

  • third party apps integration test (Ubuntu 24.04 Noble x86_64 / AArch64) seem to be only related to rabbitmq. This may need to be addressed / solved separately.
  • third party apps integration test (Debian 11 Bullseye x86_64) is a flake / failure that occurs sometimes when installing packages in Debian 11.

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 triage the rabbitmq issue if it shows again.

@franciscovalentecastro franciscovalentecastro added the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 21, 2025
@stackdriver-instrumentation-release stackdriver-instrumentation-release removed the kokoro:force-run Forces kokoro to run integration tests on a CL label Jul 21, 2025
@franciscovalentecastro
Copy link
Contributor

Mentioned in previous #1978 (comment) about the unrelated test failures to the changes in this PR. Both failures (Debian 11 frontend lock and rabbitmq in Ubuntu 24.04 are being addressed separately of this PR). Merging PR.

@franciscovalentecastro franciscovalentecastro merged commit b92a4e4 into GoogleCloudPlatform:master Jul 21, 2025
58 of 62 checks passed
@Caleb-Hurshman Caleb-Hurshman deleted the feat/nginx-otel-logging branch July 23, 2025 13:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants