vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(c0re): stop compiling out the OTLP exporter's own diagnostics

Browse source 
`default-features = false` on opentelemetry-otlp was written to trim
transports and dropped `internal-logs` with them, so every otel_warn! and
otel_debug! inside that crate compiled to nothing. The failure that
matters is the one which returns HTTP 200: the collector accepts the
request and rejects the data points, and HttpMetricsClient.PartialSuccess
is the only place the rejection count and the collector's reason are ever
surfaced.

The feature is per-crate, not per-workspace: the macros are exported by
the opentelemetry API crate but their cfg and CARGO_PKG_NAME resolve in
the calling crate, so the API crate and the SDK had internal logs on
while the exporter did not.

hive-metric keeps the identical declaration on purpose - it installs no
tracing subscriber, so the feature would be inert there and would only
mislead. Both files now record which side of that they are on, and the
stale "same features as hive-metric" comment is corrected.

Not sufficient on its own: a hard export failure is logged by the SDK at
debug on the compiled timer path, so it stays below the info filter.
That needs a level rather than a feature and is left to review.
This commit is contained in:
atlas 2026-08-14 15:16:04 +02:00 • committed by mara
commit b28af3cd1f
2 changed files with 17 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

13
hive-c0re/Cargo.toml
View file

@ -20,12 +20,19 @@ clap.workspace = true
clap_complete.workspace = true
clap-markdown = "0.1"
# OTEL SDK for the per-agent container-resource metrics exporter
# (stats/otel_metrics.rs). Same versions/features as hive-metric — the
# blocking OTLP client is deliberate: the metrics SDK's PeriodicReader runs
# on a background thread with no Tokio reactor, where the async client panics.
# (stats/otel_metrics.rs). Same versions as hive-metric, and the same blocking
# OTLP client for the same reason: the metrics SDK's PeriodicReader runs on a
# background thread with no Tokio reactor, where the async client panics.
# Features differ by one — see `internal-logs` below and hive-metric's note.
opentelemetry = "0.32"
opentelemetry_sdk = { version = "0.32", features = ["metrics"] }
opentelemetry-otlp = { version = "0.32", default-features = false, features = [
# Not a transport — this is the exporter's own diagnostics, and it is in
# `default`, so `default-features = false` drops it unless it is named here.
# Without it every `otel_warn!`/`otel_debug!` *inside this crate* compiles to
# nothing, and the one failure that returns HTTP 200 — the collector accepting
# the request and rejecting the data points — is reported nowhere at all.
"internal-logs",
"metrics",
"http-json",
"reqwest-blocking-client",

7
hive-metric/Cargo.toml
View file

@ -19,6 +19,13 @@ opentelemetry_sdk = { version = "0.32", features = ["metrics"] }
# so the async client panics there with "no reactor running". The blocking
# client sends on that thread directly — and for a fire-and-forget CLI that
# records one point then `shutdown()`s, a synchronous send is exactly right.
#
# Deliberately WITHOUT the `internal-logs` feature that `hive-c0re` names, even
# though the defect is identical: this binary installs no `tracing` subscriber,
# so the SDK's diagnostics would be emitted into a void. Enabling it here would
# read as "hive-metric reports its export failures" while changing nothing at
# all. Giving this CLI somewhere to report is a behaviour change with its own
# decision (does a metrics push print to stderr?) — tracked separately.
opentelemetry-otlp = { version = "0.32", default-features = false, features = [
"metrics",
"http-json",