[
https://issues.apache.org/jira/browse/HBASE-27536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Beaudreault updated HBASE-27536:
--------------------------------------
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.
was:
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.
We should also include any attributes from the queries, as those made aid
tracing at the client level.
> 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)
