chore(core): unify how identifiers are created for health registration and environment providers

[tobz]

Summary

This PR is a follow-up to #2029 to move over other areas of the codebase to defining component identifiers via SubsystemIdentifier for use with the health registry and in environment providers and so on.

We've focused on two main areas here:

• cleaning up how we establish our component/subsystem identifiers in our primary environment provider implementation (in bin/agent-data-plane)
• augmenting the health registry itself to switch over using SubsystemIdentifier more directly to avoid pitfalls at the API boundary between SubsystemIdentifier and &str/String

Overall, we've unified the identifiers that get generated for components in the environment provider in terms of what exists in the health registry and what exists in the resource accounting registry.

Through this PR, it's become apparent that we'll need to think about moving SubsystemIdentifier somewhere more central so other non-Saluki crates can potentially depend on it, including and up to potentially just establishing a centralized registry for identifiers themselves... in order to solve the whole issue of "how do I know I have a unique identifier?". I plan to tackle that, and the update to switch resource_accounting::ComponentRegistry over to depending on SubsystemIdentifier, in a follow-up PR.

Change Type

• Bug fix
• New feature
• Non-functional (chore, refactoring, docs)
• Performance

How did you test this PR?

Existing and new unit tests.

References

DADP-2

[pr-commenter]

Regression Detector (Agent Data Plane)

Run ID: 2c9ffbdd-41c7-4951-a9b5-631bd07895ed
Baseline: cccc3c7a · Comparison: e27cf53e · diff

Optimization Goals: ✅ No significant changes detected

Fine details of change detection per experiment (5)

Experiments configured erratic: true are tagged (ignored) and skipped when determining which experiments regressed or improved. Experiments which are detected as erratic at runtime are tagged (erratic) to flag that the run's sample dispersion was high, but their regression / improvement signal still counts.

experiment	goal	Δ mean %	links
quality_gates_rss_dsd_heavy	memory	⚪ +0.10	metrics profiles logs
quality_gates_rss_dsd_low	memory	⚪ -0.06	metrics profiles logs
quality_gates_rss_dsd_ultraheavy	memory	⚪ -0.09	metrics profiles logs
quality_gates_rss_dsd_medium	memory	⚪ -0.13	metrics profiles logs
quality_gates_rss_idle	memory	⚪ -0.47	metrics profiles logs

Bounds Checks: ✅ Passed (5)

experiment	check	replicates	observed	links
quality_gates_rss_dsd_heavy	memory_usage	10/10	✅ 135 MiB ≤ 140 MiB	metrics profiles logs
quality_gates_rss_dsd_low	memory_usage	10/10	✅ 43.1 MiB ≤ 50 MiB	metrics profiles logs
quality_gates_rss_dsd_medium	memory_usage	10/10	✅ 65.2 MiB ≤ 75 MiB	metrics profiles logs
quality_gates_rss_dsd_ultraheavy	memory_usage	10/10	✅ 192 MiB ≤ 200 MiB	metrics profiles logs
quality_gates_rss_idle	memory_usage	10/10	✅ 28.8 MiB ≤ 40 MiB	metrics profiles logs

Explanation

A change is flagged as a regression when |Δ mean %| > 5.00% in the regressing direction for its optimization goal AND SMP marks the experiment as a regression (is_regression: true). Improvements use the matching criteria for the improving direction. Experiments configured erratic: true (tagged (ignored)) are skipped outright; experiments detected as erratic at runtime (tagged (erratic)) still count, since that flag describes sample dispersion rather than directional certainty. The Δ mean % cell is colored accordingly: 🟢 = improvement, 🔴 = regression, ⚪ = neutral. Reduction in CPU or memory is an improvement; reduction in ingress throughput is a regression.

[tobz]

• chore(core): refactor ComponentRegistry to use unified identifiers #2057
• chore(core): unify how identifiers are created for health registration and environment providers #2048 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[pr-commenter]

Binary Size Analysis (Agent Data Plane)

Baseline: cccc3c7 · Comparison: e27cf53 · diff
Analysis Configuration: stripped binaries · Pass/Fail Threshold: +5%
Sizes: 41.53 MiB (baseline) vs 41.51 MiB (comparison)
Size Change: -24.81 KiB (-0.06%)

✅ Binary size difference within threshold

Changes by Module

Module	File Size	Symbols
figment	-16.47 KiB	80
serde_json	-13.26 KiB	83
h2	-13.26 KiB	64
prost	+12.06 KiB	23
hashbrown	-9.86 KiB	173
agent_data_plane::internal::env	+9.29 KiB	27
anon.af29a6a9d4a9362117e0fbd5d9b09a76.66.llvm.13283325591066943712	-8.08 KiB	1
anon.84c792902d8f7aa6b85e3dcbd3e80db0.4.llvm.11863342121551748718	+8.08 KiB	1
hyper	+7.96 KiB	43
core	+7.56 KiB	2000
serde_core	+7.40 KiB	99
tonic	-7.01 KiB	84
alloc	+6.56 KiB	243
saluki_context::tags::tagset	+6.45 KiB	9
saluki_core::topology::interconnect	-6.40 KiB	12
saluki_core::topology::built	+6.15 KiB	5
std	-6.13 KiB	71
quick_cache	+5.65 KiB	30
axum	+5.11 KiB	71
tower	-4.91 KiB	81

Detailed Symbol Changes

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  [NEW] +25.4Ki  [NEW] +25.3Ki    saluki_core::topology::built::ComponentInterconnects::generate_interconnects::h3417c39840d1b3a8
  [NEW] +21.3Ki  [NEW] +21.2Ki    agent_data_plane::internal::env::ADPEnvironmentProvider::from_configuration::_{{closure}}::h2a4d118040535a27
  [NEW] +19.8Ki  [NEW] +19.6Ki    agent_data_plane::internal::env::workload::build_collector::_{{closure}}::haba90f569e1d9d5b
 +31e2% +15.1Ki +41e2% +15.1Ki    agent_data_plane::state::metrics::rules::get_datadog_agent_remappings::h68eb3fecfeeb2a71
  [NEW] +13.9Ki  [NEW] +13.8Ki    agent_data_plane::state::metrics::rules::get_compat_remappings::hbe424d3cb4d5b04b
  [NEW] +8.08Ki  [NEW]     +77    anon.84c792902d8f7aa6b85e3dcbd3e80db0.4.llvm.11863342121551748718
  [NEW] +5.19Ki  [NEW] +5.09Ki    saluki_core::health::HealthRegistry::register_component::h915e7847779964a6
  [NEW] +5.18Ki  [NEW] +4.88Ki    alloc::collections::btree::node::Handle<alloc::collections::btree::node::NodeRef<alloc::collections::btree::node::marker::Mut,K,V,alloc::collections::btree::node::marker::Leaf>,alloc::collections::btree::node::marker::Edge>::insert_recursing::hdf591c12d6b4dc47
 -29.4% -4.72Ki -29.6% -4.72Ki    _<h2::client::Connection<T,B> as core::future::future::Future>::poll::hce78624e5d45a71c
  [DEL] -4.81Ki  [DEL] -4.51Ki    alloc::collections::btree::node::Handle<alloc::collections::btree::node::NodeRef<alloc::collections::btree::node::marker::Mut,K,V,alloc::collections::btree::node::marker::Leaf>,alloc::collections::btree::node::marker::Edge>::insert_recursing::hfa8de38d3122a79d
  [DEL] -5.05Ki  [DEL] -4.96Ki    tokio::runtime::runtime::Runtime::block_on::h007fe38b49b56e7d
 -31.8% -5.51Ki -32.1% -5.51Ki    _<h2::client::Connection<T,B> as core::future::future::Future>::poll::hcfac1ad473710cfe
  +0.0% +3.43Ki  -0.1% -7.61Ki    [10743 Others]
  [DEL] -8.08Ki  [DEL]     -77    anon.af29a6a9d4a9362117e0fbd5d9b09a76.66.llvm.13283325591066943712
  [DEL] -11.0Ki  [DEL] -10.9Ki    agent_data_plane::state::metrics::rules::dogstatsd::get_dogstatsd_remappings::h4f69ff9b102d4797
 -73.8% -11.4Ki -74.6% -11.4Ki    _<figment::value::de::ConfiguredValueDe<I> as serde_core::de::Deserializer>::deserialize_struct::h409b8b60d628b9cb
  [DEL] -12.1Ki  [DEL] -11.9Ki    _<figment::value::de::ConfiguredValueDe<I> as serde_core::de::Deserializer>::deserialize_struct::hcf9420ec32f0f836
  [DEL] -14.0Ki  [DEL] -13.9Ki    agent_data_plane::state::metrics::rules::compat::get_compat_remappings::hbb15ab96aebd90fb
  [DEL] -15.6Ki  [DEL] -15.4Ki    _<figment::value::de::ConfiguredValueDe<I> as serde_core::de::Deserializer>::deserialize_struct::h3f26e78765897c44
 -93.8% -17.3Ki -94.4% -17.3Ki    saluki_core::topology::built::ComponentInterconnects::from_graph::h5be8741b7a0533b0
  [DEL] -32.7Ki  [DEL] -32.5Ki    agent_data_plane::internal::env::workload::RemoteAgentWorkloadProvider::from_configuration::_{{closure}}::h0399488f11e43c11
  -0.1% -24.8Ki  -0.1% -35.7Ki    TOTAL

[webern]

Does this integrate with configuration in some way? For example, right now we have these "pipelines" identifiers in the schema_overlay.yaml so that we can warn/error properly on unsupported configuration. Have you thought about unifying the configuration and component identification worlds at all?

I am going to proceed with what I'm doing anyway, because I think we need my configuration system changes either way, but I'm just starting a background thread on subsystem identification and how configuration affects an identifiable subsystem.