[jira] [Commented] (HBASE-27536) Include more request information in slowlog

["Ray Mattingly (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-27536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649476#comment-17649476 ] 

Ray Mattingly commented on HBASE-27536:
---------------------------------------

{quote}I believe we should use {{Operation's toMap(int maxCols)}} method
{quote}
This seems doable. [~bbeaudreault] do you have any thoughts re: what a reasonable default {{maxCols}} might be? Should this value be configurable, or should we be hesitant to add another new conf option for something like this? I've looked through some implementations of toMap and my initial impression is that it wouldn't be too dangerous to have a relatively high default (like, in the hundreds?). But wanted to get your thoughts here too.

> Include more request information in slowlog
> -------------------------------------------
>
>                 Key: HBASE-27536
>                 URL: https://issues.apache.org/jira/browse/HBASE-27536
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Bryan Beaudreault
>            Priority: Major
>              Labels: slowlog
>
> 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.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)