Cette référence couvre la syntaxe YAML pour les utilisateurs avancés créant des configurations de gateway personnalisées. Pour des informations conceptuelles, consultez Présentation du gateway. Pour une expérience guidée, utilisez l'interface utilisateur Gateway. Bien que l'interface utilisateur de la Gateway soit recommandée pour la plupart des utilisateurs, la configuration YAML offre un contrôle total sur la structure du pipeline de télémétrie.
Structure YAML complète
Les configurations du gateway utilisent un format YAML déclaratif :
version: 2.0.1autoscaling: minReplicas: 6 maxReplicas: 10 targetCPUUtilizationPercentage: 60configuration: simplified/v2: troubleshooting: proxy: false requestTraceLogs: false steps: receivelogs: description: Receive logs from OTLP and New Relic proprietary sources output: - probabilistic_sampler/Logs receivemetrics: description: Receive metrics from OTLP and New Relic proprietary sources output: - filter/Metrics receivetraces: description: Receive traces from OTLP and New Relic proprietary sources output: - probabilistic_sampler/Traces probabilistic_sampler/Logs: description: Probabilistic sampling for all logs output: - filter/Logs config: rules: - name: sample the log records for ruby test service description: sample the log records for ruby test service with 70% sampling_percentage: 70 source_of_randomness: trace.id conditions: - resource.attributes["service.name"] == "ruby-test-service" default_sampling_percentage: 100 probabilistic_sampler/Traces: description: Probabilistic sampling for traces output: - filter/Traces config: default_sampling_percentage: 100 filter/Logs: description: Apply drop rules and data processing for logs output: - transform/Logs config: error_mode: ignore rules: - name: drop the log records description: drop all records which has severity text INFO conditions: - log.severity_text == "INFO" context: log filter/Metrics: description: Apply drop rules and data processing for metrics output: - transform/Metrics config: error_mode: ignore rules: - name: drop-internal-metrics description: drop internal metric conditions: - IsMatch(name, "^internal\\.") context: metric - name: drop-debug-datapoints description: drop-debug-datapoints conditions: - attributes["metric.type"] == "debug" context: datapoint filter/Traces: description: Apply drop rules and data processing for traces output: - transform/Traces config: error_mode: ignore rules: - name: drop-health-endpoint description: drop-health-endpoint conditions: - attributes["http.path"] == "/health" context: span - name: drop-debug-events description: drop-debug-events conditions: - name == "debug_event" context: span_event transform/Logs: description: Transform and process logs output: - nrexporter/newrelic config: rules: - name: add new field to attribute description: for otlp-test-service application add newrelic source type field conditions: - resource.attributes["service.name"] == "otlp-java-test-service" statements: - set(resource.attributes["source.type"],"otlp") transform/Metrics: description: Transform and process metrics output: - nrexporter/newrelic config: rules: - name: adding a new attributes description: adding a new field into a attributes conditions: - resource.attributes["service.name"] == "payments-api" statements: - set(resource.attributes["application.name"], "compute-application") transform/Traces: description: Transform and process traces output: - nrexporter/newrelic config: rules: - name: remove the attribute description: remove the attribute when service name is payment-service conditions: - resource.attributes["service.name"] == "payment-service" statements: - delete_key(resource.attributes, "service.version") nrexporter/newrelic: description: Export to New RelicConseil
Installation mode note: The version and autoscaling fields behavior depends on your fleet's installation mode:
- With Flux: These fields are fully managed through the UI. Changes deploy automatically to all clusters in the fleet.
- Without Flux: These fields can be set during initial installation to configure the Horizontal Pod Autoscaler (HPA). However, post-installation changes via the UI are ignored. Only the
configuration.simplified/v2section (pipeline rules) continues to deploy automatically viaConfigMap. You must manually update scaling via HPA and versions via Helm upgrades. Refer to Manage gateway without Flux for details.
Structure de niveau supérieur
version: Version du format de configuration (actuellement"2.0.1")autoscaling: Configuration de la mise à l'échelle des réplicas du gatewayconfiguration.simplified/v2: Couche d'abstraction simplifiée pour définir des pipelines de télémétrietroubleshooting: Paramètres de débogage
Hiérarchie de configuration
The gateway configuration follows a directed acyclic graph (DAG) structure where each step defines its behavior and points to the next step in the pipeline using the output field. This creates an explicit data flow: data enters through receivers, flows through processors (transform, filter, sample), and exits through exporters.
Conventions de nommage des étapes
Récepteurs :
receivelogs,receivemetrics,receivetracesProcesseurs : format
processortype/TelemetryType:- Transformation :
transform/Logs,transform/Metrics,transform/Traces - Filtre :
filter/Logs,filter/Metrics,filter/Traces - Échantillonnage :
probabilistic_sampler/Logs,probabilistic_sampler/Traces
- Transformation :
Exportateurs :
nrexporter
Configurations du processeur
Gateway prend en charge trois principaux types de processeurs pour transformer, filtrer et échantillonner les données de télémétrie.
Transformateur de processeur
Utilisé pour modifier, enrichir ou analyser la télémétrie à l'aide d'OTTL (OpenTelemetry Transformation Language).
Champs de configuration :
- metric_statements : Tableau pour les transformations de métriques (contexte : métrique)
- log_statements : Tableau pour les transformations de logs (contexte : log)
- trace_statements : Tableau pour les transformations de trace (contexte : span)
Processeur de filtre
Utilisé pour supprimer des enregistrements de télémétrie en fonction d'expressions booléennes.
Champs de configuration :
- logs : Tableau d'expressions booléennes OTTL pour le filtrage des logs
- spans : Tableau d'expressions booléennes OTTL pour le filtrage des métriques/traces
Processeur d'échantillonnage
Utilisé pour implémenter une logique d'échantillonnage probabiliste.
Champs de configuration :
global_sampling_percentage : Taux d'échantillonnage par défaut (0-100)
conditionalSamplingRules : Tableau de règles conditionnelles
- nom : Identifiant de la règle
- description : Description lisible par l'humain
- sampling_percentage : Taux d'échantillonnage pour les données correspondantes (0-100)
- source_of_randomness : Champ à utiliser pour l'aléatoire (généralement trace.id)
- condition : Expression de correspondance d'attribut
Référence des champs
Champs de premier niveau
| Champ | Type | Requis | Défaut |
|---|---|---|---|
| version | chaîne | Oui | - |
| autoscaling.minReplicas | entier | Non | 6 |
| autoscaling.maxReplicas | entier | Non | 10 |
| autoscaling.targetCPUUtilizationPercentage | entier | Non | 60 |
| configuration.simplified/v2 | objet | Oui | - |
| dépannage.proxy | booléen | Non | false |
| troubleshooting.requestTraceLogs | booléen | Non | false |
Conseil
Installation mode note: The version and autoscaling fields behavior depends on your fleet's installation mode:
- With Flux: These fields are fully managed through the UI. Changes deploy automatically to all clusters in the fleet.
- Without Flux: These fields can be set during initial installation to configure the Horizontal Pod Autoscaler (HPA). However, post-installation changes via the UI are ignored. Only the
configuration.simplified/v2section (pipeline rules) continues to deploy automatically viaConfigMap. You must manually update scaling via HPA and versions via Helm upgrades. Refer to Manage gateway without Flux for details.
Champs de l'étape
| Champ | Type | Requis | Description |
|---|---|---|---|
| description | chaîne | Recommandé | Description lisible par l'homme |
| configuration | objet | Conditionnel | Requis pour les processeurs, omettre pour les récepteurs/exportateurs |
| sortie | éventail | Oui | Noms des étapes suivantes (vide [] pour les exportateurs) |
Conventions de nommage des champs
- Respectez la casse exacte des exemples (YAML est sensible à la casse).
Le tableau de sortie de chaque étape spécifie la ou les étapes suivantes.
Validation et déploiement
- Validez la syntaxe avec un linter YAML.
- Déployez d'abord dans un environnement de non-production.
- Confirmez que la télémétrie atteint correctement New Relic.
- Téléversez la configuration via l'interface utilisateur du gateway.
Ressources supplémentaires
- https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/ottlfuncs/README.md
- https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor
- https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor
- https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/probabilisticsamplerprocessor