Skip to content

Add Minimal Set of Channel Trace Events #89

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jul 10, 2018
Merged

Add Minimal Set of Channel Trace Events #89

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
b5c2a68
Add minimal set clause for channel tracing
ncteisen Jun 29, 2018
300310f
Reviewer comments
ncteisen Jul 2, 2018
f83665a
Update updated date
ncteisen Jul 2, 2018
615a92f
reviewer feedback
ncteisen Jul 10, 2018
eb24040
reviewer
ncteisen Jul 10, 2018
f537adc
reviewer
ncteisen Jul 10, 2018
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
20 changes: 19 additions & 1 deletion A3-channel-tracing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ Channel Tracing
* Approver: markdroth
* Status: Draft
* Implemented in: N/A
* Last updated: 2018-03-01
* Last updated: 2018-07-01
* Discussion at: https://groups.google.com/forum/#!topic/grpc-io/WFDj3KeHYTI

## Terminology
Expand Down Expand Up @@ -43,6 +43,24 @@ _Trace events_ should only be added for events that happen relatively infrequent
... Entering idle mode
```

## Minimal Set of Data

We define a minimal set of events that must be traced, in order to consider the channel tracing feature as complete.

All of these events must be traced:
- Channel creation and deletion
- Subchannel creation and deletion
- Channel connectivity state changes
- Subchannel connectivity state changes
- Interesting address resolution events (see below for details)

Address resolution is special case. We want to track resolution events, but we do not want to flood the trace buffer with them. This will occur in environments with push based resolvers and dynamically scheduled backends (as is the case internally at Google). So we define several types of "interesting" resolution events that must be traced:
- Address resolution resulting in service config change
- Address resolution that causes number of backends to go from zero to non-zero
- Address resolution that causes number of backends to go from non-zero to zero
- Address resolution that causes a new LB policy to be created

Language specific implementations may add any additional trace that is deemed useful, as long as the trace is not expected to happen at a per-RPC frequency.

## Format of Exported Data

Expand Down