Skip to content
This repository has been archived by the owner on Dec 6, 2024. It is now read-only.

Stabilize messaging semantic conventions for tracing #192

Closed
wants to merge 39 commits into from
Closed

Stabilize messaging semantic conventions for tracing #192

Changes from 1 commit
Commits
Show all changes
39 commits
Select commit Hold shift + click to select a range
03d8291
Messaging semantic conventions for tracing, first draft
pyohannes Dec 1, 2021
13c975d
Change name to PR request id
pyohannes Dec 2, 2021
8f4349f
Update text/trace/0192-messaging-semantic-conventions-spec.md
pyohannes Dec 6, 2021
98cf8f3
PR comments
pyohannes Dec 6, 2021
2d8f25c
PR comments
pyohannes Dec 6, 2021
f48379f
Add first draft for consumer instrumentation span structure
pyohannes Dec 10, 2021
5e67b1f
Fix spelling
pyohannes Dec 10, 2021
7b2dbe9
PR comments
pyohannes Dec 15, 2021
f23c5ac
Rename the "Receive" span to "Deliver"
pyohannes Dec 16, 2021
51501ce
Push and pull based consumer scenarios
pyohannes Feb 3, 2022
20f272c
Remove obsolete text
pyohannes Feb 3, 2022
1e14ff0
Clarify context propagation
pyohannes Feb 3, 2022
b87adf6
Fix markdownlint errors
pyohannes Feb 3, 2022
20887d2
Add links
pyohannes Feb 3, 2022
2ae923d
PR comments
pyohannes Feb 4, 2022
0e8f824
Producer scenarios
pyohannes Mar 16, 2022
161392e
Remove trailing whitespace
pyohannes Mar 16, 2022
f40ff57
Fix wording
pyohannes Mar 16, 2022
523c435
Add examples
pyohannes Mar 16, 2022
4d341f6
Fix examples
pyohannes Mar 16, 2022
4615994
Add draft for settlement instrumentation
pyohannes Apr 5, 2022
71e5ab8
Complete settlement section
pyohannes Apr 7, 2022
b316b1a
Add details about span kinds and names
pyohannes Apr 22, 2022
bcd328e
Fix markdown lint error
pyohannes Apr 22, 2022
0e4a777
Update text/trace/0192-messaging-semantic-conventions-spec.md
pyohannes May 4, 2022
d91ac98
Update text/trace/0192-messaging-semantic-conventions-spec.md
pyohannes May 4, 2022
40c1d13
Add first attributes
pyohannes May 4, 2022
e2738c6
Avoid using the term "client"
pyohannes May 4, 2022
9055167
Add TOC
pyohannes May 4, 2022
8e663f0
Add more attributes
pyohannes May 16, 2022
7c1d84c
Add network transport attributes
pyohannes Jun 15, 2022
38dc813
Update text/trace/0192-messaging-semantic-conventions-spec.md
pyohannes Jul 1, 2022
92a1dd5
Update text/trace/0192-messaging-semantic-conventions-spec.md
pyohannes Jul 12, 2022
8dc5b9f
Apply suggestions from code review
pyohannes Jul 12, 2022
72e1215
PR comments
pyohannes Jul 12, 2022
e4ccef0
Merge branch 'main' into conventions-messaging
joaopgrassi Aug 2, 2022
5fa715d
PR suggestions and grammar fixes
joaopgrassi Aug 2, 2022
8b4461a
Make messaging.system attribute level required
joaopgrassi Aug 2, 2022
964d65e
Set requirement level for destination.temporary and anonymous
joaopgrassi Aug 5, 2022
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
Prev Previous commit
Next Next commit
Fix examples
  • Loading branch information
@pyohannes
pyohannes committed Apr 7, 2022
commit 4d341f685fa6cda512b224243e15e125dbaf8dbb
54 changes: 33 additions & 21 deletions text/trace/0192-messaging-semantic-conventions-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -238,58 +238,68 @@ spans can link to zero, one, or multiple "Create" spans.
#### Single message producer, single message push-based consumer

```
+------------+ +------------+
| Publish m1 |.............................| Deliver m1 |
PRODUCER CONSUMER

+------------+ (link) +------------+
| Publish m1 | . . . . . . . . . . . . . . | Deliver m1 |
+------------+ +------------+
```

#### Batch message producer with "Create" spans, single message pull-based consumer

```
PRODUCER CONSUMER

+-------------------------+ +------------+
| Publish | ............| Receive m1 |
| Publish | . . . . . . | Receive m1 |
+-+-----------+-----------+ . +------------+
| Create m1 |......................
| Create m1 | . . . . . . . . . . .
+-----------+-----------+ +------------+
| Create m2 |.....................| Receive m2 |
| Create m2 | . . . . . . . . . . | Receive m2 |
+-----------+ +------------+
```

#### Batch message producer, single message push-based consumer

```
PRODUCER CONSUMER

+---------+ +------------+
| Publish |.............................| Deliver m1 |
| Publish | . . . . . . . . . . . . . . | Deliver m1 |
+---------+ +------------+
. +------------+
..................................| Deliver m2 |
. . . . . . . . . . . . . . . . . | Deliver m2 |
+------------+
```

#### Batch message producer with independent "Create" spans, single message pull-based consumer

```
PRODUCER CONSUMER

+-----------------------------------+
| Ambient |
+-+-----------+---------------------+ +------------+
| Create m1 |...............................| Receive m1 |
| Create m1 | . . . . . . . . . . . . . . . | Receive m1 |
+-----------+-----------+ +------------+
| Create m2 |................
| Create m2 | . . . . . . . .
+-----------+---------+ . +------------+
| Publish | ....| Receive m2 |
| Publish | . . | Receive m2 |
+---------+ +------------+
pyohannes marked this conversation as resolved.
Show resolved Hide resolved
Copy link

Choose a reason for hiding this comment

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

We don't seem to be consistent within pull-based consumer scenarios in what the parent context should be for a receive span. I believe the intent is that the parent should be the application's ambient span?

Although intermediary instrumentation is out of scope, it's something I'm thinking about and there is a decision to make as to how the transport context of the message fits into these traces. If you care about the path the message takes, it's nice to have the receive span as a child of the message's context. But since it is the application's "pull" that caused the span, it's probably more correct for the receive span to be a child of the application's ambient span.

If we agree this is the right approach, it probably makes the most sense for the receive span to link to the message's transport context (although no need to mention here as that would be out of scope). If there is no ambient context, it seems as though it would be nicer to be a child rather than create a brand new trace with no parent at all. On the one hand, this means we have inconsistent structure. On the other hand, does splitting the traces up help with anything?

```

#### Single message producers, batch push-based consumer with process spans

```
PRODUCER CONSUMER

+------------+
| Publish m1 |.............................
+------------+ .
| Publish m1 | . . . . . . . . . . . . . .
+------------+ .
+---------------------------+
...| Deliver |
+------------+ . +-+------------+------------+
| Publish m2 |................. | Process m1 |
. . | Deliver |
+------------+ . +-+------------+------------+
| Publish m2 | . . . . . . . . | Process m1 |
+------------+ +------------+------------+
| Process m2 |
+------------+
Expand All @@ -298,13 +308,15 @@ spans can link to zero, one, or multiple "Create" spans.
#### Single message producers, batch pull-based consumer with process spans

```
PRODUCER CONSUMER

+------------+
| Publish m1 |........ +-------------------------------------+
+------------+ . | Ambient |
. +-+---------+-------------------------+
.........| Receive |
+------------+ . +---------+------------+
| Publish m2 |............ | Process m1 |
| Publish m1 |. . . . +-------------------------------------+
+------------+ . | Ambient |
. +-+---------+-------------------------+
. . . . . | Receive |
+------------+ . +---------+------------+
| Publish m2 |. . . . . . | Process m1 |
+------------+ +------------+------------+
| Process m2 |
+------------+
Expand Down