Ce guide vous présente des idées et des processus pour automatiser votre installation et votre configuration New Relic afin de maximiser la valeur que vous obtenez de l'observabilité. Cela fait partie de notre série sur la maturité de l'observabilité.
Présentation
Observability as code est un terme utilisé pour décrire le processus d'automatisation de la configuration de vos outils d'observabilité, de manière cohérente, contrôlée et automatisée, pour vous aider à tirer le maximum de valeur de vos données télémétriques. Cette ressource se concentrera sur cette tâche pour votre implémentation New Relic.
Pourquoi devriez-vous utiliser ce guide ?
À mesure que vos technologies d'infrastructure, d'application et de service évoluent, leur échelle et leur complexité augmentent, ce qui accroît le volume de données collectées à partir des outils d'instrumentation (y compris New Relic) et le défi associé à la compréhension des données, à leur mise en contexte et à la conduite d'actions à partir de celles-ci.
L'utilisation de notre méthodologie d'observabilité en tant que code pour automatiser la configuration de New Relic répond à ce défi, aidant l'organisation à accélérer l'adoption, à améliorer la stabilité et à favoriser une meilleure gouvernance.
Ce guide fournit des conseils sur la manière d'aborder la mise en œuvre de l'observabilité en tant que code et propose des conseils de bonnes pratiques et des exemples de référence pour vous permettre de créer et de maintenir votre plateforme New Relic à grande vitesse et à grande échelle. Il exploite les outils d'automatisation du workflow et de provisionnement pour permettre aux organisations de faire évoluer leurs pratiques, tout en réduisant les efforts manuels et en améliorant la prestation de services. Une mise en œuvre réussie de ces idées devrait apporter une réelle valeur ajoutée à la fois à l’organisation informatique elle-même et aux entreprises qu’elle soutient.
Résultats souhaités
Réduire les coûts et les risques associés à la mise en œuvre et à la maintenance d’une solution d’observabilité configurée de manière optimale dans des environnements en évolution rapide et à grande échelle.
Plus précisément, certains des avantages de l’adoption de l’observabilité en tant que pratiques de code sont les suivants :
Répétable, reproductible, réutilisable
La gestion des ressources New Relic via le code signifie qu'elles peuvent être facilement répétées, mises à l'échelle et mises à jour en masse. L'utilisation d'une approche modulaire avec des outils de provisionnement comme Terraform permet de partager et de déployer rapidement et facilement des ensembles de ressources tels que des tableaux de bord, des alertes et des charges de travail, accélérant ainsi le temps de démarrage et améliorant les normes à l'échelle de l'organisation.
Travail réduit
La création et la maintenance des ressources New Relic gérées via le code sont nettement moins fastidieuses que leur gestion manuelle via l'interface utilisateur, en particulier lorsque l'on travaille à grande échelle. Notre interface se prête bien à la découverte et aux tests, mais les modifications apportées aux ressources gérées par le code peuvent être appliquées en masse, réduisant ainsi considérablement le temps d'administration des ressources. Une approche courante consiste à développer des alertes et un dashboard au sein de l'interface utilisateur, puis, lorsqu'ils sont considérés comme suffisamment matures, à les migrer vers des ressources gérées par le code.
Documentation et contexte
La grande variété de ressources qui peuvent être configurées dans New Relic peut rendre difficile la compréhension, lorsqu'on examine une seule ressource, pourquoi elle a été créée ou configurée comme elle l'a été. La configuration via le code permet d'associer des commentaires et une documentation qui aident à expliquer pourquoi certains choix ont pu être faits, quand et par qui.
Historique vérifiable
Bien qu'il soit possible de comprendre qui a apporté des modifications aux ressources New Relic via l'événement NRAuditEvent , cela ne fournit pas beaucoup d'informations sur why les modifications apportées, leur état précédent ou la personne qui a approuvé les modifications. La gestion des ressources via le code en tandem avec un workflow de provisionnement basé sur l'approbation automatisée permet une visibilité beaucoup plus claire des modifications et une gouvernance améliorée tout en fournissant des méthodes de restauration et de récupération.
Sécurité
L'observabilité as code permet des contrôles plus stricts sur l'utilisation de l'API clé pour la gestion des ressources New Relic. La sécurité est améliorée en réduisant le nombre de clés API en circulation et en garantissant la mise en place d'une gouvernance adéquate concernant leur création et leur diffusion. En dissuadant les utilisateurs d’utiliser leurs propres clés, en particulier dans le cadre d’un workflow automatisé, la surface d’exposition à une violation de clé ou à une corruption involontaire est réduite.
Changements delta efficaces
Des outils de provisionnement comme Terraform permettent d’apporter des modifications delta aux ressources existantes. Cela rend les mises à jour rapides et efficaces car seuls les attributs des ressources qui doivent être modifiés sont modifiés, avec une destruction et une recréation minimales des ressources. Ceci est important car cela garantit que le GUID des ressources telles que le dashboard et les alertes ne sont pas modifiés lors de la mise à jour.
Réagir aux stimuli externes
La combinaison de l'observabilité en tant que code avec un workflow automatisé permet de créer et de modifier les ressources New Relic en fonction de stimuli externes tels que le déploiement d'une application, un événement infrastructure ou toute autre entrée de données. Par exemple, vous pouvez générer automatiquement un dashboard et des alertes qui comparent les principaux signaux dorés métriques entre la version du code sortie au moment de la diffusion.
Propriété contextuelle et packaging
La gestion des ressources dans le code permet de gérer ensemble les ressources associées. Il est plus facile de les comprendre et de les gérer en un seul endroit, dans le code, que lorsqu'ils sont distribués sur l'interface utilisateur. Par instance, cela permet à différentes équipes de gérer, de visualiser et de maintenir les ressources dans leur sphère d’influence et de ne pas avoir à rechercher les ressources qu’elles gèrent.
Reprise après sinistre
Il arrive parfois que des erreurs se produisent, que la mauvaise ressource soit mise à jour ou supprimée. Il est difficile de se remettre de ces situations avec une gestion manuelle des ressources, car il n'est pas facile de savoir ce qui existait avant ou même si la ressource a été modifiée ou perdue. L'observabilité en tant que code permet de se protéger contre ces problèmes en garantissant que toute ressource peut être recréée ou réinitialisée à la configuration attendue. Cela crée également une opportunité de détecter de manière proactive les dérives de configuration.
Rapidité de déploiement
L'observabilité en tant que code accélère la vitesse de déploiement en permettant à un ensemble commun de ressources d'être facilement partagé entre les équipes et utilisé pour bootstrap les outils d'observabilité. Cela est particulièrement évident dans les architectures de microservices où des architectures de déploiement d'applications similaires bénéficient de ressources New Relic basées sur des modules à l'emporte-pièce. La création de modules réutilisables gérés de manière centralisée contribue également à normaliser les approches communes des outils d’observabilité.
indicateurs de performances clés
La maturité de votre déploiement d’observabilité en tant que code peut être évaluée de plusieurs manières. En règle générale, plus les ressources d’un environnement gérées via du code sont nombreuses, plus le déploiement est mature. Voici quelques indicateurs clés de performance :
Prérequis
Avant de vous lancer dans une implémentation Observability as code avec New Relic, vous devez vous familiariser avec nos principes fondamentaux disponibles auprès de New Relic University.
Vous devriez également :
- Choisissez et familiarisez-vous avec un outil de provisionnement tel que Terraform
- Avoir accès à une plateforme CI/CD (intégration et livraison continue) qui prend en charge le workflow d'automatisation
- Familiarisez-vous avec la plateforme New Relic et les fonctionnalités de l'API
- Vous avez déterminé une convention ou une stratégie de balises et de dénomination pour vos ressources
- Décider de la stratégie de granularité des actifs pour déterminer les KPI
- Avoir préparé l'API clé du compte de service et un modèle d'autorisations pour appliquer les modifications des outils CI/CD (intégration et livraison continue)
Établir l'état actuel
Avant de vous lancer dans l’adoption de pratiques d’observabilité en tant que code, vous devez évaluer l’état actuel. Vous pouvez tirer parti des concepts d’évaluation de la maturité décrits ci-dessus pour déterminer le niveau de maturité de vos environnements et hiérarchiser les environnements à traiter en premier.
Processus d'amélioration
Vous avez peut-être décidé d'adopter l'observabilité en tant que code avec New Relic, mais vous ne savez pas comment commencer ou vous souhaitez éviter les impasses et les pièges courants. Nous fournissons ici des guides sur les bonnes pratiques, des conseils et des exemples de référence pour vous aider à adopter en toute confiance l'observabilité en tant que code.
Isolation des ressources en équipe
De nombreuses équipes peuvent être impliquées dans la gestion des ressources dans un seul compte New Relic ou sur plusieurs comptes. Notre pratique d’observabilité en tant que code offre un moyen de contrôler plus étroitement l’isolement, l’accès et la gestion des ressources. Restreindre l'accès en écriture aux individus et imposer les modifications à apporter via le code géré permet aux équipes de travailler en toute sécurité dans le même espace sans risquer d'affecter les ressources des autres.
Par exemple, vous pouvez disposer d'une infrastructure équipe partagée qui gère infrastructure cloud au nom de plusieurs équipes d'application qui monitorent chacune leurs applications dans différents comptes New Relic. Cette équipe d'infrastructure partagée gérerait ses propres ressources New Relic au sein de ces comptes, parallèlement aux propres ressources des équipes d'application. Restreindre l'accès en écriture des utilisateurs et garantir que les ressources clés ne sont gérées que via un workflow d'observabilité en tant que code permet aux ressources des équipes de vivre ensemble en harmonie et réduit la possibilité de modifications non autorisées ou involontaires.
Ce diagramme illustre comment le pipeline CI/CD pour différentes équipes peut avoir accès à la gestion de ressources isolées dans plusieurs comptes qui se chevauchent.
Clés API
La gestion des ressources à l'aide de notre API NerdGraph ou via des outils de provisionnement tels que Terraform nécessite une clé utilisateur New Relic. Les clés utilisateur sont associées à un utilisateur spécifique et héritent des autorisations de ce utilisateur.
Comptes de service
La création de clés d'utilisateur New Relic par rapport à un utilisateur humain réel peut entraîner des problèmes avec le pipeline automatisé. Par exemple, si les autorisations de cet utilisateur changent dans le cadre d'un déménagement d'équipe ou si l'utilisateur quitte l'organisation, un pipeline d'automatisation qui s'appuie sur lui pourrait échouer.
Envisagez de créer des utilisateurs de « compte de service » gérés par une équipe de gestion centrale et spécifiquement créés à des fins d'automatisation. Ces équipes peuvent ensuite générer et gérer des clés pour les diffuser à d’autres équipes de mise en œuvre. Les comptes de service peuvent être utilisés pour générer plusieurs clés, garantissant ainsi que les équipes de mise en œuvre n'utilisent que leur propre clé. Les clés gérées de cette manière sont plus faciles à auditer et contribuent à garantir que les autorisations sont définies correctement et restent stables. Les individus doivent être encouragés à ne pas utiliser leurs propres clés d’utilisateur, sauf à des fins de développement et de test.
Génération automatisée d'API de clés
Les clés utilisateur New Relic peuvent être générées via NerdGraph, permettant un provisionnement de clés à la demande entièrement automatisé. Cela pourrait être utilisé pour automatiser la génération de clés via un portail ou un flux de processus de service.
Outils d'automatisation
Nous vous recommandons d'utiliser Terraform pour gérer l'approvisionnement de vos ressources New Relic. Des outils comme Terraform vous permettent de configurer des ressources dans le code sans avoir à vous soucier des API à appeler ou de la manière de conserver un enregistrement de ce qui a été créé.
New Relic maintient activement notre propre fournisseur New Relic Terraform. requests de fonctionnalités et les problèmes peuvent être soumis dans notre référentiel open source Terraform GitHub.
Gestion de l'État
Lors de la gestion des ressources New Relic avec Terraform, il est important de conserver un enregistrement stable de l'état de Terraform. Idéalement, l'état doit être stocké en toute sécurité dans un emplacement distant, être contrôlé par version et tirer parti du verrouillage d'état afin de garantir la stabilité.
Identifier les ressources gérées
Il est important que vous puissiez facilement identifier les ressources dans New Relic qui sont gérées par le code. Cela permet non seulement d'évaluer le KPI de maturité, mais aide également les utilisateurs interagissant avec l'interface utilisateur à comprendre quelles ressources sont gérées par le code et qui ne doivent donc pas être modifiées manuellement.
Il est recommandé de développer une norme cohérente à l’échelle de l’organisation pour les ressources de balises et de dénomination gérées dans le code. Vous devez au moins tag et identifier qu’une ressource est gérée par code. Par exemple, vous pouvez ajouter la tag codeManaged=true et peut-être un suffixe ou un préfixe au nom de la ressource (par exemple, « résumé des performances de la base de données [CM] ») pour aider à les identifier. De plus, vous devriez envisager d'étiqueter les ressources avec d'autres informations utiles, telles que l'équipe propriétaire, la source de la ressource ou la version du code, par exemple.
Gestion de grands ensembles de ressources
Chaque ressource configurée dans Terraform doit être actualisée et évaluée pour rechercher les modifications lorsque de nouvelles configurations sont appliquées. À mesure que la quantité de configuration augmente, la liste des ressources à vérifier s'allonge. Chaque vérification nécessite un appel d'API et par conséquent une configuration importante peut prendre un certain temps à se terminer et peut rencontrer des limites d'API si trop de requests sont effectuées en parallèle. Une approche consiste à réduire le nombre de ressources gérées au sein d’un seul état, en décomposant la configuration en parties. La réduction du parallélisme des requestsTerraform peut également atténuer les limitations des API.
Adopter une approche modulaire
Les modules sont le principal moyen de package et de réutiliser la configuration des ressources avec Terraform et peuvent être utilisés pour package n'importe quel nombre de ressources New Relic. Un packaging comme celui-ci permet un déploiement piloté par paramètres. Par exemple, vous pouvez avoir un module qui prend un nom d'application et crée un dashboard présentation, des signaux dorés, des alertes et un parcours synthétique, le tout en une seule opération.
Les modules Terraform peuvent être publiés dans des registres distants, permettant aux équipes de partager et de consommer des packages de ressources développés par d'autres équipes. Cela offre la possibilité de mettre en œuvre la normalisation et de déployer facilement des modifications et des améliorations contrôlées par version.
Référence d'implémentation
Workflow d'automatisation
Les workflow d'automatisation sont essentiels pour faire évoluer l'observabilité en tant que code vers les équipes et l'organisation. Il existe de nombreux outils et services CI/CD (intégration et livraison continue) disponibles qui peuvent piloter le workflow Terraform. Ils permettent de discuter et d’approuver les modifications de configuration tout en fournissant une piste vérifiable des modifications.
Nous vous recommandons d’adopter un workflow Terraform pour permettre aux équipes de travailler ensemble sur la configuration de New Relic. Un tel workflow exploite les capacités CI/CD (intégration et livraison continue) des systèmes de gestion de versions de code tels que GitHub, GitLab et Bitbucket pour planifier et appliquer automatiquement le code à l'aide de mécanismes d'approbation et de révision intégrés.
Ce diagramme illustre comment une modification est soulevée en tant que PR, qui est ensuite approuvée et fusionnée avec la PR principale pour déclencher le déploiement des ressources.
Exemples d'implémentations workflow
Les exemples de référence suivants montrent comment configurer un workflow Terraform dans un certain nombre de systèmes différents :
- Exemple d'actions GitHub: cet exemple montre comment utiliser les actions GitHub avec le stockage d'état sauvegardé par AWS S3.
- Exemple de pipeline GitLab: cet exemple montre comment utiliser un pipeline GitLab avec le stockage d'état http Gitlab.
- Exemple de pipeline Bitbucket: cet exemple illustre l’utilisation d’un pipeline Bitbucket avec un stockage d’état sauvegardé S3.
Épinglage de version
Lors de l'approvisionnement automatique de ressources via un workflow d'observabilité en tant que code, il est important de garantir que le workflow fonctionne de la même manière à chaque exécution. Nous vous recommandons d'épingler la version du fournisseur New Relic et de Terraform que vous avez utilisés, afin de garantir qu'aucune mise à niveau inattendue ne se produise et ne provoque une défaillance du pipeline. Si vous décidez de verrouiller les versions, vous devez périodiquement mettre à jour et tester les dernières versions. Vous pouvez en apprendre davantage sur la limitation des versions dans la documentation Terraform.
Détection de dérive de configuration
Comprendre la dérive de configuration est important pour garantir la stabilité et la fiabilité de votre plateforme d’observabilité. En fonction de votre stratégie de contrôle d'accès et d'autorisations, il est possible que les utilisateurs puissent modifier des ressources dans l'interface utilisateur qui sont également gérées par le code. La détection de cette dérive de configuration vous permet de comprendre les changements et de corriger la configuration si nécessaire.
Il existe deux principaux modes de fonctionnement :
- Detect and notify:Dans ce mode, la dérive est détectée et les opérateurs sont avertis. Toutefois, aucune modification corrective n’est effectuée automatiquement.
- Detect, remediate and notify:Dans ce mode, la dérive est détectée et, si possible, également corrigée automatiquement par le workflow.
Ce diagramme illustre comment un de configuration dérive workflow peut être implémenté. Les changements détectés sont signalés à New Relic où ils peuvent être alertés et suivis au fil du temps.
Exemple de référence de dérive de configuration
Cet exemple de référence exploite GitHub Actions pour planifier des opérations de plan Terraform régulières. Le nombre de modifications détectées est signalé à New Relic et la réapplication du Terraform peut éventuellement être lancée.
Exemple de dérive de configuration de Terraform
Conclusion
bonnes pratiques à adopter
- Définissez et mettez en œuvre clairement les KPI pour mesurer la maturité de l'observabilité en tant que code.
- Établir et communiquer l’état actuel avant de mettre en œuvre de nouvelles fonctionnalités d’observabilité en tant que code.
- Tirez parti de l’automatisation dans la mesure du possible pour accélérer la fourniture d’observabilité dans tous les environnements.
- Documentez automatiquement les ressources créées via le code.
- Suivre et résoudre les dérives de configuration.
- Favorisez la réutilisation étendue des actifs dans tous les environnements.
Réalisation de la valeur
À la fin de ce processus, vous devriez bénéficier des avantages suivants :
- Communiquez facilement et efficacement votre maturité actuelle en matière d’observabilité en tant que code.
- Réduisez le temps d'observabilité de vos environnements.
- Réduisez l’effort manuel requis pour mettre en œuvre l’observabilité et libérez du temps productif.
- Réduisez les risques opérationnels dans votre environnement de production.
- Améliorez la capacité à détecter et à résoudre les problèmes plus rapidement.
- Accélérez le temps de déploiement d’une nouvelle sortie.
- Rendez les données télémétriques plus exploitables pour votre organisation dans son ensemble.
- Améliorez la disponibilité et la prestation de vos services à l’entreprise.