dd8080d678
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description <!-- Issue number if applicable --> Forgot to do this on #11561 |
||
|---|---|---|
| .. | ||
| auth | ||
| experimental/storage | ||
| extensioncapabilities | ||
| extensiontest | ||
| memorylimiterextension | ||
| zpagesextension | ||
| Makefile | ||
| README.md | ||
| extension.go | ||
| extension_test.go | ||
| go.mod | ||
| go.sum | ||
| package_test.go | ||
README.md
General Information
Extensions provide capabilities on top of the primary functionality of the collector. Generally, extensions are used for implementing components that can be added to the Collector, but which do not require direct access to telemetry data and are not part of the pipelines (like receivers, processors or exporters). Example extensions are: Health Check extension that responds to health check requests or PProf extension that allows fetching Collector's performance profile.
Supported service extensions (sorted alphabetically):
The contributors repository may have more extensions that can be added to custom builds of the Collector.
Ordering Extensions
The order extensions are specified for the service is important as this is the
order in which each extension will be started and the reverse order in which they
will be shutdown. The ordering is determined in the extensions tag under the
service tag in the configuration file, example:
service:
# Extensions specified below are going to be loaded by the service in the
# order given below, and shutdown on reverse order.
extensions: [extension1, extension2]