L'un des principes clés garantissant l'exécution d'un système fiable consiste à obtenir des métriques qui comptent vraiment. Cela signifie qu'il faut mesurer à la fois ce qui est important pour l'entreprise et ce qui est important pour résoudre les problèmes. New Relic mesure ce qui compte grâce à New Relic. Cela comprend l'utilisation de nos agents, les objectifs de niveau de service (SLO) et les alertes.
Les agents APM de New Relic
Nos équipes d'ingénierie aiment exécuter le monitoring des performances des applications (APM) pour leurs services et tout le matériel est généralement monitoré en utilisant l'agent d'infrastructure New Relic. Cela crée un ensemble de métriques cohérent qui permet aux ingénieurs de passer d'une équipe à l'autre ou d'un service à l'autre et de toujours comprendre les métriques clés sur l'intégrité et la santé du système.
Les agents APM de New Relic sont minutieusement perfectionnés pour fournir les métriques clés nécessaires aux repérage et diagnostic des problèmes de service. Ces métriques clés comprennent le temps de réponse HTTP, les temps d'appel de la base de données et les temps d'appels HTTP externes.
De plus, si les équipes d'agent dédiées ajoutent souvent une nouvelle instrumentation à nos agents, d'autres équipes d'ingénierie — celles qui utilisent les agents pour monitorer leur propre infrastructure, base de données et services de streaming — ont aussi contribué à leur instrumentation. Un excellent exemple est l'instrumentation actuelle de Kafka dans l'agent Java. Cette instrumentation fut créée à l'origine en tant qu'extension de l'agent Java par une équipe New Relic qui exécutait de nombreux services de streaming Kafka essentiels. Après avoir été adoptée par de nombreuses équipes internes, l'instrumentation fut finalement ajoutée au produit APM. L'interface Kafka, qui affiche ces métriques, fut aussi créée par une équipe du produit APM en collaboration avec nos principales équipes Kafka et Services de streaming.
Une instrumentation efficace
Utilisation des dashboards et Nerdpacks pour ne plus devoir changer de contexte
Les équipes de New Relic sont formées pour réfléchir aux données d'observabilité pendant le développement. Outre l'instrumentation par défaut fournir par nos agents, les équipes d'ingénierie peuvent aussi créer une instrumentation personnalisée supplémentaire. Certaines équipes envoient une instrumentation personnalisée à New Relic en utilisant des agents APM. D'autres ont développé des bibliothèques pour envoyer l'instrumentalisation directement à nos points de terminaison publics des métriques, événements, logs et traces. Les exemples sur l'instrumentation personnalisée comprennent un événement New Relic pour chaque requête à la base de données New Relic (NRDB). Les équipes affichent alors ces événements personnalisés dans des dashboards ou des Nerdpacks (applications personnalisées). Ces applications personnalisées intègrent des instructions textuelles aux résultats des requêtes et visualisations en direct.
Par exemple, les problèmes de ralentissement du pipeline Kafka peuvent être diagnostiqués avec des vues sur un Nerdlet personnalisé, qui génère aussi automatiquement la commande nécessaire pour prolonger la rétention des données, transformant ainsi un processus manuel à plusieurs étapes en un seul copier-coller, tout en réduisant grandement le besoin de changement de contexte et en accélérant la résolution.
Objectifs de niveau de service
Comment atteindre les objectifs métier avec les SLO
Les objectifs de niveau de service (SLO) sont importants, car ils définissent et mesurent l'expérience client au cours d'une certaine période de temps. Ils sont essentiels à l'équilibre travail de fiabilité/nouvelle fonctionnalité. Chez New Relic, nous exigeons que toutes les équipes maintiennent un ensemble de SLO internes. Avant de mettre en place les SLO dans toute l'entreprise, nous nous sommes rendu compte que nos données télémétriques étaient extrêmement riches, mais qu'elles étaient aussi paramétrées pour le dépannage et non pour mesurer l'expérience client. Nous avons donc créé un programme d'amélioration des SLO qui a aidé les équipes à créer des SLO focalisés sur les clients avec des valeurs qui reflétaient la réalité du moment.
Grâce à ces mesures, nous avons pu partager avec l'entreprise les coûts d'exécution avec les SLO actuels et le travail requis pour augmenter les SLO. Les équipes qui ont le plus bénéficié des SLO surveillent ces derniers au quotidien et prennent des mesures correctives lorsque nécessaire. Elles ont non seulement amélioré l'expérience client, mais ont également réduit de manière significative la charge due aux alertes envoyées.
Alertes et Terraform
Comment automatiser des insights proactifs
Chez New Relic, nos équipes se servent de New Relic Alerting pour obtenir des notifications en cas d'anomalie système. Ainsi, les ingénieurs New Relic peuvent prendre des mesures rapidement pour atténuer toute dégradation potentielle du système. La plupart des équipes utilisent Terraform pour la création et la maintenance de leurs alertes de contrôle des versions. Elles emploient également les alertes facettées pour garantir que les alertes sont créées pour toute nouvelle cellule ou tout nouvel environnement. Vous trouverez ci-dessous un exemple d'alerte facettée sur un nom d’hôte :
SELECT latest(etcdServerProposalsFailedRate) FROM K8sEtcdSample WHERE clusterName = 'my-cluster' FACET hostname
Pour s'assurer que les équipes reçoivent les alertes adéquates, New Relic leur fournit un ensemble d'alertes recommandées dans ses Engineering Standards. Ces normes d'ingénierie incluent les alertes pour désactivation en cas de mémoire insuffisante (OOM), les pods en attente, la latence Kafka, les taux d’erreur, etc. Les dirigeants voient alors les alertes de leur équipe (car chaque alerte est enregistrée dans NRDB) et observent les tendances chaque semaine.