xref: /aosp_15_r20/external/grpc-grpc/doc/binary-logging.md (revision cc02d7e222339f7a4f6ba5f422e6413f4bd931f2)
1*cc02d7e2SAndroid Build Coastguard Worker# Binary Logging
2*cc02d7e2SAndroid Build Coastguard Worker
3*cc02d7e2SAndroid Build Coastguard Worker## Format
4*cc02d7e2SAndroid Build Coastguard Worker
5*cc02d7e2SAndroid Build Coastguard WorkerThe log format is described in [this proto file](https://github.com/grpc/grpc-proto/blob/master/grpc/binlog/v1/binarylog.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.
6*cc02d7e2SAndroid Build Coastguard Worker
7*cc02d7e2SAndroid Build Coastguard Worker## API
8*cc02d7e2SAndroid Build Coastguard Worker
9*cc02d7e2SAndroid Build Coastguard WorkerThe 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 library will provide the ability to log sending or receiving, as relevant, the following on both the client and the server:
10*cc02d7e2SAndroid Build Coastguard Worker
11*cc02d7e2SAndroid Build Coastguard Worker - Initial metadata
12*cc02d7e2SAndroid Build Coastguard Worker - Messages
13*cc02d7e2SAndroid Build Coastguard Worker - Status with trailing metadata from the server
14*cc02d7e2SAndroid Build Coastguard Worker - Additional key/value pairs that are associated with a call but not sent over the wire
15*cc02d7e2SAndroid Build Coastguard Worker
16*cc02d7e2SAndroid Build Coastguard WorkerThe following is an example of what such an API could look like in C++:
17*cc02d7e2SAndroid Build Coastguard Worker
18*cc02d7e2SAndroid Build Coastguard Worker```c++
19*cc02d7e2SAndroid Build Coastguard Worker// The context provides the method_name, deadline, peer, and metadata contents.
20*cc02d7e2SAndroid Build Coastguard Worker// direction = CLIENT_SEND
21*cc02d7e2SAndroid Build Coastguard WorkerLogRequestHeaders(ClientContext context);
22*cc02d7e2SAndroid Build Coastguard Worker// direction = SERVER_RECV
23*cc02d7e2SAndroid Build Coastguard WorkerLogRequestHeaders(ServerContext context);
24*cc02d7e2SAndroid Build Coastguard Worker
25*cc02d7e2SAndroid Build Coastguard Worker// The context provides the metadata contents
26*cc02d7e2SAndroid Build Coastguard Worker// direction = CLIENT_RECV
27*cc02d7e2SAndroid Build Coastguard WorkerLogResponseHeaders(ClientContext context);
28*cc02d7e2SAndroid Build Coastguard Worker// direction = SERVER_SEND
29*cc02d7e2SAndroid Build Coastguard WorkerLogResponseHeaders(ServerContext context);
30*cc02d7e2SAndroid Build Coastguard Worker
31*cc02d7e2SAndroid Build Coastguard Worker// The context provides the metadata contents
32*cc02d7e2SAndroid Build Coastguard Worker// direction = CLIENT_RECV
33*cc02d7e2SAndroid Build Coastguard WorkerLogStatus(ClientContext context, grpc_status_code code, string details);
34*cc02d7e2SAndroid Build Coastguard Worker// direction = SERVER_SEND
35*cc02d7e2SAndroid Build Coastguard WorkerLogStatus(ServerContext context, grpc_status_code code, string details);
36*cc02d7e2SAndroid Build Coastguard Worker
37*cc02d7e2SAndroid Build Coastguard Worker// The context provides the user data contents
38*cc02d7e2SAndroid Build Coastguard Worker// direction = CLIENT_SEND
39*cc02d7e2SAndroid Build Coastguard WorkerLogUserData(ClientContext context);
40*cc02d7e2SAndroid Build Coastguard Worker// direction = SERVER_SEND
41*cc02d7e2SAndroid Build Coastguard WorkerLogUserData(ServerContext context);
42*cc02d7e2SAndroid Build Coastguard Worker
43*cc02d7e2SAndroid Build Coastguard Worker// direction = CLIENT_SEND
44*cc02d7e2SAndroid Build Coastguard WorkerLogRequestMessage(ClientContext context, uint32_t length, T message);
45*cc02d7e2SAndroid Build Coastguard Worker// direction = SERVER_RECV
46*cc02d7e2SAndroid Build Coastguard WorkerLogRequestMessage(ServerContext context, uint32_t length, T message);
47*cc02d7e2SAndroid Build Coastguard Worker// direction = CLIENT_RECV
48*cc02d7e2SAndroid Build Coastguard WorkerLogResponseMessage(ClientContext context, uint32_t length, T message);
49*cc02d7e2SAndroid Build Coastguard Worker// direction = SERVER_SEND
50*cc02d7e2SAndroid Build Coastguard WorkerLogResponseMessage(ServerContext context, uint32_t length, T message);
51*cc02d7e2SAndroid Build Coastguard Worker```
52*cc02d7e2SAndroid Build Coastguard Worker
53*cc02d7e2SAndroid Build Coastguard WorkerIn 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.
54*cc02d7e2SAndroid Build Coastguard Worker
55*cc02d7e2SAndroid Build Coastguard WorkerFor 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.
56*cc02d7e2SAndroid Build Coastguard Worker
57*cc02d7e2SAndroid Build Coastguard Worker## Language differences
58*cc02d7e2SAndroid Build Coastguard Worker
59*cc02d7e2SAndroid Build Coastguard WorkerIn 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.
60