Use slog with a JSON handler for machine-parseable output, attach request-scoped fields via slog.With, and inject the logger via dependency injection rather than using a global.
JSON output for log aggregators (Datadog, Loki, CloudWatch) — text for local development
Attach traceID, spanID, userID, requestID to every log entry for correlation
Avoid logging sensitive data: passwords, tokens, PII — mask or omit
Log at appropriate levels: Debug (local only), Info (normal ops), Warn (recoverable issues), Error (failures)
Inject logger via dependency injection — global loggers make testing and context propagation harder
We have a small Go microservice that currently uses fmt.Printf for logs. How would you replace it with log/slog to emit JSON structured logs?
If you need to add a request ID field to every log entry in this service, where would you configure it with slog?
What does the output look like when you call slog.Info without any attributes?
You're adding a new feature that processes user uploads, and you need to log errors with stack traces and request context using slog. How would you structure the logger and what trade‑offs would you consider?
During a production incident you notice that logs are missing the 'user_id' field for some requests. Walk me through how you'd debug the slog configuration to find the cause.
Explain how you would integrate slog with an external log aggregation system like Loki or Elasticsearch, and what changes you’d make to the logger setup.
Our service runs on dozens of instances behind a load balancer, each emitting high‑volume JSON logs via slog. How would you design the logging pipeline to avoid performance bottlenecks and ensure logs are correlated across instances?
We need to support dynamic log level changes without restarting the service. How would you implement this with slog, and what are the implications for concurrency and safety?
Describe how you would handle logging of sensitive data (PII) in structured logs while still providing useful context for debugging.
Our organization is migrating from a legacy logging library to log/slog across multiple services. What strategy would you use to roll out the change while maintaining backward compatibility and observability?
At scale we need to enforce a company‑wide logging schema (field names, types, required fields). How would you implement schema validation or enforcement in Go using slog, and how would you govern it across teams?
Discuss the long‑term maintenance considerations of using slog for structured logging, including version upgrades, vendor lock‑in, and integration with evolving observability platforms.