[ 
https://issues.apache.org/jira/browse/HBASE-27536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viraj Jasani resolved HBASE-27536.
----------------------------------
    Fix Version/s: 2.6.0
                   3.0.0-alpha-4
     Hadoop Flags: Reviewed
       Resolution: Fixed

> Include more request information in slowlog for Scans
> -----------------------------------------------------
>
>                 Key: HBASE-27536
>                 URL: https://issues.apache.org/jira/browse/HBASE-27536
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Bryan Beaudreault
>            Assignee: Ray Mattingly
>            Priority: Major
>              Labels: slowlog
>             Fix For: 2.6.0, 3.0.0-alpha-4
>
>
> 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



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

Reply via email to