[TT-7099] [Customer FR] Send info and debug messages to stdout not stderr

[shults]

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

Ticket Details

TT-7099

Status	In Dev
Summary	Configurable sinks for application logs [Gateway]

Generated at: 2026-07-21 16:16:05

[probelabs]

This pull request introduces a significant enhancement to the Tyk Gateway's logging system by making it fully configurable. Users can now define multiple logging "sinks" in the configuration, allowing for granular control over log levels, formats, and outputs. This change addresses a customer feature request to separate informational logs from error logs, a common practice in containerized environments.

Files Changed Analysis

• Total Files Changed: 30
• Additions/Deletions: 445 additions, 129 deletions
• Key New Files:
  • config/log_format.go: Introduces the new LogFormat type, which can be either a simple string (for backward compatibility) or an array of SinkConfig objects.
  • config/log_format_test.go: Provides comprehensive tests for the new configuration parsing logic.
• Notable Changes:
  • config/config.go: The log_format field is updated to use the new flexible LogFormat type.
  • cli/linter/schema.json: The configuration schema is updated to validate the new log_format structure, including the definition for a SinkConfig.
  • The majority of the changes are a widespread refactoring across more than 20 files in the gateway/ directory and other modules. This involves replacing the direct use of logrus.Logger with a new tyklog.Logger abstraction, ensuring the entire application adopts the new configurable logging system.

Architecture & Impact Assessment

• What this PR accomplishes: It replaces the gateway's monolithic logging setup with a flexible, multi-sink system. This allows routing logs of different severity levels (e.g., info to stdout, error to stderr) to different destinations with distinct formatting, all from the main configuration file.

• Key technical changes introduced:

  1. Configurable Sinks: A new log_format configuration option that accepts an array of sink configurations (SinkConfig). Each sink can specify its own level range, output (e.g., stdout, file), and format (e.g., json, text).
  2. Logger Abstraction: A new tyklog.Logger type is used throughout the application. This wrapper encapsulates the underlying logging logic, decoupling the application code from the specific logrus implementation and centralizing the new sink-routing behavior.
  3. Schema Update: The JSON schema for tyk.conf has been updated to support and validate this new, more complex logging configuration.

• Affected system components: As logging is a cross-cutting concern, this change impacts nearly every component within the Tyk Gateway. This includes all middleware, event handlers, JavaScript VMs (Otto and Goja), analytics processing, and the core request/response pipeline.

Logging Flow Visualization

graph TD
    subgraph "tyk.conf"
        A["log_format: [sink1, sink2, ...]"]
    end

    subgraph "Tyk Gateway"
        B[Application Code] --> C{tyklog.Logger}
        C --|reads config|--> A
    end

    subgraph "Log Sinks"
        D["Output 1 (e.g., stdout)"]
        E["Output 2 (e.g., stderr)"]
        F["Output 3 (e.g., file)"]
    end

    C --|"routes based on level & config"|--> D
    C --|"routes based on level & config"|--> E
    C --|"routes based on level & config"|--> F

Loading

Scope Discovery & Context Expansion

• The scope of this PR is foundational and extensive. By refactoring the logging system at its core, the changes propagate through the entire codebase. The introduction of the LogFormat type and SinkConfig in config/log_format.go is the central architectural change.
• The impact extends beyond just log output; it affects how developers interact with the logger, how tests are written (e.g., the new InitTest helper in cli/cli.go), and how operators configure and monitor the gateway.
• To fully assess the implementation, one would need to review the definition of tyklog.Logger and the initialization logic (likely in main.go or gateway/server.go) that parses the SinkConfig array and sets up the underlying logrus hooks or writers. The provided diff indicates a comprehensive replacement of the old logger, suggesting this has been handled consistently.

Metadata

• Review Effort: 4 / 5
• Primary Label: feature

---

Powered by Visor from Probelabs

Last updated: 2026-07-21T16:18:03.853Z | Triggered by: pr_updated | Commit: 11be04e

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

[probelabs]

Security Issues (1)

Severity	Location	Issue
🟡 Warning	cli/linter/schema.json:504	The introduction of configurable logging sinks with arbitrary `output_options` creates a new potential attack surface. If an attacker can influence the gateway's configuration, they could potentially configure a malicious sink to exfiltrate sensitive data (e.g., via an HTTP sink) or cause a denial-of-service (e.g., by writing to a critical file path or exhausting resources). While the implementation of the sinks is not in this pull request, this change introduces the configuration vector for such attacks. 💡 Suggestion Ensure that the implementation of the logging sinks that consume `output_options` performs strict validation and sanitization of all options. For file-based sinks, prevent path traversal attacks by restricting log file locations to a specific, non-critical directory. For network-based sinks, provide and encourage options for secure transport (TLS). Documentation should clearly outline the security implications of each sink type and its options.

✅ Architecture Check Passed

No architecture issues found – changes LGTM.

Quality Issues (1)

Severity	Location	Issue
🟡 Warning	gateway/event_handler_webhooks_test.go:556	The test uses the global logger `tyklog.Get()`, which can introduce side effects and make tests less reliable, especially when run in parallel. The function under test logs an error on failure, and using a global logger can pollute test output. It's a best practice to use an isolated logger instance for each test. 💡 Suggestion Replace `tyklog.Get()` with `tyklog.NewNullLogger()` to create a discarded, isolated logger for this test. This aligns with improvements made in other tests within this PR and ensures test isolation.

---

Powered by Visor from Probelabs

Last updated: 2026-07-21T16:17:58.598Z | Triggered by: pr_updated | Commit: 11be04e

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

[shults]

/visor ask

rpc.Log uses the same global reference as tyk logger. I suppose that your theory regarding removing rpc.Log = log is wrong.

[probelabs]

---

Powered by Visor from Probelabs

Last updated: 2026-06-23T10:52:36.731Z | Triggered by: shults | Commit: e815d43

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

[sonarqubecloud]

Quality Gate passed

Issues
8 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[sentinelone-cnapp-eu1]

SentinelOne CNS Hardcoded Secret Detector
✅ Congratulations, your code is safe

SentinelOne CNS is a cloud-agnostic, agentless CSPM & CWPP solution that continuously detects and prevents vulnerabilities that have the highest probability of being exploited in Azure, AWS, Google Cloud, and Kubernetes.