-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update binary log proto, add document explaining it
- Loading branch information
1 parent
44de6a1
commit f8c6545
Showing
2 changed files
with
81 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
# Binary Logging | ||
|
||
## Format | ||
|
||
The log format is described in [this proto file](src/proto/grpc/binary_log/v1alpha/log.proto). It is intended that multiple parts of the call will be logged in separate files, and then correlated by analysis tools using the rpc\_id. | ||
|
||
## API | ||
|
||
The binary logger will be a separate library from gRPC, in each language that we support. The user will need to explicitly call into the library to generate logs. The following API is an example of what it will approximately look like in C++: | ||
|
||
```c++ | ||
// The context provides the method_name, deadline, peer, and metadata contents. | ||
// direction = CLIENT_SEND | ||
LogRequestHeaders(ClientContext context); | ||
// direction = SERVER_RECV | ||
LogRequestHeaders(ServerContext context); | ||
|
||
// The context provides the metadata contents | ||
// direction = CLIENT_RECV | ||
LogResponseHeaders(ClientContext context); | ||
// direction = SERVER_SEND | ||
LogResponseHeaders(ServerContext context); | ||
|
||
// The context provides the metadata contents | ||
// direction = CLIENT_RECV | ||
LogStatus(ClientContext context, grpc_status_code code, string details); | ||
// direction = SERVER_SEND | ||
LogStatus(ServerContext context, grpc_status_code code, string details); | ||
|
||
// The context provides the user data contents | ||
// direction = CLIENT_SEND | ||
LogUserData(ClientContext context); | ||
// direction = SERVER_SEND | ||
LogUserData(ServerContext context); | ||
|
||
// direction = CLIENT_SEND | ||
LogRequestMessage(ClientContext context, uint32_t length, T message); | ||
// direction = SERVER_RECV | ||
LogRequestMessage(ServerContext context, uint32_t length, T message); | ||
// direction = CLIENT_RECV | ||
LogResponseMessage(ClientContext context, uint32_t length, T message); | ||
// direction = SERVER_SEND | ||
LogResponseMessage(ServerContext context, uint32_t length, T message); | ||
``` | ||
In all of those cases, the `rpc_id` is provided by the context, and each combination of method and context argument type implies a single direction, as noted in the comments. | ||
For the message log functions, the `length` argument indicates the length of the complete message, and the `message` argument may be only part of the complete message, stripped of sensitive material and/or shortened for efficiency. | ||
## Language differences | ||
In other languages, more or less data will need to be passed explicitly as separate arguments. In some languages, for example, the metadata will be separate from the context-like object and will need to be passed as a separate argument. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters