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:

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

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

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 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:

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.

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.

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.

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. 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.