Skip to content

Merging to release-5.13: [TT-13727] Add RFC3339 compliant option for consistent GW application logs (#8157)#8179

Merged
shults merged 1 commit into
release-5.13from
merge/release-5.13/432bcba341df25f1f35292f07075008d65c65a98/TT-13727
May 5, 2026
Merged

Merging to release-5.13: [TT-13727] Add RFC3339 compliant option for consistent GW application logs (#8157)#8179
shults merged 1 commit into
release-5.13from
merge/release-5.13/432bcba341df25f1f35292f07075008d65c65a98/TT-13727

Conversation

@probelabs

@probelabs probelabs Bot commented May 5, 2026

Copy link
Copy Markdown
Contributor

TT-13727 Add RFC3339 compliant option for consistent GW application logs (#8157)

Description

Related Issue

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing
    functionality to change)
  • Refactoring or add test (improvements in base code or adds test
    coverage to functionality)

Checklist

  • I ensured that the documentation is up to date
  • I explained why this PR updates go.mod in detail with reasoning
    why it's required
  • I would like a code coverage CI quality gate exception and have
    explained why

… logs (#8157)

<!-- Provide a general summary of your changes in the Title above -->

## Description

<!-- Describe your changes in detail -->

## Related Issue

<!-- This project only accepts pull requests related to open issues. -->
<!-- If suggesting a new feature or change, please discuss it in an
issue first. -->
<!-- If fixing a bug, there should be an issue describing it with steps
to reproduce. -->
<!-- OSS: Please link to the issue here. Tyk: please create/link the
JIRA ticket. -->

## Motivation and Context

<!-- Why is this change required? What problem does it solve? -->

## How This Has Been Tested

<!-- Please describe in detail how you tested your changes -->
<!-- Include details of your testing environment, and the tests -->
<!-- you ran to see how your change affects other areas of the code,
etc. -->
<!-- This information is helpful for reviewers and QA. -->

## Screenshots (if appropriate)

## Types of changes

<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test
coverage to functionality)

## Checklist

<!-- Go over all the following points, and put an `x` in all the boxes
that apply -->
<!-- If there are no documentation updates required, mark the item as
checked. -->
<!-- Raise up any additional concerns not covered by the checklist. -->

- [ ] I ensured that the documentation is up to date
- [ ] I explained why this PR updates go.mod in detail with reasoning
why it's required
- [ ] I would like a code coverage CI quality gate exception and have
explained why

(cherry picked from commit 432bcba)
@github-actions

github-actions Bot commented May 5, 2026

Copy link
Copy Markdown
Contributor

🚨 Jira Linter Failed

Commit: 80dc4bc
Failed at: 2026-05-05 15:36:58 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details
failed to get Jira issue: failed to fetch Jira issue TT-13727: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

Next Steps

  • Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
  • Verify your PR title matches the branch's Jira ticket ID
  • Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

@probelabs

probelabs Bot commented May 5, 2026

Copy link
Copy Markdown
Contributor Author

This PR introduces a new configuration option for log formatting to standardize gateway application log timestamps, making them RFC3339 compliant by default.

Files Changed Analysis

The changes introduce a new log_format option with three possible values: text (default), json, and legacy.

  • log/log.go & log/log_test.go: This is the core of the change. It refactors the logging formatter logic to support different timestamp formats. A new SetupFormatter function centralizes the configuration of both the Tyk logger and the global logrus logger. The text and json formats use RFC3339 timestamps, while the legacy format retains the old timestamp style for backward compatibility. Extensive tests have been added to validate the new behavior.
  • config/config.go: The Config struct is updated to include the new LogFormat field, changing its type from string to a new logger.Format type.
  • cli/linter/schema.json: The JSON schema for the configuration is updated to reflect the new allowed values for log_format.
  • gateway/server.go: The gateway initialization logic is updated to call the new tyklog.SetupFormatter function, applying the configured log format at startup.
  • certs/manager.go: Updated to use the centralized tyklog.Get() logger instead of instantiating a new one, promoting consistency.
  • gateway/host_checker_manager.go: Minor import reordering.

Architecture & Impact Assessment

  • What this PR accomplishes: It provides a mechanism to control the timestamp format in application logs. By defaulting to RFC3339, it enhances consistency and makes logs easier to parse for modern observability tools. The legacy option ensures a non-breaking change for users who rely on the previous format.

  • Key technical changes introduced:

    • A new configuration option, log_format, is added.
    • The logging package is refactored to introduce explicit formatters for text, json, and legacy outputs.
    • A centralized function, log.SetupFormatter, is created to apply the chosen format globally during gateway initialization.
  • Affected system components: The primary impact is on the Logging Subsystem and Configuration Management. All logs generated by the gateway will be affected by this change, ensuring a consistent output format across the application.

Log Formatting Flow

graph TD
    subgraph sg1 [Configuration]
        A[tyk.conf: log_format] --> B[config.go: Config.LogFormat]
    end
    subgraph sg2 [Gateway Initialization]
        B --> C["gateway/server.go: initSystem()"]
        C --> D["log/log.go: SetupFormatter(format)"]
    end
    subgraph sg3 [Logging Subsystem]
        D --> E{Switch on format}
        E --|text or default|--> F[Create TextFormatter with RFC3339]
        E --|json|--> G[Create JSONFormatter with RFC3339]
        E --|legacy|--> H[Create TextFormatter with legacy format]
        F --> I[Set tyk logger & global logrus formatter]
        G --> I
        H --> J[Set tyk logger formatter ONLY]
    end

Loading

Scope Discovery & Context Expansion

The changes are well-contained within the logging and configuration initialization paths. The refactoring in certs/manager.go to use tyklog.Get() is a positive step towards standardizing how logger instances are obtained throughout the codebase.

Further work could involve auditing the repository for any other direct instantiations of logrus.New() and replacing them with the centralized tyklog.Get() to ensure all application logs adhere to the configured format.

Metadata
  • Review Effort: 3 / 5
  • Primary Label: enhancement

Powered by Visor from Probelabs

Last updated: 2026-05-05T15:38:59.193Z | Triggered by: pr_opened | Commit: 80dc4bc

💡 TIP: You can chat with Visor using /visor ask <your question>

@probelabs

probelabs Bot commented May 5, 2026

Copy link
Copy Markdown
Contributor Author

Architecture Issues (1)

Severity Location Issue
🟡 Warning log/log.go:75-77
The special handling for the `legacy` log format introduces an inconsistency in system behavior. The global `logrus.StandardLogger()` formatter is configured for `text` and `json` formats but is intentionally not configured for the `legacy` format. While this is a pragmatic approach to maintain backward compatibility, it creates a divergence where the behavior of a global component depends on a configuration setting, which can be a source of confusion or subtle bugs. Furthermore, the comment on line 75 is incorrect, stating the opposite of what the code does, which exacerbates the problem.
💡 SuggestionThe comment on line 75 should be corrected to accurately reflect the code's logic and its rationale. For example: `// For non-legacy formats, we also configure the global logrus standard logger to ensure consistent logging. // The legacy format is excluded to preserve backward compatibility and avoid side-effects.` In the long term, consider unifying this behavior in a future major version to eliminate the special case and make the logging configuration more consistent.
\n\n

Architecture Issues (1)

Severity Location Issue
🟡 Warning log/log.go:75-77
The special handling for the `legacy` log format introduces an inconsistency in system behavior. The global `logrus.StandardLogger()` formatter is configured for `text` and `json` formats but is intentionally not configured for the `legacy` format. While this is a pragmatic approach to maintain backward compatibility, it creates a divergence where the behavior of a global component depends on a configuration setting, which can be a source of confusion or subtle bugs. Furthermore, the comment on line 75 is incorrect, stating the opposite of what the code does, which exacerbates the problem.
💡 SuggestionThe comment on line 75 should be corrected to accurately reflect the code's logic and its rationale. For example: `// For non-legacy formats, we also configure the global logrus standard logger to ensure consistent logging. // The legacy format is excluded to preserve backward compatibility and avoid side-effects.` In the long term, consider unifying this behavior in a future major version to eliminate the special case and make the logging configuration more consistent.
\n\n ### ✅ Performance Check Passed

No performance issues found – changes LGTM.

Quality Issues (2)

Severity Location Issue
🟠 Error log/log.go:94-96
This change introduces an undocumented breaking change in the default logging behavior. The default log timestamp format is changed from 'Jan 02 15:04:05' to RFC3339. Additionally, the previously supported 'standard' log format value is no longer recognized and will fall back to the new 'text' format (RFC3339). Users who want to retain the old format must now explicitly set `log_format` to 'legacy'. This can break log parsing and monitoring systems for users who upgrade without being aware of this change. The pull request should be marked as a breaking change and this should be clearly communicated in the release notes.
💡 SuggestionAcknowledge the breaking change in the pull request description and ensure it is mentioned prominently in the release notes. Users migrating from previous versions will need clear instructions on how to preserve the old logging format by setting `log_format: "legacy"` in their configuration.
🟡 Warning log/log.go:75
The comment at this line is misleading and contradicts the code. The comment states 'non legacy formatter does not set up global logrus formatter', but the code `if format != FormatLegacy` clearly shows that non-legacy formatters (like 'text' and 'json') *do* set the global logrus formatter. The comment should be corrected to reflect the actual behavior of the code to avoid confusion for future maintainers.
💡 SuggestionCorrect the comment to accurately describe the code's behavior. For example: `// Non-legacy formatters also set up the global logrus formatter to ensure consistency across the application.`
🔧 Suggested Fix
	// non legacy formatter also sets up global logrus formatter

Powered by Visor from Probelabs

Last updated: 2026-05-05T15:38:41.725Z | Triggered by: pr_opened | Commit: 80dc4bc

💡 TIP: You can chat with Visor using /visor ask <your question>

@shults
shults enabled auto-merge (squash) May 5, 2026 15:49
@sonarqubecloud

sonarqubecloud Bot commented May 5, 2026

Copy link
Copy Markdown

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@shults
shults merged commit 13cc028 into release-5.13 May 5, 2026
30 of 52 checks passed
@shults
shults deleted the merge/release-5.13/432bcba341df25f1f35292f07075008d65c65a98/TT-13727 branch May 5, 2026 16:46
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.

1 participant