You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/ninja-workshops/10-advanced-otel/8-routing-data/8-1-connector.md
+26-28Lines changed: 26 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,34 +7,32 @@ weight: 1
7
7
In this exercise, you will configure the `routing` connector in the `gateway.yaml` file. This setup enables the **Gateway** to route traces based on the `deployment.environment` attribute in the spans you send. By implementing this, you can process and handle traces differently depending on their attributes.
Open the `gateway.yaml` and add the following configuration:
11
-
12
-
-**Add the `routing` connector**: In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors. This approach also applies to `metrics` and `logs`, allowing them to be routed based on attributes in `resourceMetrics` or `resourceLogs`.
13
-
14
-
Add the following below the `receivers:` section and above the `processors:` section:
15
-
16
-
```yaml
17
-
connectors:
18
-
routing:
19
-
default_pipelines: [traces/standard] # Default pipeline if no rule matches
20
-
error_mode: ignore # Ignore errors in routing
21
-
table: # Define routing rules
22
-
# Routes spans to a target pipeline if the resourceSpan attribute matches the rule
23
-
- statement: route() where attributes["deployment.environment"] == "security_applications"
24
-
pipelines: [traces/security] # Target pipeline
25
-
```
26
-
27
-
- **Configure `file:` exporters**:
28
-
The `routing` connector requires separate targets for routing. Add two file exporters, `file/traces/security` and `file/traces/standard`, to ensure data is directed correctly:
29
-
30
-
```yaml
31
-
file/traces/standard: # Exporter for regular traces
32
-
path: "./gateway-traces-standard.out" # Path for saving trace data
33
-
append: false # Overwrite the file each time
34
-
file/traces/security: # Exporter for security traces
35
-
path: "./gateway-traces-security.out" # Path for saving trace data
36
-
append: false # Overwrite the file each time
37
-
```
10
+
11
+
**Add the `routing` connector**: In the **Gateway** terminal window edit `gateway.yaml` and add the following below the `receivers:` section and above the `processors:` section:
12
+
13
+
```yaml
14
+
connectors:
15
+
routing:
16
+
default_pipelines: [traces/standard] # Default pipeline if no rule matches
17
+
error_mode: ignore # Ignore errors in routing
18
+
table: # Define routing rules
19
+
# Routes spans to a target pipeline if the resourceSpan attribute matches the rule
20
+
- statement: route() where attributes["deployment.environment"] == "security_applications"
21
+
pipelines: [traces/security] # Target pipeline
22
+
```
23
+
24
+
In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors. This approach also applies to `metrics` and `logs`, allowing them to be routed based on attributes in `resourceMetrics` or `resourceLogs`.
25
+
26
+
**Configure `file:` exporters**: The `routing` connector requires separate targets for routing. Add two file exporters, `file/traces/security` and `file/traces/standard`, to ensure data is directed correctly:
27
+
28
+
```yaml
29
+
file/traces/standard: # Exporter for regular traces
30
+
path: "./gateway-traces-standard.out" # Path for saving trace data
31
+
append: false # Overwrite the file each time
32
+
file/traces/security: # Exporter for security traces
33
+
path: "./gateway-traces-security.out" # Path for saving trace data
-**Add both the `standard` and `security` traces pipelines**:
9
+
**Add both the `standard` and `security` traces pipelines**:
10
10
11
-
1.**Standard pipeline**: This pipeline processes all spans that do not match the routing rule. Add it below the existing `traces:` pipeline, keeping the configuration unchanged for now:
11
+
1.**Standard pipeline**: This pipeline processes all spans that do not match the routing rule. Add it below the existing `traces:` pipeline, keeping the configuration unchanged for now:
12
12
13
-
```yaml
14
-
traces/standard: # Default pipeline for unmatched spans
15
-
receivers:
16
-
- routing # Receive data from the routing connector
- file/traces/security# File Exporter for spans matching rule
37
-
```
21
+
- debug # Debug exporter
22
+
- file/traces/standard# File exporter for unmatched spans
23
+
```
38
24
39
-
- **Update the `traces` pipeline to use routing**: To enable `routing`, update the original `traces:` pipeline by adding `routing` as an exporter. This ensures all span data is sent through the routing connector for evaluation.
25
+
2. **Security pipeline**: This pipeline will handle all spans that match the routing rule:
40
26
41
-
Remove all processors as these are now defined in the `traces/standard` and `traces/security` pipelines.
27
+
```yaml
28
+
traces/security: # New Security Traces/Spans Pipeline
29
+
receivers:
30
+
- routing # Routing Connector, Only receives data from Connector
- file/traces/security # File Exporter for spans matching rule
37
+
```
42
38
43
-
```yaml
44
-
pipelines:
45
-
traces: # Original traces pipeline
46
-
receivers:
47
-
- otlp # OTLP Receiver
48
-
processors:
49
-
exporters:
50
-
- routing # Routing Connector
51
-
```
39
+
**Update the `traces` pipeline to use routing**:
40
+
41
+
1. To enable `routing`, update the original `traces:` pipeline by adding `routing` as an exporter. This ensures all span data is sent through the routing connector for evaluation.
42
+
43
+
2. Remove all processors as these are now defined in the `traces/standard` and `traces/security` pipelines.
44
+
45
+
```yaml
46
+
pipelines:
47
+
traces: # Original traces pipeline
48
+
receivers:
49
+
- otlp # OTLP Receiver
50
+
processors:
51
+
exporters:
52
+
- routing # Routing Connector
53
+
```
52
54
53
-
{{% notice note %}}
54
-
By excluding the batch processor, spans are written immediately instead of waiting for multiple spans to accumulate before processing. This improves responsiveness, making the workshop run faster and allowing you to see results sooner.
55
55
{{% /notice %}}
56
56
57
+
{{% notice note %}}
58
+
By excluding the batch processor, spans are written immediately instead of waiting for multiple spans to accumulate before processing. This improves responsiveness, making the workshop run faster and allowing you to see results sooner.
57
59
{{% /notice %}}
58
60
59
61
Validate the agent configuration using **[otelbin.io](https://www.otelbin.io/)**. For reference, the `traces:` section of your pipelines will look similar to this:
-**Start the Gateway**: In the **Gateway** terminal window navigate to the `[WORKSHOP]/8-routing` directory and run:
11
+
**Start the Gateway**: In the **Gateway** terminal window navigate to the `[WORKSHOP]/8-routing` directory and run:
12
12
13
-
```sh
14
-
../otelbin --config=gateway.yaml
15
-
```
13
+
```sh
14
+
../otelbin --config=gateway.yaml
15
+
```
16
16
17
-
-**Start the Agent**: In the **Agent** terminal window navigate to the `[WORKSHOP]/8-routing` directory and run:
17
+
**Start the Agent**: In the **Agent** terminal window navigate to the `[WORKSHOP]/8-routing` directory and run:
18
18
19
-
```sh
20
-
../otelbin --config=agent.yaml
21
-
```
19
+
```sh
20
+
../otelbin --config=agent.yaml
21
+
```
22
22
23
-
-**Create new security trace**: In the **Tests** terminal window navigate to the `[WORKSHOP]/8-routing` directory.
23
+
**Create new security trace**: In the **Tests** terminal window navigate to the `[WORKSHOP]/8-routing` directory.
24
24
25
-
The following JSON contains attributes which will trigger the routing rule. Copy the content from the tab below and save into a file named `security.json`.
25
+
The following JSON contains attributes which will trigger the routing rule. Copy the content from the tab below and save into a file named `security.json`.
1. Locate the **Test** terminal and navigate to the `[WORKSHOP]/8-routing` directory.
11
-
2. Send a regular span using the `trace.json` file to confirm proper communication.
9
+
**Send a Regular Span**:
12
10
13
-
Both the **Agent** and **Gateway** should display debug information, including the span you just sent. The gateway will also generate a new `gateway-traces-standard.out` file, as this is now the designated destination for regular spans.
11
+
1. Locate the **Test** terminal and navigate to the `[WORKSHOP]/8-routing` directory.
12
+
2. Send a regular span using the `trace.json` file to confirm proper communication.
13
+
14
+
Both the **Agent** and **Gateway** should display debug information, including the span you just sent. The gateway will also generate a new `gateway-traces-standard.out` file, as this is now the designated destination for regular spans.
If you check `gateway-traces-standard.out`, it should contain the `span` sent using the `cURL` command. You will also see an empty `gateway-traces-security.out` file, as the routing configuration creates output files immediately, even if no matching spans have been processed yet.
17
18
{{% /notice %}}
18
19
19
-
-**Send a Security Span**:
20
-
1. Ensure both the **Agent** and **Gateway** are running.
21
-
2. Send a security span using the `security.json` file to test the gateway’s routing rule.
20
+
**Send a Security Span**:
21
+
22
+
1. Ensure both the **Agent** and **Gateway** are running.
23
+
2. Send a security span using the `security.json` file to test the gateway’s routing rule.
22
24
23
25
Again, both the **Agent** and **Gateway** should display debug information, including the span you just sent. This time, the **Gateway** will write a line to the `gateway-traces-security.out` file, which is designated for spans where the `deployment.environment` resource attribute matches `"security_applications"`.
24
26
The `gateway-traces-standard.out` should be unchanged.
0 commit comments