A observabilidade está ainda mais fácil com o Elastic Stack 7.2. Conheça as melhorias, como as métricas específicas de agente APM, o Metrics Explorer com nova

<p>Estamos empolgados em compartilhar com você nosso entusiasmo irrestrito para melhorar as ferramentas disponíveis aos operadores para manter aplicativos e serviços disponíveis, funcionais e rápidos. Não importa se você chama esse objetivo de “observabilidade”, leia o que temos a dizer.
</p>
<p>O Elastic APM adiciona suporte ao .NET, com a versão beta do .NET Agent de alta solicitação. No aspecto do monitoramento de infraestrutura, adicionamos o Metrics Explorer — &nbsp;uma nova visão do aplicativo Infrastructure do Kibana que foi projetado para melhorar a maneira como você interage com as métricas de infraestrutura de modo ad hoc. Por fim, continuamos a ampliar as ferramentas de monitoramento do Kubernetes na versão 7.2 com o lançamento de várias novas integrações de dados para tecnologias nativas na nuvem, como CoreDNS e CRI-O.
</p>
<p>Se você estiver ansioso, a versão 7.2 está disponível agora em nosso <a href="/pt/cloud/elasticsearch-service">Elasticsearch Service</a>&nbsp;— o único produto hospedado do Elasticsearch a oferecer todos esses novos recursos. Ou pode <a href="/pt/downloads">fazer download da versão mais recente do Elastic Stack</a>.
</p>
<h2>A abordagem da Elastic à observabilidade</h2>
<p>O termo “observabilidade” descreve uma filosofia que enfatiza a visibilidade unificada da integridade dos sistemas, serviços e aplicativos. Apesar de ser um termo mais novo no setor, ele captura com eficácia o principal motivo pelo qual muitos usuários e suas equipes estão escolhendo o Elastic Stack para suas necessidades operacionais. Devido à natureza flexível do Elasticsearch, em que <em>tudo é apenas um índice</em>, os usuários podem reunir com sucesso logs, métricas, rastreamentos e medições de disponibilidade — que tradicionalmente eram fontes de dados distintas — em um único armazenamento operacional.
</p>
<p>
	<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6082737bba8cc593/5d0416aa0b20e952523c959c/elastic-observability-devops.png" data-sys-asset-uid="blt6082737bba8cc593" alt="Unifique todos os logs de infraestrutura, métricas, dados de disponibilidade e rastreamentos de APM com o Elastic Stack" data-image="wvo4blfyqzu1" style="display: block; margin: auto;">
</p>
<p>Adotamos uma estratégia dupla no segmento da observabilidade: continuar proporcionando as melhores experiências para cada “pilar” da observabilidade, ao mesmo tempo oferecendo suporte à maneira como esses fluxos de dados são combinados para os usuários de maneiras mais naturais e fluidas. Todos os dados de observabilidade cumprem o Elastic Common Schema (ECS) e todos os aplicativos do Kibana são integrados para oferecer fluxos de trabalho de correlação de dados e navegação de apenas um clique.
</p>
<p><img data-image="vav8bcqlcf3y" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt368c68953bf815de/5d0a9a65877575d0584775e5/elastic-observability-containers.gif" data-sys-asset-uid="blt368c68953bf815de" alt="A observabilidade em ação no Elastic Stack" "="">
</p>
<p>A Red Wing Shoes, uma fabricante de calçados de segurança, confia na dupla <a href="/pt/products/elasticsearch/service">Elasticsearch Service</a> + Elastic Cloud para obter uma visão unificada sobre o processo de manufatura no chão de fábrica, a integridade de seu site de e-commerce e as operações em mais de 600 lojas no mundo todo. A equipe responsável pelas operações também conduz a implantação de novos aplicativos e serviços voltados para a expansão dos negócios. “Conseguimos fazer isso com uma equipe pequena, porque nosso foco é tornar as operações de TI eficientes”, conta Marc Kermisch, Vice-Presidente e Diretor de TI. “Ver todos os dados de operações relevantes em um banco de dados único com uma interface única nos ajudou a ser mais eficientes na triagem e na resolução de questões com base em dados prontos para atuação. E o fato de o Stack ser gerenciável por completo na Elastic Cloud significa que nosso contingente administrativo pode ser baixo já que qualquer implementação, ampliação ou upgrade do Elastic Stack acontece com um clique.”


</p>
<p>Leia mais sobre nossa abordagem a esta importante tendência em nosso blog sobre <a href="/pt/blog/observability-with-the-elastic-stack">observabilidade com o Elastic Stack</a>.
</p>
<p>Na versão 7.2, continuamos a ampliar e aprofundar nossas iniciativas de observabilidade com as seguintes melhorias de produtos.
</p>
<h2>O Elastic APM adiciona suporte ao .NET, a aplicativos de única página e a métricas específicas de agente.</h2>
<p>Estamos muito empolgados em anunciar que estamos migrando o agente Elastic APM para o .NET do status de <a href="/pt/blog/elastic-apm-dot-net-agent-preview-released">prévia</a> para beta. O .NET Agent adiciona <a href="/guide/en/apm/agent/dotnet/current/index.html">instrumentação</a> automática para o ASP.NET Core 2.x+ e o Entity Framework Core 2.x+, ao mesmo tempo também oferecendo uma <a href="/guide/en/apm/agent/dotnet/current/public-api.html">API de agente público</a> que permite aos usuários instrumentar manualmente quaisquer aplicativos .NET que estejam usando outras estruturas.
</p>
<p>O suporte ao .NET foi um dos recursos mais solicitados para o Elastic APM, e estamos muito satisfeitos em uniformizar o universo de idiomas compatíveis. Gostaríamos de agradecer a todos os membros da nossa comunidade que preencheram nossa <a href="https://docs.google.com/forms/d/e/1FAIpQLSfBjUbv9qjcwNFSXpjJT_PmGJn0kpuF1IdZDtnBl0MLNRbYbQ/viewform">pesquisa</a> para nos ajudar a priorizar nossos esforços de suporte a idiomas e fornecer comentários sobre a versão da prévia.
</p>
<p>O RUM (Real User Monitoring) Agent no Elastic APM expanda o suporte a aplicativos de única página (SPAs), permitindo aos usuários capturar transações de alteração de roteamento além de transações de carregamento de página. Os SPAs oferecem muitos benefícios em comparação com os aplicativos de múltiplas páginas (MPAs), incluindo uma experiência de usuário mais otimizada e tempos de carregamento mais rápidos para renderizar dinamicamente elementos de dados à medida que o usuário navega pela página. A natureza dinâmica da entrega precisa de uma abordagem mais personalizada à adaptação da experiência do usuário final, como o exame das alterações de roteamento de aplicativos internos.
</p>
<p>Por fim, os agentes de APM agora coletam métricas específicas de idioma, além de indicadores principais de desempenho comuns — como utilização de recursos gerais&nbsp;— vinculados a dados de rastreamento de APM. Por exemplo, o Java Agent agora coleta métricas de JVM, como memória de heap Java e contagem de threads, que também são exibidos automaticamente no aplicativo APM. A adição dessas métricas específicas de agente cria uma experiência de monitoramento mais rica oferecendo contexto adicional ao comportamento do aplicativo, sem exigir que os desenvolvedores instalem outros agentes.
</p>
<p><img data-image="ah8ondecltp5" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltaa9753682c89f6e9/5d0a9a485fe8e2af5a55ae2e/elastic-observability-metrics-explorer.gif" data-sys-asset-uid="bltaa9753682c89f6e9" alt="Métricas específicas de idioma" "="">
</p>
<p>Leia sobre mais vantagens do APM em nosso <a href="/pt/blog/elastic-apm-7-2-0-released">blog da versão do Elastic APM</a>.
</p>
<h2>O Metrics Explorer melhora a exploração de métricas de infraestrutura</h2>
<p>A expansão do suporte a métricas é foco constante da equipe de engenharia do Elastic Stack nos últimos anos. Melhorar as eficiências de armazenamento através de novos formatos de dados como as árvores Bkd que são otimizadas para dados numéricos, expandir o conjunto de integrações de dados de métricas através de novos módulos do Metricbeat e aprimorar os recursos de visualização de séries de tempo com aplicativos dedicados do Kibana como o Time Series Visual Builder são apenas alguns exemplos do nosso contínuo compromisso com essa área.
</p>
<p>Nossos usuários adoraram, e na versão 7.2 vamos dobrar a exploração de métricas ad-hoc ao incluir o Metrics Explorer no aplicativo Elastic Infrastructure. Essa interface de usuário permite navegar pelas métricas de infraestrutura mais importantes e interagir com elas usando marcas comuns e agrupamentos de diagrama. Cada diagrama do Metrics Explorer pode ser aberto no Time Series Visual Builder para permitir maior investigação, combinando a simplicidade de navegar pelas métricas com apenas um clique aos recursos de todas as agregações do Elasticsearch. Toda essa exploração acontece em altíssima velocidade independentemente do número e da cardinalidade de suas marcas e dimensões. O Metrics&nbsp;
</p>
<p><img data-image="ah8ondecltp5" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltaa9753682c89f6e9/5d0a9a485fe8e2af5a55ae2e/elastic-observability-metrics-explorer.gif" data-sys-asset-uid="bltaa9753682c89f6e9" alt="Metrics Explorer no Kibana 7.2" "="">
</p>
<p>Explorer no momento está em versão beta — adoraríamos receber seus comentários em <a href="https://discuss.elastic.co/c/infrastructure">Discuss</a>! (Discutir)&nbsp;Leia sobre outras melhorias em nosso <a href="/pt/blog/elastic-infrastructure-7-2-0-released">blog de versão do Elastic Infrastructure</a>.
</p>
<h2>A Elastic reforça a observabilidade do Kubernetes</h2>
<p>O ecossistema do Kubernetes está em rápida evolução, alimentado pela inovação do open source em muitas empresas. Novos projetos são adicionados ao ecossistema do CNCF todos os meses e são promovidos ao status Graduated (Graduados) em velocidade impressionante.
</p>
<p>A Elastic tem o compromisso de oferecer suporte às equipes que migram no Kubernetes, incluindo sua necessidade de monitorar esses recursos tecnológicos dinâmicos. Por exemplo, recursos como a autodescoberta no Filebeat e no Metricbeat e os módulos para tecnologias nativas na nuvem como o <a href="/pt/blog/elasticsearch-observability-embracing-prometheus-and-openmetrics-standards-for-metrics">Prometheus</a> oferecem métodos turnkey para monitorar tanto a infraestrutura do Kubernetes quanto os serviços executados nele.
</p>
<p>A versão 7.2 aproveita esses esforços com o lançamento de várias novas integrações para tecnologias nativas na nuvem. O Filebeat e o Metricbeat apresentam o suporte ao CoreDNS, o DNS de cluster padrão para o Kubernetes, que foi recentemente promovido para o status Graduated (Graduado) no CNCF. Também estamos expandindo nosso <a href="/pt/blog/monitoring-nats-messaging-system-with-elastic-beats">suporte ao sistema de mensagens NATS</a> — um sistema de mensagens nativo na nuvem open source — em estreita colaboração com os membros da comunidade.
</p>
<p>Por fim, o Filebeat 7.2 adiciona suporte ao CRI-O, a iniciativa de tempo de execução de container aberta para o Kubernetes. Desenvolvida na RedHat, essa alternativa leve ao Docker já é o tempo de execução de container padrão na conhecida distribuição Openshift. O módulo CRI-O permite que os usuários do Kubernetes troquem para o CRI-O como tempo de execução de container, sem sacrificar os requisitos de monitoramento.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb62e24736c6384d5/5d019984ea19705f1784b04f/elastic-observability-kubernetes.jpg" data-sys-asset-uid="bltb62e24736c6384d5" alt="Observabilidade do Kubernetes com o Elastic Stack" "="">
</p>
<p>Leia mais sobre as vantagens de integrações de dados do Kubernetes em nossos blogs de versão do <a href="/pt/blog/elastic-infrastructure-7-2-0-released">Elastic Infrastructure</a> e do <a href="/pt/blog/elastic-logs-7-2-0-released">Elastic Logs</a>.
</p>
<h2>Mas espere... porque ainda tem mais!</h2>
<p>O Elastic Uptime, apresentado recentemente para proporcionar uma experiência turnkey em torno do monitoramento ativo da disponibilidade, agora inclui integrações de apenas um clique com os aplicativos Elastic Logs, Infrastructure e APM. Essas integrações facilitam muito mais a integração do monitoramento ativo com os fluxos de trabalho de análise de logs e de observabilidade. Leia mais sobre esses e outros avanços em nosso <a href="/pt/blog/elastic-uptime-monitoring-7-2-0-released">blog de versão do Elastic Uptime</a>.
</p>
<p>O Elastic Logs, apresentado na versão 6.5 para otimizar o trabalho com dados de log, adicionou suporte a logs e eventos estruturados por meio da configuração explícita de colunas. Ele também apresentou um recurso de “filtro por campo”, que permite um importante fluxo de trabalho de “visualização de logs adjacentes” que muitos usuários de logs usam nas investigações. Leia mais sobre esses e outros novos avanços em nosso <a href="/pt/blog/elastic-logs-7-2-0-released">blog de versão do Elastic Logs</a>.
</p>
<h2>Faça como seu</h2>
<p>A maneira mais fácil de experimentar os recursos mais recentes é usar um cluster do <a href="/pt/cloud/elasticsearch-service">Elasticsearch Service</a> no Elastic Cloud. Disponibilizamos as versões mais recentes do Elastic Stack no dia do lançamento. Se quiser é só manter — cuidamos das atividades de executar, escalonar para cima ou para baixo e atualizar o cluster para você. Se você é do tipo que faz as coisas sozinho, pode aprender sobre as nossas <a href="/pt/downloads">opções autogerenciadas</a>, por exemplo, fazer download de binários, executar containers do Docker e implantar o Elastic Stack sobre o Kubernetes
</p> <span></span>

blog-generic-teal-banner.png

elastic-observability-7-2-0-thumb.jpg

Observability updates: .NET in APM, Kubernetes monitoring, Metrics Explorer

Atualizações de observabilidade: .NET no APM, monitoramento do Kubernetes, Metrics Explorer

Um esforço extra no seu schema vai tornar as buscas e a análise de dados mais rápidas. É como dar aquele toque extra na hora de preparar uma refeição.

schema-banner.jpg

schema-read-write-thumb.jpg

Schema on write vs. schema on read

Schema em escrita ou schema em leitura

Então você precisa correlacionar logs, métricas e rastros? Não tem problema. Saiba como pode ser simples gerenciar os três pilares da observabilidade com o

<p>Em minha função como Líder de Produto para Observabilidade na Elastic, recebo muitas reações diferentes quando uso o termo 'observabilidade'. A reação mais comum de longe ainda é: "O que é 'Observabilidade'?" Mas cada vez mais também ouço comentários do tipo: "Acabamos de dar início a uma 'iniciativa de observabilidade, mas ainda estamos imaginando exatamente como lidar com isso." E por fim algumas organizações com as quais tivemos a felicidade de trabalhar já consideram a 'observabilidade' uma parte integrante de como elas projetam e criam produtos e serviços.
</p>
<p>Considerando que o termo ainda está se firmando, achei que seria útil desmistificar a maneira como nós na Elastic enxergamos a 'observabilidade', o que aprendemos com nossos clientes formadores de opinião e como pensamos a respeito do ponto de vista do produto à medida que evoluímos nossos recursos para casos de uso operacionais.
</p>
<h2>O que é 'Observabilidade'?</h2>
<p>Com certeza não inventamos o termo 'observabilidade'. Começamos a ouvir pelos usuários, principalmente aqueles da comunidade SRE (Engenharia de confiabilidade de sites). Várias fontes remontam a origem desse termo às organizações SRE de gigantes do vale do Silício como o <a href="https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html">Twitter</a>. E apesar de o inspirador <a href="https://landing.google.com/sre/books/">Google SRE Book</a> não mencionar o termo, ele estrutura muitos dos princípios associados à 'observabilidade' hoje.
</p>
<p>'Observabilidade' não é algo que um fornecedor entrega prontinho -- ela é um atributo de um sistema que você cria, muito parecido com a usabilidade, a alta disponibilidade e a estabilidade. A meta de projetar e criar um sistema 'observável' é garantir que, ao ser colocado em produção, os operadores responsáveis por ele possam detectar comportamentos indesejáveis (p. ex.: inatividade do sistema, erros, respostas lentas) e ter informações produtivas para identificar a causa principal de maneira eficaz (p. ex.: logs de evento detalhados, informações de uso de recursos granulares e rastros de aplicativos). Os desafios comuns que impedem as organizações de alcançar essas metas aparentemente óbvias são não coletar informações suficientes, coletar informações excessivas porém não torná-las produtivas e fragmentar o acesso a essas informações.
</p>
<p>O primeiro aspecto — detecção de comportamentos indesejáveis — normalmente começa com a configuração de <a href="https://landing.google.com/sre/sre-book/chapters/service-level-objectives/">SLIs (Indicadores de nível de serviço) e SLOs (Objetivos de nível de serviço).</a> Elas são medidas internas de sucesso pelas quais os sistemas de produção são julgados nas organizações sensíveis à observabilidade. Se houver uma obrigação contratual para cumprir esses objetivos, um SLI/SLO também poderá se converter em SLA (Acordo de nível de serviço). O exemplo mais comum de um SLI é a <em>atividade do sistema</em>, para a qual você pode definir um SLO de 99,9999%. A atividade do sistema também é o SLA mais comum exposta a clientes externos. Entretanto, os SLI/SLOs podem ser internamente muito mais granulares, e o monitoramento e alerta sobre esses fatores mais importantes do comportamento do sistema de produção é a base de qualquer iniciativa de observabilidade. Esse aspecto da observabilidade também é conhecido pelo termo "monitoramento".
</p>
<p>O segundo aspecto — fornecer operadores com informações granulares para depurar problemas de produção de maneira rápida e eficiente — é uma área em que vemos muito movimento e inovação. Existe muita conversa sobre os "três pilares da observabilidade" — métrica, logs e rastros de aplicativo. Também há o reconhecimento de que meramente coletar todos esses dados granulares usando um remendo de ferramentas não é necessariamente produtivo e geralmente não é econômico.&nbsp;
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf85be52d51892228/5c98d45f8e3cc6505f19f678/three-pillars-of-observability-logs-metrics-tracs-apm.png" data-sys-asset-uid="bltf85be52d51892228" alt="three-pillars-of-observability-logs-metrics-tracs-apm.png" "="" width="446" height="194" style="width: 446px; height: 194px; display: block; margin: auto;">
</p>
<h2>'Pilares' da observabilidade</h2>
<p>Vamos examinar esses aspectos da coleta de dados em mais detalhes. O status quo que normalmente encontramos hoje é coletar métricas para um sistema (normalmente um banco de dados de séries de tempo ou um serviço SaaS para monitoramento de recursos), coletar logs em um segundo sistema (não é de surpreender que sejam os recursos do ELK em nossas conversas) e usar ainda uma terceira ferramenta para instrumentar os aplicativos para fornecer rastro no nível da solicitação. Quando um alerta dispara, indicando uma violação em um nível de serviço, os operadores saem como loucos atrás dos sistemas e fazem a melhor integração possível -- olhando as métricas em uma janela de navegador, correlacionando-as manualmente com logs em outra janela e obtendo os rastros (se relevantes) em uma terceira janela.
</p>
<p>Essa abordagem tem vários problemas. Primeiro, a correlação manual de diferentes fontes de dados todas com as mesmas informações desperdiça tempo valioso durante a degradação ou falha do serviço. Segundo, os custos operacionais de manter três diferentes armazenamentos de dados operacionais são onerosos — custos de licenciamento, efetivo separado para administradores de ferramentas operacionais distintas, recursos de aprendizado de máquina inconsistentes em cada armazenamento de dados, "espaço" para pensar por meio de diferentes semânticas para alertas — cada organização com quem falo enfrenta todos esses desafios.
</p>
<p>Há um reconhecimento cada vez maior da importância de ter todas essas informações em um único armazenamento operacional com a capacidade de correlacionar automaticamente esses dados em uma interface de usuário intuitiva. O sonho dos usuários com quem falamos é expor seus operadores a cada dado relevante ao serviço ao qual oferecem suporte de maneira unificada, seja uma linha de log emitida pelo aplicativo, dados de rastro resultantes de instrumentação ou utilização de recursos representada pela métrica em uma série de tempo. Os requisitos que ouvimos falar enfatizam acesso uniforme e específico a esses dados, independentemente da fonte, incluindo pesquisa, filtragem, agregações e visualizações. Começar com a métrica e detalhar até logs e rastros em alguns cliques sem mudar o contexto acelera as investigações. Da mesma maneira, extrair valores numéricos de logs estruturados parece surpreendentemente como métrica e visualizar ambos lado a lado oferece um valor imensurável de uma perspectiva operacional.
</p>
<p>Como mencionado acima, meramente coletar os dados pode resultar em excesso de informações em disco e inteligência produtiva insuficiente quando ocorre um incidente. Cada vez mais, há uma expectativa de que o sistema que coleta dados operacionais ofereça detecção automática de eventos, rastros e anomalias "interessantes" nos padrões de séries de tempo. Isso ajuda os operadores que investigam um problema a se concentrarem na causa principal mais rapidamente. Esses recursos de detecção de anomalias às vezes são chamados de "quarto pilar da observabilidade". A detecção de anomalias em dados de atividade, utilização de recursos, anomalias em padrões de log e  rastros mais relevantes é um requisito emergente que as equipes de observabilidade propõem.
</p>
<h2>A observabilidade... e o ELK Stack?</h2>
<p>Então o que a observabilidade tem a ver com o Elastic Stack (ou <a href="/pt/elk-stack">ELK Stack</a>, como é carinhosamente chamado nos meios operacionais)?
</p>
<p>O ELK Stack é amplamente conhecido como o verdadeiro método para centralizar logs a partir de sistemas operacionais. A suposição é que o Elasticsearch (um "motor de pesquisa") é um ótimo lugar para colocar logs baseados em texto para as finalidades de pesquisa de texto livre. E realmente a mera pesquisa em logs baseados em texto pela palavra "erro" ou a filtragem de logs com base em um conjunto de marcas bem conhecidas é extremamente poderosa e normalmente é o ponto de partida da maioria dos usuários.
</p>
<p>Entretanto, como sabe a maioria dos usuários do ELK Stack, o Elasticsearch como armazenamento de dados oferece muito mais do que um índice invertido para a pesquisa de texto completo eficiente e capacidades de filtragem simples. Ele também contém um armazenamento colunar otimizado para armazenar e operar em séries de tempo numéricas. Esse armazenamento colunar é usado para armazenar dados de estrutura extraídos de logs analisados, tanto de sequência de caracteres quanto numéricos. Na verdade, o caso de uso de converter logs em métricas é o que inicialmente nos levou a otimizar o Elasticsearch para um armazenamento e recuperação eficientes de números.
</p>
<p>Com o tempo, os usuários começaram a colocar <a href="/pt/solutions/metrics">séries de tempo numéricas</a> diretamente no Elasticsearch, substituindo os bancos de dados de séries de tempo herdados. Levada por essa necessidade, a Elastic lançou recentemente o <a href="/guide/en/beats/metricbeat/6.6/metricbeat-modules.html">Metricbeat</a> para a coleta automatizada de métricas, o conceito dos rollups automáticos e outras funcionalidades específicas de métricas tanto no armazenamento de dados quanto na interface de usuário. Consequentemente, <a href="/pt/webinars/ns1-leveraging-elasticsearch-as-a-time-series-database">cada vez mais usuário</a>s que adotaram o ELK Stack para logs, também começaram a inserir dados de métricas, como a utilização de recursos, no Elastic Stack. Além das economias operacionais já mencionadas acima, um motivo atraente para isso foi a falta de restrições que o Elasticsearch coloca na cardinalidade de campos elegíveis para agregações numéricas (uma reclamação comum ao discutir muitos bancos de dados de séries de tempo existentes).
</p>
<p>Semelhantes à métrica, os <a href="/pt/products/beats/heartbeat">dados de atividade</a> são um tipo altamente valorizado de dados juntamente com os logs, representando uma fonte importante de alertas SLO/SLI de um monitor ativo. Os dados de atividade podem fornecer informações sobre degradação de serviços, APIs e sites, geralmente antes de os usuários sentirem o impacto. O bônus é que os dados de atividade são pequenos em termos de requisitos de armazenamento, portanto um grande valor por um custo adicional muito baixo.
</p>
<p>No ano passado, a Elastic também lançou o <a href="/pt/solutions/apm">Elastic APM</a>, adicionando recursos de rastro de aplicativos e de rastro distribuído aos recursos. Essa foi uma evolução natural para nós, à medida que vários projetos de código-fonte aberto e fornecedores APM destacados já estavam usando o Elasticsearch para armazenar e pesquisar dados de rastro. O status quo nas ferramentas de APM tradicionais é manter os dados de rastro de APM separados dos logs e métricas, perpetuando os silos de dados operacionais. O Elastic APM oferece um conjunto de agentes para coletar dados de rastro das linguagens e estruturas compatíveis, além de oferecer suporte ao OpenTracing, e esses dados de rastro são correlacionados automaticamente às métricas e aos logs.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt248065423cca3f6c/5c98d436fc9053fa5ecd78e3/Screen_Shot_2019-02-28_at_6.58.21_AM.png" data-sys-asset-uid="blt248065423cca3f6c" alt="Screen Shot 2019-02-28 at 6.58.21 AM.png">
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc5c9236cde8b37b8/5c98d43b146c873d59750036/Screen_Shot_2019-02-28_at_6.47.51_AM.png" data-sys-asset-uid="bltc5c9236cde8b37b8" alt="Screen Shot 2019-02-28 at 6.47.51 AM.png">
</p>
<p>Um thread comum em todas essas entradas de dados é que cada uma delas é apenas outro índice no Elasticsearch. Não há restrições nas agregações que você executa em todos esses dados, como você os visualiza no Kibana e como os alertas e o aprendizado de máquina se aplicam a cada fonte de dados. Para ver isso em ação, <a href="https://www.youtube.com/watch?v=d6h5gpACD4o&feature=youtu.be">confira este vídeo</a>.
</p>
<div style="height: 478px; margin-bottom: 20px;">
	<iframe width="100%" height="478" src="//www.youtube.com/embed/d6h5gpACD4o?rel=0" class="video-iframe" frameborder="0" allowfullscreen="">
	</iframe>
</div>
<h2>Kubernetes observável e o Elastic Stack</h2>
<p>Uma comunidade em que o conceito da observabilidade é um tópico bastante ativo de conversas é o conjunto de usuários que adotam o  Kubernetes para orquestração de containers. Esses usuários "nativos da nuvem", um termo popularizado pela <a href="https://www.cncf.io/">Cloud Native Computing Foundation (ou CNCF)</a>, enfrentam desafios exclusivos. Eles encaram uma centralização em massa de aplicativos e serviços desenvolvidos sobre ou migrados para uma plataforma de orquestração de containers baseada em Kubernetes, aliada à tendência de dividir aplicativos monolíticos em "microsserviços". As ferramentas e os métodos que funcionavam antes para proporcionar a visibilidade necessária dos aplicativos executados sobre essa  infraestrutura não funcionam mais.
</p>
<p>A observabilidade do Kubernetes merece uma postagem separada toda especial, então por enquanto recomendo que você participe do <a href="/pt/webinars/observable-kubernetes-with-the-elastic-stack"> webinar Observable Kubernetes</a> e leia a <a href="/pt/blog/distributed-tracing-opentracing-and-elastic-apm">postagem de blog Distributed Tracing with Elastic APM</a> para obter mais informações.
</p>
<h2>E o que vem em seguida?</h2>
<p>Em uma postagem como essa, parece apropriado deixar o leitor com alguns recursos para explorar.
</p>
<p>Para saber mais sobre práticas recomendadas de observabilidade, recomendo começar com o <a href="https://landing.google.com/sre/books/">Google SRE Book</a> mencionado anteriormente. Postagens de blog de empresas cuja sobrevivência depende da operação infalível de seus aplicativos cruciais em produção normalmente também são instigantes. Por exemplo, eu considero esta postagem recente da engenharia da <a href="https://engineering.salesforce.com/what-is-observability-d175eb6cd2e4">Salesforce</a> um guia pragmático e prático para melhorar cada vez mais o estado da observabilidade.
</p>
<p>Teste os recursos do Elastic Stack para suas iniciativas de observabilidade, execute a versão mais recente dos nossos recursos no <a href="/pt/cloud/elasticsearch-service">Elasticsearch Service</a>&nbsp;no <a href="https://cloud.elastic.co/">Elastic Cloud</a> (ótimo sandbox mesmo se você por fim implantar como autogerenciado) ou faça <a href="/pt/downloads">download</a> e <a href="/pt/start">instalação</a> dos componentes do Elastic Stack localmente. Confira as novas interfaces de usuário <strong>Logs</strong>, <strong>Infrastructure</strong> monitoring, <strong>APM</strong> e <strong>Uptime</strong> (em breve na versão 6.7) no Kibana, criados especialmente para fluxos de trabalho de observabilidade comuns. E faça perguntas nos <a href="https://discuss.elastic.co/">fóruns de discussão</a> — estamos prontos para ajudá-lo!
</p>

Articles by Tanya Bragin

Atualizações de observabilidade: .NET no APM, monitoramento do Kubernetes, Metrics Explorer

Schema em escrita ou schema em leitura

Observabilidade com o Elastic Stack

Produtos

Empresa

Resources

SaaS

Orquestração

Articles by Tanya Bragin

Atualizações de observabilidade: .NET no APM, monitoramento do Kubernetes, Metrics Explorer

Schema em escrita ou schema em leitura

Observabilidade com o Elastic Stack