Introdução ao Elastic Stack e ao Docker Compose: Parte 2

Por

Eddie Mitchell

13 de outubro de 2023

Olá! Esta é a segunda parte da série de Introdução ao Elastic^® Stack e ao Docker Compose. Na primeira parte, abordamos os conceitos básicos do Docker Compose e mostramos como criar um cluster de nó único como seu playground local, que inclui o Elasticsearch^®, o Kibana^®, o Logstash^®, o Metricbeat e o Filebeat. Se você ainda não leu o primeiro post do blog, sugerimos que o faça antes de continuar.

Neste post, vamos complementar nosso cluster anterior e implementar recursos adicionais, como Fleet, Agent, APM e uma aplicação de demonstração. Lembre-se de que o Docker Compose não é recomendado para produção, mesmo que o cluster seja maior.

Claro, se você já tiver familiaridade com o assunto e quiser apenas programar, fique à vontade para acessar o repositório do GitHub e pegar os arquivos.

Vamos começar!

Agent, Fleet, APM, caramba!

Se você não conhece esses termos e produtos, não se preocupe! Vamos começar dedicando alguns minutos para explicar o que são esses recursos e por que eles podem ser úteis para você.

Em nossa arquitetura original para este cluster, nós nos concentramos nos aspectos básicos com algum monitoramento e ingestão de arquivos. Aqui você pode ver uma representação disso.

Elastic Agent: uma rápida visão geral

Vamos começar com o Elastic Agent e algumas terminologias adicionais que o acompanham.

O Elastic Agent fornece uma maneira unificada de permitir o monitoramento do host de vários tipos de dados, como logs, métricas e outros dados. Além disso, ele oferece proteção contra ameaças à segurança, consulta de dados do sistema operacional, serviço remoto ou encaminhamento de dados de hardware e muito mais. O Agent simplifica e acelera as implantações de monitoramento em toda a sua infraestrutura. Cada agente está associado a políticas que podem ser atualizadas para incorporar integrações para novas fontes de dados, medidas de segurança e funcionalidades adicionais.

As Elastic Integrations foram projetadas para possibilitar que você colete dados de fontes externas de forma rápida e fácil a fim de obter insights. Essas integrações geralmente usam configurações, dashboards, visualizações e pipelines pré-criados para ajudar a dar sentido a métricas, logs e eventos. A página Integrations (Integrações) pode ser encontrada na sua instância local do Kibana, facilitando a navegação, a instalação e a configuração de integrações em conjunto com o Elastic Agent e suas políticas. Você também pode ver uma lista das integrações disponíveis no site da Elastic.

Políticas são coleções de configurações e integrações que definem como um Elastic Agent funcionará. Múltiplas integrações podem ser atribuídas a uma política do Elastic Agent, proporcionando flexibilidade quanto a quais dados os agentes podem capturar. A atribuição de uma política do Elastic Agent a vários agentes permite gerenciar e configurar muitos agentes em maior escala com o uso do Fleet.

Fleet é a interface do usuário do Kibana que possibilita o gerenciamento centralizado do Elastic Agent e das políticas associadas. Essa interface do usuário permite ver a integridade de cada Elastic Agent, a versão instalada, o último check-in ou horário de atividade e informações de política. A comunicação com cada um dos Elastic Agents é facilitada pelo Fleet via Fleet Server. Isso permite enviar remotamente novas atualizações de políticas no momento do check-in, bem como atualizar os binários ou integrações do Elastic Agent.

Fleet Server é uma instância do Elastic Agent que está em execução como coordenadora da comunicação entre o Fleet e todos os Elastic Agents implantados.

*ufa*

Confira a documentação da Elastic para ler mais sobre todos esses tópicos relacionados ao Agent e ao Fleet.

Integraremos o Elastic Agent e o Fleet para fornecer uma demonstração de como logs e métricas podem ser coletados junto com as políticas de gerenciamento. Vamos adicioná-los ao nosso diagrama de arquitetura para ver como ficarão.

Elastic APM e aplicação web customizada

O Elastic APM é um monitor de desempenho de aplicações criado com base no Elastic Stack. O uso de Elastic APM Agents para instrumentar seu código pode ajudar a simplificar a solução de problemas e a responder a perguntas sobre desempenho reunindo métricas, traces, logs, erros e exceções e enviando-os para o Elasticsearch para visibilidade na interface do usuário do APM.

O Elastic APM pode ser configurado na nuvem ou autogerenciado localmente. Ao gerenciar uma instância local do APM, você pode optar por gerenciar um binário do APM Server independente ou utilizar o APM como uma integração via Elastic Agent.

Para nossa POC local, implementaremos o Elastic APM gerenciado pelos serviços Elastic Agent e Fleet.

A capacidade de monitorar o desempenho da aplicação não adianta muito se você não tem uma aplicação para monitorar. O ideal é que você já tenha algum código que gostaria de instrumentar usando um dos nossos APM Agents. Caso contrário, o repositório do GitHub tem uma pequena aplicação Python que usaremos para fazer alguns testes básicos.

Nova arquitetura

Vamos dar uma olhada no nosso diagrama de arquitetura novamente e ver como tudo se encaixa.

Aqui você pode ver que temos o novo container Fleet-Server, que executa o Elastic Agent para atuar como ponto de comunicação central para todas as comunicações do agente com o cluster da Elastic. O Elastic Agent está executando a integração do Elastic APM para coletar informações de telemetria da nossa aplicação web customizada e do Kibana.

Comunicação e acesso

Muitos dos desafios comuns que surgem quando se começa a usar o Docker em geral consistem em entender como as comunicações funcionam. Com todos os containers, portas, certificados e URLs mencionados, vamos dar um passo para trás e ver como fica essa nova arquitetura quando as diferentes peças precisam conversar entre si.

No nosso arquivo docker-compose.yml , você viu o código que usamos para gerar certificados para os diferentes containers. Ele fica mais ou menos assim:

echo "Creating certs";
echo -ne \
"instances:\n"\
"  - name: es01\n"\
"    dns:\n"\
"       - es01\n"\
"       - localhost\n"\
"    ip:\n"\
"      - 127.0.0.1\n"\
"  - name: kibana\n"\
"    dns:\n"\
"      - kibana\n"\
"      - localhost\n"\
"    ip:\n"\
"      - 127.0.0.1\n"\
"  - name: fleet-server\n"\
"    dns:\n"\
"      - fleet-server\n"\
"      - localhost\n"\
"    ip:\n"\
"      - 127.0.0.1\n"\
> config/certs/instances.yml;

Esse bloco de código está criando um arquivo chamado instances.yml residente no container “setup”, que é uma lista de todos os nomes dos containers junto com suas entradas de DNS dentro do Docker Engine. Usamos esse arquivo em conjunto com o utilitário elasticsearch-certutil para criar um certificado para cada container, a fim de proteger a comunicação entre os containers quando eles se comunicam e quando você se comunica com eles.

Todos os nossos containers se comunicam entre si usando a rede padrão que definimos em docker-compose.yml assim:

networks:
  default:
    name: elastic

Essa rede é interna ao Docker Engine e permite que todos os containers conversem entre si e resolvam os nomes de outros containers. Para permitir que o tráfego do seu navegador chegue ao container, expomos as portas necessárias em cada serviço. Por exemplo:

es01:
  depends_on:
    setup:
      condition: service_healthy
  image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
  labels:
    co.elastic.logs/module: elasticsearch
  volumes:
    - certs:/usr/share/elasticsearch/config/certs
    - esdata01:/usr/share/elasticsearch/data
  ports:
    - ${ES_PORT}:9200
  environment:
    - node.name=es01
    - cluster.name=${CLUSTER_NAME}
    - discovery.type=single-node
  ...

Especificamente, estamos analisando a seção “ports:”. Isso diz ao Docker Compose para mapear as portas especificadas com o formato “host:container”. Nesse exemplo, `${ES_PORT}` seria substituído por 9200 do nosso arquivo .env e a porta seria aberta no seu computador (host). O segundo 9200 representa a porta no container para a qual mapeamos nosso host. Dessa forma, quando você acessar https://localhost:9200 no seu navegador, seu tráfego será enviado para o container es01.

O Elasticsearch, por padrão, também abre a porta 9300 para comunicação entre nós. Embora os outros containers no seu Docker Engine possam acessar essa porta, se necessário, você não poderá fazê-lo do seu host porque não expusemos essa porta.

Se tentássemos visualizar esses conceitos usando nossa nova arquitetura, ficaria assim:

Nesse gráfico, o container `metricbeat01` é capaz de resolver os nomes que demos a “es01” e “logstash01” e até mesmo acessar a porta de monitoramento não exposta de 9600 em “logstash01” porque eles residem na mesma rede Docker.

No entanto, podemos ver que, para acessar o Elasticsearch na porta 9200 e o Kibana na porta 5601, você precisará acessar “localhost” para que sua máquina possa rotear o tráfego para a rede Docker e para os containers corretos.

Por último, decidir qual endereço usar ao fazer referência a um desses serviços pode ser complicado. É importante lembrar o seguinte: quando um dos seus containers estiver acessando outro container que foi configurado com a rede Elastic, use o nome de serviço/container adequado. Porém, se o tráfego originado da sua máquina host estiver acessando um dos containers, você precisará verificar se a porta correta está exposta em docker-compose.yml e acessar essa porta via localhost.

Observe também que essas configurações são formas de começar o desenvolvimento local, mas não são recomendadas para uso em ambientes de produção.

Implementação

Então, como implementamos tudo isso?

Primeiro, faremos uma rápida revisão da nossa stack de base e destacaremos algumas alterações, começando com nossa estrutura de arquivos, arquivo .env e o docker-compose.yml.

Estrutura de arquivos

Para nossa estrutura de arquivos, adicionamos a pasta “app” para armazenar todo o código e a configuração da nossa aplicação web customizada junto com um novo kibana.yml porque adicionaremos configurações mais específicas relacionadas ao Elastic Agent e ao APM.

.env

Nosso arquivo .env (link do GitHub) permanece praticamente inalterado com exceção de novas portas para Fleet, APM Server e um token secreto do APM, conforme visto abaixo.

O token secreto será usado posteriormente na nossa implementação para autorizar solicitações ao APM Server. Você pode ler mais sobre elas na documentação.

# Port to expose Fleet to the host
FLEET_PORT=8220


# Port to expose APM to the host
APMSERVER_PORT=8200


# APM Secret Token for POC environments only
ELASTIC_APM_SECRET_TOKEN=supersecrettoken

Lembre-se de que todas as senhas ou chaves listadas neste post do blog são para fins de demonstração e devem ser alteradas imediatamente nos seus ambientes.

docker-compose.yml

Para nosso arquivo docker-compose.yml, temos algumas adições à stack de base, ou seja, containers para “Fleet Server” e “ webapp”, incluindo a adição de outros volumes e a adição de fleet-server à nossa lista de servidores para geração de certificados, conforme mencionado acima.

Você pode encontrar o arquivo completo no GitHub, mas abordaremos apenas algumas das edições.

Uma observação sobre variáveis de ambiente

Há diversas variáveis de ambiente nos serviços existentes nas quais certificados foram especificados e passados ao container ou ao arquivo de configuração correspondente.

Assim como no nosso arquivo .env, variáveis de ambiente no arquivo docker-compose.yml nos permitem passar variáveis para nossos containers. Dessa forma, definimos a variável `CA_CERT` igual ao caminho do certificado uma vez no nosso container. Depois, dentro do arquivo metricbeat.yml, podemos usar essa variável sempre que necessário. Se precisássemos atualizar o CA_CERT, por exemplo, precisaríamos apenas atualizar o caminho uma vez no arquivo docker-compose.yml e então reimplantar o container metricbeat.

O container metricbeat01 e o arquivo metricbeat.yml são bons exemplos de como passar a variável de ambiente `CA_CERT` e usá-la diversas vezes no arquivo yml.

docker-compose.yml (container ‘fleet-server’)

A adição de um container `fleet-server` ao arquivo docker-compose.yml (link do GitHub) cria um container adicional extraindo a imagem do Elastic Agent. A imagem do agente é usada tanto para coleta de dados de borda quanto para a imagem de base usada para configurar o servidor de gerenciamento do Fleet.

Lembre-se de que estamos usando algumas sinalizações adicionais para diminuir a rigidez das verificações de certificado, já que esta é uma POC local. Em um ambiente de produção, convém que todos os certificados sejam emitidos e verificados corretamente.

Conforme mencionado acima, estamos expondo duas portas para comunicações.

ports:
  - ${FLEET_PORT}:8220
  - ${APMSERVER_PORT}:8200

'8220' lida com todo o tráfego destinado às comunicações do Agent/Fleet.
'8200' lida com todo o tráfego que será utilizado pelo servidor do APM, já que nosso Agent hospeda a integração do APM.

Algumas das principais configurações de ambiente aqui:

Observação: se você também quiser configurar e executar testes sintéticos, precisará usar a imagem Docker de `docker.elastic.co/beats/elastic-agent-complete:${STACK_VERSION}`. Não abordaremos essa parte, mas você pode ler mais sobre ela na nossa documentação.

docker-compose.yml (container ‘kibana’)

Duas alterações são necessárias no container ‘kibana’ (link do GitHub). A primeira é a conexão muito importante entre o arquivo docker-compose.yml e o arquivo kibana.yml na seção 'volumes'. Essa linha diz ao Docker para fazer um “bind mount” do arquivo kibana.yml local ao container a ser utilizado.

- ./kibana.yml:/usr/share/kibana/config/kibana.yml:ro

Em seguida, uma alteração simples foi adicionada na parte inferior das variáveis de ambiente, o que nos permite passar pelo token secreto do APM que definimos originalmente no arquivo .env.

- ELASTIC_APM_SECRET_TOKEN=${ELASTIC_APM_SECRET_TOKEN}

kibana.yml

Estamos adicionando um novo arquivo yml para configurar o Kibana a fim de incorporar o Fleet e o Agent (link do GitHub).

Notavelmente, xpack.fleet.packages nos permite especificar que os pacotes extrairão seus ativos automaticamente:

xpack.fleet.packages:
  - name: fleet_server
    version: latest
  - name: system
...

Enquanto xpack.fleet.agentPolicies permite a definição das políticas de base a serem usadas para o Fleet e o Agent iniciais:

xpack.fleet.agentPolicies:
  - name: Fleet-Server-Policy
    id: fleet-server-policy
    namespace: default
    monitoring_enabled: 
      - logs
      - metrics
...

Você pode ler mais sobre como configurar políticas sem a UI na nossa documentação.

Também estamos adicionando uma política para oferecer suporte ao Elastic APM, bem como aos ativos associados do pacote do APM:

- name: apm-1
        package:
          name: apm
        inputs:
        - type: apm
          enabled: true
          vars:
          - name: host
            value: 0.0.0.0:8200
          - name: secret_token
            value: ${ELASTIC_APM_SECRET_TOKEN}

Definimos o URL do servidor e o secret_token para garantir que nossas aplicações possam se comunicar corretamente.

Um bônus é telemetry.enabled: "true", que nos permite executar o Elastic APM em nossa própria instância do Kibana para ver o uso adicional de como o APM funciona.

docker-compose.yml (container ‘webapp’)

 webapp:
    build:
      context: app
    volumes:
      - "/var/lib/docker/containers:/var/lib/docker/containers:ro"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "/sys/fs/cgroup:/hostfs/sys/fs/cgroup:ro"
      - "/proc:/hostfs/proc:ro"
      - "/:/hostfs:ro"
    ports:
      - 8000:8000

Para nosso webapp de exemplo, estamos usando um dockerfile para nos ajudar a criar nossa aplicação e implantá-la no Docker.

Essa configuração de container depende muito do comando de compilação `context: app`. O Docker está assumindo que “app” é uma pasta e que dentro dessa pasta está nosso Dockerfile. Esses atributos podem ser mais específicos, mas para nossos propósitos, as suposições padrão são perfeitamente adequadas.

Quando o Docker Compose cria esse container, ele lê a pasta “app” e pega o dockerfile para obter instruções sobre como criar a imagem para usar no container.

Também especificamos que queremos expor a porta 8000, bem como passamos alguns “volumes” semelhantes aos que o Metricbeat tem disponíveis para monitorar recursos.

app/dockerfile

# syntax=docker/dockerfile:1


FROM python:3.9-slim-buster


WORKDIR /app


COPY requirements.txt requirements.txt


RUN pip3 install -r requirements.txt


COPY main.py main.py


CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--log-level", "info", "--workers", "1"]

Nosso dockerfile agora usará a imagem “python:3.9-slim-buster” como base para extração. A partir daí, ele criará a pasta /app, copiará o arquivo requirements.txt do nosso local e instalará os requisitos via pip3.

Depois disso, ele copiará nossa aplicação main.py e tentará executar a aplicação Uvicorn, que está integrada a main.py.

Observação: a ordem das operações é importante em um dockerfile para fins de armazenamento em cache. Se você alterar qualquer um dos arquivos chamados no dockerfile, o cache será descartado e uma nova extração do arquivo acontecerá. Normalmente, é desejável colocar os arquivos que mudam com mais frequência posteriormente no dockerfile para que os arquivos mais lentos ou que não mudam possam permanecer em cache para o processo de compilação.

app/main.py

A aplicação main.py (GitHub) é uma aplicação muito simples que combina FastAPI e NiceGUI. A aplicação principal foi instrumentada com o Elastic APM Agent do Starlette, e alguns botões permitem fazer chamadas que gerarão erros e mensagens propositalmente em nosso ambiente do APM.

Python:

from elasticapm.contrib.starlette import ElasticAPM, make_apm_client

apm = make_apm_client({
      'SERVICE_NAME': 'my_python_service',
      'SECRET_TOKEN': 'supersecrettoken',
      'SERVER_URL': 'http://fleet-server:8200',
      'ENVIRONMENT': 'development'
  })

app = FastAPI()
app.add_middleware(ElasticAPM, client=apm)

apm.capture_message(f"Custom Message: {message}")

@app.get("/error")
async def throw_error():
    try:
        1 / 0
    except Exception as e:
        apm.capture_exception()
    return {"message": "Failed Successfully :)"}

Acima estão trechos do código onde podemos ver que estamos importando a biblioteca do APM, criando o cliente do APM e adicionando o middleware à nossa aplicação FastAPI.

Essa aplicação serve apenas como um exemplo de como interagir com o Elastic APM.

Vamos ao Docker Compose

Agora que temos tudo configurado, vamos abrir o cluster!

A execução do comando docker compose up abrirá todos os containers e permitirá que você faça login no Kibana em https://localhost:5601. Lembre-se de que, como já temos certificados para o Kibana, teremos de usar HTTPS, portanto, talvez você precise clicar em algum aviso de certificado apresentado pelo seu navegador.
Ao fazer login, você pode navegar até o Fleet através do menu hambúrguer -> Management (Gerenciamento) -> Fleet.

Uma vez lá, você verá um único host no menu Agents (Agentes). Nessa página do Fleet, você pode fazer check-in de todo e qualquer agente que você inscreveu no seu cluster. Você também pode criar ou alterar políticas, inscrever novos agentes e atualizar qualquer configuração global do Fleet.

No entanto, você pode perceber que os campos de uso de CPU e memória não estão sendo atualizados. Da mesma forma, se você clica no link Host, parece que os logs também não estão sendo preenchidos. Após uma investigação mais aprofundada, vemos erros nos logs do container fleet-server semelhantes a:

{"log.level":"info","message":"Attempting to reconnect to backoff(elasticsearch(http://localhost:9200)) with 17 reconnect attempt(s)","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"http/metrics-monitoring","type":"http/metrics"},"log":{"source":"http/metrics-monitoring"},"log.origin":{"file.line":139,"file.name":"pipeline/client_worker.go"},"service.name":"metricbeat","ecs.version":"1.6.0","log.logger":"publisher_pipeline_output","ecs.version":"1.6.0"}
{"log.level":"error","message":"Error dialing dial tcp 127.0.0.1:9200: connect: connection refused","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"http/metrics-monitoring","type":"http/metrics"},"log":{"source":"http/metrics-monitoring"},"service.name":"metricbeat","ecs.version":"1.6.0","log.logger":"esclientleg","log.origin":{"file.line":38,"file.name":"transport/logging.go"},"network":"tcp","address":"localhost:9200","ecs.version":"1.6.0"}

Isso ocorre porque, por padrão, nosso Elastic Agent tenta registrar dados em uma instância local do Elasticsearch, o que não é correto para nosso ambiente Docker.

Precisaremos realizar algumas atualizações na UI Fleet -> Settings (Configurações) para resolver isso.

Vamos dar uma olhada.

Reconfigurar saída, adicionar certificado

Depois de navegar até Fleet -> Settings (Configurações), vamos olhar a seção Outputs (Saídas) e clicar no botão Edit (Editar) abaixo do cabeçalho Actions (Ações):

Isso nos fornecerá uma caixa de diálogo no lado direito da interface para modificar a saída padrão.

Queremos alterar o campo “Hosts” junto com o campo “Elasticsearch CA trusted fingerprint” (Impressão digital aceita pela CA do Elasticsearch), bem como uma alteração na seção “Advanced YAML configuration” (Configuração avançada do YAML).

No entanto, ainda não temos todas essas informações. Então, vamos entrar em um terminal e pegá-las.

Primeiro, precisaremos extrair o certificado CA do cluster. Este será o mesmo comando que usamos na parte 1:

docker cp es-cluster-es01-1:/usr/share/elasticsearch/config/certs/ca/ca.crt /tmp/.

Observação: esse comando será diferente dependendo do diretório em que você estiver executando o arquivo docker-compose.yml ou da variável COMPOSE_PROJECT_NAME especificada no arquivo .env.

Em seguida, precisaremos obter a impressão digital do certificado. Para isso, podemos usar um comando OpenSSL:

openssl x509 -fingerprint -sha256 -noout -in /tmp/ca.crt | awk -F"=" {' print $2 '} | sed s/://g

Isso produzirá um valor semelhante a:

5A7464CEABC54FA60CAD3BDF16395E69243B827898F5CCC93E5A38B8F78D5E72

Por fim, precisamos colocar todo o certificado no formato yml. Podemos fazer isso com um comando `cat` ou apenas abrindo o certificado em um editor de texto:

cat /tmp/ca.crt

Assim que você tiver o texto do certificado, nós o adicionaremos a um formato yml e inseriremos todas essas informações na tela de configurações do Fleet mostrada anteriormente.

Para “Hosts”, usaremos “https://es01:9200”. Isso ocorre porque o container que hospeda o servidor do Fleet sabe como se comunicar com o container es01 para enviar dados.

Insira a impressão digital produzida no campo “Elasticsearch CA trusted fingerprint” (Impressão digital aceita pela CA do Elasticsearch).

Por fim, adicione o texto do certificado em “Advanced YAML configuration” (Configuração avançada do YAML). Como essa é uma configuração yml, ocorrerá um erro se os espaços não forem aplicados corretamente.

Comece com:

ssl:
certificate_authorities:
- |

E cole o texto do certificado, verificando se o recuo está correto.

Exemplo:

Não se esqueça de clicar em “Save and Apply Settings” (Salvar e aplicar configurações) -> “Save and Deploy” (Salvar e implantar).

Revisar os dados do Elastic Agent

Após clicar em“Save and Deploy” (Salvar e implantar), volte para a guia Agent (Agente), clique no nome do seu agente e você verá a utilização da CPU e da memória exibida corretamente, bem como os logs sendo preenchidos.

Aqui, você também pode clicar em View more agent metrics (Ver mais métricas do agente) para acessar os dashboards do Agent e ver dados adicionais.

Consulte a documentação para obter informações adicionais sobre o monitoramento de agentes.

Revisar os dados do Elastic APM

Navegando até o menu hambúrguer -> Observability -> Overview (Visão geral), você também poderá começar a ver algumas das métricas do Elastic APM fluindo.

Especificamente, navegue até APM -> Services (Serviços), e você poderá ver o Kibana e nossa aplicação de demonstração.

Isso permitirá que você veja mais detalhes sobre os serviços e se familiarize com os tipos de informações que o Elastic APM está capturando.

Solucione problemas e redimensione tranquilamente com o Elastic Stack

A segunda parte da série de Introdução ao Elastic Stack e Docker Compose se concentrou no aumento da segurança e em recursos como Elastic Agent, Fleet e Elastic APM. Adicionar uma aplicação customizada via Dockerfile também ajuda a ilustrar a implementação do Elastic APM.

Isso proporciona uma excelente plataforma local de aprendizagem para desenvolver e testar recursos.

Instrumentar suas aplicações com Elastic APM Agents para monitorá-las melhorará muito sua capacidade de aprimorar e solucionar problemas em suas aplicações no futuro. A utilização dos serviços Elastic Agent e Fleet permitirá que você redimensione sua instrumentação com facilidade.

Lembre-se de que, embora tenhamos demonstrado o Elastic Agent e o APM, esta configuração também permitirá testar configurações do OTel!

Quando quiser migrar para um cluster mais pronto para produção, confira o Elastic Cloud para encontrar uma transição perfeita do que você aprendeu localmente para um ambiente pronto para produção com muitas integrações.

Todos os arquivos discutidos aqui estão disponíveis no GitHub. Perguntas e solicitações pull são bem-vindas!

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste post permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis atualmente poderão não ser entregues dentro do prazo previsto ou nem chegar a ser entregues.

The Search AI Company

IA generativa

Busca

Segurança

Observabilidade

Por solução

Setores