Des mesures et une surveillance efficaces jouent un rôle clé dans un développement de haute qualité, la correction de bogues et la gestion des demandes et des incidents des utilisateurs. Chez Social Discovery Group, nous utilisons une gamme diversifiée d'outils pour évaluer les performances de nos produits.  Dans cet article, nous partagerons quelques astuces sur la façon dont nous avons réussi à créer un système stable de surveillance et de métrique des applications et à réduire le temps de détection des bugs sur nos produits avec l'aide de Datadog.  Les produits SDG aident plus de 250 millions de personnes à se connecter et à établir des relations dans le monde, et notre base d'utilisateurs ne cesse de croître. Le principal facteur de ce succès est notre capacité à répondre rapidement aux besoins des utilisateurs. Nous avons beaucoup d'expérience avec divers systèmes de surveillance, dont Datadog. Voici pourquoi:  Actuellement, Datadog propose une variété d'options d'intégration avec des systèmes à différents niveaux. Vous pouvez explorer ces fonctionnalités   . ici  Datadog fournit une documentation complète pour configurer les intégrations avec divers services.  Nous avons réussi à construire de solides relations de partenariat.  Nous partageons ici notre expérience dans la mise en place et la configuration des métriques APM pour les applications au sein de notre cluster Kubernetes pour Datadog. L'article ne couvrira pas le déploiement de projets dans AKS, le processus CI/CD et d'autres détails DevOps.  Au lieu de cela, nous nous concentrerons sur les points les plus subtils de la configuration de la surveillance Datadog pour les métriques APM.  La pile technologique utilisée : Azure Services, Azure Kubernetes Service (AKS), ASP .Net Core 7, Datadog.  Pour surveiller les applications et les services, nous utilisons l'agent Datadog déployé au sein du cluster via une charte Helm avec des paramètres supplémentaires du fichier values.yaml. Dans le fichier de configuration principal de l'agent, vous devrez activer le module DogStatsD et spécifier le port (la valeur par défaut est 8125).  Pour les données envoyées depuis un hôte externe, l'agent Datadog nécessite la configuration suivante : dogstatsd_non_local_traffic : true et apm_non_local_traffic : true. Voici le fichier values.yaml pour l'un des clusters, avec certaines variables transmises au stade du déploiement. Le déploiement est réalisé avec Azure Devops.   " datadog: apiKey: #{apiKey}# appKey: #{appKey}# clusterName: #{ClusterName}# kubeStateMetricsEnabled: true clusterChecks: enabled: true dogstatsd: useSocketVolume: false nonLocalTraffic: true collectEvents: false apm: portEnabled: true #тут обязательно включить env: - name: "DD_KUBELET_TLS_VERIFY" value: "false" systemProbe: collectDNSStats: false orchestratorExplorer: enabled: false clusterAgent: image: repository: public.ecr.aws/datadog/cluster-agent tag: #{tag}# admissionController: enabled: false agents: image: repository: public.ecr.aws/datadog/agent tag: #{tag}# doNotCheckTag: true clusterChecksRunner: image: repository: public.ecr.aws/datadog/agent tag: #{tag}# "  Ensuite, vous devez préciser l'adresse de l'agent pour transmettre les métriques à Datadog dans les paramètres de l'application. Les tableaux de bord pour la surveillance des applications sont basés sur les métriques utilisées en interne ; ils devaient être créés indépendamment.  Pour mettre en place la surveillance des services ASP.Net, nous avons utilisé la documentation officielle accessible par le   . lien  L'agent étant déjà configuré, l'une des méthodes consistait à ajouter les lignes nécessaires à la création de l'image et à transmettre les variables dans le système CI/CD : DD_ENV, DD_SERVICE, DD_AGENT_HOST, pour spécifier respectivement l'environnement, le nom du service et l'adresse de l'agent. . Nous devons également ajouter les éléments suivants aux fichiers docker pour les services :   " RUN TRACER_VERSION=$(curl -s \https://api.github.com/repos/DataDog/dd-trace-dotnet/releases/latest | grep tag_name | cut -d '"' -f 4 | cut -c2-) \ && curl -Lo /tmp/datadog-dotnet-apm.deb https://github.com/DataDog/dd-trace-dotnet/releases/download/v${TRACER_VERSION}/datadog-dotnet-apm_${TRACER_VERSION}_amd64.deb # Copy the tracer from build target COPY --from=build /tmp/datadog-dotnet-apm.deb /tmp/datadog-dotnet-apm.deb # Install the tracer RUN mkdir -p /opt/datadog \ && mkdir -p /var/log/datadog \ && dpkg -i /tmp/datadog-dotnet-apm.deb \ && rm /tmp/datadog-dotnet-apm.deb # Enable the tracer ENV CORECLR_ENABLE_PROFILING=1 ENV CORECLR_PROFILER={846F5F1C-F9AE-4B07-969E-05C26BC060D8} ENV CORECLR_PROFILER_PATH=/opt/datadog/Datadog.Trace.ClrProfiler.Native.so ENV DD_DOTNET_TRACER_HOME=/opt/datadog ENV DD_INTEGRATIONS=/opt/datadog/integrations.json "  Cette méthode fonctionne, mais elle ne semble pas être la solution la plus optimale. Nous avons décidé d'aller plus loin et avons ajouté les éléments suivants aux déploiements de nos services :  " metadata.labels: tags.datadoghq.com/env: feature tags.datadoghq.com/service: service_name tags.datadoghq.com/version: '1488' spec.template.metadata.labels: admission.datadoghq.com/config.mode: service admission.datadoghq.com/enabled: 'true' tags.datadoghq.com/env: feature tags.datadoghq.com/service: service_name tags.datadoghq.com/version: '1111' spec.template.metadata.annotations: admission.datadoghq.com/dotnet-lib.version: v2.38.0 spec.template.spec.containers.name.env: - name: DD_TRACE_AGENT_URL value: datadog-agent.monitoring - name: DD_TRACE_STARTUP_LOGS value: 'true' - name: DD_LOGS_INJECTION value: 'true' - name: DD_RUNTIME_METRICS_ENABLED value: 'true' - name: DD_PROFILING_ENABLED value: 'true' - name: DD_APPSEC_ENABLED value: 'true' "  C'est ce qui a changé chez les agents :   " datadog: apm: socketEnabled: true portEnabled: true enabled: true clusterAgent: admissionController: enabled: true mutateUnlabelled: false providers: aks: enabled: true "  Après toutes ces étapes, les données contenant des métriques très détaillées pour tous les services ont commencé à circuler dans Datadog sous la section APM -> Services, et les graphiques ont été automatiquement affichés.   Nous avons dû bricoler les paramètres d'annotations pour la deuxième méthode ; tout n’a pas commencé à fonctionner correctement tout de suite.  Concernant le système de notification, il convient de mentionner qu'il est convivial et intuitif dans Datadog. Les notifications sont créées dans la section "Moniteurs -> Gérer les moniteurs".   Les améliorations que nous avons décrites ci-dessus ont donné plusieurs résultats précieux. Nous comprenons désormais mieux comment notre système fonctionne et s’adapte aux différents changements.  De plus, nous avons mis en place un système stable de surveillance et de métrique des applications qui fonctionne indépendamment des versions de services, contribuant ainsi à réduire les délais de détection des bogues.  Ceci, à son tour, nous a permis d’optimiser nos services et d’améliorer la vitesse de développement et la qualité globale du système.

Comment utiliser Datadog pour l'application APM Metrics

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Télégramme : le pont de Crypto Island vers le continent

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Télégramme : le pont de Crypto Island vers le continent

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps