Top 1.4% dependent packages on proxy.golang.org
Top 1.8% dependent repos on proxy.golang.org
Top 9.9% forks on proxy.golang.org
Top 1.5% docker downloads on proxy.golang.org
proxy.golang.org : github.com/tetratelabs/telemetry
Package telemetry holds observability facades for our services and libraries. The provided interface here allows for instrumenting libraries and packages without any dependencies on Logging and Metric instrumentation implementations. This allows a consistent way of authoring Log lines and Metrics for the producers of these libraries and packages while providing consumers the ability to plug in the implementations of their choice. The following requirements helped shape the form of the interfaces. Or developers will resort to using `fmt.Printf()` Error: something happened that we can't gracefully recover from. This is a log line that should be actionable by an operator and be alerted on. Info: something happened that might be of interest but does not impact the application stability. E.g. someone gave the wrong credentials and was therefore denied access, parsing error on external input, etc. Debug: anything that can help to understand application state during development. More levels get tricky to reason about when writing log lines or establishing the right level of verbosity at runtime. By the above explanations fatal folds into error, warning folds into info, and trace folds into debug. We trust more in partitioning loggers per domain, component, etc. and allow them to be individually addressed to required log levels than controlling a single logger with more levels. We also believe that most logs should be metrics. Anything above Debug level should be able to emit a metric which can be use for dashboards, alerting, etc. We want the ability to rollup / aggregate over the same message while allowing for contextual data to be added. A logging implementation can make the choice how to present to provided log data. This can be 100% structured, a single log line, or a combination. Allow the Go Context object to be passed and have a registry for values of interest we want to pull from context. A good example of an item we want to automatically include in log lines is the `x-request-id` so we can tie log lines produced in the request path together. This allows us to control per component which levels of log lines we want to output at runtime. The interface design allows for this to be implemented without having an opinion on it. By providing at each library or component entry point the ability to provide a Logger implementation, this can be easily achieved. Look at that lovely very empty go.mod and non-existent go.sum file.
Registry
-
Source
- Documentation
- JSON
purl: pkg:golang/github.com/tetratelabs/telemetry
License: Apache-2.0
Latest release: over 1 year ago
First release: over 3 years ago
Namespace: github.com/tetratelabs
Dependent packages: 14
Dependent repositories: 8
Stars: 4 on GitHub
Forks: 3 on GitHub
Docker dependents: 6
Docker downloads: 161
See more repository details: repos.ecosyste.ms
Last synced: 14 days ago