Esta referência aborda a sintaxe YAML para usuários avançados que criam configurações de gateway personalizadas. Para informações conceituais, consulte Visão geral do Gateway. Para uma experiência guiada, use a IU do Gateway. Embora a IU do Gateway seja recomendada para a maioria dos usuários, a configuração YAML oferece controle total sobre a estrutura do pipeline de telemetria.
Estrutura YAML completa
As configurações do gateway usam um formato YAML declarativo:
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 RelicDica
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.
Estrutura de nível superior
version: Versão do formato de configuração (atualmente"2.0.1")autoscaling: Configuração de escalonamento de réplicas do Gatewayconfiguration.simplified/v2: Camada de abstração simplificada para definir pipelines de telemetriatroubleshooting: Configurações de depuração
Hierarquia de configuração
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.
Convenções de nomeação de etapas
Receptores:
receivelogs,receivemetrics,receivetracesProcessadores: formato
processortype/TelemetryType:- Transformar:
transform/Logs,transform/Metrics,transform/Traces - Filtro:
filter/Logs,filter/Metrics,filter/Traces - Amostragem:
probabilistic_sampler/Logs,probabilistic_sampler/Traces
- Transformar:
Exportadores:
nrexporter
Configurações do processador
O Gateway suporta três tipos principais de processadores para transformar, filtrar e amostrar dados de telemetria.
Processador de transformação
Usado para modificar, enriquecer ou analisar telemetria usando a OTTL (OpenTelemetry Transformation Language).
Campos de configuração:
- metric_statements: Array para transformações de métrica (contexto: métrica)
- log_statements: Array para transformações de log (contexto: log)
- trace_statements: Array para transformações de trace (contexto: span)
Processador de filtro
Usado para descartar registros de telemetria com base em expressões booleanas.
Campos de configuração:
- logs: Array de expressões booleanas OTTL para filtragem de logs
- spans: Array de expressões booleanas OTTL para filtragem de métricas/traces
Processador de amostragem
Usado para implementar lógica de amostragem probabilística.
Campos de configuração:
global_sampling_percentage: Taxa de amostragem padrão (0-100)
conditionalSamplingRules: Array de regras condicionais
- nome: Identificador da regra
- descrição: Descrição legível por humanos
- sampling_percentage: Taxa de amostragem para dados correspondentes (0-100)
- source_of_randomness: Campo a ser usado para aleatoriedade (geralmente trace.id)
- condição: Expressão de correspondência de atributo
Referência de campos
Campos de nível superior
| Campo | Tipo | Obrigatório | Padrão |
|---|---|---|---|
| versão | corda | Sim | - |
| autoscaling.minReplicas | inteiro | Não | 6 |
| autoscaling.maxReplicas | inteiro | Não | 10 |
| autoscaling.targetCPUUtilizationPercentage | inteiro | Não | 60 |
| configuration.simplified/v2 | objeto | Sim | - |
| troubleshooting.proxy | boleano | Não | false |
| troubleshooting.requestTraceLogs | boleano | Não | false |
Dica
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.
Campos da etapa
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
| descrição | corda | Recomendado | Descrição legível por humanos |
| configuração | objeto | Condicional | Obrigatório para processadores, omita para receptores/exportadores |
| saída | matriz | Sim | Nomes das próximas etapas (vazio [] para exportadores) |
Convenções de nomenclatura de campos
- Use as letras maiúsculas e minúsculas exatas dos exemplos (o YAML diferencia maiúsculas de minúsculas).
O array de saída de cada etapa especifica a(s) próxima(s) etapa(s).
Validação e implantação
- Valide a sintaxe com um linter YAML.
- Implante em um ambiente de não produção primeiro.
- Confirme se a telemetria chega ao New Relic corretamente.
- Faça o upload da configuração através da interface do gateway.
Recursos adicionais
- 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