# 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`, `ats`, `rtc`, or `rrcp_trans`) 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 application-specific aliases for mapped LMC object classes. 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 - An additional raw path selection ## 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 ``` ## Application Metrics in 0.19.0 ### ADH Coverage Version 0.19.0 adds 196 ADH metric definitions covering REST and source IPC servers, RRCP queue and read statistics, cache configuration, domain item counts, route login backoff, and TCP receive-window limits. The following class selectors and groups are available in addition to existing ADH filters:

ADH Coverage
Class	Seed path group
`RESTServer`	`rest_server`
`SourceRIPCServer`	`source_ripc_server`
`SourceIPCServer`	`source_ipc_server`
`CacheListMgr`	`cache_list_mgr`
`NoDataCache`	`no_data_cache`
`RecordDataCache`	`record_data_cache`

For example, add a target to your existing licensing and HTTP configuration: ``` [[targets]] app = "adh" server_key = "999" classes = ["RESTServer", "SourceRIPCServer", "SourceIPCServer"] ``` `SourceIPCServer` covers both the transmission bus and its nested `ipcServer` object. `NoDataCache` and `RecordDataCache` expose configuration flags, not cache hit or miss statistics. Cache paths add service, route, and server identifiers as labels. TCP window-limit metrics remain gauges; confirm their units and accumulation behavior for your deployed ADH before using them in alerts. Existing restrictive filters may exclude the new coverage. Review the selected classes, groups, and raw paths after upgrading. NoteADH series changes on upgrade Existing source-side RRCP series gain `rrcp_transmission_bus_src_driver_name`. The ThreadBindingStats topology metric gains `thread_binding_stats_rest_thread_cpu`, `thread_binding_stats_rrcp_snk_read_cpu_0`, `thread_binding_stats_rrcp_src_read_cpu_0`, `thread_binding_stats_rrcp_src_read_cpu_1`, and `thread_binding_stats_rrcp_src_read_cpu_2`. Metric names and types are retained, but the added labels change series identity. Review queries, joins, recording rules, and consumers that depend on exact label sets. Allow for a series transition and increased cardinality from both the new labels and new metrics. ### RRCP Trans Select `app = "rrcp_trans"` in TOML or `--app rrcp_trans` on the CLI. The mapping provides 67 gauge families in the `rrcp_trans_` namespace. Sample counts depend on the objects and roles present in the source. Sink and source metrics carry `rrcp_role="sink"` or `rrcp_role="source"`. Daemon descriptors label daemon metrics, and the root version labels process metrics; statistics and packet-pool metrics do not inherit those descriptors.

RRCP Trans
Class selector	Selected paths
`ManagedProcess.RrcpTrans`	`@root` process variables
`RRCP`	`sink` and `source` daemon subtrees
`Memory utilization`	`sink.pktPoolStats` and `source.pktPoolStats`
`RRCP statistics`	`sink.stats` and `source.stats`

The groups `core`, `sink`, and `source` select `@root`, `sink`, and `source` respectively. Class and group names are case-insensitive. For statistics from both roles: ``` [[targets]] app = "rrcp_trans" server_key = "123" classes = ["RRCP statistics"] ``` For sink statistics only, replace the class selection with: ``` seed_paths = ["sink.stats"] ``` Filters are combined as a union: leaving a broader class or group selection in place also includes those paths. All RRCP Trans numeric families, including traffic totals, are gauges. Do not assume counter semantics or apply unverified unit conversions. `Update Interval` and packet-pool size retain their raw values. Collection is read-only and excludes the `Reset stats?` control. NoteValidate RRCP Trans before production rollout Confirm live shared-memory discovery, the sink/source layout, readiness and recovery, source units, and timestamp interpretation for your deployment. Gateway mode for RRCP Trans requires **Keystone Gateway v0.2.1**, the `rrcp_trans` entitlement, and a stable `component_instance_id` on every target. Validate acquisition and renewal with your Gateway before production use. ### Timestamp Metrics Ten ADH event-time fields are exposed as Unix-second gauges with `_timestamp_seconds` names, including `adh_rest_server_last_connect_time_timestamp_seconds` and `adh_source_ipc_server_last_read_time_timestamp_seconds`. RRCP Trans start times use `rrcp_trans_rrcp_daemon_started_at_seconds` and `rrcp_trans_managed_process_rrcp_trans_time_seconds`. For example: ``` time() - adh_rest_server_last_connect_time_timestamp_seconds ``` ``` time() - rrcp_trans_managed_process_rrcp_trans_time_seconds ``` For source dates without timezone information, the exporter process timezone must match the application’s timezone. Configure the host timezone or the standard `TZ` process environment variable; for service setup, see [Installation](https://portal.cjcit.io/knowledge-base/lmc_exporter/0.19/getting-started/installation/#service-management). Supported yearless dates use the current local year, so verify populated values around year boundaries. Time-only values and durations are not epoch timestamps. Blank values emit no sample. Unsupported nonempty strings are skipped with a diagnostic comment. Do not interpret absent samples as epoch zero. Validate populated date values in a live scrape before relying on timestamp alerts. Version 0.19.0 preserves double precision when rendering numeric samples, retaining individual timestamp seconds. ## 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.