Skip to content

OBSDOCS-577: Docs bug fix for an incorrect API #70512

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 9, 2024
Merged

OBSDOCS-577: Docs bug fix for an incorrect API #70512

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions distr_tracing/distr_tracing_tempo/distr-tracing-tempo-configuring.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,11 @@ include::modules/distr-tracing-tempo-config-storage.adoc[leveloffset=+2]

include::modules/distr-tracing-tempo-config-query-frontend.adoc[leveloffset=+2]

[role="_additional-resources"]
[id="additional-resources_distr-tracing-tempo-configuring"]
==== Additional resources
* xref:../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations-about_nodes-scheduler-taints-tolerations[Understanding taints and tolerations]

include::modules/distr-tracing-tempo-config-spanmetrics.adoc[leveloffset=+2]

include::modules/distr-tracing-tempo-config-multitenancy.adoc[leveloffset=+2]
Expand Down
4 changes: 2 additions & 2 deletions modules/distr-tracing-tempo-config-default.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,8 +38,8 @@ spec:

|apiVersion:
|API version to use when creating the object.
|`tempotracing.io/v1`
|`tempotracing.io/v1`
|`tempo.grafana.com/v1alpha1`
|`tempo.grafana.com/v1alpha1`

|kind:
|Defines the kind of Kubernetes object to create.
Expand Down
151 changes: 107 additions & 44 deletions modules/distr-tracing-tempo-config-query-frontend.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,62 +6,125 @@
[id="distr-tracing-tempo-config-query_{context}"]
= Query configuration options

Query is a service that retrieves traces from storage and hosts the user interface to display them.
Two components of the {TempoShortName}, the querier and query frontend, manage queries. You can configure both of these components.

.Parameters used by the {TempoOperator} to define Query
The querier component finds the requested trace ID in the ingesters or back-end storage. Depending on the set parameters, the querier component can query both the ingesters and pull bloom or indexes from the back end to search blocks in object storage. The querier component exposes an HTTP endpoint at `GET /querier/api/traces/<traceID>`, but it is not expected to be used directly. Queries must be sent to the query frontend.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<trace_id> (and one other instance below) + "front end":

Suggested change
The querier component finds the requested trace ID in the ingesters or back-end storage. Depending on the set parameters, the querier component can query both the ingesters and pull bloom or indexes from the back end to search blocks in object storage. The querier component exposes an HTTP endpoint at `GET /querier/api/traces/<traceID>`, but it is not expected to be used directly. Queries must be sent to the query frontend.
The querier component finds the requested trace ID in the ingesters or back-end storage. Depending on the set parameters, the querier component can query both the ingesters and pull bloom or indexes from the back end to search blocks in object storage. The querier component exposes an HTTP endpoint at `GET /querier/api/traces/<trace_id>`, but it is not expected to be used directly. Queries must be sent to the query front end.

Copy link
Contributor Author

@max-cx max-cx Feb 12, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adellape, thank you, in this case it is a set name for a component that is already used upstream, "query frontend".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I will lowercase trace_id in another PR. Taking note of it. Thank you for spotting this.


.Configuration parameters for the querier component
[options="header"]
[cols="l, a, a, a"]
|===
|Parameter |Description |Values |Default value

|spec:
query:
replicas:
|Specifies the number of Query replicas to create.
|Positive integer
|
|Parameter |Description |Values

|`nodeSelector`
|The simple form of the node-selection constraint.
|type: object

|`replicas`
|The number of replicas to be created for the component.
|type: integer; format: int32

|`tolerations`
|Component-specific pod tolerations.
|type: array
|===

The query frontend component is responsible for sharding the search space for an incoming query. The query frontend exposes traces via a simple HTTP endpoint: `GET /api/traces/<traceID>`. Internally, the query frontend component splits the `blockID` space into a configurable number of shards and then queues these requests. The querier component connects to the query frontend component via a streaming gRPC connection to process these sharded queries.

.Configuration parameters passed to Query
.Configuration parameters for the query frontend component
[options="header"]
[cols="l, a, a, a"]
|===
|Parameter |Description |Values |Default value

|spec:
query:
options: {}
|Configuration options that define the Query service.
|
|

|options:
log-level:
|Logging level for Query.
|`debug`, `info`, `warn`, `error`, `fatal`, `panic`
|

|options:
query:
base-path:
|You can set the base path for all tempo-query HTTP routes to a non-root value: for example, `/tempo` will cause all UI URLs to start with `/tempo`. This can be useful when running `tempo-query` behind a reverse proxy.
|`/<path>`
|
|Parameter |Description |Values

|`component`
|Configuration of the query frontend component.
|type: object

|`component.nodeSelector`
|The simple form of the node selection constraint.
|type: object

|`component.replicas`
|The number of replicas to be created for the query frontend component.
|type: integer; format: int32

|`component.tolerations`
|Pod tolerations specific to the query frontend component.
|type: array

|`jaegerQuery`
|The options specific to the Jaeger Query component.
|type: object

|`jaegerQuery.enabled`
|When `enabled`, creates the Jaeger Query component,`jaegerQuery`.
|type: boolean

|`jaegerQuery.ingress`
|The options for the Jaeger Query ingress.
|type: object

|`jaegerQuery.ingress.annotations`
|The annotations of the ingress object.
|type: object

|`jaegerQuery.ingress.host`
|The hostname of the ingress object.
|type: string

|`jaegerQuery.ingress.ingressClassName`
|The name of an IngressClass cluster resource. Defines which ingress controller serves this ingress resource.
|type: string

|`jaegerQuery.ingress.route`
|The options for the OpenShift route.
|type: object

|`jaegerQuery.ingress.route.termination`
|The termination type. The default is `edge`.
|type: string (enum: insecure, edge, passthrough, reencrypt)

|`jaegerQuery.ingress.type`
|The type of ingress for the Jaeger Query UI. The supported types are `ingress`, `route`, and `none`.
|type: string (enum: ingress, route)

|`jaegerQuery.monitorTab`
|The monitor tab configuration.
|type: object

|`jaegerQuery.monitorTab.enabled`
|Enables the monitor tab in the Jaeger console. The `PrometheusEndpoint` must be configured.
|type: boolean

|`jaegerQuery.monitorTab.prometheusEndpoint`
|The endpoint to the Prometheus instance that contains the span rate, error, and duration (RED) metrics. For example, `+https://thanos-querier.openshift-monitoring.svc.cluster.local:9091+`.
|type: string

|===

.Sample Query configuration
.Example configuration of the query frontend component in a `TempoStack` CR
[source,yaml]
----
apiVersion: tempotracing.io/v1
kind: "Tempo"
apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
name: "my-tempo"
name: simplest
spec:
strategy: allInOne
allInOne:
options:
log-level: debug
query:
base-path: /tempo
storage:
secret:
name: minio
type: s3
storageSize: 200M
resources:
total:
limits:
memory: 2Gi
cpu: 2000m
template:
queryFrontend:
jaegerQuery:
enabled: true
ingress:
route:
termination: edge
type: route
----
2 changes: 1 addition & 1 deletion modules/distr-tracing-tempo-config-spanmetrics.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@
= Configuration of the monitor tab in Jaeger UI

Trace data contains rich information, and the data is normalized across instrumented languages and frameworks.
Therefore, additional metrics can be extracted from traces. These metrics are request count, duration, and error count (RED).
Therefore, request rate, error, and duration (RED) metrics can be extracted from traces.
The metrics can be visualized in Jaeger console in the *Monitor* tab.

The metrics are derived from spans in the OpenTelemetry Collector that are scraped from the Collector by the Prometheus deployed in the user-workload monitoring stack.
Expand Down