[
https://issues.apache.org/jira/browse/HDDS-17586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajesh updated HDDS-17586:
--------------------------
Description:
An OM trace today is the RPC span from OzoneProtocolMessageDispatcher. It does
not show where time is spent inside OM, and a failure does not record the Ozone
status or the exception.
Close that gap for volume, bucket and key requests, including ACL checks:
* The trace shows preExecute, the Ratis apply on the state machine,
validateAndUpdateCache, the key, bucket, volume and S3 managers, and the ACL
authorizer.
* A failed request records ozone.status and the exception on the span where it
failed.
* Spans carry the fields needed to tell requests apart: volume, bucket, key,
request type, client user, OM role, bucket layout, data size, lock time,
whether the ACL check granted access, and the double-buffer batch size.
* Key read steps, EDEK handling, bucket checks and the snapshot checkpoint have
their own spans where that work is not a separate component call.
Depends on HDDS-17581. The KeyManager, fault-injection and IOMClientRequest
refactors stay as HDDS-17595, HDDS-17596, HDDS-17597 and HDDS-17598.
Out of scope: SCM (HDDS-17593), datanode (HDDS-17594), and the client and shell
trace under HDDS-13679.
was:
Improve OpenTelemetry tracing in OM so that a trace shows where the time goes
inside OM, not only the RPC span created by
\{{OzoneProtocolMessageDispatcher}}. Today there are no spans for request
validation, cache update, the Ratis apply on the state machine executor, the OM
managers or the ACL authorizer. Failed spans also don't record the exception.
The work is split into three sub-tasks:
# Create tracing proxies for OM components.
# Add span attributes for OM requests.
# Add logical spans for critical paths that the proxies don't cover.
Shared building blocks in \{{hdds-common}} (\{{TracingUtil}} span helpers,
\{{createProxy(delegate, itf, SpanKind)}}, exception recording,
\{{TestSpanCollector}}) are added as part of the first sub-task and are reused
for SCM and datanode.
> Improve OpenTelemetry tracing in OM
> ------------------------------------
>
> Key: HDDS-17586
> URL: https://issues.apache.org/jira/browse/HDDS-17586
> Project: Apache Ozone
> Issue Type: Task
> Reporter: rajesh
> Assignee: rajesh
> Priority: Major
>
> An OM trace today is the RPC span from OzoneProtocolMessageDispatcher. It
> does not show where time is spent inside OM, and a failure does not record
> the Ozone status or the exception.
> Close that gap for volume, bucket and key requests, including ACL checks:
> * The trace shows preExecute, the Ratis apply on the state machine,
> validateAndUpdateCache, the key, bucket, volume and S3 managers, and the ACL
> authorizer.
> * A failed request records ozone.status and the exception on the span where
> it failed.
> * Spans carry the fields needed to tell requests apart: volume, bucket, key,
> request type, client user, OM role, bucket layout, data size, lock time,
> whether the ACL check granted access, and the double-buffer batch size.
> * Key read steps, EDEK handling, bucket checks and the snapshot checkpoint
> have their own spans where that work is not a separate component call.
> Depends on HDDS-17581. The KeyManager, fault-injection and IOMClientRequest
> refactors stay as HDDS-17595, HDDS-17596, HDDS-17597 and HDDS-17598.
> Out of scope: SCM (HDDS-17593), datanode (HDDS-17594), and the client and
> shell trace under HDDS-13679.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
