jaegertracing
/
documentation
mirror of https://github.com/jaegertracing/documentation.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add references to configs (#871) 

## Which problem is this PR solving?
- Resolves https://github.com/jaegertracing/jaeger/issues/6683
- Closes #870

Signed-off-by: Yuri Shkuro <github@ysh.us>
This commit is contained in:
Yuri Shkuro 2025-05-03 12:32:30 -04:00 committed by GitHub
parent 030fafba74
commit e8c7d0e02b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 14 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
content/docs/next-release-v2/architecture.md
View File

@ -12,7 +12,10 @@ children:
url: terminology
---
Jaeger v2 is designed to be a versatile and flexible tracing platform. It can be deployed as a single binary that can be configured to perform different **roles** within the Jaeger architecture, such as:
Jaeger v2 is designed to be a versatile and flexible tracing platform. It can be deployed as a single binary that can be configured to perform different **roles** within the Jaeger architecture.
## Roles
* **collector**: Receives incoming trace data from applications and writes it into a storage backend.
* **query**: Serves the APIs and the user interface for querying and visualizing traces.
* **ingester**: Ingests spans from Kafka and writes them into a storage backend; useful when running in a [split collector-Kafka-ingester configuration](./#via-kafka).

11
content/docs/next-release-v2/configuration.md
View File

@ -12,9 +12,17 @@ We are currently working on expanding this section with more details. [Examples
Jaeger can be configured via a YAML configuration file that uses the same format as the [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/configuration/). The configuration defines the main ingestion pipeline as a collection of **receivers**, **processors**, **connectors**, and **exporters**. Jaeger implements many of these components, but also a number of **extensions** that provide Jaeger's unique capabilities.
### Configuration Examples
[Examples of working configuration files](https://github.com/jaegertracing/jaeger/tree/main/cmd/jaeger) are available in the Jaeger GitHub repository:
* `config-{storage}.yaml` are examples of running Jaeger as `collector` role with different storage backends.
* `config-query.yaml` is an example of running Jaeger in a standalone `query` role (with UI).
* `cmd/jaeger/internal/all-in-one.yaml` is bundled in the Jaeger binary for `all-in-one` role.
* Other examples demonstrate additional features like SPM, tail sampling, adaptive sampling, etc.
### Environment Variables
Note that Jaeger v2 does not recognize environment variables in the same way as Jaeger v1 used to do for configuration, it only reads the YAML config file. However, the format of that YAML config does allow referring to environment variables, that provides some additional flexibility when needed. For example, in the config snippet below the hostname is `localhost` by default but it can be overwritten via `JAEGER_LISTEN_HOST` environment variable, which is useful when running Jaeger in a container and it needs to be `0.0.0.0`:
Jaeger v2 can only be configured via a config file, it does not recognize environment variables in the same way as Jaeger v1 used to do. However, the format of that YAML config does allow referring to environment variables, which provides some additional flexibility when needed. For example, in the config snippet below the hostname is `localhost` by default but it can be overwritten via `JAEGER_LISTEN_HOST` environment variable, which is useful when running Jaeger in a container and it needs to be `0.0.0.0`:
```yaml
receivers:
@ -35,6 +43,7 @@ Another way to override certain config values is by passing them via `--set` com
--set=receivers.otlp.protocols.grpc.endpoint=0.0.0.0:4317
```
This can be handy when running the `all-in-one` role that relies on a built-in config.
## Extensions