hiero-ledger / hiero-ledger/hiero-enterprise-java

feat: OpenTelemetry tracing support for hiero-enterprise-java

Open
#157 1 comment 0 reactions 0 assignees View on GitHub
pending-review
Dominant language
Java
Stars
6
Forks
21
Avg merge
10h 27m
Merged PRs (30d)
37

Description

## Problem Statement
While hiero-enterprise-java currently provides robust support for metrics, there is no built-in mechanism for distributed tracing. In enterprise microservice environments, deep visibility into request flows is critical for debugging performance bottlenecks and failures.

Currently, if a Hiero transaction is slow or fails, it is difficult to determine whether the delay occurred during transaction submission, record retrieval, or the Mirror Node query without manual, repetitive instrumentation in the application layer.

## Proposed Solution
I propose integrating OpenTelemetry (OTel) to provide standardized tracing for all Hiero interactions. This would allow Hiero operations to automatically participate in existing trace spans from systems like Jaeger, Grafana Tempo, Datadog, or AWS X-Ray.

## Key Areas for Instrumentation
- MirrorNodeClient: Capture spans for REST/gRPC interactions, including latency and status codes.
- ProtocolLayerClient: Instrument the full transaction lifecycle (submission -> pre-check -> receipt/record retrieval).
- Context Propagation: Ensure trace contexts from frameworks like Spring Boot or MicroProfile are automatically propagated, linking application requests to Hiero Transaction IDs.

- Key Attributes to Capture:`hiero.account_id`, `hiero.transaction_id`, `hiero.status_code`, `hiero.entity_id` (Contract, Token, Topic, etc.) and Standard HTTP/gRPC semantic conventions.

## Benefit
This enhancement would significantly improve the "Enterprise Ready" story of the library, allowing DevOps teams to monitor Hiero operations using their existing observability stack with zero to minimal configuration.

please assign this to me and i am open for discussion.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the MirrorNodeClient and ProtocolLayerClient entry points, then map the existing metrics support and transaction lifecycle. Define how OpenTelemetry spans, context propagation, Hiero attributes, and HTTP/gRPC conventions should work before implementation. Done means tracing covers the listed interactions with minimal configuration and is validated across the relevant lifecycle paths.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend, observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.