Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
Reviewed
Description
Currently the slowlog only includes a barebones text format of the underlying protobuf Message fields. This is not a great UX for 2 reasons:
- Most of the proto fields dont mirror the actual API names in our requests (Scan, Get, etc).
- The chosen data is often not enough to actually infer anything about the request
Any of the API class's toString method would be a much better representation of the request. On the server side, we already have to turn the protobuf Message into an actual API class in order to serve the request in RSRpcServices. Given slow logs should be a very small percent of total requests, I think we should do a similar parsing in SlowLogQueueService. Or better yet, perhaps we can pass the already parsed request into the queue at the start to avoid the extra work.
When hydrating a SlowLogPayload with this request information, I believe we should use Operation's toMap(int maxCols) method. Adding this onto the SlowLogPayload as a map (or list of key/values) will make it easier to consume via downstream automation. Alternatively we could use toJSON().
We should also include any attributes from the queries, as those made aid tracing at the client level.
Edit: because of nuance related to handling multis and the adequacy of info available for gets/puts, we're scoping this issue down to focus on improving the information available on Scan slowlogs