Utilisez des balises pour vous aider à organiser et à trouver vos données

Nous appliquons automatiquement certaines balises aux entités qui incluent des informations de compte. Ces balises incluent :

• account
• accountId

Les agents New Relic peuvent être configurés pour appliquer une balise à l'entité créée à partir de leurs données. Les options de configuration sont quelque peu spécifiques à l'agent, mais utilisent généralement la touche labels . Quelques exemples :

• Configuration du tag de l'agent Java

• Configuration tag de l'agent .NET

  une balise appliquée à partir de configuration de l'agent APMpeut générer plusieurs valeurs pour une clé tag donnée sur une entité donnée, car chaque instance déployée de l'agent peut être configurée pour envoyer une valeur différente.

Les agents New Relic appliquent automatiquement certaines balises à l'entité de service en fonction de l'environnement. Il s’agit notamment (mais sans s’y limiter) :

• Pour entité de service/application

  • language: (par exemple, java ou python)

• Pour l'entité hôte

  • awsRegion, le cas échéant

  Si vous utilisez l'une de nos intégrations de fournisseurscloud (AWS, Azure ou Google Cloud Platform), nous vous recommandons d'installer l'agent infrastructure sur vos hôtes : cela ajoutera une balise d'environnement cloud à votre entité hôte de monitoring dans New Relic.

1. Accéder à une condition.

2. Près du nom de la condition en haut du formulaire, cliquez sur Manage tags.

3. Dans le menu qui apparaît, ajoutez ou supprimez une tag.

   Vous pouvez également ajouter une balise à une condition d'alerte en tant qu'entité via l'API NerdGraph (utilisez le GUID d'entité de la condition à partir de l'écran « Gérer la balise »).

   Consultez notre tutoriel pour en savoir plus sur les données de balises via l'API NerdGraph.

Pour un guide sur l'automatisation des balises à l'aide de notre outil CLI, consultez notre site développeurs.

• L'interface utilisateur a des limites sur le nombre total de balises qu'elle peut afficher par entité :

  • Limite de 100 pour les balises signalées par défaut ou ajoutées via configuration de l'agent/de l'intégration.
  • Limite de 100 pour les balises personnalisées ajoutées via l'interface utilisateur ou l'API.

• Voici la longueur maximale de caractères pour la balise :

  • Clé : 128 caractères
  • Valeur : 256 caractères

• Caractères autorisés :

  • Les caractères doivent être UTF-8.
  • Lorsque vous utilisez NerdGraph pour ajouter une balise, un tiret - dans une clé tag est interprété comme un symbole moins. Si votre clé tag comporte un tiret, utilisez des guillemets arrière autour de celui-ci, comme `key-name`.

Quelques conseils pour garder le tag simple :

• Commencez par ajouter uniquement les balises que vous savez que vous utiliserez certainement. Les balises non utilisées créent du bruit et peuvent ajouter de la confusion.
• Essayez d'utiliser une balise courte. Les balises plus courtes sont plus faciles à analyser et l'interface utilisateur peut parfois tronquer les balises plus longues. (Voir les limites de caractères.)
• Dans la mesure du possible, utilisez des clés et des valeurs lisibles par l’homme (par exemple, region: EMEA est meilleur que Param8323 : 1229072).
• Évitez d'inclure plusieurs valeurs comme regions: EMEA | US | LATAM dans une seule tag. Nous vous recommandons d'utiliser trois balises différentes pour cela, comme region: emea, region: us et region: latam. Si vous souhaitez faire correspondre plusieurs balises, vous pouvez le faire à l'aide des options avancées de l'interface utilisateur du filtre.
  • Un avertissement concernant les incidents d'alerte: ceux-ci ne prennent en charge qu'une seule instance de nom de clé. Si vous utilisez plusieurs noms de clés, l'un d'eux sera sélectionné au hasard pour être ajouté à cet incident.

• Essayez d’être cohérent avec le langage tag dans vos équipes et votre entité.
• Soyez cohérent dans la dénomination. Par exemple, évitez d’utiliser à la fois region: emea et reg: emea.
• Soyez cohérent avec le format. Par exemple, évitez d’utiliser à la fois camelCase et kebab-case.
• Bien que la recherche tag ne soit pas sensible à la casse dans l'interface utilisateur et l'API, essayez d'être cohérent avec la mise en majuscules. Par exemple, évitez d’utiliser à la fois env: staging et env: Staging.

Les balises aident à améliorer l'observabilité et la répartition des coûts. Pour cette raison, la responsabilité de la mise en œuvre tag est souvent attribuée à une équipe d'observabilité, à des SRE, à un groupe d'architectes ou à un groupe de travail inter-équipes.

Nous recommandons aux personnes responsables de la mise en œuvre des balises de se réunir et de créer une politique interne pour décrire comment les balises sont définies et quelles conventions doivent être utilisées. Alors:

• Maintenez ce manuel de référence à jour.
• Automatisez la définition des balises lorsque vous déployez des agents New Relic, chez le fournisseur cloud ou via les outils d'automatisation New Relic, tels que l'API ou le fournisseur New Relic Terraform.
• Créez des rapports récurrents qui identifient les entités non conformes à vos normes de balises.

La création d’étiquettes pour les noms d’équipe peut être utile pour comprendre quelle équipe, quel groupe, quel département ou quelle région était responsable d’un changement ayant entraîné un problème de performances.

### Team tags
team: backend
team: frontend
team: db
### Role tags
roles: architecture
roles: devops
roles: pm
### Region tags
region: emea
region: america
region: asia

Vous pouvez créer une entité pour l’environnement auquel elle appartient. Par exemple:

env: production
env: qa
env: development
env: staging

Vous pouvez créer des balises liées aux niveaux de criticité, ce qui vous permet de suivre plus facilement les problèmes les plus critiques. Par exemple:

layer: level1
layer: level2
layer: level3

Étant donné un service distribué sur neuf fragments, chaque fragment étant attribué à un environment, nous pouvons tracer le débit des transactions sur tous les fragments à l'aide d'une requête générique comme :

SELECT rate(count(apm.service.transaction.duration), 1 minute)
FROM Metric WHERE appName LIKE 'MyApp (%' AND transactionType = 'Other'
FACET tags.Environment TIMESERIES

Pour voir le nombre de transactions par service pour une équipe spécifique, nous pouvons utiliser une requête comme :

FROM Transaction SELECT count(*)
WHERE tags.Team = 'team-a'
FACET tags.Project TIMESERIES

Vous pouvez utiliser une requête pour le taux d'erreur de vos services pour définir une alerte sans avoir à créer une règle pour chaque service. Voici le taux d’erreur pour tous les services d’une équipe appelée team-b. Et cette alerte monitorera automatiquement tous les nouveaux noms d'application ajoutés avec la tag d'équipe.

FROM Metric SELECT count(apm.service.error.count) / count(apm.service.transaction.duration)
WHERE tags.Team = 'team-b' FACET appName

Dans ce contexte, vous pouvez créer une règle générale pour un service spécifique déployé dans plusieurs environnements, afin que nous ayons une alarme pour un seul service monitoring chaque environnement individuellement :

FROM Metric SELECT count(apm.service.error.count) / count(apm.service.transaction.duration)
WHERE tags.Project = 'MyProject' FACET tags.Environment

Pour rechercher des équipes internes qui possèdent une entité nommée, par exemple, SensitiveEntity, exécutez la commande suivante :

FROM SystemSample SELECT internalOwningTeam WHERE entityName = 'SensitiveEntity'

Disons que vous souhaitez effectuer des tests de charge sur vos différentes entités infrastructure avec des CPU. Vous pouvez appliquer un traitement à l'entité dans un groupe appelé A, appliquer un traitement différent à l'entité dans un groupe appelé B et conserver un groupe d'entités sans traitement, appelé control group.

Vous pouvez créer une balise appelée experimentGroup dans l'interface utilisateur de New Relic, mappée au groupe expérimental auquel appartient chaque entité. Comme il s'agit de balises créées dans l'interface utilisateur de New Relic, vous devez ajouter le préfixe tags. au nom de la tag , contrairement à l'attribut personnalisé créé dans le fichier configuration newrelic-infra.yml.

Voici la requête NRQL pour sélectionner cpuPercent, décomposée par les différents groupes expérimentaux à l'aide d'une clause 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 1 DAY AGO

Pour désactiver la propagation tag pour les balises infrastructure , exécutez la commande suivante dans NerdGraph:

mutation {
  dataManagementUpdateFeatureSettings(
    accountId: YOUR_ACCOUNT_ID
    setting: {
      enabled: false
      featureSetting: { key: "infra_tag_propagation" }
      locked: false
    }
  ) {
    enabled
    key
    locked
    name
  }
}

Cet appel devrait renvoyer la réponse suivante :

{
  "data": {
    "dataManagementUpdateFeatureSettings": {
      "enabled": false,
      "key": "infra_tag_propagation",
      "locked": false,
      "name": "Infra tag propagation"
    }
  }
}