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
{{ message }}
This repository was archived by the owner on May 5, 2025. It is now read-only.
TriggerMesh provides various configuration parameters to control the delivery of events in case of failure. For instance, you can decide to retry sending events that failed to be consumed, and if this didn't work you can decide to forward those events to a dead letter sink.
5
+
A [Dead Letter Sink](https://knative.dev/docs/eventing/event-delivery/) is a Knative construct that allows the user to configure a destination for events that would otherwise be dropped due to some delivery failure. This is useful for scenarios where you want to ensure that events are not lost due to a failure in the underlying system.
6
6
7
-
## Implementing a Dead Letter Sink
8
7
9
-
There are two ways to implement a dead letter sink, either by use of a Subscription or by use of a Broker.
8
+
## Creating a Bridge with a Dead Letter Sink.
10
9
11
-
### Subscription Configuration
10
+
In this example we are going to create a [Bridge](https://docs.triggermesh.io/concepts/) that contains a [PingSource](https://knative.dev/docs/eventing/sources/ping-source/) object that will emit an event on a regular basis to a [Broker](https://knative.dev/docs/eventing/broker/), named `events`, that will then forward the event to a [Service](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#service), named `event-display`. We will also be configuring our [Broker](https://knative.dev/docs/eventing/broker/) to use a [Dead Letter Sink](https://knative.dev/docs/eventing/event-delivery/) so that in the case of a delivery error to `event-display` the event will go to another [Service](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#service) named `event-failure-capture`, instead of being lost into the void. We will then break the bridge by removing the `event-display` service, so that we can view the [Dead Letter Sink](https://knative.dev/docs/eventing/event-delivery/) in action!
12
11
13
-
You can configure how events are delivered for each Subscription by adding a delivery spec to the Subscription object, as shown in the following example:
12
+
13
+
### Step 1: Create the Broker
14
+
15
+
Create a new [Broker](https://knative.dev/docs/eventing/broker/) with following configuration:
14
16
15
17
```yaml
16
-
apiVersion: messaging.knative.dev/v1
17
-
kind: Subscription
18
+
apiVersion: eventing.knative.dev/v1
19
+
kind: Broker
18
20
metadata:
19
-
name: example-subscription
20
-
namespace: example-namespace
21
+
name: events
21
22
spec:
22
23
delivery:
23
24
deadLetterSink:
24
25
ref:
25
-
apiVersion: serving.knative.dev/v1
26
-
kind: Service
27
-
name: example-sink
28
-
backoffDelay: <duration>
29
-
backoffPolicy: <policy-type>
30
-
retry: <integer>
26
+
apiVersion: serving.knative.dev/v1
27
+
kind: Service
28
+
name: event-failure-capture
29
+
backoffDelay: "PT0.5S"# or ISO8601 duration
30
+
backoffPolicy: exponential # or linear
31
+
retry: 2
31
32
```
32
33
33
-
Where:
34
+
Here a [Broker](https://knative.dev/docs/eventing/broker/) named `events` with a [Dead Letter Sink](https://knative.dev/docs/eventing/event-delivery/) configured to send the events to a [Service](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#service) `sockeye` is configured with a `backoffDelay` of `0.5s`, a `backoffPolicy` of `exponential`, and a `retry` number of 2 (more info about those properties can be found [here](https://knative.dev/docs/eventing/event-delivery/#configuring-subscription-event-delivery).
34
35
35
-
The `deadLetterSink` spec contains configuration settings to enable using a dead letter sink. This tells the Subscription what happens to events that cannot be delivered to the subscriber. When this is configured, events that fail to be delivered are sent to the dead letter sink destination. The destination can be a Knative Service or a URI. In the example, the destination is a Service object, or Knative Service, named example-sink.
36
36
37
-
The `backoffDelay` delivery parameter specifies the time delay before an event delivery retry is attempted after a failure. The duration of the backoffDelay parameter is specified using the ISO 8601 format. For example, PT1S specifies a 1 second delay.
38
37
39
-
The `backoffPolicy` delivery parameter can be used to specify the retry back off policy. The policy can be specified as either linear or exponential. When using the linear back off policy, the back off delay is the time interval specified between retries. When using the exponential back off policy, the back off delay is equal to backoffDelay*2^<numberOfRetries>.
40
-
retry specifies the number of times that event delivery is retried before the event is sent to the dead letter sink.
38
+
### Step 2: Create the PingSource
41
39
42
-
43
-
### Broker Configuration
40
+
Create a [PingSource](https://knative.dev/docs/eventing/sources/ping-source/) object with the following configuration:
44
41
45
-
You can configure how events are delivered for each Broker by adding a delivery spec, as shown in the following example:
42
+
```yaml
43
+
apiVersion: sources.knative.dev/v1
44
+
kind: PingSource
45
+
metadata:
46
+
name: ping-sockeye
47
+
spec:
48
+
data: '{"name": "triggermesh"}'
49
+
schedule: "*/1 * * * *"
50
+
sink:
51
+
ref:
52
+
apiVersion: eventing.knative.dev/v1
53
+
kind: Broker
54
+
name: events
55
+
```
56
+
57
+
### Step 3: Create the `event-display` Service
58
+
59
+
Create a [Service](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#service) named `event-display` with the following configuration:
Create a [Trigger](https://knative.dev/docs/eventing/broker/triggers/) to route events to the `event-display` [Service](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#service) with the following configuration:
46
77
47
78
```yaml
48
79
apiVersion: eventing.knative.dev/v1
49
-
kind: Broker
80
+
kind: Trigger
50
81
metadata:
51
-
name: with-dead-letter-sink
82
+
name: failtest
52
83
spec:
53
-
delivery:
54
-
deadLetterSink:
55
-
ref:
56
-
apiVersion: serving.knative.dev/v1
57
-
kind: Service
58
-
name: example-sink
59
-
backoffDelay: <duration>
60
-
backoffPolicy: <policy-type>
61
-
retry: <integer>
84
+
broker: events
85
+
subscriber:
86
+
ref:
87
+
apiVersion: serving.knative.dev/v1
88
+
kind: Service
89
+
name: event-display
90
+
```
91
+
92
+
### Step 5: Create the `event-failure-capture` Service
93
+
94
+
Create a [Service](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#service) named `event-failure-capture` with the following configuration:
Lets take a look at an example of a Broker with a dead letter sink and configure a simple bridge with a dead letter sink. For our discussion, let us consider [this example Bridge](../assets/yamlexamples/simple-bridge.yaml) as a starting point:
110
+
Now that we have created all the necessary objects, we can review and apply the changes to the cluster. A concatenation of all the YAML objects is shown below:
67
111
68
112
```yaml
69
113
apiVersion: eventing.knative.dev/v1
70
114
kind: Broker
71
115
metadata:
72
116
name: events
117
+
spec:
118
+
delivery:
119
+
deadLetterSink:
120
+
ref:
121
+
apiVersion: serving.knative.dev/v1
122
+
kind: Service
123
+
name: event-failure-capture
124
+
backoffDelay: "PT0.5S" # or ISO8601 duration
125
+
backoffPolicy: exponential # or linear
126
+
retry: 2
127
+
73
128
---
129
+
74
130
apiVersion: sources.knative.dev/v1
75
131
kind: PingSource
76
132
metadata:
@@ -83,52 +139,137 @@ spec:
83
139
apiVersion: eventing.knative.dev/v1
84
140
kind: Broker
85
141
name: events
86
-
```
87
-
88
-
Now, lets modify this example to add a dead letter sink to the `Broker`. We can accomplish this in two steps:
89
-
90
-
1. Add a service to catch the "dead letter" events. (We will be using `Sockeye` here, but in a production scenario you would want to use something like SQS, Kafka, or another Sink that has some form of persistence.)
Now that we have all the parts in place, we can monitor the events that are being sent to the dead letter sink. We can do this in two ways:
188
+
Now with everything in place if we retrieve the current pods in the namespace of deployment, we should see our `event-display` and `event-failure-capture` services running.
View the logs of the `event-display` service, to verify that the events are being recieved from the [PingSource](https://knative.dev/docs/eventing/sources/ping-source/) object.
Here we can see that the events are being delivered and the [Bridge](https://docs.triggermesh.io/concepts/) is functioning properly.
227
+
228
+
229
+
### Step 8: Break the Bridge
230
+
231
+
Break the [Bridge](https://docs.triggermesh.io/concepts/) by removing the `event-display` [Service](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#service).
### Step 9: View the Events in the Dead Letter Sink
248
+
249
+
Now that our [Bridge](https://docs.triggermesh.io/concepts/) is broken, if we view the current pods we find that the `event-display` [Service](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#service) has been removed, and our `event-failure-capture` [Service](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#service) has spun up.
0 commit comments