HoundOSfaustob/java-o11y-test
A real HoundOS analysis of an open-source Java microservices demo — services detected, SLOs recommended and agreed, instrumentation PRs opened. Static snapshot; sign in to run this on your repos.
Detected entities
| Entity | Path | Runtime | Archetype | SLOs |
|---|---|---|---|---|
| Base-domain | base-domain | java | library | 7 agreed |
| Compensating rollback on partial failure | order-service | java | business-flow | 5 agreed |
| Dependencies | . | java | dependency-group | draft |
| Distributed order confirmation (SAGA) | order-service | java | business-flow | 5 agreed |
| Order-service | order-service | java | stream-processor | 5 agreed |
| Payment-service | payment-service | java | stream-processor | 7 agreed |
| Stock-service | stock-service | java | stream-processor | 7 agreed |
Latest report · commit a5981db · Claude
What this repository does
This is a demonstration order-processing domain in which a customer order is only confirmed once both payment and inventory can honour it. Orders are submitted through the order service, which coordinates a distributed transaction: the payment side reserves funds against the customer's account balance and the stock side reserves the requested product quantities, and the order is confirmed only if both sides accept — otherwise it is rolled back or rejected. The value delivered is consistent, eventually-correct order outcomes across independently-owned payment and inventory data without a shared database or two-phase commit. Its users are developers/architects learning the SAGA pattern (it backs a pair of published articles) rather than end consumers, so it is a reference implementation of an e-commerce checkout backbone.
HoundOS analyzed this repo and detected business purpose, end-to-end flows, services, dependencies and more. Based on this analysis, HoundOS identified observability gaps against industry best practices.
We address these observability gaps through a two-pronged approach:
- Auto-instrumentation recommendations: Leveraging OpenTelemetry packages that provide out-of-the-box coverage.
- Custom instrumentation recommendations: For the remaining gaps, specific implementation guidance.
Note: Not all the identified gaps need to be addressed. Application owners can choose what to prioritize. HoundOS can automate the process of generating and applying the recommended changes by opening pull requests for configurations and code, and continuously manage the repo so instrumentation stays aligned with the agreed SLOs as code and config change.
Signalswhat this repo emits or should emit, grouped by the entity that owns it
Trace-context propagation: payment-service-order → service
Propagate W3C trace context across the Payment-service → Order-service messaging boundary: inject traceparent into message headers at the producer; extract it and start the consumer span with that parent, so one trace spans the whole "Compensating rollback on partial failure" flow.
Trace-context propagation: stock-service-order → service
Propagate W3C trace context across the Stock-service → Order-service messaging boundary: inject traceparent into message headers at the producer; extract it and start the consumer span with that parent, so one trace spans the whole "Compensating rollback on partial failure" flow.
Trace-context propagation: payment-service-order → service
Propagate W3C trace context across the Payment-service → Order-service messaging boundary: inject traceparent into message headers at the producer; extract it and start the consumer span with that parent, so one trace spans the whole "Distributed order confirmation (SAGA)" flow.
Trace-context propagation: stock-service-order → service
Propagate W3C trace context across the Stock-service → Order-service messaging boundary: inject traceparent into message headers at the producer; extract it and start the consumer span with that parent, so one trace spans the whole "Distributed order confirmation (SAGA)" flow.
Server request spans (auto-instrumentation)
Server request spans for Order-service (auto-instrumentation once the SDK bootstrap is wired).
backs 6 SLOs
This signal is the measurement source those SLOs read from — their SLIs are computed off the spans it emits.
- order-service-http-availability
- order-service-http-latency-p95
- order-service-http-latency-p99
- order-service-http-error-rate
- order-service-http-auth-failure-rate
- order-service-http-request-rate
Server request spans (auto-instrumentation)
Server request spans for Payment-service (auto-instrumentation once the SDK bootstrap is wired).
Server request spans (auto-instrumentation)
Server request spans for Stock-service (auto-instrumentation once the SDK bootstrap is wired).
Base-domainagreedv1
- Base-domain — Upstream Availability99.9% / 30-day
- Base-domain — Upstream Error Rate< 1% / 30-day
- Base-domain — Payment Webhook Processing Success Rate99.9% / 30-day
- Base-domain — DB Error Rate< 0.5% / 1-hour
- Base-domain — Broker Publish Success Rate99.95% / 30-day
- Base-domain — LLM Completion Success Rate99% / 30-day
- Base-domain — Auth Provider Success Rate99.9% / 30-day
Compensating rollback on partial failuredraftv1
- Compensating rollback on partial failure — E2E Business Flow Success Rate99.95% / 30-day
- Compensating rollback on partial failure — E2E Business Flow Latency P95< 500ms / 24-hour
- Compensating rollback on partial failure — Flow Validation Failure Rate< 5% / 24-hour
- Compensating rollback on partial failure — E2E Business Flow Throughputbaseline ± 25% / 1-hour
- Compensating rollback on partial failure — Flow Completion Freshness< 2 minutes / 1-hour
Trace-context propagation: payment-service-order → service
Propagate W3C trace context across the Payment-service → Order-service messaging boundary: inject traceparent into message headers at the producer; extract it and start the consumer span with that parent, so one trace spans the whole "Compensating rollback on partial failure" flow.
Trace-context propagation: stock-service-order → service
Propagate W3C trace context across the Stock-service → Order-service messaging boundary: inject traceparent into message headers at the producer; extract it and start the consumer span with that parent, so one trace spans the whole "Compensating rollback on partial failure" flow.
Dependenciesdraftv2
- Apache Kafka / Kafka Streams — Broker Publish Success Rate99.95% / 30-day
- Apache Kafka / Kafka Streams — Upstream Latency (p95)< 500ms / 30-day
- H2 Database — DB Query Latency (p95)< 100ms / 1-hour
- H2 Database — DB Error Rate< 0.5% / 1-hour
- SonarCloud — Upstream Availability99.9% / 30-day
Distributed order confirmation (SAGA)draftv1
- Distributed order confirmation (SAGA) — E2E Business Flow Success Rate99.95% / 30-day
- Distributed order confirmation (SAGA) — E2E Business Flow Latency P95< 500ms / 24-hour
- Distributed order confirmation (SAGA) — Flow Validation Failure Rate< 5% / 24-hour
- Distributed order confirmation (SAGA) — E2E Business Flow Throughputbaseline ± 25% / 1-hour
- Distributed order confirmation (SAGA) — Flow Completion Freshness< 2 minutes / 1-hour
Trace-context propagation: payment-service-order → service
Propagate W3C trace context across the Payment-service → Order-service messaging boundary: inject traceparent into message headers at the producer; extract it and start the consumer span with that parent, so one trace spans the whole "Distributed order confirmation (SAGA)" flow.
Trace-context propagation: stock-service-order → service
Propagate W3C trace context across the Stock-service → Order-service messaging boundary: inject traceparent into message headers at the producer; extract it and start the consumer span with that parent, so one trace spans the whole "Distributed order confirmation (SAGA)" flow.
Order-serviceagreedv1
- Order-service — Message Produce Success Rate99.9% / 1-hour
- Order-service — Message Consume Success Rate99.9% / 1-hour
- Order-service — Message Loss Rate0% / 24-hour
- Order-service — Dead-Letter Queue Rate< 0.5% / 1-hour
- Order-service — Consumer Group Rebalance Frequency< 1 per hour / 24-hour
- Order-service — HTTP Service Availability99.95% / 30-day
- Order-service — HTTP 5xx Error Rate< 0.1% / 1-hour
- Order-service — Authentication Failure Rate< 2% / 1-hour
Server request spans (auto-instrumentation)
Server request spans for Order-service (auto-instrumentation once the SDK bootstrap is wired).
backs 6 SLOs
This signal is the measurement source those SLOs read from — their SLIs are computed off the spans it emits.
- order-service-http-availability
- order-service-http-latency-p95
- order-service-http-latency-p99
- order-service-http-error-rate
- order-service-http-auth-failure-rate
- order-service-http-request-rate
Payment-servicedraftv2
- Payment-service — Message Produce Success Rate99.9% / 1-hour
- Payment-service — Message Consume Success Rate99.9% / 1-hour
- Payment-service — Consumer Lag< 1000 messages / 5-minute
- Payment-service — Message Processing Latency P95< 1s / 1-hour
- Payment-service — Message Loss Rate0% / 24-hour
- Payment-service — Dead-Letter Queue Rate< 0.5% / 1-hour
- Payment-service — Consumer Group Rebalance Frequency< 1 per hour / 24-hour
- Payment-service — Database Query Success Rate99.9% / 1-hour
- Payment-service — Database Query Latency P95< 200ms / 1-hour
- Payment-service — Connection Pool Saturation< 80% / 5-minute
- Payment-service — Read Replica Lag< 5s / 5-minute
- Payment-service — Transaction Error Rate< 0.5% / 1-hour
- Payment-service — Slow Query Rate< 1% / 1-hour
Server request spans (auto-instrumentation)
Server request spans for Payment-service (auto-instrumentation once the SDK bootstrap is wired).
Stock-servicedraftv1
- Stock-service — Message Produce Success Rate99.9% / 1-hour
- Stock-service — Message Consume Success Rate99.9% / 1-hour
- Stock-service — Consumer Lag< 200 messages / 1-hour
- Stock-service — Message Processing Latency P95< 500ms / 1-hour
- Stock-service — Message Loss Rate0% / 24-hour
- Stock-service — Dead-Letter Queue Rate< 0.5% / 6-hour
- Stock-service — Consumer Group Rebalance Frequency< 1 per hour / 24-hour
- Stock-service — Database Query Success Rate99.9% / 1-hour
- Stock-service — Database Query Latency P95< 100ms / 1-hour
- Stock-service — Read Replica Lag< 5s / 5-minute
- Stock-service — Transaction Error Rate< 0.5% / 6-hour
- Stock-service — Slow Query Rate< 1% / 6-hour
Server request spans (auto-instrumentation)
Server request spans for Stock-service (auto-instrumentation once the SDK bootstrap is wired).
Instrumentation pull requests
- C152.6 validation — selection fill (Order-service)staged
- C151 recheck — Order-service with the corrected binding-order check#49open
- Add OpenTelemetry instrumentation for 5 SLIs — Order-servicesuperseded
- C150 stepped-loop live check — Order-servicesuperseded
- Add OpenTelemetry instrumentation for 5 SLIs — Order-servicefailed
- Add OpenTelemetry instrumentation for 5 SLIs — Order-servicefailed
- Add OpenTelemetry instrumentation for 5 SLIs — Order-servicefailed
- Add OpenTelemetry instrumentation for 5 SLIs — Order-servicesuperseded
- Add OpenTelemetry instrumentation for 5 SLIs — Order-servicesuperseded
- Add OpenTelemetry instrumentation for 5 SLIs — Order-servicesuperseded
- Add OpenTelemetry instrumentation for 5 SLIs — Order-servicesuperseded
- Add OpenTelemetry instrumentation for 5 SLIs — Order-servicesuperseded