Skip to content

Commit 8ed21af

Browse files
rcastleyrcastley
committed
Formatting fixes
1 parent 27999aa commit 8ed21af

File tree

4 files changed

+169
-152
lines changed

4 files changed

+169
-152
lines changed

‎content/en/ninja-workshops/10-advanced-otel/8-routing/8-1-connector.md‎

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
---
2+
title: 8.1 Configuring the Routing Connector
3+
linkTitle: 8.1 Routing Configuration
4+
weight: 1
5+
---
6+
7+
In the following exercise, you will configure the `routing connector` in the `gateway.yaml` file. This setup will enable the **Gateway** to route traces based on the `deployment.environment` attribute in the spans you send. By doing so, you can process and handle traces differently depending on their attributes.
8+
9+
{{% notice title="Exercise" style="green" icon="running" %}}
10+
Open the `gateway.yaml` and add the following configuration:
11+
12+
- **Add the `connectors:` section**:
13+
In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors. In the `gateway.yaml` file, insert the `connectors:` section below the `receivers` section and above the `processors` section.
14+
15+
```yaml
16+
connectors: # Section to configure connectors
17+
18+
processors:
19+
20+
```
21+
22+
- **Add the `routing` connector**:
23+
In this configuration, spans will be routed if the `deployment.environment` resource attribute matches `"security_applications"`.
24+
25+
This same approach can also be applied to `metrics` and `logs`, allowing you to route them based on attributes in `resourceMetrics` or `resourceLogs` similarly. Add the following under the `connectors:` section:
26+
27+
```yaml
28+
routing:
29+
default_pipelines: [traces/standard] # Default pipeline to use if no matching rule
30+
error_mode: ignore # Ignore errors in the routing
31+
table: # Array with routing rules
32+
# Connector will route any span to target pipeline if if the resourceSpn attribute matches this rule
33+
- statement: route() where attributes["deployment.environment"] == "security_applications"
34+
pipelines: [traces/security] # Target pipeline
35+
```
36+
37+
- **Configure two `file:` Exporters**:
38+
The `routing connector` requires different targets for routing. To achieve this, update the default `file/traces:` exporter and name it `file/traces/default:` and add a second file exporter called `file/traces/security:`. This will allow the routing connector to direct data to the appropriate target based on the rules you define.
39+
40+
```yaml
41+
file/traces/standard: # Exporter Type/Name (For regular traces)
42+
# Path where trace data will be saved in OTLP json format
43+
path: "./gateway-traces-standard.out"
44+
append: false # Overwrite the file each time
45+
file/traces/security: # Exporter Type/Name (For security traces)
46+
# Path where trace data will be saved in OTLP json format
47+
path: "./gateway-traces-security.out"
48+
append: false # Overwrite the file each time
49+
```
50+
51+
{{% /notice %}}
52+
53+
With the routing configuration complete, next we configure the pipelines to use the routing rules.

‎content/en/ninja-workshops/10-advanced-otel/8-routing/8-2-pipelines.md‎

Lines changed: 112 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,112 @@
1+
---
2+
title: 8.2 Configuring the Pipelines
3+
linkTitle: 8.2 Pipeline Configuration
4+
weight: 2
5+
---
6+
7+
{{% notice title="Exercise" style="green" icon="running" %}}
8+
- **Add both the `standard` and `security` traces pipelines**:
9+
10+
1. **Standard** pipeline: This pipeline will handle all spans that do not match the routing rule. Add it below the regular `traces:` pipeline, and leave the configuration unchanged for now.
11+
12+
```yaml
13+
pipelines:
14+
traces/standard: # New Default Traces/Spans Pipeline
15+
receivers:
16+
- routing # Routing Connector, Only receives data from Connector
17+
processors:
18+
- memory_limiter # Memory Limiter Processor
19+
- resource/add_mode # Adds collector mode metadata
20+
exporters:
21+
- debug # Debug Exporter
22+
- file/traces/standard # File Exporter for spans NOT matching rule
23+
```
24+
25+
- **Target pipeline**: This pipepline will handle all spans that match the routing rule.
26+
27+
```yaml
28+
pipelines:
29+
traces/security: # New Security Traces/Spans Pipeline
30+
receivers:
31+
- routing # Routing Connector, Only receives data from Connector
32+
processors:
33+
- memory_limiter # Memory Limiter Processor
34+
- resource/add_mode # Adds collector mode metadata
35+
exporters:
36+
- debug # Debug Exporter
37+
- file/traces/security # File Exporter for spans matching rule
38+
```
39+
40+
- **Update the `traces` pipeline to handle routing**: To enable `routing`, update the original `traces:` pipeline by adding `routing` as an exporter. This ensures that all span data is sent through the routing connector for evaluation.
41+
42+
For clarity, we are removing the `debug` exporter from this pipeline, so that debug output is only shown from the new exporters behind the routing connector.
43+
44+
```yaml
45+
pipelines:
46+
traces: # Original traces pipeline
47+
receivers:
48+
- otlp # Debug Exporter
49+
exporters:
50+
- routing # Routing Connector, Only exports data to Connector
51+
```
52+
53+
{{% notice title="Tip" style="primary" icon="lightbulb" %}}
54+
55+
Keep in mind that any existing processors have been removed from this pipeline. They are now handled by either the standard pipeline or the target pipelines, depending on the routing rules.
56+
57+
Additionally, the `batch` processor has been removed from the new pipelines. This ensures that `spans` are written immediately, rather than waiting for multiple spans to arrive before processing. This change speeds up the workshop and allows you to see results faster.
58+
{{% /notice %}}
59+
60+
{{% /notice %}}
61+
62+
Again, validate the **Gateway** configuration using `otelbin.io` for spelling mistakes etc. Your `Traces:` pipeline should like this:
63+
64+
```mermaid
65+
%%{init:{"fontFamily":"monospace"}}%%
66+
graph LR
67+
%% Nodes
68+
REC1(&nbsp;&nbsp;&nbsp;otlp&nbsp;&nbsp;&nbsp;<br>fa:fa-download):::receiver
69+
PRO1(memory_limiter<br>fa:fa-microchip):::processor
70+
PRO2(memory_limiter<br>fa:fa-microchip):::processor
71+
PRO3(resource<br>fa:fa-microchip):::processor
72+
PRO4(resource<br>fa:fa-microchip):::processor
73+
EXP1(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload):::exporter
74+
EXP2(&emsp;&emsp;file&emsp;&emsp;<br>fa:fa-upload):::exporter
75+
EXP3(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload):::exporter
76+
EXP4(&emsp;&emsp;file&emsp;&emsp;<br>fa:fa-upload):::exporter
77+
ROUTE1(&nbsp;routing&nbsp;<br>fa:fa-route):::con-export
78+
ROUTE2(&nbsp;routing&nbsp;<br>fa:fa-route):::con-receive
79+
ROUTE3(&nbsp;routing&nbsp;<br>fa:fa-route):::con-receive
80+
%% Links
81+
subID1:::sub-traces
82+
subID2:::sub-traces
83+
subID3:::sub-traces
84+
subgraph " "
85+
direction LR
86+
subgraph subID1[**Traces**]
87+
REC1 --> ROUTE1
88+
end
89+
subgraph subID2[**Traces/standard**]
90+
ROUTE1 --> ROUTE2
91+
ROUTE2 --> PRO1
92+
PRO1 --> PRO3
93+
PRO3 --> EXP1
94+
PRO3 --> EXP2
95+
end
96+
subgraph subID3[**Traces/security**]
97+
ROUTE1 --> ROUTE3
98+
ROUTE3 --> PRO2
99+
PRO2 --> PRO4
100+
PRO4 --> EXP3
101+
PRO4 --> EXP4
102+
end
103+
end
104+
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
105+
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
106+
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
107+
classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
108+
```
109+
110+
<!--![Routing Connector](../images/routing-8-1.png)-->
111+
112+
Lets' test our configuration!

‎content/en/ninja-workshops/10-advanced-otel/8-routing/8-1-routing-test.md‎ renamed to ‎content/en/ninja-workshops/10-advanced-otel/8-routing/8-3-routing-test.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
2-
title: 8.1 Test Routing Connector
3-
linkTitle: 8.1 Test Routing
4-
weight: 1
2+
title: 8.3 Test Routing Connector
3+
linkTitle: 8.3 Test Routing
4+
weight: 3
55
---
66

77
### Setup Test

‎content/en/ninja-workshops/10-advanced-otel/8-routing/_index.md‎

Lines changed: 1 addition & 149 deletions
Original file line numberDiff line numberDiff line change
@@ -35,152 +35,4 @@ WORKSHOP
3535

3636
{{% /tab %}}
3737

38-
In the following exercise, you will configure the `routing connector` in the `gateway.yaml` file. This setup will enable the **Gateway** to route traces based on the `deployment.environment` attribute in the spans you send. By doing so, you can process and handle traces differently depending on their attributes.
39-
40-
{{% notice title="Exercise" style="green" icon="running" %}}
41-
Open the `gateway.yaml` and add the following configuration:
42-
43-
- **Add the `connectors:` section**:
44-
In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors. In the `gateway.yaml` file, insert the `connectors:` section below the `receivers` section and above the `processors` section.
45-
46-
```yaml
47-
connectors: # Section to configure connectors
48-
49-
processors:
50-
51-
```
52-
53-
- **Add the `routing` connector**:
54-
In this configuration, spans will be routed if the `deployment.environment` resource attribute matches `"security_applications"`.
55-
56-
This same approach can also be applied to `metrics` and `logs`, allowing you to route them based on attributes in `resourceMetrics` or `resourceLogs` similarly. Add the following under the `connectors:` section:
57-
58-
```yaml
59-
routing:
60-
default_pipelines: [traces/standard] # Default pipeline to use if no matching rule
61-
error_mode: ignore # Ignore errors in the routing
62-
table: # Array with routing rules
63-
# Connector will route any span to target pipeline if if the resourceSpn attribute matches this rule
64-
- statement: route() where attributes["deployment.environment"] == "security_applications"
65-
pipelines: [traces/security] # Target pipeline
66-
```
67-
68-
- **Configure two `file:` Exporters**:
69-
The `routing connector` requires different targets for routing. To achieve this, update the default `file/traces:` exporter and name it `file/traces/default:` and add a second file exporter called `file/traces/security:`. This will allow the routing connector to direct data to the appropriate target based on the rules you define.
70-
71-
```yaml
72-
file/traces/standard: # Exporter Type/Name (For regular traces)
73-
# Path where trace data will be saved in OTLP json format
74-
path: "./gateway-traces-standard.out"
75-
append: false # Overwrite the file each time
76-
file/traces/security: # Exporter Type/Name (For security traces)
77-
# Path where trace data will be saved in OTLP json format
78-
path: "./gateway-traces-security.out"
79-
append: false # Overwrite the file each time
80-
```
81-
82-
- **Add both the `standard` and `security` traces pipelines**:
83-
84-
1. **Standard** pipeline: This pipeline will handle all spans that do not match the routing rule. Add it below the regular `traces:` pipeline, and leave the configuration unchanged for now.
85-
86-
```yaml
87-
pipelines:
88-
traces/standard: # New Default Traces/Spans Pipeline
89-
receivers:
90-
- routing # Routing Connector, Only receives data from Connector
91-
processors:
92-
- memory_limiter # Memory Limiter Processor
93-
- resource/add_mode # Adds collector mode metadata
94-
exporters:
95-
- debug # Debug Exporter
96-
- file/traces/standard # File Exporter for spans NOT matching rule
97-
```
98-
99-
- **Target pipeline**: This pipepline will handle all spans that match the routing rule.
100-
101-
```yaml
102-
pipelines:
103-
traces/security: # New Security Traces/Spans Pipeline
104-
receivers:
105-
- routing # Routing Connector, Only receives data from Connector
106-
processors:
107-
- memory_limiter # Memory Limiter Processor
108-
- resource/add_mode # Adds collector mode metadata
109-
exporters:
110-
- debug # Debug Exporter
111-
- file/traces/security # File Exporter for spans matching rule
112-
```
113-
114-
- **Update the `traces` pipeline to handle routing**: To enable `routing`, update the original `traces:` pipeline by adding `routing` as an exporter. This ensures that all span data is sent through the routing connector for evaluation.
115-
116-
For clarity, we are removing the `debug` exporter from this pipeline, so that debug output is only shown from the new exporters behind the routing connector.
117-
118-
```yaml
119-
pipelines:
120-
traces: # Original traces pipeline
121-
receivers:
122-
- otlp # Debug Exporter
123-
exporters:
124-
- routing # Routing Connector, Only exports data to Connector
125-
```
126-
127-
{{% notice title="Tip" style="primary" icon="lightbulb" %}}
128-
129-
Keep in mind that any existing processors have been removed from this pipeline. They are now handled by either the standard pipeline or the target pipelines, depending on the routing rules.
130-
131-
Additionally, the `batch` processor has been removed from the new pipelines. This ensures that `spans` are written immediately, rather than waiting for multiple spans to arrive before processing. This change speeds up the workshop and allows you to see results faster.
132-
{{% /notice %}}
133-
134-
{{% /notice %}}
135-
136-
Again, validate the **Gateway** configuration using `otelbin.io` for spelling mistakes etc. Your `Traces:` pipeline should like this:
137-
138-
```mermaid
139-
%%{init:{"fontFamily":"monospace"}}%%
140-
graph LR
141-
%% Nodes
142-
REC1(&nbsp;&nbsp;&nbsp;otlp&nbsp;&nbsp;&nbsp;<br>fa:fa-download):::receiver
143-
PRO1(memory_limiter<br>fa:fa-microchip):::processor
144-
PRO2(memory_limiter<br>fa:fa-microchip):::processor
145-
PRO3(resource<br>fa:fa-microchip):::processor
146-
PRO4(resource<br>fa:fa-microchip):::processor
147-
EXP1(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload):::exporter
148-
EXP2(&emsp;&emsp;file&emsp;&emsp;<br>fa:fa-upload):::exporter
149-
EXP3(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload):::exporter
150-
EXP4(&emsp;&emsp;file&emsp;&emsp;<br>fa:fa-upload):::exporter
151-
ROUTE1(&nbsp;routing&nbsp;<br>fa:fa-route):::con-export
152-
ROUTE2(&nbsp;routing&nbsp;<br>fa:fa-route):::con-receive
153-
ROUTE3(&nbsp;routing&nbsp;<br>fa:fa-route):::con-receive
154-
%% Links
155-
subID1:::sub-traces
156-
subID2:::sub-traces
157-
subID3:::sub-traces
158-
subgraph " "
159-
direction LR
160-
subgraph subID1[**Traces**]
161-
REC1 --> ROUTE1
162-
end
163-
subgraph subID2[**Traces/standard**]
164-
ROUTE1 --> ROUTE2
165-
ROUTE2 --> PRO1
166-
PRO1 --> PRO3
167-
PRO3 --> EXP1
168-
PRO3 --> EXP2
169-
end
170-
subgraph subID3[**Traces/security**]
171-
ROUTE1 --> ROUTE3
172-
ROUTE3 --> PRO2
173-
PRO2 --> PRO4
174-
PRO4 --> EXP3
175-
PRO4 --> EXP4
176-
end
177-
end
178-
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
179-
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
180-
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
181-
classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
182-
```
183-
184-
<!--![Routing Connector](../images/routing-8-1.png)-->
185-
186-
Lets' test our configuration!
38+
Next, we will configure the routing connector and the respective pipelines.

0 commit comments

Comments
 (0)