Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
Avec vos données d’ingestion correctement cartographiées, vous avez la possibilité de commencer à optimiser votre télémétrie pour réduire vos données d’ingestion redondantes et diminuer vos coûts d’ingestion. La première étape consiste à créer un plan d’optimisation, puis à utiliser des techniques d’optimisation des données pour mettre ce plan en action.
Comprendre vos objectifs d'observabilité
L’un des éléments les plus importants du framework de gouvernance de l’ingestion de données est de créer des moteurs de valeur d’observabilité. Ils vous aident à aligner vos données sur des mesures concrètes que vous pouvez utiliser pour mesurer leur importance (ou leur redondance) par rapport à vos objectifs.
Ils vous aident également à comprendre vos objectifs lorsque vous devez configurer une nouvelle télémétrie à l’avenir. Lorsque vous le faites, vous voudrez comprendre ce qu’il apporte à votre système d’observabilité global pour éviter tout chevauchement inutile. Si vous vous retrouvez à créer de nouvelles données télémétriques qui ne correspondent à aucun des objectifs ci-dessous, cela peut être un bon signe que les données ne sont pas nécessaires et que vous pouvez éviter de les créer pour contribuer à réduire les coûts :
Respect d'un SLA interne
Respect d'un SLA externe
Soutenir l'innovation en matière de fonctionnalités (tests de performance et d'adoption A/B)
expérience client de suivi
Tenir les fournisseurs et prestataires de services internes à leur SLA
suivi des processus métier santé
Autres exigences de conformité
L'alignement sur ces objectifs vous permet de prendre les bonnes décisions en matière de priorisation de la valeur et aide à guider les équipes pour savoir par où commencer lors de la mise en œuvre de nouvelles plateformes et de nouveaux services.
Développer un plan d'optimisation
Une fois que vous avez compris vos objectifs, il est temps de mettre en place un plan d’optimisation. Ce plan vous aidera à mesurer la valeur de vos données ingérées et vous aidera à trouver les données que vous pouvez exclure en toute sécurité pour réduire les coûts.
Pour cette section, nous partirons de deux hypothèses fondamentales :
Nous vous proposons ci-dessous trois exemples de la manière dont vous pouvez évaluer votre propre ingestion de télémétrie et prendre les bonnes décisions en fonction des besoins de votre organisation. Bien que chacun de ces exemples se concentre sur un seul facteur de valeur, la plupart des instruments fournissent des données sur de nombreux domaines de valeur.
Un compte ingère environ 20 % de plus que ce qui avait été budgété. Un responsable leur a demandé de trouver un moyen de réduire la consommation. Leur facteur de valeur le plus important est Uptime, performance, and reliability.
Logs (développement, simulation, production - y compris débogage)
Plan d'optimisation
Omettre les logs de débogage (sachant qu'ils peuvent être activés en cas de problème), ce qui permet d'économiser 5 %.
Omettez plusieurs Kubernetes métriques d'état qui ne sont pas nécessaires pour afficher cluster Kubernetes l'explorateur , ce qui permet d'économiser 10 %.
Laissez tomber certains événements de navigateur personnalisés qu'ils collectaient lorsqu'ils testaient une nouvelle fonctionnalité, économisant 10 %.
Après avoir exécuté ces changements, l'équipe est à 5 % en dessous de son budget et a libéré de l'espace pour faire un pilote NPM, accomplissant ainsi la tâche qui lui a été assignée par son manager.
Résultat final
5% en dessous de leur budget initial
Marge de manœuvre créée pour un pilote NPM qui répond aux objectifs de temps de disponibilité, de performance et de fiabilité
Perte minimale de temps de disponibilité et de fiabilité observabilité
Une équipe responsable d'une nouvelle plateforme orientée utilisateur mettant l'accent sur et monitoring des navigateurs fonctionne à 50 % au-dessus du budget. Ils devront adapter leur ingestion, mais ils sont déterminés à ne sacrifier aucune observabilité Customer experience .
Leur patrimoine comprend :
Applications mobiles
Navigateur
APM
Tracing distribué
infrastructure sur 30 hôtes, incluant des échantillons de processus
monitoring sans serveur pour certains processus asynchrones backend
Logs de leur fonction sans serveur
Diverses intégrations cloud
Plan d'optimisation
Omettez les logs sans serveur, qui sont redondants pour leurs besoins en raison de l'intégration Lambda .
Réduisez le taux d’échantillonnage du processus sur leurs hôtes à toutes les minutes.
Supprimer les exemples de données de processus dans les environnements de développement.
Désactivez l'intégration EC2 qui est hautement redondante avec les autres monitoring deinfrastructure fournies par l'agent d'infrastructure New Relic.
Résultat final
5% de plus que leur budget initial
Suffisant pour les faire passer à travers la haute saison
Aucune perte d'observabilité de l'expérience client
Après avoir effectué les changements, ils n'ont désormais dépassé que de 5 % leur budget initial et concluent que cela est suffisant pour traverser la haute saison.
Une équipe est en train de refactoring un grand monolithe Python en quatre microservices. Le monolithe partage infrastructure avec la nouvelle architecture comprenant une base de données clients et une couche de cache. Ils ont dépassé de 70 % le budget prévu et disposent de deux mois avant de pouvoir officiellement démanteler le monolithe.
Leur patrimoine comprend :
Kubernetes monitoring (microservices)
monitoring de l'hôte New Relic (monolithe)
APM (microservices et monitoring d'hôte)
Tracing distribué (microservices et monitoring des hôtes )
Postgresql (partagé)
Redis (partagé)
MSSQL (future base de données pour l'architecture des microservices)
Logging de l'équilibreur de charge (microservices et monitoring de l'hôte)
Plan d'optimisation
Configurez le logging de l'équilibreur de charge pour monitorer uniquement les codes de réponse 5xx .
Définissez le taux d'échantillonnage personnalisé sur ProcessSample, StorageSample et NetworkSample sur 60 s pour les hôtes exécutant le monolithe
Désactivez monitoring MSSQL car la nouvelle architecture ne l'utilise pas.
Désactivez le tracing distribué pour le monolithe car il est beaucoup moins utile qu'il ne le sera pour l'architecture des microservices.
Résultat final
1% en dessous de leur budget initial
Aucune perte d'observabilité Innovation and growth
Conseil
Nous vous recommandons de suivre le plan dans un outil de gestion des tâches pour vous aider à gérer le plan d'optimisation et à comprendre l'effet de chaque tâche d'optimisation. Vous pouvez utiliser ce modèle de plan d’optimisation des données pour vous aider.