Performance and Observability

Reaktor links runtime health and performance evidence to graph ownership, exact artifacts and runtime instances. Monitoring, profiling and benchmarking are distinct disciplines: metrics reveal a symptom, profiles explain resource use, and controlled workloads establish comparable performance.

This overview belongs to Operations & Reliability. Detailed contracts now live on focused pages; existing product analytics and Reaktor service evidence continue to use ClickHouse.

Source-grounded starting state

Reviewed 1 October 2026 against the current working tree and the 13–14 September infrastructure receipts. This is not a fresh remote health check.

The earlier claim that every OTel host is noop, that no completed port spans export, or that mobile probes are universally absent is obsolete. Infrastructure ingestion also does not prove all application wiring. Implementation references distinguish source and dated deployment evidence.

Operating paths

Evidence and budgets

Retain the full original profile/capture plus a small normalized ReaktorPerformanceReport. A Perfetto-compatible trace is useful where supported; a JFR or Instruments artifact requires explicit conversion and coverage, not an extension change. Profiles are attachment facts with target, time, workload, tool/settings, symbols and perturbation.

The implemented required-measurement manifest distinguishes passed, exceeded, no collector and measurement failed. Release requirements name target/revision, metric, unit and collector. Gates must call the manifest path; a legacy budget checker that skips an absent metric cannot establish a pass.

Keep warmup, cold and steady-state intervals separate. Record repetitions and uncertainty, real dependency/capacity equivalence and generator health. An enum entry, script filename or declared collector is not qualification. The September five-platform harness claims were corrected after script failures; each current target still needs a real capture receipt before a broad parity claim.

Graph, privacy and lifecycle

Metrics need quantitative cardinality limits; stable node/snapshot IDs are not automatically bounded labels. Payload values are off by default, client ingestion is authenticated and server-side secrets stay on the server. Heap/profile/replay artifacts have narrower access and explicit deletion/retention policy.

Instrumentation has scope, bounded duration, cancellation and owned teardown. A graph-selected capture reports dropped/unknown boundaries and excludes its own export path. Instance disposal is a verification concern: repeated attach/detach, reconnect and live update must release listeners, jobs, timers, native handles and buffers.

Supporting documents

Analytics + Telemetry owns event catalogs and runtime conventions; DevTools owns live-device inspection; Tooling owns probes and acquisition; Connected panes owns structural navigation. The pre-rewrite design and reviews remain in Performance design history.

Earlier section links

Earlier section anchors remain available here. Their dated source text is in the archive; the reading map above points to the current topic pages.

• Earlier summary section.
• Earlier current section.
• Earlier lighthouse section.
• Earlier principles section.
• Earlier model section.
• Earlier architecture section.
• Earlier android section.
• Earlier ios section.
• Earlier web section.
• Earlier desktop section.
• Earlier client-drivers section.
• Earlier jvm-server section.
• Earlier workers section.
• Earlier server-drivers section.
• Earlier postgres section.
• Earlier memgraph section.
• Earlier sqlite section.
• Earlier telemetry-pipeline section.
• Earlier prod-slos section.
• Earlier blueprint section.
• Earlier ai section.
• Earlier bestbuds section.
• Earlier plan section.
• Earlier risks section.