Métricas e monitoramento eficazes desempenham um papel fundamental no desenvolvimento de alta qualidade, na correção de bugs e no tratamento de solicitações e incidentes de usuários. No Social Discovery Group, empregamos uma ampla gama de ferramentas para avaliar o desempenho de nossos produtos.  Neste artigo, compartilharemos alguns hacks de como conseguimos construir um sistema estável de monitoramento e métricas de aplicativos e reduzimos o tempo de detecção de bugs em nossos produtos com a ajuda do Datadog.  Os produtos ODS estão ajudando mais de 250 milhões de pessoas a se conectar e construir relacionamentos globalmente, e nossa base de usuários está em constante crescimento. O principal fator deste sucesso é a nossa capacidade de responder prontamente às necessidades dos usuários. Temos muita experiência trabalhando com diversos sistemas de monitoramento, inclusive o Datadog. Aqui está o porquê:  Atualmente, o Datadog oferece diversas opções de integração com sistemas em diferentes níveis. Você pode explorar esses recursos   . aqui  Datadog fornece documentação abrangente para configurar integrações com vários serviços.  Conseguimos construir fortes relações de parceria.  Aqui, estamos compartilhando nossa experiência na instalação e configuração de métricas APM para aplicativos em nosso cluster Kubernetes para Datadog. O artigo não abordará a implantação de projetos em AKS, o processo de CI/CD e outros detalhes de DevOps.  Em vez disso, nos concentraremos nos pontos mais delicados da configuração do monitoramento Datadog para métricas APM.  A pilha de tecnologia usada: Azure Services, Azure Kubernetes Service (AKS), ASP .Net Core 7, Datadog.  Para monitorar aplicativos e serviços, utilizamos o agente Datadog implantado no cluster por meio de um gráfico Helm com parâmetros adicionais do arquivo values.yaml. No arquivo de configuração do agente principal, você precisará habilitar o módulo DogStatsD e especificar a porta (o padrão é 8125).  Para os dados enviados de um host externo, o agente Datadog requer a seguinte configuração: dogstatsd_non_local_traffic: true e apm_non_local_traffic: true. Aqui está o arquivovalues.yaml para um dos clusters, com algumas variáveis sendo passadas no estágio de implantação. A implantação é produzida com 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}# "  Em seguida, você precisa especificar o endereço do agente para transmissão de métricas ao Datadog nas configurações do aplicativo. Os dashboards para monitoramento de apps são baseados nas métricas utilizadas internamente; eles tiveram que ser criados de forma independente.  Para configurar o monitoramento dos serviços ASP.Net, utilizamos a documentação oficial que pode ser encontrada pelo   . link  Como o agente já estava configurado, um dos métodos foi adicionar as linhas necessárias à construção da imagem e passar variáveis no sistema CI/CD: DD_ENV, DD_SERVICE, DD_AGENT_HOST, para especificar o ambiente, nome do serviço e endereço do agente, respectivamente . Também precisamos adicionar o seguinte aos dockerfiles dos serviços:   " 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 "  Este método funciona, mas não parece ser a solução ideal. Decidimos dar um passo adiante e adicionamos o seguinte às implantações de nossos serviços:  " 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' "  Foi isso que mudou nos agentes:   " datadog: apm: socketEnabled: true portEnabled: true enabled: true clusterAgent: admissionController: enabled: true mutateUnlabelled: false providers: aks: enabled: true "  Após todas essas etapas, os dados com métricas altamente detalhadas para todos os serviços começaram a fluir no Datadog na seção APM -> Serviços, e os gráficos foram exibidos automaticamente.   Tivemos que alterar as configurações de anotações do segundo método; nem tudo começou a funcionar bem imediatamente.  Em relação ao sistema de notificação, vale ressaltar que ele é amigável e intuitivo no Datadog. As notificações são criadas na seção "Monitores -> Gerenciar Monitores".   As melhorias que descrevemos acima produziram vários resultados valiosos. Agora temos uma compreensão mais profunda de como nosso sistema funciona e se adapta a diversas mudanças.  Além disso, estabelecemos um sistema estável de monitoramento e métricas de aplicativos que opera independentemente da criação de serviços, ajudando a reduzir o tempo de detecção de bugs.  Isso, por sua vez, nos permitiu otimizar nossos serviços e melhorar a velocidade de desenvolvimento e a qualidade geral do sistema.

See how we create Social Life 3.0 👉

Social Discovery Group Earns the Great Place To Work® Certification in the USA!

Swipe Away Loneliness: 2024 Dating Trends Forecast

Este áudio é produzido no idioma original da história!

Como usar o Datadog para o aplicativo de métricas APM

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps