태그는 키-값 쌍(예 team: operations)으로, 모니터링 대상이나 대시보드 또는 워크로드에 추가됩니다. 몇 가지 중요한 속성을 태그로 사용할 수 있습니다. 여기에는 앱 이름 및 언어와 같은 앱 메타데이터와 호스트 이름 및 클라우드 공급자 지역과 같은 호스트 메타데이터가 포함됩니다. 고유한 사용자 지정 태그를 추가할 수도 있습니다.
UI에서 태그를 사용하여 관련 엔터티로 필터링할 수 있습니다. 예를 들면 다음과 같습니다.
여기에서 특정 계정에 대한 워크로드 를 필터링하는 데 사용되는 accountId 태그를 볼 수 있습니다.
태그의 이점
태그는 다음을 도와줍니다.
다수의 소스 및/또는 다수의 New Relic 계정으로 들어오는 데이터를 구성합니다.
누가 무엇을 담당하는지 알기 위해 팀, 역할, 환경 또는 지역을 식별합니다.몇 가지 예 를 참조하십시오.
필드를 클릭하면 사용 가능한 속성 및 태그의 다운 드롭 메뉴가 표시되거나 필터링하려는 태그(예: accountId: 123456789)를 입력할 수 있습니다.
모범 사례
태그를 최대한 활용하려면 다음 권장사항을 따르세요.
UI에는 엔터티당 표시할 수 있는 총 태그 수에 제한이 있습니다.
기본적으로 보고되거나 에이전트/통합 구성을 통해 추가되는 태그의 경우 100개로 제한됩니다.
UI 또는 API를 통해 추가된 사용자 정의 태그는 100개로 제한됩니다.
다음은 태그의 최대 문자 길이입니다.
키: 128자
값: 256자
허용되는 문자:
문자는 UTF-8이어야 합니다.
NerdGraph를 사용하여 태그를 추가 할 때 태그 키의 대시 - 는 빼기 기호로 해석됩니다.태그 키에 대시가 있는 경우 `key-name` 과 같이 백틱을 사용하세요.
태그를 단순하게 유지하기 위한 몇 가지 팁:
확실히 사용할 것으로 알고 있는 태그만 추가하는 것으로 시작하십시오.사용하지 않는 태그는 노이즈를 생성하고 혼란을 가중시킬 수 있습니다.
짧은 태그를 사용해 보세요. 짧은 태그는 구문 분석하기 쉽고 UI는 때때로 긴 태그를 잘릴 수 있습니다. ( 글자 제한 참조)
가능하면 사람이 읽을 수 있는 키와 값을 사용하세요(예: region: EMEA 가 Param8323 : 1229072 보다 좋음).
단일 태그에 regions: EMEA | US | LATAM 과 같은 여러 값을 포함하지 마십시오. region: emea , region: us 및 region: latam 과 같이 세 가지 다른 태그를 사용하는 것이 좋습니다. 여러 태그를 일치시키려면 필터 UI의 고급 옵션을 사용하여 일치시킬 수 있습니다.
경고 사고 에 대한 주의 사항: 이는 하나의 키 이름 인스턴스만 지원합니다. 여러 키 이름을 사용하는 경우 하나가 무작위로 선택되어 해당 인시던트에 추가됩니다.
팀과 엔터티 전반에 걸쳐 태그 언어와 일관성을 유지하십시오.
명명과 일관성을 유지하십시오. 예를 들어, region: emea 및 reg: emea 을 모두 사용하지 마십시오.
형식을 일관되게 유지하십시오. 예를 들어, camelCase 및 kebab-case 을 모두 사용하지 마십시오.
태그 검색은 UI 및 API에서 대소문자를 구분하지 않지만 대소문자를 일관되게 사용하십시오. 예를 들어, env: staging 및 env: Staging 을 모두 사용하지 마십시오.
태그는 관찰 가능성과 비용 할당을 개선하는 데 도움이 됩니다. 이러한 이유로 태그 구현에 대한 책임은 종종 관찰 가능성 팀, SRE, 설계자 그룹 또는 팀 간 태스크 포스에 할당됩니다.
태그 구현을 담당하는 사람들은 태그 정의 방법과 사용 규칙을 설명하는 내부 정책을 충족하고 생성할 것을 권장합니다. 그 다음에:
이 참조 설명서를 최신 상태로 유지하십시오.
클라우드 제공자에서 배포하다 뉴렐릭 에이전트를 구현하거나 API 또는 뉴렐릭 Terraform 제공자 와 같은 뉴렐릭 자동화 도구를 통해 태그 정의를 자동화합니다.
태그 지정 표준을 준수하지 않는 엔터티를 식별하는 반복 보고서를 만듭니다.
태그 예
다음은 태그를 사용하여 데이터를 구성하는 일반적인 방법의 몇 가지 예입니다.
팀 이름에 대한 태그를 생성하면 성능 문제를 야기한 변경에 대해 책임이 있는 팀, 그룹, 부서 또는 지역을 이해하는 데 도움이 될 수 있습니다.
### Team tags
team: backend
team: frontend
team: db
### Role tags
roles: architecture
roles: devops
roles: pm
### Region tags
region: emea
region: america
region: asia
그들이 속한 환경에 대한 엔티티를 생성할 수 있습니다.예를 들어:
env: production
env: qa
env: development
env: staging
중요도 수준과 관련된 태그를 생성하여 가장 중요한 문제를 더 쉽게 추적할 수 있습니다.예를 들어:
layer: level1
layer: level2
layer: level3
사용자 지정 쿼리, 대시보드 및 알림
기능마다 태그를 다르게 처리합니다. 다음은 NRQL 을 사용하여 태그 데이터를 쿼리하거나 NRQL 상태 경고 를 생성하는 방법에 대한 몇 가지 세부 정보입니다.
FROM Metric WHERE appName LIKE'MyApp (%'AND transactionType ='Other'
FACET tags.Environment TIMESERIES
특정 팀의 서비스당 트랜잭션 수를 보려면 다음과 같은 쿼리를 사용할 수 있습니다.
FROMTransactionSELECTcount(*)
WHERE tags.Team ='team-a'
FACET tags.Project TIMESERIES
각 서비스에 대한 규칙을 만들지 않고도 경고를 설정하기 위해 서비스의 오류율에 대한 쿼리를 사용할 수 있습니다. 다음은 team-b라는 팀의 모든 서비스에 대한 오류율입니다. 이 알림은 팀 태그로 추가된 새 앱 이름을 자동으로 모니터링합니다.
FROM Metric SELECTcount(apm.service.error.count)/count(apm.service.transaction.duration)
WHERE tags.Team ='team-b' FACET appName
이와 관련하여 여러 환경에 배포된 특정 서비스에 대한 일반 규칙을 생성하여 각 환경을 개별적으로 모니터링하는 단일 서비스에 대한 경보를 생성할 수 있습니다.
From Metric SELECTcount(apm.service.error.count)/count(apm.service.transaction.duration)
WHERE tags.Project ='MyProject' FACET tags.Environment
예를 들어 SensitiveEntity라는 항목을 소유한 내부 팀을 찾으려면 다음을 실행하세요.
FROM SystemSample SELECT internalOwningTeam WHERE entityName ='SensitiveEntity'
CPU가 있는 다른 인프라 엔터티에서 일부 부하 테스트를 수행하려고 한다고 가정해 보겠습니다. A 그룹의 항목에 한 가지 처리를 적용하고, B 그룹의 항목에 다른 처리를 적용하고, control group 라는 처리가 없는 하나의 항목 그룹을 유지할 수 있습니다.
New Relic UI에서 각 엔티티가 속한 실험 그룹에 매핑된 experimentGroup 라는 태그를 생성할 수 있습니다. New Relic UI에서 생성된 태그이므로 newrelic-infra.yml 구성 파일에서 생성된 사용자 정의 속성과 달리 태그 이름에 tags. 접두사를 추가해야 합니다.
다음은 cpuPercent) 선택하는 NRQL 쿼리이며 FACET CASES (...) 절을 사용하여 다양한 실험 그룹으로 분류됩니다.
FROM SystemSample SELECT cpuPercent FACET CASES (WHERE tags.experimentGroup ='control'AS'control group',WHERE tags.experimentGroup ='A'AS'given treatment A',WHERE tags.experimentGroup ='B'AS'given treatment B') SINCE 1DAY AGO