Overview
The logging middleware automatically logs incoming requests (server) and outgoing requests (client) with detailed information including operation name, status code, error reason, latency, and request arguments.Installation
Server Middleware
TheServer function creates a server-side logging middleware:
Basic Usage
Client Middleware
TheClient function creates a client-side logging middleware:
Usage Example
Log Fields
The logging middleware automatically includes the following fields:| Field | Description | Example |
|---|---|---|
kind | Always “server” or “client” | "server", "client" |
component | Transport kind | "http", "grpc" |
operation | Operation name | "/api.v1.Greeter/SayHello" |
args | Request arguments | "{\"name\":\"world\"}" |
code | Response status code | 200, 500 |
reason | Error reason (if error) | "INTERNAL_ERROR", "" |
stack | Error stack trace (if error) | Stack trace string |
latency | Request latency in seconds | 0.123 |
Structured Logging Example
Log Output Examples
Successful Request
Failed Request
Sensitive Data Redaction
The logging middleware supports theRedacter interface for redacting sensitive data from logs:
Usage Example
Redacter, the middleware will attempt to use fmt.Stringer interface, or fall back to fmt.Sprintf("%+v", req).
Redaction Priority
The middleware checks for log-friendly interfaces in this order:Redacterinterface - Custom redaction logicfmt.Stringerinterface - Custom string representation- Default formatting - Uses
fmt.Sprintf("%+v", req)
Custom Logger Implementation
You can use any logger that implements thelog.Logger interface:
Zap Logger Example
Logrus Logger Example
Complete Example
Log Levels
The logging middleware uses different log levels based on the result:INFO- Successful requests (no error)ERROR- Failed requests (with error)
Best Practices
Always Redact Sensitive Data
Always Redact Sensitive Data
Implement the
Redacter interface for any request types containing passwords, tokens, or PII.Include Trace Context
Include Trace Context
Always include trace IDs in logs for correlation with distributed traces.
Use Structured Logging
Use Structured Logging
Use structured (JSON) logging in production for easier parsing and analysis.
Add Service Metadata
Add Service Metadata
Include service name, version, and instance ID in all logs.
Monitor Log Volume
Monitor Log Volume
High-traffic services can generate large log volumes. Consider sampling or filtering in production.
Centralize Logs
Centralize Logs
Send logs to a centralized logging system (ELK, Loki, CloudWatch) for aggregation and analysis.
Filtering Requests
Use the selector middleware to log only specific operations:Source Reference
The logging middleware implementation can be found in:middleware/logging/logging.go:22- Server middlewaremiddleware/logging/logging.go:63- Client middlewaremiddleware/logging/logging.go:17- Redacter interfacemiddleware/logging/logging.go:102- extractArgs function
Next Steps
Tracing
Add distributed tracing for request correlation
Metrics
Collect performance metrics