Pipeline Control Gateway release notesRSS

New features and improvements

• Upgraded the embedded OpenTelemetry Collector from v0.139.0 to v0.156.0, incorporating the latest upstream components and resolving several CVEs flagged by vulnerability scanning.
• Migrated the gateway runtime to a hardened distroless/Alpine base image, with Docker base images now pinned by digest for reproducible, tamper-resistant builds.
• Upgraded to Go 1.25 and refreshed the golang.org/x/crypto dependency.
• Updated metering to retain the first data point in each series.

Fixes

• Added nil-safety checks to prevent potential panics.
• Prevented an unintended overwrite of the trace_id string value.

Security updates

• The gateway container now runs as a non-root user (UID 65532) by default, reducing its privilege footprint.
• The gateway now listens on the unprivileged port 8080 instead of 80. The Kubernetes Service, ingress, and Gloo upstream definitions are all updated to match. If you reference the gateway service port directly, update it to 8080.
• The gateway now masks sensitive values, such as license keys and API keys, in the logs it emits.
• The gateway now fails fast when the license key is missing or invalid.
• Applied additional security hardening and dependency fixes.

Mode Configuration only (without Flux)

• Vous pouvez désormais installer et utiliser le gateway Contrôle de pipeline sans nécessiter de contrôleurs Flux dans votre cluster. Dans ce mode, New Relic continue à gérer la configuration de votre pipeline (échantillonnage, filtrage, transformations) automatiquement via l'UI, tandis que vous gérez l'infrastructure du gateway (mise à l'échelle, versions) manuellement via Helm.
• Cela réduit l’empreinte des autorisations de cluster-admin à un accès aux ConfigMap limité à l’espace de nommage uniquement, ce qui le rend adapté aux environnements soumis à des restrictions de sécurité et axés sur la conformité.
• Un sidecar config-watcher intégré détecte automatiquement les changements de configuration poussés depuis l'interface utilisateur et redémarre les pods du gateway — aucun opérateur externe (tel que Stakater Reloader) n'est requis.
• Pour les instructions d’installation, consultez Installer le gateway sans Flux.

Mode de déploiement DaemonSet

• Ajout de la prise en charge pour déployer le gateway en tant que DaemonSet Kubernetes (un pod par nœud) au lieu d'un déploiement avec HPA. Ceci est utile pour les environnements qui nécessitent un traitement de la télémétrie au niveau du nœud ou une allocation cohérente des ressources par nœud.
• Activez le mode DaemonSet en définissant daemonset.enabled: true dans vos valeurs Helm. Le mode DaemonSet prend également en charge le sidecar config-watcher et customConfigMap pour les installations de configuration uniquement.
• Les modes DaemonSet et déploiement sont mutuellement exclusifs — le chart utilise des gardes conditionnelles pour s'assurer qu'un seul mode est actif à la fois.

Prise en charge multi-flottes

• Vous pouvez désormais créer et gérer plusieurs flottes de gateways au sein d'une seule organisation. Cela permet à des unités commerciales ou à des environnements distincts (par exemple, prod vs simulation) de maintenir des règles d'échantillonnage, de filtrage et de transformation indépendantes.
• Naviguez facilement entre différentes configurations à l'aide de la nouvelle liste déroulante du sélecteur de flotte dans l'interface utilisateur de Contrôle de pipeline.

Schéma YAML mis à jour

• Migré vers une configuration simplifiée qui supprime l'imbrication spécifique aux signaux (par exemple, logs:, spans:) au profit d'un éventail de règles directes, rendant la configuration plus plate et plus facile à lire.
• Pour les processeurs de filtre, le nouveau schéma prend en charge un champ context explicite. Cela permet un ciblage plus précis des sous-types de données, tels que les points de données de métrique et les événements de span.

UX de déploiement améliorée

• La nouvelle page de déploiement renseigne désormais automatiquement les valeurs par défaut pour le nom et la description du déploiement, réduisant considérablement les étapes manuelles requises pour livrer les modifications.
• Ajout d’un aperçu côte à côte des différences de configuration pour les processeurs de transformation. Cela vous permet de comparer votre nouvelle logique YAML à la version actuelle avant de finaliser un déploiement.

Notes de version du gateway Pipeline Control - v2.0.1

Débogage

Correctif pour l'environnement UE

Résolution d'un problème affectant le déploiement et le fonctionnement de Pipeline Control Gateway dans les environnements de l'UE. Ce correctif assure une connectivité et un routage des données appropriés pour les instances basées dans l'UE.

Notes de version du gateway Pipeline Control - v2.0.0

Mis à jour vers OpenTelemetry Collector v0.139.0

Cette version est basée sur OpenTelemetry Collector v0.139.0, apportant les dernières améliorations de stabilité et les fonctionnalités du projet en amont. Cette mise à niveau permet de nouvelles capacités de traitement des données non disponibles dans les versions précédentes du gateway.

Nouvelles capacités du processeur

Ajout de trois nouveaux processeurs qui vous donnent le contrôle de vos données de télémétrie avant qu'elles ne quittent votre infrastructure :

• Processeur d'échantillonnage: Réduisez le volume de données avec des règles d'échantillonnage probabilistes et conditionnelles
• Filter processor: supprimez des enregistrements entiers ou des attributs spécifiques en fonction de conditions booléennes OTTL
• Processeur de transformation: ajoutez, modifiez ou supprimez des attributs à l'aide de l'OpenTelemetry Transformation Language (OTTL)

Ces processeurs peuvent être chaînés pour créer des pipelines de traitement de données sophistiqués pour les métriques, les événements, les logs et les traces.

Options de configuration améliorées

• Interface utilisateur refondue: Nouvelle interface basée sur des formulaires pour créer et gérer des règles de processeur sans écrire de YAML
• Configuration YAML améliorée: Prise en charge de la configuration de processeur basée sur OTTL

Structure de la documentation améliorée

• Guides complets pour chaque type de processeur avec des exemples OTTL et des cas d'utilisation
• Distinction claire entre les règles de gateway (dans votre infrastructure) et les règles cloud (dans l'infrastructure de New Relic)
• Ressources de dépannage étendues pour l'installation du gateway, le monitoring de l'état de santé et les problèmes de flux de données
• Architecture de l'information réorganisée pour faciliter la navigation