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:

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

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