Aller au contenu
fernet.consultores

Splunk Observability Cloud

Observability Architecture.

Conception de l’architecture d’observabilité : agents, gateways, chemins de sortie, attributs communs et échantillonnage.

Le problème que nous résolvons.

Sans architecture claire, chaque serveur envoie ses données de son côté, les attributs ne coïncident pas entre équipes et la cardinalité explose. Le résultat est coûteux et difficile à corréler.

Ce qui est inclus.

  • Conception des collectors en mode agent et gateway
  • Chemins de sortie depuis des réseaux segmentés
  • Conventions d’attributs et de noms
  • Stratégie d’échantillonnage des traces
  • Document d’architecture revu avec vos équipes

Notre façon de travailler.

Cinq phases, toujours dans le même ordre. Sélectionnez-en une pour voir ce qui s’y passe. Dans les projets complets, elles s’inscrivent dans les étapes de notre méthode.

Nous examinons ce qui est surveillé aujourd’hui, avec quels outils, quels incidents sont passés inaperçus et ce que cela coûte.

Nous concevons la collecte avec OpenTelemetry : agents, gateways, chemins de sortie, attributs communs et échantillonnage.

Nous documentons agents, gateways, chemins de sortie, attributs communs et échantillonnage, avec des modèles de configuration.

Nous testons les chemins de sortie et la corrélation entre signaux dans un environnement pilote avant de généraliser la conception.

Nous ajustons cardinalité, échantillonnage et détecteurs selon l’usage réel pour contenir le coût et le bruit.

Compétences techniques.

  • Splunk Distribution of the OpenTelemetry Collector
  • Mode agent et gateway
  • Répartition de charge
  • Semantic conventions
  • Tail sampling
  • Intégrations cloud

Cas d’usage.

Environnements isolés

Faire sortir la télémétrie par un point unique et contrôlé.

Plusieurs clouds

Unifier la collecte sur AWS, Azure, Google Cloud et les centres de données.

Croissance prévue

Concevoir pour multiplier les services sans tout refaire.

Bénéfices pour votre organisation.

  • Corrélation entre signaux dès la conception
  • Coût de cardinalité maîtrisé
  • Un chemin de sortie unique et auditable
  • Base stable pour croître

Livrables.

  • Document d’architecture
  • Schémas des flux de données
  • Conventions d’attributs
  • Modèles de configuration

Questions fréquentes.

Pourquoi agent et gateway ?

L’agent collecte près de la source et le gateway concentre, filtre et constitue le seul point de sortie. Séparer les deux simplifie la sécurité et les changements.

Cela fonctionne-t-il pour des réseaux sans internet ?

Oui. C’est justement le cas où le gateway, derrière un répartiteur de charge ou un proxy, fait la différence.

Concevez-vous aussi la partie logs ?

Oui, pour que les logs partagent les attributs avec les métriques et les traces et puissent être corrélés.

Parlons de Architecture ?

Décrivez-nous votre situation. Si ce service ne correspond pas à votre besoin, nous vous le dirons ; sinon, nous vous proposerons une première étape concrète.

Demander ce service