A Elastic adota padrões open source e abertos. Saiba como importar as métricas do Prometheus e visualizá-las juntamente com todos os outros dados com o stack

<p>Neste blog, trataremos destes assuntos:
</p>
<ul>
	<li>Por que os padrões abertos são importantes</li>
	<li>O formato de exposição do Prometheus</li>
	<li>Como a Elastic enxerga a observabilidade</li>
	<li>Três maneiras pelas quais o Elasticsearch pode consumir as métricas do Prometheus</li>
	<li>Exemplo de como coletar e visualizar as métricas expostas pelo
exportador Prometheus Redis
	</li>
</ul>
<h2>Padrões abertos</h2>
<p>Em 
	<a href="http://opensource.com">opensource.com</a>, há um recurso informativo com o título: "<a href="https://opensource.com/resources/what-are-open-standards">What are Open Standards?</a>" (O que são os padrões abertos?).  Há
muitos assuntos excelentes nesse documento, mas na minha opinião pessoal de quem atua há
muitos anos nas operações, estes são os mais importantes:
</p>
<ol start="1">
	<li>Disponibilidade: Os padrões abertos ficam disponíveis para que todos leiam e
implementem.
	</li>
	<li>Maximizam a escolha do usuário final</li>
	<li>Não há discriminação (neutralidade de fornecedor): Os padrões abertos e as
organizações que os administram não favorecem um implementador
em detrimento de outro.
	</li>
	<li>Não há segredos intencionais: o padrão não deve reter nenhum
detalhe necessário para implementação interoperável.
	</li>
</ol>
<p>Esses são os motivos atraentes pelos quais os padrões abertos são interessantes;
agora vamos falar sobre por que o 
	<a href="https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md">
	formato de exposição do Prometheus</a> é a base para o <a href="https://openmetrics.io/">
	OpenMetrics</a>. Em suas palestras nos eventos <a href="https://promcon.io/2018-munich/slides/openmetrics-transforming-the-prometheus-exposition-format-into-a-global-standard.pdf">
	PromCon 2018</a> e KubeCon + <a href="https://www.youtube.com/watch?v=DARVop91kBQ">
	CloudNativeCon</a> North America 2018, Richard Hartmann resumiu
os motivos para criar um padrão aberto influenciado pelo
formato de exposição do Prometheus:
</p>
<ul>
	<li>A maioria dos formatos de dados é proprietária, difícil de implementar ou
as duas coisas
	</li>
	<li>O Prometheus se tornou o verdadeiro padrão no
monitoramento de métricas nativo na nuvem
	</li>
	<li>A facilidade dos dados de exposição resultou em uma explosão nos <a href="https://prometheus.io/docs/instrumenting/exporters/">
	endpoints de métricas compatíveis</a></li>
	<li>O formato de exposição do Prometheus se baseia em muita experiência operacional,
mas foi projetado entre poucas pessoas
	</li>
	<li>Alguns outros projetos e fornecedores ficam receosos em termos de adotar uma tecnologia de
um produto "concorrente"
	</li>
</ul>
<h2>Formato de exposição do Prometheus</h2>
<p>Você pode ler sobre o formato de exposição no <a href="https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md">
	repositório do Prometheus Github</a>. Por enquanto, vamos apenas analisar um exemplo.
 Eu tenho um exportador, o 
	<a href="https://github.com/oliver006/redis_exporter">
	exportador Redis da Oliver006</a>, publicando métricas na porta 9121 no
endpoint /metrics.  Estou mostrando somente informações sobre a
métrica "operações instantâneas por segundo" do Redis aqui.  Há três
linhas para a leitura:
</p>
<ol start="1">
	<li>Texto de Ajuda</li>
	<li>Tipo de métrica (gauge neste caso)</li>
	<li>O servidor Redis sendo mensurado (porta host local 6379) e sua 
leitura atual (9 operações por segundo)
	</li>
</ol>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdc2597dd9d329537/5cd475e29033f96a5b031b8b/roscigno-prometheus-exposition-format.png" data-sys-asset-uid="bltdc2597dd9d329537" alt="roscigno-prometheus-exposition-format.png">
</p>
<h2>Observabilidade na Elastic</h2>
<p>Eu incentivo você a ler sobre <a href="/pt/blog/observability-with-the-elastic-stack">
	como a Elastic enxerga a observabilidade</a>, mas esta é minha linha favorita
da postagem:
</p>
<blockquote>O objetivo de projetar e desenvolver um sistema 'observável' é
garantir que, quando ele for executado em produção, os operadores responsáveis
por ele possam detectar comportamentos indesejáveis (p. ex.: inatividade de serviço,
erros, respostas lentas) e ter informações práticas para identificar
a causa principal de maneira eficaz (p. ex.: logs de evento detalhados,
informações de utilização de recursos granulares e rastreamentos de aplicativos).
</blockquote>
<p>Essa instrução, que eu apoio incondicionalmente, informa que
precisamos de todos os logs, métricas e informações de rastreamento para executar,
reparar e gerenciar os serviços que fornecemos.  O Prometheus é uma
parte importante da observabilidade devido à sua adoção disseminada
e comunidade ativa.  O padrão OpenMetrics só aumentará
o valor removendo barreiras, sejam elas reais ou percebidas,
à adoção de um formato de métricas surgido nas operações e de bom senso.
</p>
<p>A maioria das pessoas com quem converso é bastante familiarizada com o Elastic
Stack, ou ELK, para logs.  Se você não sabia que o Elastic
Stack também é ótimo para métricas e APM, veja nossas 
	<a href="/pt/blog/elasticsearch-as-a-time-series-database-for-telemetry-data-at-ns1">
	métricas</a> e <a href="/pt/solutions/apm">
	APM/rastreamento distribuído</a>.
</p>
<p>Os principais motivos para os quais vemos interesse na profunda integração entre os métodos do
Elastic Stack e do Prometheus de exportar métricas são:
</p>
<ul>
	<li>Combinar métricas com logs e APM no Elasticsearch e
correlacioná-los no Kibana. Confira uma 
	<a href="/pt/blog/elasticsearch-as-a-time-series-database-for-telemetry-data-at-ns1">
	história de usuário</a> da NS1 sobre combinação de logs e métricas no Elastic
Stack.
	</li>
	<li>Usar o Elasticsearch como armazenamento de longo prazo para métricas coletadas
pelo Prometheus Server, que no momento não oferece suporte a cluster
nativamente.
	</li>
	<li>Atingir uma visão global das métricas entre instâncias
do Prometheus geograficamente dispersas.
	</li>
</ul>
<p>O restante do blog descreve em detalhes como abordamos essas
integrações.
</p>
<h3>Um exportador de amostra</h3>
<p>Meu ambiente de demonstração está em execução no Google
Kubernetes Engine (GKE), por isso estou executando meu aplicativo,
o Metricbeat, e o exportador do Prometheus, tudo no Kubernetes.  Este
é um trecho do manifesto do Oliver006 para implantar um exportador do Redis como
um sidecar ao longo da imagem do Redis.  Como você pode ver, o exportador
está publicando na porta 9121, que é o 
	<a href="https://github.com/prometheus/prometheus/wiki/Default-port-allocations">
	número de porta atribuído padrão</a> para o exportador do Prometheus
Redis.
</p>
<pre class="prettyprint">...
  - name: redis-exporter
    image: oliver006/redis_exporter:latest
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
    ports:
    - containerPort: 9121
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/guestbook.yaml">Fonte completa em GitHub</a>
</p>
<h3>Uso de scraping nas métricas com o módulo Metricbeat Prometheus
</h3>
<p><a href="/pt/products/beats/metricbeat">
	O Metricbeat</a> é o shipper leve da Elastic para métricas.  O
	<a href="/guide/en/beats/metricbeat/7.0/metricbeat-module-prometheus.html">
	módulo Prometheus</a> que é fornecido com o Metricbeat pode reunir métricas
de três maneiras:
</p>
<ol start="1">
	<li>Conectar-se ao servidor do Prometheus na porta 9090 e obter
métricas já coletadas usando a API de federação do Prometheus (para obter as
métricas que o Prometheus está coletando)
	</li>
	<li>Conectar-se ao servidor do Prometheus na porta 9090 usando o
endpoint /metrics (automonitoramento do Prometheus)
	</li>
	<li>Conectar-se aos exportadores do Prometheus individualmente e analisar o
formato de exposição
	</li>
</ol>
<p>Por que você escolheria uma abordagem em detrimento da outra? Isso depende do
seu nível de conforto com o servidor do Prometheus.
</p>
<ul>
	<li>Se você já tem o servidor do Prometheus configurado para fazer scraping de métricas
e quiser consultar diretamente essas métricas para
fins de integração, você poderá começar com as opções (1) e (2).
	</li>
	<li>Se, por outro lado, você ainda não tiver o servidor do Prometheus
ou não se importar em fazer scraping dos exportadores em paralelo por várias
ferramentas, você poderá escolher a opção (3).
	</li>
</ul>
<p>Nota: Parte da funcionalidade do Metricbeat acima é beta no
Metricbeat versão 7.0.  Nós incentivaríamos você a 
	<a href="/pt/downloads ">fazer download da versão 7.0 beta</a>
	ou copiar os links de container de
	<a href="https://www.docker.elastic.co/">
	https://www.docker.elastic.co/</a> e executar a versão beta em um ambiente de não produção.
</p>
<h3>API de federação do Prometheus</h3>
<p>Em geral, a federação é usada para habilitar o escalonamento, reunir os conjuntos de dados ou fazer uma cópia dos dados disponíveis em um local diferente (para recuperação de desastres).  O servidor do Prometheus fornece um endpoint <a href="https://prometheus.io/docs/prometheus/latest/federation/"><code>/federation</code></a>, e a Elastic se conecta a esse endpoint para copiar as métricas coletadas pelo Prometheus para todos os motivos anteriores.
</p>
<pre class="prettyprint">...
  - module: prometheus
    period: 10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: '/federate'
    query:
      'match[]': '{__name__!=""}'
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml">Fonte completa em GitHub</a><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml"></a>
</p>
<p>No exemplo anterior, a consulta é definida como "qualquer coisa que tenha um nome que não seja em branco".  Talvez você não queira obter tudo, e os documentos do Prometheus têm informações sobre como gravar uma condição de correspondência mais restritiva.  O exemplo também está se conectando ao servidor do Prometheus a cada dez segundos, meu servidor de demonstração só está coletando a partir de alguns pods e métricas com estado de kube, mas talvez você queira alterar o intervalo.
</p>
<h3>Automonitoramento do Prometheus</h3>
<p>O Prometheus fornece um endpoint <code>/metrics</code>, assim como os exportadores.  Tanto é assim que você pode coletar as métricas sobre o servidor do Prometheus.  Isso é configurado desta maneira:
</p>
<pre class="prettyprint">...
  - module: prometheus
    period: 10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: /metrics
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml">Fonte completa em GitHub</a>
</p>
<h3>Scraping do exportador do Prometheus</h3>
<p>Esse trecho do YAML proveniente de um manifesto para implantar um Metricbeat
DaemonSet informa que o Metricbeat faça uma autodescoberta das tarefas
com 
	<code>kubernetes.labels.app</code> == <code>redis</code> e leia as métricas recebidas na porta
9121 desse pod.  Lembre-se de que o conjunto de containerPort para o
container do exportador do Redis é 9121.
</p>
<pre class="prettyprint">...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period: 10s
      # Redis pods
      hosts: ["${data.host}:9121"]
      metrics_path: /metrics
...
</pre>
<p>Depois que o Metricbeat for implantado, quaisquer pods que satisfaçam a condição
kubernetes.labels.app == redis terão o módulo Prometheus aplicado
a eles, e as métricas serão coletadas a partir do sidecar do exportador na
porta 9121.
</p>
<p>Mas, os metadados fazem o mundo dos k8s avançar, não é?  Vamos fazer
mais com metadados e o recurso de autodescoberta do Beats.  Analise
este substituto para o trecho anterior do YAML:
</p>
<pre class="prettyprint">...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period: 10s
      hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]
      metrics_path: /metrics
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-prometheus-auto-discover.yaml">Fonte completa em GitHub</a>
</p>
<p>Agora, em vez de procurar por exportadores para pods do Redis, estamos
procurando por exportadores para qualquer pod com uma anotação de
	<code>kubernetes.annotations.prometheus.io/scrape</code> definida como verdadeira.  Isso é
também como a autodescoberta do Prometheus é configurada.  Geralmente, a autodescoberta do Metricbeat
é orientada por uma anotação no namespace elastic.co,
mas como estamos falando sobre a leitura dos exportadores do Prometheus,
deveríamos honrar as anotações de k8s padrão associadas
ao Prometheus.  Se você analisar a lista de hosts anterior:
</p>
<p><code>hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]</code>
</p>
<p>Você poderá ver que não estamos mais fazendo hard coding da porta 9121, porque essa
é a porta para o exportador do Redis.  A anotação 
	<code>prometheus.io/port</code> é configurada com o número de porta para o exportador.  Para ser completo, aqui
está um trecho do guestbook.yaml em que essas anotações foram
configuradas:
</p>
<pre class="prettyprint">...
kind: Deployment
metadata:
  name: redis-master
spec:
  replicas: 1
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9121"
      labels:
        app: redis
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/guestbook.yaml">Fonte completa em GitHub</a>
</p>
<p>Eu não mencionei que os metadados fazem o mundo dos k8s avançar? 
Vamos para o próximo tópico.
</p>
<h3>Visualização melhorada</h3>
<p>Importar os dados para o Elastic Stack é excelente, mas é necessário poder interagir com os dados.  No vídeo a seguir, veremos como abordar a criação de uma visualização útil usando métricas do Redis que passaram por scraping feito pelo Prometheus (e que foram importadas para o Elastic Stack) e os eventos do Kubernetes coletados das métricas com estado de kube com o Metricbeat diretamente.
</p>
<p>Se quiser prosseguir com o vídeo e obter instruções detalhadas, veja
o 
	<a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/README.md">
	repositório de exemplo</a>.
</p>
<div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/kt1jkhu1sptWzV3Y1wrfwE.jpg" data-uuid="kt1jkhu1sptWzV3Y1wrfwE" data-v="4" data-type="inline">
</div>
<h2>De volta à observabilidade</h2>
<p>Na última seção, criamos uma visualização do Kibana para uma
métrica do Redis crucial (operações instantâneas por segundo) exposta pelo
exportador Redis do Oliver006.  Nossa próxima etapa seria coletar logs
e criar um painel e combinar logs e métricas
entre nossos aplicativos.
</p>
<p>Para saber como coletar logs em um ambiente do Kubernetes,
minha sugestão seria seguir as instruções no 
	<a href="https://github.com/elastic/examples/blob/master/MonitoringKubernetes/README.md">
	repositório do GitHub elastic/examples</a>.  Em apenas alguns minutos, você pode
ter o Filebeat, o Metricbeat e o Packetbeat coletando dados e
publicando no Elasticsearch.  Há painéis de amostra que são fornecidos
com os Beats diferentes, e você ficar à vontade de criar suas próprias
visualizações para os dados do Prometheus e misturar as visualizações
para criar seus próprios painéis para a maneira que você trabalha. E se você tiver quaisquer problemas ou quiser falar sobre observabilidade, acesse os 
	fóruns de 
	<a href="https://discuss.elastic.co">discussão</a>.
</p>

blog-roscigno-wide.jpg

blog-roscigno-thumb.png

Elasticsearch Observability: Embracing Prometheus and OpenMetrics Standards for Metrics

Observabilidade do Elasticsearch: adoção dos padrões do Prometheus e do OpenMetrics para métricas

<p>Com a versão 6.5 do Elastic Stack, lançamos duas novas maneiras de interagir com seus dados: as UIs de logs e de infraestrutura. Ambas estão na versão beta no 6.5, mas falarei sobre isso mais tarde, quando pedirei sua opinião. Para cada uma delas, gostaria de falar um pouco sobre a motivação, a experiência do usuário e a configuração da UI. Vamos começar com a UI de logs.</p><h2>UI de logs</h2><h3>Motivação</h3><p>Já ouvi isto tantas vezes: "Só me dê os logs, não preciso de nada sofisticado, tudo o que preciso saber está escrito nos logs, eu só quero lê-los." Nós ouvimos você. A escolha é sua:</p><p>Um tail -f turbinado onde os registros mais recentes ficam na parte inferior; uma experiência visual com tabelas, gráficos, nuvens de tags etc.; ou uma visualização tabular. Você deve poder trabalhar da maneira mais adequada para você, e o Elastic Stack tem total abertura para dar suporte a isso.</p><table border="0" style="width: 100%;"><tbody><tr><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf9bdf54b4eeab8bc/5c57d6fb85820dce0bcc2bf5/Logs-small.jpg" data-sys-asset-uid="bltf9bdf54b4eeab8bc" alt="Logs-small.jpg" style="background-color: initial;"/> </td><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1af8714b20964974/5c57d6ef16a7de000c2b32a0/visuals-small.jpg" data-sys-asset-uid="blt1af8714b20964974" alt="visuals-small.jpg"/> </td><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7193fa48ab952fe4/5c57d6e94c9f4feb0b4c5843/discover-small.jpg" data-sys-asset-uid="blt7193fa48ab952fe4" alt="discover-small.jpg"/> </td></tr></tbody></table><h3>Experiência do usuário</h3><p>O uso da UI de logs é semelhante a fazer tailing de um arquivo de log, mas com todos os seus logs de todos os seus sistemas disponíveis em um único console. Os logs são transmitidos e a parte inferior da visualização é o registro mais recente, assim como um tail -f. Por padrão, a UI de logs mostra todos os registros de todos os logs que atendem aos critérios de configuração (veremos mais sobre isso na próxima seção). Quando você está trabalhando em um problema e decide que não quer todos os seus logs, de todos os seus serviços, todos juntos (sendo transmitidos mais rápido do que qualquer um poderia ler), basta alterar a interação digitando na barra de busca na parte superior. Por exemplo, se eu quiser ver apenas erros 404 dos pods h do Apache com o rótulo do Kubernetes tier = "frontend", basta começar a digitar na barra de busca e deixar o preenchimento automático me ajudar a encontrar os logs certos:</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6f7988e6a847040c/5ca7ef626583cf3c4114a271/animated-gif-logs-ui-optimized.gif"/></p><p>Compare isso com abrir um terminal, autenticar-se com o provedor do k8s, descobrir quais pods você quer e executar kubectl logs -f … | grep 404 (ou no mundo sem container, encontrar os nomes dos hosts, entrar no SSH, fazer tailing dos logs etc.). Queremos facilitar sua vida e fornecer seus dados da maneira que você quer vê-los.</p><h3>Configuração</h3><p>Os <a href="/guide/en/kibana/6.x/xpack-logs.html">documentos da UI de logs</a> estão no local de sempre, mas destacarei algumas das opções de configuração aqui. Esta é a configuração padrão que você pode colar no config/kibana.yml e depois modificar a partir dos padrões:</p><pre class="prettyprint">xpack.infra.sources.default.logAlias: "filebeat-*"<br/>xpack.infra.sources.default.fields.timestamp: "@timestamp"<br/>xpack.infra.sources.default.fields.message: ['message', '@message']<br/></pre><p>A configuração é bem simples; logo de cara, as linhas que aparecem na UI de logs são o campo message de cada índice que corresponde ao alias filebeat-*. Então, e se você quiser adicionar todos os seus índices do Logstash? Basta modificar o xpack.infra.sources.default.logAlias na entrada do config/kibana.yml desta forma e reiniciar o Kibana:</p><pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*"<br/>xpack.infra.sources.default.logAlias: "filebeat-*,logstash-*"<br/></pre><p>Não se esqueça de reiniciar o Kibana. Abra a UI de logs novamente e clique em Stream Live. Você verá todos os seus logs do Logstash e do Filebeat sendo transmitidos para a UI de logs.</p><p><strong>Observação</strong>: se preferir usar <a href="/guide/en/elasticsearch/reference/6.5/indices-aliases.html">aliases do Elasticsearch</a>, defina xpack.infra.sources.default.logAlias como o nome do alias e atualize o alias conforme necessário. Aqui está o equivalente ao uso de um alias de logs</p><p>Crie o alias:</p><pre class="prettyprint">curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d'<br/>{<br/>    "actions" : [<br/>        { "add" : { "indices" : ["logstash-*", "filebeat-*"], "alias" : "logs" } }<br/>    ]<br/>}<br/>'<br/></pre><p>Atualize o config/kibana.yml:</p><pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*"<br/>xpack.infra.sources.default.logAlias: "logs"<br/></pre><h2>UI de infraestrutura</h2><h3>Motivação</h3><p>Vejo três níveis básicos de maturidade no gerenciamento da infraestrutura:</p><ol><li>Descobrir que algo está com problema e abrir um sistema de monitoramento para explorar.</li><li><span></span>Traçar gráficos dos principais indicadores de todos os sistemas em um grande dashboard e observar isso, depois analisar até encontrar os problemas.</li><li>Automatizar os operadores com machine learning descobrindo o comportamento normal, detectando problemas emergentes e alertando os operadores.</li></ol><p>A UI de infraestrutura foi desenvolvida para levar os operadores ao estágio de "traçar gráficos dos principais indicadores em um grande dashboard". É seguro dizer que todos nós precisamos chegar ao "estágio automatizado com machine learning"; você pode ler mais sobre o <a href="/pt/products/stack/machine-learning">machine learning da Elastic</a> e, se assistir ao vídeo no final deste post, verá um fluxo de trabalho que começa com um alerta de um trabalho de machine learning e progride a partir daí pelo APM e o rastreamento distribuído, a UI de infraestrutura e a UI de logs. Ter todos os logs, metrics, APM e rastreamento distribuído juntos no Elasticsearch permite usar todas as ferramentas de análise e visualização com todos os seus dados.</p><p>Vamos dar uma olhada na UI de infraestrutura e depois explorar. Nesta visualização, estamos olhando para os pods do Kubernetes, e eu os agrupo por espaço de nome. Eu estou olhando para o tráfego de rede de entrada. Ao clicar com o botão direito do mouse em um dos pods, posso ir para os logs desse pod ou para um dashboard de metrics selecionadas desse pod.</p><h3>Experiência do usuário</h3><p>Atualmente, três tipos de dispositivos são compatíveis: hosts, pods do Kubernetes (k8s) e containers do Docker. A vantagem da UI de infraestrutura é que você pode ver o estado dos principais indicadores de um número muito grande de dispositivos. Em grande volume, você tem quadrados coloridos sem texto até pesquisar um subconjunto interessante usando a barra de busca ou clicando em um grupo. Você também pode executar os logs de um dispositivo ou exibir um dashboard de metrics.</p><p>Eu mencionei "principais indicadores"; no momento, esta é a lista, e todos eles vêm do Metricbeat:</p><p style="margin-left: 20px;">Hosts: CPU, memória, carga, tráfego de entrada, tráfego de saída e taxa de log<br/>Kubernetes: CPU, memória, tráfego de entrada e tráfego de saída<br/>Docker: CPU, memória, tráfego de entrada e tráfego de saída</p><p>O agrupamento permite detalhar a lista de dispositivos. Se você dá suporte a um aplicativo específico implantado com o Kubernetes, o grupo "espaço de nome" é para você. Se você acha que um problema está relacionado a um nó específico que está sendo sobrecarregado, convém subdividir ainda mais agrupando por espaço de nome e nó. Aqui está a lista de agrupamentos no momento (e você pode usar até dois por tipo de dispositivo):</p><p style="margin-left: 20px;">Hosts: zona de disponibilidade, tipo de máquina, ID do projeto, provedor de serviços em nuvem<br/>Kubernetes: espaço de nome, nó<br/>Docker: host, zona de disponibilidade, tipo de máquina, ID do projeto, provedor</p><p>Se nenhum dos agrupamentos acima for compatível com a maneira como você quer interagir com seus dados, use a barra de busca. Basta começar a digitar e o recurso de preenchimento automático do <a href="/guide/en/kibana/6.5/kuery-query.html">Kibana Query Language</a> (KQL) guiará você. Eu forneci um exemplo no GIF da UI de logs na parte superior; quando comecei a digitar kubernetes, o Kibana ofereceu labels e depois tier e, então, forneceu as opções possíveis com base no que foi indexado no Elasticsearch.</p><p>Depois de agrupar os recursos, você pode pesquisar em um grupo clicando nele, o que lhe permite ver mais detalhes sobre esse grupo. Se um host, pod ou container específico lhe interessar, pesquise nos respectivos logs ou metrics. Aqui está uma parte da visualização da metric de um host:</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0db77ee61091f61f/5d2848c18e6f797b0da2f02e/screenshot-metrics-infrastructure-monitoring-feature-page.jpg"/></p><h3>Configuração</h3><p>Há muito pouca configuração a ser feita para a UI da infraestrutura. Basta implantar o Metricbeat e habilitar o <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-system.html">módulo System</a>. Se estiver executando containers, habilite também os módulos <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-kubernetes.html">Kubernetes</a> e <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-docker.html">Docker</a>.</p><p>A menos que você tenha modificado o padrão de indexação padrão (metricbeat-*), a configuração estará pronta. Se precisar personalizar as coisas, os <a href="/guide/en/kibana/6.x/xpack-infra.html">documentos da UI da infraestrutura</a> terão os detalhes. Incluo as principais opções aqui:</p><pre class="prettyprint">xpack.infra.sources.default.metricAlias: "metricbeat-*"<br/>xpack.infra.sources.default.fields.host: "beat.hostname"<br/>xpack.infra.sources.default.fields.container: "docker.container.name"<br/>xpack.infra.sources.default.fields.pod: "kubernetes.pod.name"<br/></pre><h2>Dê sua opinião</h2><p>Ambas as UIs estão na versão beta e gostaríamos muito de receber o seu feedback (e continuar recebendo-o mesmo depois da disponibilidade geral das UIs). Diga-nos como você prefere interagir com seus dados. Os agrupamentos nesta versão beta da UI de infraestrutura são suficientes para dar suporte à maneira como sua equipe está organizada? O que seria melhor? Temos as metrics corretas orientando as cores? Você precisa de uma maneira diferente de filtrar os logs na UI de logs? Quando você executa a visualização de metrics na UI de infraestrutura, vê as metrics mais relevantes para você?</p><p>Vá para o <a href="https://discuss.elastic.co/c/kibana">fórum de discussão do Kibana</a> e diga-nos o que você gosta, não gosta, precisa etc. Os desenvolvedores leem e respondem a essas discussões, e vão adorar saber a sua opinião. Você também pode abrir um registro de problema, enviar um PR ou ficar de olho no <a href="https://github.com/elastic/kibana">GitHub</a>.</p><h2>Entre e experimente</h2><p>Nosso <a href="https://demo.elastic.co/">sistema de demonstração</a> ao vivo tem logs e metrics que você pode buscar, visualizar e com os quais pode interagir. Acesse e clique no bloco Infrastructure para executar a UI de infraestrutura:</p><p><a href="https://demo.elastic.co"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc85a8861b14f7f05/5c57d682a669c2e50b763c45/JumpIn.jpg" data-sys-asset-uid="bltc85a8861b14f7f05" alt="JumpIn.jpg" width="200" height="187" style="width: 200;height: 187;"/></a></p><p>Você pode alternar para as visualizações do Kubernetes ou Docker, agrupar os objetos usando a UI ou restringir a visualização com a barra de busca. Clique com o botão esquerdo do mouse em um host, pod ou container e execute a UI de logs desse objeto. Enquanto estiver no demo.elastic.co, dê uma olhada em alguns dos dashboards e visualizações. Você pode navegar para diferentes áreas da <a href="https://demo.elastic.co/">página de destino</a>.</p><h2>Assista a uma demonstração</h2><p>Aqui está um vídeo que mostra o fluxo de trabalho dessas UIs (e também machine learning e APM com rastreamento distribuído). Mais uma vez obrigado pela leitura e pelo seu feedback!</p><div class="video embed-container" style="height: 478px;"><img style="width: 677;margin: auto;display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/78EpMXQeU57jR7HrKsMXqK.jpg" data-uuid="78EpMXQeU57jR7HrKsMXqK" data-v="4" data-type="inline" width="677"/></div>

infrastructure-and-logs-background.jpg

infrastructure-and-logs-thumbnail.jpg

Infrastructure and Logs UI: New ways for Ops to interact with Elasticsearch

UI de logs e de infraestrutura: novas maneiras de os operadores interagirem com o Elasticsearch

Monitore logs e métricas de Docker e Kubernetes com o Elastic Stack. Envie dados de containers com Beats, analise-os com o Elasticsearch e visualize no Kibana.

<p>Este post é sobre o monitoramento de um ambiente de containers, que pode incluir o <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a> (GKE), o <a href="https://www.ibm.com/cloud/container-service">IBM Cloud Kubernetes Service</a> e qualquer outro ambiente&nbsp;Kubernetes (k8s) e&nbsp;Docker. Neste post, usarei o IBM Cloud Kubernetes Service.
</p>
<p>Você deve estar se perguntando por que escrevo sobre o monitoramento de containers Docker e&nbsp;Kubernetes.&nbsp;Certamente,&nbsp;os provedores da nuvem estão gerenciando a infraestrutura para que eu possa me preocupar apenas com a minha aplicação, certo?  Você pode ter razão, mas eu sou o tipo de pessoa que lê as avaliações do Yelp mesmo se um conhecido me recomendar algum lugar, porque quanto mais informações eu tiver, melhor.  Eu quero ter todos os logs e métricas da minha aplicação e do ambiente dela, e quero também poder pesquisar, visualizar e receber alertas sobre tudo isso. Aquele monitoramento comum de containers é ótimo, mas eu também vou mostrar a você um jeito interessante de usar eventos e metadados do Kubernetes para anotar&nbsp;o gráfico de performance da minha aplicação com notificações sobre aumento de capacidade&nbsp;ou atualizações sem interrupção.
</p>
<p>Vamos definir alguns termos antes de continuar.
</p>
<ul>
	<li><strong>Log:</strong> é um carimbo de data/hora e uma mensagem.  Inclui entradas típicas de log, como “NGINX iniciou às 13h42” e eventos do k8s, como “Houve um recuo em um container do NGINX reinicializando container&nbsp;falho às 16h20.”</li>
	<li><strong>Métrica:</strong> uma medida numérica coletada em período predeterminado.  Por exemplo, “As vendas pelo site de e-commerce totalizaram US$ 50.000 nos últimos 10 minutos” ou “A utilização da CPU foi de 17% das 14:00:00&nbsp;às 14:00:10”.</li>
</ul>
<h2>Implantação de aplicações em um cluster do Kubernetes</h2>
<p>No meu exemplo, vou usar esta aplicação baseada em Apache HTTP Server, PHP e Redis.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb6c40127948a43cc/5c305565760e7f7a666d690f/k8s-module-1.png" data-sys-asset-uid="bltb6c40127948a43cc" alt="k8s-module-1.png">
</p>
<p>Além disso, para monitorar a aplicação e a infraestrutura de containers, temos:&nbsp;
</p>
<ul>
	<li>Uma implantação hospedada do Elasticsearch Service no Elastic Cloud.</li>
	<li><span></span>Beats, expedidores leves de logs e métricas implantados como um DaemonSet no mesmo cluster de Kubernetes.&nbsp; Observe que ele pode substituir o fluentd que é geralmente implantado em um cluster de Kubernetes.</li>
</ul>
<h2>Logs e métricas</h2>
<p>A aplicação acima é apenas uma parte de um ecossistema que está constantemente gerando informações úteis que devemos capturar. Estes são os níveis em que coletamos esses logs e métricas:
</p>
<ol>
	<li>Orquestração (Kubernetes)</li>
	<li><span></span>Hosts</li>
	<li>Aplicação</li>
	<li>Container (Docker)</li>
</ol>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd3029c1072fc382e/5c57e478bc5d07ed0b48c928/k8s-module-2.png" data-sys-asset-uid="bltd3029c1072fc382e" alt="k8s-module-2.png">
</p>
<p>Para coletar os dados, usamos os&nbsp;<a href="/pt/products/beats">Beats</a> (Filebeat, Metricbeat e Packetbeat) e os módulos System, Kubernetes e Docker juntamente com os módulos de aplicação (Apache e Redis).  Implantamos um <a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/">DaemonSet</a> para cada Beat e deixamos o Kubernetes gerenciá-los.  A lista parece longa, mas fique tranquilo, pois a descoberta automática dos Beats mantém a simplicidade do processo.&nbsp; Os detalhes sobre a implantação dos Beats para monitorar uma aplicação estão&nbsp;<a href="/pt/blog/monitoring-an-application-running-in-docker-containers-and-kubernetes-with-the-elastic-stack">neste post</a>&nbsp;e no vídeo que o acompanha.&nbsp; Para começar do início, confira a <a href="/pt/docker-kubernetes-container-monitoring">página de monitoramento de containers</a> da Elastic.<span></span>
</p>
<p>Para indexar, armazenar, pesquisar, analisar e visualizar os dados, eu usei o <a href="/pt/cloud/elasticsearch-service/signup">Elasticsearch Service hospedado</a>.&nbsp; A implantação do Elasticsearch Service no Elastic Cloud está <a href="/pt/start">detalhada em nossa página de introdução</a>, bem como a implantação do Elasticsearch e do Kibana em um sistema que você mesmo gerencia.&nbsp; De um jeito ou de outro, funciona bem.
</p>
<p>Eu mencionei Beats e módulos, e estes pontos merecem uma apresentação mais detalhada.  Um Beat é um agente leve que envia dados para o Elasticsearch e para o Logstash.  Em alguns casos, os Beats são implantados no ponto de origem dos dados, como em sistemas físicos ou virtuais, e, em outros, a implantação acontece paralela às fontes, por exemplo, como um DaemonSet (e esta é forma descrita neste post).  Os módulos simplificam o&nbsp;processo&nbsp;de coleta, análise, indexação e visualização de formatos comuns de logs.
</p>
<p>Isso soou meio enfadonho, mas deixe-me explicar melhor: os módulos do Elastic são uma experiência pré-empacotada.  Digamos que você saiba tudo sobre o gerenciamento do Apache HTTPD Server, mas&nbsp;NGINX é novidade para você.  Talvez você pergunte a alguém que conheça o NGINX: “O que você observa nos logs?  Que métricas você acompanha?  Tem como obter os greps do seu arquivo de histórico?”  As respostas a essas perguntas definem os módulos Beat para mim: dashboards prontos, pesquisas salvas, parsing e coleta para um monte de coisas, como &nbsp;Kubernetes, Docker, NGINX, Apache, sistemas operacionais, bancos de dados, etc.  Na minha experiência, é um conjunto de recursos bastante potente.
</p>
<p>O <a href="/guide/en/beats/metricbeat/current/metricbeat-module-kubernetes.html">módulo k8s</a> coleta métricas relacionadas a pods, nós, volumes, ReplicaSets, implantações, etc.  Cada métrica tem um&nbsp;conjunto rico de metadados para que você atrelar os dados à sua aplicação.  Por exemplo, talvez você não se importe que o pod <em>xyz</em> esteja próximo ao limite do uso de memória, mas se a métrica aparecer como associada ao front-end da sua aplicação, você saberá o valor dessa informação para o seu negócio. Ela também coleta eventos (lembre-se de que eu incluí os eventos de Kubernetes na definição de log acima), que usaremos para enriquecer um gráfico de performance no vídeo abaixo.
</p>
<p>O <a href="/guide/en/beats/metricbeat/current/metricbeat-module-docker.html">módulo do Docker</a> coleta métricas relacionadas a containers, hosts, memória, rede, checks de saúde, etc.  Assim como o módulo do Kubernetes, os metadados são muito valiosos para entender a performance da sua aplicação e do ambiente.
</p>
<p>Há muitos outros <a href="/guide/en/beats/filebeat/current/filebeat-modules.html">módulos para o Filebeat</a> e para o <a href="/guide/en/beats/metricbeat/current/metricbeat-modules.html">Metricbeat</a>.&nbsp; Além disso, o <a href="/guide/en/beats/packetbeat/current/visualizing-data-packetbeat.html">Packetbeat</a> vem com muitos dashboards para serviços como Cassandra, Flows, HTTP, MySQL, MongoDB, etc.
</p>
<p>Assista para ver como é fácil transformar dados em inteligência acionável. O vídeo mostra:
</p>
<ul>
	<li>Visualização de eventos de Kubernetes com métricas de performance da aplicação
	</li>
	<li>Aprofundamento no conjunto de métricas de eventos do módulo de Kubernetes do Metricbeat
	</li>
	<li>Navegação pelos eventos do Kubernetes e construção da visualização customizada</li>
</ul>
<div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/FMHRF7JA2JhmPqpTNm4edp.jpg" data-uuid="FMHRF7JA2JhmPqpTNm4edp" data-v="4" data-type="inline">
</div>

Mashup-dashboards.jpg

MetricBeatDocker-Dash.png

Monitoring Kubernetes and Docker Containers with Beats: Logs, Metrics, and Metadata

Monitoramento de Kubernetes e Containers Docker com os Beats: logs, métricas e metadados

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Customer Success Manager

Dan Roscigno

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Communication Preferences - ONLY for /communication-preferences

<p>Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/elastic-cloud-account-terms" target="_self">Termos de Serviço</a> e também concorda em receber <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">comunicações especiais</a> por meio dos dados de contato que forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Serverless GDPR Text

<p>Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/serverless-preview-terms" target="_self">Termos de Serviço</a> e que a Elastic pode <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">entrar em contato com você</a> para divulgar nossos produtos e serviços relacionados usando os dados que você forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.</p>

<p>By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.</p>

Cloud Trial GDPR Text

<p>Ao enviar, você concorda com os <a href="/pt/agreements/global/cloud-services-monthly" rel="nofollow">Termos de Serviço do Elastic Cloud</a>. Seus dados pessoais serão tratados de acordo com a <a href="/pt/legal/privacy-statement">Declaração de Privacidade da Elastic</a>.
</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Newsletter GDPR Text

<p>Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/terms-of-use" target="_self">Termos de Serviço</a> e que a Elastic pode <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">entrar em contato com você</a> para divulgar nossos produtos e serviços relacionados usando os dados que você forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.</p>

Explore similar demos

Explore outras demonstrações semelhantes

Overview

Load More

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

O conteúdo desta página não está disponível no idioma selecionado. A Elastic está trabalhando para garantir que o conteúdo esteja disponível em vários idiomas.Agradecemos a compreensão.

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

Consultar a hora de início do webinar no meu fuso horário

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

Não vai conseguir participar? Inscreva-se e nós lhe enviaremos a gravação. Você também receberá um email com conteúdo relacionado.

Author

Articles by Dan Roscigno

Customer Success Manager, Elastic

Observabilidade do Elasticsearch: adoção dos padrões do Prometheus e do OpenMetrics para métricas

UI de logs e de infraestrutura: novas maneiras de os operadores interagirem com o Elasticsearch

Monitoramento de Kubernetes e Containers Docker com os Beats: logs, métricas e metadados