@ -23,7 +23,7 @@ Administrators can also [configure the data source via YAML]({{< relref "#provis
Once you've added the data source, you can [configure it]({{< relref "#configure-the-data-source" >}}) so that your Grafana instance's users can create queries in its [query editor]({{< relref "./query-editor/" >}}) when they [build dashboards]({{< relref "../../dashboards/build-dashboards/" >}}) and use [Explore]({{< relref "../../explore/" >}}).
You can also [use the service graph]({{< relref "#use-the-service-graph" >}}) to view service relationships, [track RED metrics]({{< relref "#open-the-service-graph-view" >}}), [upload a JSON trace file]({{< relref "#upload-a-json-trace-file" >}}), and [link a trace ID from logs]({{< relref "#link-a-trace-id-from-logs" >}}) in Loki or Elasticsearch.
You can also [use the Service Graph]({{< relref "#use-the-service-graph" >}}) to view service relationships, [track RED metrics]({{< relref "#open-the-service-graph-view" >}}), [upload a JSON trace file]({{< relref "#upload-a-json-trace-file" >}}), and [link a trace ID from logs]({{< relref "#link-a-trace-id-from-logs" >}}) from a logs data source.
## Configure the data source
@ -44,9 +44,9 @@ Set the data source's basic configuration options carefully:
| **User** | Sets the user name for basic authentication. |
| **Password** | Sets the password for basic authentication. |
You can also configure settings specific to the Tempo data source:
You can also configure settings specific to the Tempo data source. These options are described in the sections below.
### Configure trace to logs
### Trace to logs
@ -55,53 +55,57 @@ You can also configure settings specific to the Tempo data source:
The **Trace to logs** setting configures the [trace to logs feature]({{< relref "../../explore/trace-integration" >}}) that is available when you integrate Grafana with Tempo.
There are two ways to configure the trace to logs feature. You can use simplified configuration with default query, or you can configure custom query where you can use a [template language]({{< relref "../../dashboards/variables/variable-syntax">}}) to interpolate variables from the trace or span.
There are two ways to configure the trace to logs feature:
**To use simple configuration:**
- Use a simplified configuration with default query, or
- Configure a custom query where you can use a [template language]({{< relref "../../dashboards/variables/variable-syntax">}}) to interpolate variables from the trace or span.
#### Use a simple configuration
1. Select the target data source.
1. Set start and end time shift. As the logs timestamps may not exactly match the timestamps of the spans in trace it may be necessary to search in larger or shifted time range to find the desired logs.
1. Select which tags to use in the logs query. The tags you configure must be present in the spans attributes or resources for a trace to logs span link to appear. You can optionally configure a new name for the tag. This is useful for example if the tag has dots in the name and the target data source does not allow using dots in labels. In that case you can for example remap `http.status` to `http_status`.
1. Optionally switch on Filter by Trace ID and/or Filter by Span ID to further filter the logs if your logs consistently contain trace or span IDs.
1. Optionally switch on the **Filter by trace ID** and/or **Filter by span ID** setting to further filter the logs if your logs consistently contain trace or span IDs.
**To use custom query configuration:**
#### Configure a custom query
1. Select the target data source.
1. Set start and end time shift. As the logs timestamps may not exactly match the timestamps of the spans in the trace it may be necessary to widen or shift the time range to find the desired logs.
1. Optionally select tags to map. These tags can be used in the custom query with `${__tags}` variable. This variable will interpolate the mapped tags as list in an appropriate syntax for the data source and will only include the tags that were present in the span omitting those that weren't present. You can optionally configure a new name for the tag. This is useful in cases where the tag has dots in the name and the target data source does not allow using dots in labels. For example, you can remap `http.status` to `http_status` in such a case. If you don't map any tags here, you can still use any tag in the query like this `method="${__span.tags.method}"`.
1. Skip Filter by Trace ID or Filter by Span ID as these cannot be used with custom query.
1. Switch on Use custom query.
1. Specify custom query to be used to query the logs. You can use various variables to make that query relevant for current span. The link will only be shown only if all the variables are interpolated with non-empty values to prevent creating invalid query.
1. Skip **Filter by trace ID** and **Filter by span ID** settings as these cannot be used with a custom query.
1. Switch on **Use custom query**.
1. Specify a custom query to be used to query the logs. You can use various variables to make that query relevant for current span. The link will only be shown only if all the variables are interpolated with non-empty values to prevent creating an invalid query.
#### Variables that can be used in a custom query
**Variables that can be used in custom query**
To use a variable you need to wrap it in `${}`. For example `${__span.name}`.
| \_\_tags | This variable is special because it uses the tag mapping in from the UI to create a label matcher string in the specific data source syntax. It uses only tags that are present in the span so the link will still be created even if only one of those tags is present in the span. You can use this if not all the tags are required for the query to be useful. |
| \_\_span.spanId | The ID of the span. |
| \_\_span.traceId | The ID of the trace. |
| \_\_span.duration | The duration of the span. |
| \_\_span.name | Name of the span. |
| \_\_span.tags | Namespace for the tags in the span. To access a specific tag named "version" you would use `${__span.tags.version}`. In case the tag contains dot you have to access it as `${__span.tags["http.status"]}`. |
| \_\_trace.traceId | The ID of the trace. |
| \_\_trace.duration | The duration of the trace. |
| **\_\_tags** | This variable uses the tag mapping from the UI to create a label matcher string in the specific data source syntax. The variable only uses tags that are present in the span. The link is still created even if only one of those tags is present in the span. You can use this if all tags are not required for the query to be useful. |
| **\_\_span.spanId** | The ID of the span. |
| **\_\_span.traceId** | The ID of the trace. |
| **\_\_span.duration** | The duration of the span. |
| **\_\_span.name** | Name of the span. |
| **\_\_span.tags** | Namespace for the tags in the span. To access a specific tag named `version`, you would use `${__span.tags.version}`. In case the tag contains dot, you have to access it as `${__span.tags["http.status"]}`. |
| **\_\_trace.traceId** | The ID of the trace. |
| **\_\_trace.duration** | The duration of the trace. |
| **\_\_trace.name** | The name of the trace. |
The following table describes the ways in which you can configure your trace to logs settings:
| **Data source** | Defines the target data source. You can select only Loki or Splunk \[logs\] data sources. |
| **Span start time shift** | Shifts the start time for the logs query, based on the span's start time. You can use time units, such as `5s`, `1m`, `3h`. To extend the time to the past, use a negative value. Default is 0. |
| **Span end time shift** | Shifts the end time for the logs query, based on the span's end time. You can use time units. Default is 0. |
| **Tags** | Defines the the tags to use in the logs query. Default is `'cluster', 'hostname', 'namespace', 'pod'`. You can change the tag name for example to remove dots from the name if they are not allowed in the target data source. For example map `http.status` to `http_status` |
| **Filter by Trace ID** | Toggles whether to append the trace ID to the logs query. |
| **Filter by Span ID** | Toggles whether to append the span ID to the logs query. |
| **Use custom query** | Toggles use of custom query with interpolation. |
| **Query** | Input to write custom query. Use variable interpolation to customize it with variables from span. |
| **Data source** | Defines the target data source. You can select only Loki or Splunk \[logs\] data sources. |
| **Span start time shift** | Shifts the start time for the logs query, based on the span's start time. You can use time units, such as `5s`, `1m`, `3h`. To extend the time to the past, use a negative value. Default: `0`. |
| **Span end time shift** | Shifts the end time for the logs query, based on the span's end time. You can use time units. Default: `0`. |
| **Tags** | Defines the the tags to use in the logs query. Default is `cluster`, `hostname`, `namespace`, `pod`. You can change the tag name for example to remove dots from the name if they are not allowed in the target data source. For example map `http.status` to `http_status`. |
| **Filter by trace ID** | Toggles whether to append the trace ID to the logs query. |
| **Filter by span ID** | Toggles whether to append the span ID to the logs query. |
| **Use custom query** | Toggles use of custom query with interpolation. |
| **Query** | Input to write custom query. Use variable interpolation to customize it with variables from span. |
### Configure trace to metrics
### Trace to metrics
> **Note:** This feature is behind the `traceToMetrics` [feature toggle]({{< relref "../../setup-grafana/configure-grafana#feature_toggles" >}}).
> If you use Grafana Cloud, open a [support ticket in the Cloud Portal](/profile/org#support) to access this feature.
@ -125,27 +129,27 @@ Each linked query consists of:
Interpolate tags using the `$__tags` keyword.
For example, when you configure the query `requests_total{$__tags}`with the tags `k8s.pod=pod` and `cluster`, the result looks like `requests_total{pod="nginx-554b9", cluster="us-east-1"}`.
### Configure service graph
### Service Graph
The **Service Graph** section configures the [Service Graph](/docs/tempo/latest/grafana-agent/service-graphs/) feature.
Configure the **Data source** setting to define in which Prometheus instance the Service Graph data is stored.
To use the service graph, refer to the [Service graph section]({{< relref "#use-the-service-graph" >}}).
To use the Service Graph, refer to the [Service Graph documentation]({{< relref "#use-the-service-graph" >}}).
### Configure Tempo search integration
### Node Graph
The **Search** section configures [Tempo search](/docs/tempo/latest/configuration/#search).
The **Node Graph** setting enables the [node graph visualization]({{< relref "../../panels-visualizations/visualizations/node-graph/" >}}), which is disabled by default.
Optionally configure the **Hide search** setting to hide the search query option in Explore if search is not configured in the Tempo instance.
Once enabled, Grafana displays the node graph after loading the trace view.
### Enable Node Graph
### Tempo search
The **Node Graph** setting enables the [Node Graph visualization]({{< relref "../../panels-visualizations/visualizations/node-graph/" >}}), which is disabled by default.
The **Search** section configures [Tempo search](/docs/tempo/latest/configuration/#search).
Once enabled, Grafana displays the Node Graph after loading the trace view.
You can configure the **Hide search** setting to hide the search query option in **Explore** if search is not configured in the Tempo instance.
### Configure Loki search
### Loki search
The **Loki search** section configures the Loki search query type.
@ -218,11 +222,11 @@ For details, refer to the [query editor documentation]({{< relref "./query-edito
You can upload a JSON file that contains a single trace and visualize it.
If the file has multiple traces, Grafana visualizes its first trace.
**To download a trace or service graph through the inspector:**
**To download a trace or Service Graph through the inspector:**
1. Open the inspector.
1. Navigate to the **Data** tab.
1. Click **Download traces** or **Download service graph**.
1. Click **Download traces** or **Download Service Graph**.
### Trace JSON example
@ -268,18 +272,18 @@ If the file has multiple traces, Grafana visualizes its first trace.
}
```
## Use the service graph
## Use the Service Graph
A service graph is a visual representation of the relationships between services.
The Service Graph is a visual representation of the relationships between services.
Each node on the graph represents a service such as an API or database.
You use a service graph to detect performance issues; track increases in error, fault, or throttle rates in services; and investigate root causes by viewing corresponding traces.
You use the Service Graph to detect performance issues; track increases in error, fault, or throttle rates in services; and investigate root causes by viewing corresponding traces.
{{<figuresrc="/static/img/docs/node-graph/node-graph-8-0.png"class="docs-image--no-shadow"max-width="500px"caption="Screenshot of a Node Graph">}}
**To display the service graph:**
**To display the Service Graph:**
1. [Configure Grafana Agent](/docs/tempo/latest/grafana-agent/service-graphs/#quickstart) or [Tempo or GET](/docs/tempo/latest/metrics-generator/service_graphs/#tempo) to generate service graph data.
1. [Configure Grafana Agent](/docs/tempo/latest/grafana-agent/service-graphs/#quickstart) or [Tempo or GET](/docs/tempo/latest/metrics-generator/service_graphs/#tempo) to generate Service Graph data.
1. Link a Prometheus data source in the Tempo data source's [Service Graph](#configure-service-graph) settings.
1. Navigate to [Explore]({{< relref "../../explore/" >}}).
1. Select the Tempo data source.
@ -316,7 +320,8 @@ To open the Service Graph view:
1. Link a Prometheus data source in the Tempo data source settings.
1. Navigate to [Explore]({{< relref "../../explore/" >}}).
1. Select the Tempo data source.
1. Select the **Service Graph** query type and run the query.
1. Select the **Service Graph** query type.
1. Run the query.
1. _(Optional)_ Filter your results.
> **Note:** Grafana uses the `traces_spanmetrics_calls_total` metric to display the name, rate, and error rate columns, and `traces_spanmetrics_latency_bucket` to display the duration column.
tooltip="The time range is ignored by default when querying by TraceID but can be used when there are performance issues or timeouts since it will narrow down the search to the defined range. Default is disabled."
tooltip="The time range can be used when there are performance issues or timeouts since it will narrow down the search to the defined range. Default: disabled"
tooltip="Shifts the start of the time range when searching by TraceID. This is needed as searching for traces can return traces that do not fully fall into the search time range, so we recommend using higher time shifts for longer traces. Default 30m (Time units can be used here, for example: 5s, 1m, 3h)"
tooltip="Shifts the start of the time range when searching by TraceID. Searching can return traces that do not fully fall into the search time range, so we recommend using higher time shifts for longer traces. Default: 30m (Time units can be used here, for example: 5s, 1m, 3h)"
tooltip="Shifts the end of the time range when searching by TraceID. This is needed as searching for traces can return traces that do not fully fall into the search time range, so we recommend using higher time shifts for longer traces. Default 30m (Time units can be used here, for example: 5s, 1m, 3h)"
tooltip="Shifts the end of the time range when searching by TraceID. Searching can return traces that do not fully fall into the search time range, so we recommend using higher time shifts for longer traces. Default: 30m (Time units can be used here, for example: 5s, 1m, 3h)"
Joey
2 years ago
committed by