How to choose your attributes
Ask yourself: “What groups of collectors should receive the same configuration?”
| If you want to target… | You need an attribute like… |
|---|---|
| All production servers | env=production |
| Collectors in specific regions | region=us-east |
| Collectors owned by a team | team=platform |
| Collectors for a specific service | service=api-gateway |
Common attribute patterns
| Attribute | Example values | Use case |
|---|---|---|
env | production, staging, dev | Environment-specific configs |
region | us-east, eu-west, ap-south | Region-specific collection |
team | platform, backend, data | Team ownership |
service | api, web, worker | Service-specific monitoring |
Start simple. Begin with
envand one or two others. Add more as needed.
Script
Now that you understand what attributes are, let’s talk about how to design them well. A little planning up front saves a lot of pain later.
Start by asking one question: “What groups of collectors should receive the same configuration?” The answer reveals the attributes needed. If all production servers should get the same metrics config, an env attribute is needed. If different regions have different collection requirements, a region attribute is needed. If teams manage their own collectors, a team attribute is needed.
The table on this slide shows common patterns that work well. Environment is the most common—production, staging, development. Region is useful for geographic targeting. Team helps with ownership and accountability. Service identifies what the collector monitors.
Start with these basics. More attributes can be added as patterns emerge from real usage.