Version v3.7-DRAFT of the documentation is in DRAFT status. For the latest stable documentation, see v3.6.
Logging conventions
etcd uses the zap library for logging application output categorized into levels. A log messageβs level is determined according to these conventions:
DebugLevel logs are typically voluminous, and are usually disabled in production.
- Examples:
- Send a normal message to a remote peer
- Write a log entry to disk
- Examples:
InfoLevel is the default logging priority.
- Examples:
- Startup configuration
- Start to do snapshot
- Add a new node into the cluster
- Add a new user into auth subsystem
- Examples:
WarnLevel logs are more important than Info, but donβt need individual human review.
- Examples:
- Failure to send Raft message to a remote peer
- Failure to receive heartbeat message within the configured election timeout
- Examples:
ErrorLevel logs are high-priority. If an application is running smoothly, it shouldnβt generate any error-level logs.
- Examples:
- Failure to allocate disk space for WAL
- Examples:
PanicLevel logs a message, then panics.
- Examples:
- Failure to encode Raft messages
- Examples:
FatalLevel logs a message, then calls os.Exit(1).
- Examples:
- Failure to save Raft snapshot
- Examples:
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.