- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- Administrator's Guide
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
The “name” tag is one of many host-level tags that are applied by default from the AWS integration. But it is also a tag that’s often applied by default at the metric-level by our JMX-based integrations (based on the “bean names” matched in JMX). Both tags are useful, but using both at the same time can cause tag-conflicts that result in inappropriately aggregated values. So what to do about this?
The best approach is to rename your JMX integration’s “name” tag to be something else (e.g, “bean_name”). With our JMX-based integrations, there are two configuration features that make this possible: 1, the ability to exclude default tags via configuration, and 2, the ability to add specified bean attributes as customized metric tags.
For example, the following configuration of your kafka.yaml would collect a metric called “kafka.messages_in.rate” that would be tagged, among other things, by “name:messagesinpersec”.
- include:
domain: 'kafka.server'
bean: 'kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec'
attribute:
Count:
metric_type: rate
alias: kafka.messages_in.rate
To stop this from conflicting with an AWS “name” tag, you could change that metric’s configuration to the following:
- include:
domain: 'kafka.server'
bean: 'kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec'
attribute:
Count:
metric_type: rate
alias: kafka.messages_in.rate
exclude_tags:
- name
tags:
bean_name: $name
In this case, the same metric would be collected, but with the “name” tag applied as “bean_name:messagesinpersec” instead, which would no longer conflict with the AWS “name” tag key.