# Metric Configuration: Filtering Metrics with Classes, Seed Paths, and Metric Scopes ## Overview `lmc_exporter` provides two complementary ways to control which metrics are collected and exposed: 1. **Target Filters** – Limit the subscribed LMC subtree and the metrics rendered for a target using: - `classes` - `seed_path_groups` - `seed_paths` 2. **Metric Scopes** – Create named subsets of already-rendered Prometheus metrics and expose them through dedicated HTTP endpoints. These features can be used independently or together to reduce metric volume, focus on operational areas, and provide purpose-built scrape endpoints. ## Prerequisites Before configuring metric filters or scopes: - Configure `lmc_exporter` using a TOML configuration file. - Define at least one target in either: - Single-target mode, or - Multi-target mode using `[[targets]]`. - Ensure the target application (`ads`, `adh`, or `ats`) is configured correctly. ## How Metric Filtering Works Target filters affect both: - The portion of the LMC object tree that is subscribed to. - The metrics that are rendered and exposed for that target. Three filter mechanisms are available:

How Metric Filtering Works
Filter Type	Purpose	Best Used For
`classes`	Filter by LMC class aliases	Precise metric selection
`seed_path_groups`	Filter by curated operational bundles	Common monitoring scenarios
`seed_paths`	Filter by raw path prefixes	Custom or advanced filtering

All configured filters are combined. The exporter unions the resulting paths and metric templates. ## Filtering with Classes ### What Are Classes? `classes` are operator-facing aliases based on ADS/ATS class definitions. Each class resolves to one or more metric reference templates while automatically maintaining the broader tracking prefixes required to discover runtime objects and variables. ### Characteristics - Case-insensitive matching - Precise metric filtering - Easier to understand than raw paths - Recommended when monitoring specific functional components ### Example ``` classes = [ "ManagedProcess.SinkDist", "WSOCKServer" ] ``` ### Example ADS Class Mappings

Example ADS Class Mappings
Class	Metric Template
`ManagedProcess.SinkDist`	`@root`
`WSOCKServer`	`sink.server.ws.transmissionBus`
`RIPCServer`	`sink.server.ripc.transmissionBus`
`SSLDispatcher`	`sourceApplicationPool.sslDispatcher`
`ConsumerDataStream`	`userDatabase.dataStreams` and related paths
`ThreadBindingStats`	`ThreadBindingStats`

### When to Use Classes Use `classes` when you want monitoring to align directly with a known LMC object class or metric family. ``` classes = [ "ManagedProcess.SinkDist", "RIPCServer", "ConsumerDataStream" ] ``` ## Filtering with Seed Path Groups ### What Are Seed Path Groups? `seed_path_groups` are curated bundles maintained by the exporter. Each group expands into one or more predefined seed path prefixes that represent a logical operational area. ### Characteristics - Case-insensitive matching - Broader than class filtering - Easier to maintain than individual paths - Useful for operational monitoring domains ### Example ``` seed_path_groups = [ "core", "sink_ripc", "users" ] ``` ### ADS Seed Path Group Examples

ADS Seed Path Group Examples
Group	Seed Paths
`core`	`@root`, `ManagedProcess.SinkDist`
`client_sessions`	`clientSessionThread`
`service_generator`	`serviceGenerator`
`sink_ipc`	`sink.server.ipc.transmissionBus`
`sink_ripc`	`sink.server.ripc.transmissionBus`
`sink_ws`	`sink.server.ws.transmissionBus`
`source_all`	`sourceApplicationPool`
`source_ssl`	`sourceApplicationPool.sslDispatcher`, `sourceApplicationPool.sslIpcSessionHandler`
`users`	`userDatabase`
`thread_binding`	`ThreadBindingStats`

### When to Use Seed Path Groups Use seed path groups when you want a complete operational slice rather than a specific class. Examples: - All user database metrics - All RIPC sink metrics - All SSL-related source metrics ``` seed_path_groups = [ "core", "users", "sink_ripc" ] ``` ## Filtering with Seed Paths ### What Are Seed Paths? `seed_paths` are raw path prefixes relative to the selected root object. Unlike classes and groups, they do not use aliases or logical mappings. ### Characteristics - Exact control - No abstraction layer - Supports custom and experimental configurations - Most flexible filtering option ### Example ``` seed_paths = [ "serviceGenerator.srcPrdServicePool" ] ``` ### Including Root-Level Variables The reserved path `@root` includes variables located directly on the selected root object. ``` seed_paths = [ "@root", "serviceGenerator.srcPrdServicePool" ] ``` ### When to Use Seed Paths Use seed paths when: - No class alias exists. - No seed path group matches your requirement. - You need precise path-level control. ## Combining Filters Filters are not mutually exclusive. The exporter combines all configured filters into a single effective scope. ### Example ``` classes = [ "SSLDispatcher", "ManagedSSLChannel" ] seed_path_groups = [ "core" ] seed_paths = [ "sourceApplicationPool.sslDispatcher" ] ``` This configuration combines: - Class-driven filtering - A curated operational bundle - A custom path restriction ## Metric Scopes ### What Are Metric Scopes? Metric scopes define named subsets of rendered Prometheus metrics. Unlike target filters, scopes do not change subscription behavior. Instead, they control which already-rendered metrics are returned by a specific HTTP endpoint. Metric scopes are configured using repeated `[[metric_scopes]]` sections. ### Basic Example ``` [[metric_scopes]] name = "client_threads" metrics = [ "ads_client_session_thread_*" ] [[metric_scopes]] name = "process_health" metrics = [ "ads_managed_process_sink_dist_state", "ads_managed_process_sink_dist_process_id", "ads_shmem_mo_server_stats_num_clients" ] ``` ## Scope Configuration Each scope supports:

Scope Configuration
Key	Description
`name`	Unique scope name
`metrics`	List of metric patterns included in the scope

### Scope Naming Rules Scope names may contain: - Letters - Numbers - `.` - `_` - `-` Example: ``` name = "process-health" ``` ## Metric Matching Rules The `metrics` list supports exact matches and wildcards. ### Exact Match ``` metrics = [ "ads_managed_process_sink_dist_state" ] ``` ### Prefix Match Trailing `*` performs a prefix match. ``` metrics = [ "ads_client_session_thread_*" ] ``` ### Wildcard Match `*` can appear anywhere within the metric name. ``` metrics = [ "ads_*_num_clients" ] ``` ### Histograms and Summaries When an exact metric name is included, related metric-family series are also included automatically when applicable: - `_sum` - `_count` - `_bucket` ## Scoped Endpoints ### Path-Based Scope Routing Each scope becomes a dedicated endpoint. For a scope named `update_rate`: ``` /metrics/update_rate ``` For a scope named `health`: ``` /metrics/health ``` ### Query Parameter Routing Scopes can also be selected using the `scope` query parameter. ``` /metrics?scope=update_rate ``` Both approaches are equivalent. ## Scoped Endpoints in Multi-Target Mode When multiple targets are configured, target routing parameters remain required. ### Path-Based Scope Selection ``` /metrics/update_rate?server_key=82 ``` ### Query-Based Scope Selection ``` /metrics?scope=update_rate&server_key=82 ``` ### Instance-Based Routing ``` /metrics/update_rate?instance=phoads01.1.ads&app=ads ``` ### Duplicate Instance Targets If multiple targets share the same application and instance, include the server key. ``` /metrics/update_rate?instance=phoads01.1.ads&app=ads&server_key=82 ``` ## Examples ### Broad Operational Monitoring ``` [[targets]] app = "ads" server_key = "82" seed_path_groups = [ "core", "sink_ripc", "users" ] ``` ### Precise Class-Based Monitoring ``` [[targets]] app = "ads" server_key = "82" classes = [ "ManagedProcess.SinkDist", "RIPCServer", "ConsumerDataStream" ] ``` ### Custom Path Monitoring ``` [[targets]] app = "ads" server_key = "82" seed_paths = [ "serviceGenerator.srcPrdServicePool", "sourceApplicationPool.sslDispatcher" ] ``` ### Scoped Client Session Metrics ``` [[metric_scopes]] name = "client_threads" metrics = [ "ads_client_session_thread_*" ] ``` Access: ``` /metrics/client_threads?server_key=82 ``` ## Troubleshooting ### Expected Metrics Are Missing Verify: - The correct target is selected. - The relevant `classes`, `seed_path_groups`, or `seed_paths` are configured. - Path names and class names are valid for the application. - The selected scope includes the metric pattern you expect. ### Scope Endpoint Returns No Data Verify: - The scope name matches the configuration. - Metric patterns match the rendered Prometheus metric names. - Wildcard expressions are correct. ### Scope Endpoint Fails in Multi-Target Mode If multiple targets are configured, include target-routing parameters. Incorrect: ``` /metrics/update_rate ``` Correct: ``` /metrics/update_rate?server_key=82 ``` ### Error: Target Routing Required The following response indicates that a scope was selected but the target was not: ``` scope selected, but target routing still required when multiple targets are configured. ``` Add one of: - `server_key` - `instance` and `app` - `instance`, `app`, and `server_key` when duplicates exist ## Related Information - `classes`, `seed_path_groups`, and `seed_paths` all limit subscription scope and rendered metrics. - Metric scopes create alternative views of rendered metrics but do not affect subscriptions. - Filters and scopes can be used together to create narrowly focused scrape endpoints for specific operational use cases.