metrics: attribute hashrate to build, device, kernel and job outcomes #14
Reference in New Issue
Block a user
Delete Branch "metrics/build-device-job"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Miner side of #9. Additive metrics in a lair-owned module (
crates/metrics/src/lair.rs); origin's metrics are untouched.New series
miner_build_infominer_config_infominer_device_hashes_totalminer_device_solutions_totalminer_device_lost_totalminer_gpu_batch_secondsminer_jobs_received_totalminer_stale_hashes_totalminer_job_pickup_secondsminer_results_submitted_total,miner_results_send_failed_totalminer_seal_latency_secondsminer_job_idle_seconds_totalminer_connects_total,miner_connect_failures_total,miner_disconnects_total,miner_connected,miner_disconnected_seconds_totalPer-device handles are resolved once at engine init (
DeviceMetricsonGpuContext), so the per-batch path does two histogram observes and a counter add with no label lookups.Origin-owned code touched (all marked
// lair:)engine-gpu:metricsdependency;metricsfield onGpuContext; three timestamps and four recording calls inrun_single_batch; one call in the device-lost branch.miner-service:found_atonWorkerResult,created_atonMiningJob, pickup observation inworker_loop, stale/submitted/idle/connection recording inquic.rs, config info inrun.miner-cli:set_build_infoat startup.deploy.yamlvalidate:miner_build_infomust carry the deployed commit.Validation
-D warningson all targets and features, fmt, workspace tests: clean./metricsshowsminer_build_info{commit="f1064345e5ed-dirty",version="4.0.2"} 1andminer_config_info{cpu_workers="1",engine="cpu",gpu_batch_size="1000000",...} 1from startup.Not in this PR: recording rules, the dashboard row and the nvidia throttle-reason field, which live in lair/quantus and follow once these series exist on the hosts.
🤖 Generated with Claude Code
https://claude.ai/code/session_01CBgs2nSi4H2mdh8kD8vMX5
quantus/miner#9. Additive metrics in a lair-owned module of the metrics crate; origin's metrics are untouched so the fleet dashboard keeps working across origin merges. Identity: - miner_build_info{version, commit}: the join key for everything below. - miner_config_info{engine, gpu_batch_size, gpu_devices, cpu_workers, gpu_throttle_ms}: two deploys of one commit with different flags are different experiments. Per device (handles resolved once at engine init, no label lookups in the batch path): - miner_device_hashes_total{device, kernel}, miner_device_solutions_total, miner_device_lost_total. - miner_gpu_batch_seconds{device, kernel, phase=gpu|host}: submit-to-mapped on the device versus everything else in the batch. This is the bubble #4, #5 and #6 attack, measured directly. Jobs and results: - miner_jobs_received_total, miner_stale_hashes_total{engine}, miner_job_pickup_seconds{engine} (issued to picked up; the cancel latency of a busy worker), miner_results_submitted_total, miner_results_send_failed_total, miner_seal_latency_seconds (found to sent), miner_job_idle_seconds_total (sent to next job, node-attributable). Connection: miner_connects_total, miner_connect_failures_total, miner_disconnects_total, miner_connected, miner_disconnected_seconds_total. Origin-owned code touched, each block marked lair: engine-gpu gains a metrics dependency, a DeviceMetrics handle on GpuContext and timing points in run_single_batch; miner-service gains found_at on WorkerResult, created_at on MiningJob and the recording calls; miner-cli sets build info at startup. Deploy validate now asserts miner_build_info carries the deployed commit. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CBgs2nSi4H2mdh8kD8vMX5quantus-bench
3ba996dcdfon benjy.hanzalova.internaltotal median: 143.89 MH/s (batch 1000000, 5 x 30s, engine gpu-wgpu)
--- resume miner ---
active