|
| 1 | +# Logging Policy for Sensitive Data |
| 2 | + |
| 3 | +To ensure the security and privacy of data processed by the OpenTelemetry Collector, the following rules regarding logging must be observed. |
| 4 | + |
| 5 | +## Rules |
| 6 | + |
| 7 | +1. **No Sensitive Data at Info/Warn/Error Levels** |
| 8 | + - Telemetry data (metric names, label values, attribute values, resource attributes) must NOT be logged at `Info`, `Warn`, or `Error` levels. |
| 9 | + - PII (Personally Identifiable Information), credentials, and exact payload contents are strictly prohibited in high-level logs. |
| 10 | + |
| 11 | +2. **Error Messages** |
| 12 | + - Returned errors must be generic and actionable without embedding specific metric data. |
| 13 | + - Do NOT wrap errors with formatted strings containing raw telemetry values (e.g., `fmt.Errorf("failed processing metric %s: %w", metricName, err)` is prohibited). |
| 14 | + - Use structural logging fields at `Debug` level if context is needed. |
| 15 | + |
| 16 | +3. **Debug Level Exception** |
| 17 | + - Detailed diagnostic context, including specific metric names or attribute values, MAY be logged at `Debug` level only. |
| 18 | + - This allows operators to opt-in to verbose logging for troubleshooting without polluting default logs with potentially sensitive data. |
| 19 | + |
| 20 | +## Implementation Guidelines |
| 21 | + |
| 22 | +**Incorrect:** |
| 23 | +```go |
| 24 | +// BAD: Leaks sensitive metric name in error |
| 25 | +if err := process(metric); err != nil { |
| 26 | + return fmt.Errorf("failed to process metric %s: %w", metric.Name(), err) |
| 27 | +} |
| 28 | +``` |
| 29 | + |
| 30 | +**Correct:** |
| 31 | +```go |
| 32 | +// GOOD: Logs details at debug, returns generic error |
| 33 | +if err := process(metric); err != nil { |
| 34 | + logger.Debug("failed to process metric", |
| 35 | + zap.String("metric_name", metric.Name()), |
| 36 | + zap.Error(err)) |
| 37 | + return fmt.Errorf("failed to process metric: %w", err) |
| 38 | +} |
| 39 | +``` |
0 commit comments