ARCHIVE/rippled
1
0
Fork 0
mirror of https://github.com/XRPLF/rippled.git synced 2026-08-21 22:30:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'pratik/otel-phase9-metric-gap-fill' into pratik/otel-phase10-workload-validation

Browse Source
This commit is contained in:
Pratik Mankawde
2026-08-05 16:01:06 +01:00
parent fd4783319e 46ac6df81f
commit 1df24ae649
2 changed files with 4 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
OpenTelemetryPlan/09-data-collection-reference.md
View File

@@ -1384,7 +1384,7 @@ macros, not as `MetricsRegistry` members: the two rejection counters in
**Per request, not per object.** `getobject_lookup_us` times the whole fetch
loop once, and `getobject_lookups_total` adds the batch hit and miss totals in
two calls. Incrementing per object on a loop bounded by
`Tuning::kHardMaxReplyNodes` (12288) would cost measurably and add no
`tuning::kHardMaxReplyNodes` (12288) would cost measurably and add no
information the batch totals do not already carry.
**All three histograms need an explicit bucket view.** The SDK's default
@@ -1410,7 +1410,7 @@ observation in one or two buckets and make the distribution unreadable.
`addHistogramView()` exists to take caller-supplied boundaries for exactly this
case.
- **Counts** run 1 to `Tuning::kHardMaxReplyNodes` (12288). The low end is
- **Counts** run 1 to `tuning::kHardMaxReplyNodes` (12288). The low end is
fine-grained because the honest sync path asks for at most 8 objects, so the
interesting distinction is between a normal request and a large one. The upper
bounds follow the charge size bands — `kBandSmallMax` (64) and
@@ -1418,7 +1418,7 @@ case.
with each price change.
- **Charges** run 0 to roughly 99k for a full-size all-miss request. Two of the
boundaries are the resource thresholds that decide a peer's fate:
`Resource::kWarningThreshold` (5000) and `Resource::kDropThreshold` (25000),
`resource::kWarningThreshold` (5000) and `resource::kDropThreshold` (25000),
both in `include/xrpl/resource/detail/Tuning.h`. Placing bucket edges exactly
there lets a panel read off how close real charges run to a warning or a drop,
rather than interpolating across an edge.

1
src/xrpld/rpc/detail/ServerHandler.cpp
View File

@@ -1,6 +1,7 @@
#include <xrpld/rpc/ServerHandler.h>
#include <xrpld/app/main/Application.h>
#include <xrpld/core/Config.h>
#include <xrpld/overlay/Overlay.h>
#include <xrpld/rpc/RPCHandler.h>
#include <xrpld/rpc/Role.h>