Skip to content
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

Tt 2539/transaction logs #6354

Open
wants to merge 16 commits into
base: master
Choose a base branch
from
Open

Tt 2539/transaction logs #6354

wants to merge 16 commits into from

Conversation

LLe27
Copy link

@LLe27 LLe27 commented Jun 18, 2024

Description

  • Added the TYK_GW_ACCESSLOGS_ENABLED Gateway config option
  • The Tyk Gateway will determine to print access logs to STDOUT for both success and error handling situations
    • If the TYK_GW_ACCESSLOGS_ENABLED is set to true then the Gateway will print access logs to STDOUT
    • If the TYK_GW_ACCESSLOGS_ENABLED is set to false then the Gateway will not print access logs to STDOUT

Related Issue

Motivation and Context

Today the Tyk Gateway does not print access logs for success API calls but instead only for error API calls. Providing access logs for both scenarios within the Tyk Gateway is extremely valuable especially if you are monitoring logs, capturing analytics or even debugging. Providing the option to turn on or off the Tyk Gateway access logs will provide clients more insights in for API calls in regards to success and error situations.

How This Has Been Tested

  • Manual testing
  • Unit testing
  • Performance testing/benchmarks

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

@LLe27 LLe27 requested a review from titpetric June 18, 2024 15:32
Copy link
Contributor

API Changes

--- prev.txt	2024-06-19 18:19:19.146129194 +0000
+++ current.txt	2024-06-19 18:19:15.994102579 +0000
@@ -5033,6 +5033,12 @@
 
 TYPES
 
+type AccessLogsConfig struct {
+	// Enable the transaction logs. Default: false
+	Enabled bool `json:"enabled"`
+}
+    AccessLogsConfig defines the type of transactions logs printed to stdout
+
 type AnalyticsConfigConfig struct {
 	// Set empty for a Self-Managed installation or `rpc` for multi-cloud.
 	Type string `json:"type"`
@@ -5473,6 +5479,10 @@
 	// If not set or left empty, it will default to `info`.
 	LogLevel string `json:"log_level"`
 
+	// You can configure the transaction logs to be turned on
+	// If not set or left empty, it will default to 'false'
+	AccessLogs AccessLogsConfig `json:"access_logs"`
+
 	// Section for configuring OpenTracing support
 	// Deprecated: use OpenTelemetry instead.
 	Tracer Tracer `json:"tracing"`

fields[typeOfA.Field(i).Name] = v.Field(i).Interface()
}

return log.WithFields(fields)

Check failure

Code scanning / CodeQL

Clear-text logging of sensitive information High

Sensitive data returned by an access to APIKey
flows to a logging call.
Copy link
Contributor

💥 CI tests failed 🙈

git-state

all ok

Please look at the run or in the Checks tab.

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.

None yet

2 participants