Environnements de projet

Configurez les environnements de déploiement acceptés par votre projet et comprenez comment Lyncea route chaque log vers le bon.

Comment fonctionnent les environnements

Chaque projet dispose d'une allowlist d'environnements — l'ensemble des valeurs de deployment.environment qu'il acceptera dans les logs entrants. Les trois valeurs disponibles sont dev, staging et prod. Les trois sont activées par défaut ; vous pouvez restreindre la liste à la création du projet ou la modifier ultérieurement.

Déclarer l'environnement dans vos logs

Lyncea lit l'attribut deployment.environment dans la section resource de chaque enregistrement de log OTLP. Vous le définissez dans votre SDK ou OTel Collector — il n'est jamais déduit de la clé d'API.

processors:
  resource:
    attributes:
      - key: deployment.environment
        value: staging   # dev | staging | prod
        action: insert

service:
  pipelines:
    logs:
      processors: [resource]
      exporters: [otlphttp/lyncea]

Extrait du Resource à passer à votre setup OTel — l'export OTLP complet (processor + exporter) est couvert par l'exemple Pino de Premiers pas.

import { NodeSDK } from '@opentelemetry/sdk-node';
import { Resource } from '@opentelemetry/resources';

const sdk = new NodeSDK({
  resource: new Resource({
    'deployment.environment': 'staging', // dev | staging | prod
  }),
  // …logRecordProcessor / OTLPLogExporter à câbler ici pour exporter vers Lyncea.
});

from opentelemetry.sdk.resources import Resource
from opentelemetry.semconv.resource import ResourceAttributes

resource = Resource.create({
    ResourceAttributes.DEPLOYMENT_ENVIRONMENT: "staging",  # dev | staging | prod
})

Lyncea normalise automatiquement les alias courants : development → dev, production → prod.

Les logs dont la valeur de deployment.environment n'est pas dans l'allowlist du projet sont silencieusement rejetés — aucune erreur n'est renvoyée à l'émetteur. L'endpoint d'ingestion répond toujours 200 OK pour les payloads bien formés.

Clés d'API et environnements

Une clé d'API est scopée à un projet, pas à un environnement spécifique. Une seule clé peut envoyer des logs depuis tous les environnements acceptés par le projet — vous n'avez pas besoin d'une clé par environnement.

Ce que signifie le préfixe `live` / `test`

Les clés ont la forme lyn_live_xxx ou lyn_test_xxx. Ce préfixe reflète la plateforme Lyncea sur laquelle la clé a été émise :

Préfixe	Signification
`lyn_live_xxx`	Émise sur un déploiement Lyncea en production
`lyn_test_xxx`	Émise sur un déploiement sandbox / hors-production

Ce préfixe existe pour que les outils de détection de secrets (GitGuardian, TruffleHog, …) puissent identifier les clés exposées. Il ne détermine pas pour quels environnements dev / staging / prod la clé est valide.

Restreindre l'allowlist

Vous pouvez restreindre l'allowlist à tout moment depuis la console ou via l'API. Par exemple, un projet dédié à la surveillance de la production peut être limité à prod uniquement — tout log tagué dev ou staging envoyé à ce projet sera rejeté.

La restriction prend effet immédiatement pour les nouveaux lots de logs. Les logs déjà indexés ne sont pas affectés.

Référence API : POST /api/v1/projects · PATCH /api/v1/projects/{projectId}