What are some best practices for logging in Go?

Using structured logging, adding context, controlling log levels, avoiding logging sensitive data, using consistent field names, correctly logging errors, taking into account performance, centrally monitoring logs and unifying configurations are best practices in Go to achieve efficient logging. First, structured logs in JSON format (such as using uber-go/zap or rs/zerolog) are convenient for machine analysis and integration of ELK, Datadog and other tools; second, log traceability is enhanced by requesting context information such as ID and user ID, and can be injected through context.Context or HTTP middleware; third, use Debug, Info, Warn, Error levels reasonably, and dynamically control them through environment variables; fourth, record sensitive information such as passwords and API keys, and desensitization of inputs is strictly prohibited; fifth, unified field naming is such as "user_id", "req_id", "method", etc. to improve query efficiency; Sixth, when recording errors, you should include context and zap.Error(err) to capture stack information, rather than just outputting err.Error(); Seventh, you should give priority to using high-performance library zap to avoid executing string splicing or function calls in hot paths; Eighth, in production environment, logs should be concentrated on CloudWatch, Splunk and other systems, set up alarms and integrate observability pipelines; Ninth, initialization loggers should be completed in main function, and passed through dependency injection to avoid the arbitrary use of global variables and log.Printf. In summary, good Go logs should take into account structure, context integrity, security and performance to ensure that logs have long-term value to both current developers and future maintenance teams.

Logging in Go doesn't have to be complicated, but doing it right helps with debugging, monitoring, and maintaining applications in production. While Go's built-in log package works for basics, real-world applications benefit from more structured and flexible approaches. Here are some best practices:

✅ Use Structured Logging

Plain text logs are hard to parse and search at scale. Instead, use structured logging (typically JSON format) so logs can be easily ingested by tools like ELK, Datadog, or Loki.

Popular libraries:

• uber-go/zap – high-performance, structured logging.
• rs/zerolog – zero-allocation JSON logger.
• logrus – feature-rich, though slower than zap/zerolog.

Example with zap :

 logger, _ := zap.NewProduction()
defer logger.Sync()

logger.Info("Failed to fetch URL",
    zap.String("url", "http://example.com"),
    zap.Int("attempt", 3),
    zap.Duration("backoff", time.Second),
)

This outputs machine-readable JSON:

 {"level":"info","msg":"Failed to fetch URL","url":"http://example.com","attempt":3,"backoff":"1s"}

✅ Add Context to Your Logs

Avoid logging isolated events. Always include relevant context like:

• Request IDs
• User IDs
• Correlation IDs
• Timestamps (usually automatic)
• Function or handler names

One way to do this is by creating context-aware loggers . You can attach a logger to context.Context :

 ctx := context.WithValue(context.Background(), "requestID", "abc123")
logger := baseLogger.With(zap.String("requestID", ctx.Value("requestID").(string)))

Alternatively, use a logging middleware in HTTP handlers to inject request-scoped loggers.

✅ Control Log Levels

Use appropriate log levels ( Debug , Info , Warn , Error , Fatal ) to filter noise and highlight severity.

Best practices:

• Use Info for notable events (eg, service started, user logged in).
• Use Debug during development or troubleshooting (disable in production unless needed).
• Use Error for failures that don't crash the app.
• Avoid overusing Fatal or Panic —they terminate the process.

Ensure you can configure log levels at runtime via environment variables:

 level := zap.NewAtomicLevel()
if env == "production" {
    level.SetLevel(zap.InfoLevel)
} else {
    level.SetLevel(zap.DebugLevel)
}

✅ Avoid Logging Sensitive Data

Never log:

• Passwords
• API keys
• Personal Identifiable Information (PII)
• Credit card numbers

Always sanitize input:

 logger.Info("User login attempt",
    zap.String("email", user.Email),
    // zap.String("password", user.Password) ← NEVER DO THIS
    zap.Bool("success", success),
)

Consider redacting or hashing sensitive fields if needed for debugging.

✅ Use Consistent Field Names

Stick to a naming convention across your logs to make querying easier. For example:

• "user_id" instead of "userID" , "UserId" , or "user"
• "req_id" for request ID
• "method" , "path" , "status" for HTTP requests

This helps when writing log queries or alerts.

✅ Log Errors Properly

Don't just log err.Error() —include context and structured fields.

❌ Bad:

 if err != nil {
    log.Printf("Error: %v", err)
}

✅ Good:

 if err != nil {
    logger.Error("Failed to process payment",
        zap.String("user_id", userID),
        zap.String("payment_id", paymentID),
        zap.Error(err),
    )
}

Use zap.Error(err) or equivalent to capture error messages and stack traces (if available).

✅ Consider Performance

In high-throughput services, logging can become a bottleneck. Avoid expensive operations in hot paths.

Tips:

• Use zap in production for better performance.
• Avoid string formatting or function calls in debug logs that are disabled.
• Use zap.SugaredLogger only when you need printf-style logging; prefer zap.Logger for performance.

✅ Centralize and Monitor Logs

In production:

• Ship logs to a centralized system (eg, CloudWatch, Splunk, Graylog).
• Set up alerts on critical errors.
• Use structured logs to filter, aggregate, and analyze.

Don't rely on stdout / stderr alone—integrate with observability pipelines.

✅ Initialize and Configure Logger Once

Set up your logger early in main() and pass it explicitly or via context. Avoid global loggers unless necessary.

 func main() {
    logger := setupLogger()
    defer logger.Sync()

    svc := &MyService{logger: logger}
    svc.Run()
}

Avoid using log.Printf scattered across code—promote consistency.

Basically, good logging in Go comes down to: structure, context, safety, and performance . Pick the right tool (like zap or zerolog ), be consistent, and design logs to be useful—not just for you today, but for your team and systems tomorrow.

The above is the detailed content of What are some best practices for logging in Go?. For more information, please follow other related articles on the PHP Chinese website!