adds HTTP log exclusion regex paths, updates Go version and module dependencies, and bumps Helm chart version #4

Merged
rmcguire merged 4 commits from development into main 2025-09-02 17:51:38 +00:00
Owner

/describe

/describe
rmcguire added 2 commits 2025-09-02 17:24:17 +00:00
rmcguire added 2 commits 2025-09-02 17:24:27 +00:00
Author
Owner

/issues

/issues
Author
Owner

High-Level Summary:
This change primarily focuses on updating Go dependencies, bumping the Go version, and introducing a configuration schema for HTTP log exclusion paths. While the configuration aspect is well-defined, the core implementation logic for applying these exclusion rules is notably absent from the provided diff.


Code Issues:

  • File: (N/A - implementation code is missing)

  • Line: (N/A)

  • Issue: The CHANGELOG.md entry and contrib/schema.json clearly indicate the intent to "Add HTTP log exclusion regex paths to configuration schema." However, the provided diff does not include any Go source code that implements the actual logic to read, compile, and apply these logExcludePathRegexps to filter HTTP requests before logging. Without this implementation, the feature is incomplete.

  • Suggestion: Please provide the Go code changes that will:
    1 . Parse the logExcludePathRegexps from the application configuration.
    2. Compile each string into a *regexp.Regexp object (preferably once during application startup).
    3. Integrate this compiled list of regexes into the HTTP request logging middleware or handler to check if an incoming request's path matches any of the exclusion patterns, and if so, skip logging for that request.

  • File: (Will be in the missing implementation )

  • Line: (Will be in the missing implementation)

  • Issue: When implementing the HTTP log exclusion using regular expressions, there is a potential for Regular Expression Denial of Service (ReDoS) if the regex patterns are complex or crafted maliciously. An attacker could provide a pathological regex or a request path that causes the regex engine to consume excessive CPU resources, leading to a denial of service.

  • Suggestion: In the upcoming implementation, ensure that:

    1. All regex patterns are compiled and validated during application startup. Handle compilation errors gracefully (e.g., log a warning and skip the invalid regex).
    2. Consider using a regex library or implementing safeguards (e.g., timeouts for regex matching) if the regexes can be dynamically configured or are sourced from untrusted inputs.
    3. Document best practices for defining logExcludePathRegexps to avoid performance pitfalls.
  • File: ( Will be in the missing implementation)

  • Line: (Will be in the missing implementation)

  • Issue: Applying multiple regular expressions to the path of every incoming HTTP request can introduce a measurable performance overhead, especially under high traffic conditions or with a large number of complex exclusion patterns.

  • Suggestion: When implementing the regex matching logic:

    1. Ensure that the regex patterns are compiled only once, typically during application initialization, and reused for all subsequent requests.
    2. Benchmark the performance impact of the regex matching logic, especially with a realistic number of patterns and request rates, to identify potential bottlenecks.
    3. If performance becomes a concern, consider optimizing the matching strategy, perhaps by checking for simple prefix/suffix matches before resorting to full regex evaluation for more complex patterns.
  • File: (N/A - tests are missing)

  • Line: (N/A)

  • Issue: The introduction of a new feature like logExcludePathRegexps requires corresponding test coverage to ensure its correctness and robustness. The current diff does not include any new unit or integration tests for this functionality.

  • Suggestion: Add comprehensive tests for the HTTP log exclusion feature. This should include:

    • Test cases with various valid regex patterns that should successfully exclude logs for matching paths.
    • Test cases with paths that should not be excluded by the configured regexes.
    • Tests for edge cases, such as an empty list of exclusion patterns, or patterns that might be syntactically incorrect (if the implementation handles them).
    • Integration tests to verify the end-to-end behavior of log exclusion within the HTTP server.
  • File: go.mod

  • Line: 10 (where the replace directive for github.com/prometheus/otlptransl ator was removed)

  • Issue: The replace directive for github.com/prometheus/otlptranslator has been removed, and the module is now directly referenced at v0.0.2. While this is generally a positive change, it's important to confirm that the v0.0.2 release (or the version it resolves to) fully addresses the original reason the replace directive was put in place. Sometimes replace directives are used for specific unreleased fixes or forks.

  • Suggestion: Verify that the v0.0.2 version of github.com/prometheus/otlptranslator contains all necessary fixes or features that the previous replace directive was providing. This ensures that no critical functionality or bug fixes are inadvertently lost by switching to the official release.

**High-Level Summary:** This change primarily focuses on updating Go dependencies, bumping the Go version, and introducing a configuration schema for HTTP log exclusion paths. While the configuration aspect is well-defined, the core implementation logic for applying these exclusion rules is notably absent from the provided diff. --- **Code Issues:** * **File:** (N/A - implementation code is missing) * **Line:** (N/A) * **Issue:** The `CHANGELOG.md` entry and `contrib/schema.json` clearly indicate the intent to "Add HTTP log exclusion regex paths to configuration schema." However, the provided diff does not include any Go source code that implements the actual logic to read, compile, and apply these `logExcludePathRegexps` to filter HTTP requests before logging. Without this implementation, the feature is incomplete. * **Suggestion:** Please provide the Go code changes that will: 1 . Parse the `logExcludePathRegexps` from the application configuration. 2. Compile each string into a `*regexp.Regexp` object (preferably once during application startup). 3. Integrate this compiled list of regexes into the HTTP request logging middleware or handler to check if an incoming request's path matches any of the exclusion patterns, and if so, skip logging for that request. * **File:** (Will be in the missing implementation ) * **Line:** (Will be in the missing implementation) * **Issue:** When implementing the HTTP log exclusion using regular expressions, there is a potential for Regular Expression Denial of Service (ReDoS) if the regex patterns are complex or crafted maliciously. An attacker could provide a pathological regex or a request path that causes the regex engine to consume excessive CPU resources, leading to a denial of service. * **Suggestion:** In the upcoming implementation, ensure that: 1. All regex patterns are compiled and validated during application startup. Handle compilation errors gracefully (e.g., log a warning and skip the invalid regex). 2. Consider using a regex library or implementing safeguards (e.g., timeouts for regex matching) if the regexes can be dynamically configured or are sourced from untrusted inputs. 3. Document best practices for defining `logExcludePathRegexps` to avoid performance pitfalls. * **File:** ( Will be in the missing implementation) * **Line:** (Will be in the missing implementation) * **Issue:** Applying multiple regular expressions to the path of every incoming HTTP request can introduce a measurable performance overhead, especially under high traffic conditions or with a large number of complex exclusion patterns. * **Suggestion:** When implementing the regex matching logic: 1. Ensure that the regex patterns are compiled only once, typically during application initialization, and reused for all subsequent requests. 2. Benchmark the performance impact of the regex matching logic, especially with a realistic number of patterns and request rates, to identify potential bottlenecks. 3. If performance becomes a concern, consider optimizing the matching strategy, perhaps by checking for simple prefix/suffix matches before resorting to full regex evaluation for more complex patterns. * **File:** (N/A - tests are missing) * **Line:** (N/A) * **Issue:** The introduction of a new feature like `logExcludePathRegexps` requires corresponding test coverage to ensure its correctness and robustness. The current diff does not include any new unit or integration tests for this functionality. * **Suggestion:** Add comprehensive tests for the HTTP log exclusion feature. This should include: * Test cases with various valid regex patterns that should successfully exclude logs for matching paths. * Test cases with paths that should *not* be excluded by the configured regexes. * Tests for edge cases, such as an empty list of exclusion patterns, or patterns that might be syntactically incorrect (if the implementation handles them). * Integration tests to verify the end-to-end behavior of log exclusion within the HTTP server. * **File:** `go.mod` * **Line:** 10 (where the `replace` directive for `github.com/prometheus/otlptransl ator` was removed) * **Issue:** The `replace` directive for `github.com/prometheus/otlptranslator` has been removed, and the module is now directly referenced at `v0.0.2`. While this is generally a positive change, it's important to confirm that the `v0.0.2` release (or the version it resolves to) fully addresses the original reason the `replace` directive was put in place. Sometimes `replace` directives are used for specific unreleased fixes or forks. * **Suggestion:** Verify that the `v0.0.2` version of `github.com/prometheus/otlptranslator` contains all necessary fixes or features that the previous `replace` directive was providing. This ensures that no critical functionality or bug fixes are inadvertently lost by switching to the official release.
rmcguire merged commit c0a1631320 into main 2025-09-02 17:51:38 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rmcguire/go-server-with-otel#4
No description provided.