Event and span level should correspond to the significance of the event as follows:
TRACE - low-level, detailed information. This is useful for debugging, but is not necessary for normal operation. This may include very large data or very frequent events. This should be used rarely. Examples: the body of an http request. Every packet received by a network server.DEBUG - low-level lifecycle information that is useful for debugging, but not for tracing normal operation. This should be used sparingly. Examples: the result of a single database query. The result of a single function call.INFO - lifecycle information that is useful for understanding the operation of the system. This should be the default level for most events. Examples: the start of request processing. Connection established to a database. Initialization of a service succeeded.WARN - lifecycle information that indicates a potential problem. These are often ignorable errors that may indicate a problem, but do not prevent the system from operating. Examples: a request took longer than expected. Input failed to parse, but was ignored.ERROR - lifecycle information that indicates a problem that prevents the system from operating correctly. These are often fatal errors that require human intervention. Examples: a database connection failed. A required file was not found.By default, our OTLP exporter captures DEBUG and higher level events. This means that trace! events will not be exported by default. If you need to capture these events, you can change the level of the exporter using the OTEL_LEVEL env var.
Our log formatter logs at INFO level, so trace! and debug! events will not be visible in the logs. This can be configured with the RUST_LOG env var.
// avoid this
warn!("Connected to database");
// instead do this
info!("Connected to database");
We re-export all necessary crates from init4-bin-base. Use those as re-imports, rather than adding them to the local project’s Cargo.toml. This is not super important, but just nice for simplifying our dep trees and avoiding having multiple crate versions at once.
Yes this is more verbose, and we may choose to not like this later.
// avoid this
use tracing::info;
// instead do this
use init4_bin_base::deps::tracing::info;
Spans represent the duration of a unit of work. They are the primary data structure in tracing, and wrap span events produced by the event macros. Spans should be