ARCHIVE/rippled
1
0
Fork 0
mirror of https://github.com/XRPLF/rippled.git synced 2026-09-28 07:48:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(telemetry): Warn on server=otel with telemetry off, and widen the TLS guard

Browse Source 
Three fixes in the telemetry wiring this branch owns.

An OTel collector records through the global meter provider, which only the
telemetry module installs. With [telemetry] enabled=0 the collector attached to
the SDK's noop provider, dropped every metric, and still logged that it had
started. makeCollectorManager now takes whether telemetry is on and warns; what
gets built is unchanged. telemetry_ is constructed before collectorManager_, so
the value is available.

The default metrics endpoint was spelled three times. Name it once as
kDefaultMetricsEndpoint, beside the export-cadence defaults that already live in
Telemetry.h for the same reason, and read it from the Setup member, the config
parser's default and the collector.

The scheme guard ran only when tls_client_cert was set, so use_tls=1 on an http
endpoint validated the certificate files and then exported in the clear. It now
covers every use_tls=1 node, for both signals. Two cases that pinned the old
behaviour are flipped to _throws, each asserting which endpoint key the message
names, and three more get https endpoints so the scheme guard is not what fires.
This commit is contained in:
Pratik Mankawde
2026-09-23 14:29:24 +01:00
parent 360cde04ef
commit 5ce7e4e855
6 changed files with 93 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
src/libxrpl/telemetry/TelemetryConfig.cpp
View File

@@ -72,7 +72,7 @@ constexpr char const* consensusTraceStrategy = "consensus_trace_strategy";
namespace dflt {
constexpr char const* serviceName = "xrpld";
constexpr char const* tracesEndpoint = "http://localhost:4318/v1/traces";
constexpr char const* metricsEndpoint = "http://localhost:4318/v1/metrics";
constexpr char const* metricsEndpoint = kDefaultMetricsEndpoint;
constexpr std::uint32_t batchSize = 512u;
constexpr std::uint32_t batchDelayMs = 5000u;
constexpr std::uint32_t maxQueueSize = 2048u;
@@ -250,14 +250,14 @@ requirePositive(std::chrono::milliseconds value, char const* configKey)
}
/**
* Throw unless an endpoint URL is one the client certificate can be used on.
* Throw unless an endpoint URL is one TLS can actually be used on.
*
* The OTLP/HTTP exporter turns TLS on from the URL scheme alone, and matches
* "https:" exactly and case-sensitively. So a client certificate only reaches
* the collector on an https endpoint, and this check is what holds that
* invariant: with a client certificate configured, the endpoint is an https URL.
* "https://" is required in full, which is stricter than the exporter's own
* test, so anything this accepts the exporter also treats as TLS.
* "https:" exactly and case-sensitively. So the certificate settings only mean
* anything on an https endpoint, and this check is what holds that invariant:
* with TLS asked for, the endpoint is an https URL. "https://" is required in
* full, which is stricter than the exporter's own test, so anything this
* accepts the exporter also treats as TLS.
*
* @param endpoint Endpoint URL from the config, or the built-in default.
* @param configKey Config key the URL came from, named in the message.
@@ -273,8 +273,8 @@ requireHttpsEndpoint(std::string const& endpoint, char const* configKey)
Throw<std::runtime_error>(
std::string("Invalid value '") + configKey + "' in " + kSectionLabel +
": must start with '" + std::string{kHttpsPrefix} + "' when " + key::tlsClientCert +
" is set, but is '" + endpoint + "'.");
": must start with '" + std::string{kHttpsPrefix} + "' when " + key::useTls +
"=1, but is '" + endpoint + "'.");
}
/**
@@ -388,13 +388,12 @@ makeTelemetrySetup(
// Still inside the enabled branch, and checked before the files are
// opened so a scheme problem is not hidden behind a path problem. Each
// exporter reads TLS off its own endpoint scheme, and both are handed
// the client certificate, so both endpoints have to be https. Checking
// only one leaves the other signal exporting in the clear without this
// node's identity. tls_ca_cert is left out of this check: it only names
// a trust store, while a client certificate is this node's own identity
// and has to reach the collector to mean anything.
if (!setup.tlsClientCertPath.empty())
// exporter reads TLS off its own endpoint scheme alone, so use_tls=1 on
// an http endpoint would validate the certificate files and then still
// export in the clear. Both endpoints are checked, because checking only
// one leaves the other signal in plaintext. An operator who asks for TLS
// gets TLS on both signals, or a startup error.
if (setup.useTls)
{
requireHttpsEndpoint(setup.tracesEndpoint, key::tracesEndpoint);
requireHttpsEndpoint(setup.metricsEndpoint, key::metricsEndpoint);