Common patterns
| Pattern | Matcher examples |
|---|---|
| Environment-based | env="production", env="staging" |
| Region-based | region="us-east", region="eu-west" |
| Team-based | team="platform", team="backend" |
| Catch-all | collector.os=~".+" (matches all collectors) |
Example: Production platform pipeline
Matchers: env=~"prod-.*", team="platform"This pipeline applies to collectors where:
envmatches the regexprod-.*ANDteamequalsplatform
Limits to know
| Limit | Value |
|---|---|
| Matcher length | 200 characters max (key + operator + value) |
| Local attributes per collector | 22 max when polling |
Script
Now that you understand matcher syntax and AND logic, let’s look at how teams typically use attribute matching in practice.
Because collectors have their own attributes, you have flexibility in how you organize your fleet. Maybe by environment and region. Maybe by team and service. Maybe by Kubernetes namespace.
A common pattern is environment-based matching. Your production collectors get production configs, your staging collectors get staging configs—all from the same Fleet Management instance. Region-based matching works similarly, letting you target collectors by geographic area.
You can also create a catch-all matcher using a regex that matches any value. This is useful for pipelines that should apply to every collector in your fleet.
One thing to watch out for: matchers are limited to 200 characters total including key, value, and operator. And collectors can have at most 22 local attributes when polling for configuration. These limits are generous for most use cases, but worth knowing as you design your attribute schema.