Elasticsearch: o que é, como funciona e casos de uso para TI

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado jun/2015Atualizado set/2026

O Elasticsearch encontra um evento em terabytes de log porque inverte o índice: em vez de varrer documentos, ele salta direto para o termo. Esta página mostra como esse mecanismo funciona, os quatro usos que sustentam a adoção em TI e o que mudou no licenciamento.

Além disso, todo número aqui saiu de laboratório próprio, com Elasticsearch 9.5.2 em Docker, medido em 1º de setembro de 2026.

O Elasticsearch é um mecanismo de busca e análise distribuído, construído sobre o Apache Lucene. Ele indexa e consulta grandes volumes de dados estruturados e não estruturados em tempo quase real.

Criado para busca de texto em documentos, evoluiu até virar a base da stack ELK (Elasticsearch, Logstash, Kibana) e do Elastic Stack moderno. Hoje é a plataforma que empresas adotam para centralizar gerenciamento de logs, observabilidade e análise operacional em um único pipeline.

Como o Elasticsearch funciona: os conceitos essenciais

O Elasticsearch armazena dados como documentos JSON em índices. Cada documento é indexado de forma invertida, estrutura que recupera qualquer termo de qualquer campo em milissegundos, independentemente do volume total armazenado.

 
Antes da ingestão vem o mapping, porque o tipo do campo decide o que você consegue perguntar depois. Em campo text o servidor quebra o valor em termos e recusa agregação. Por outro lado, em campo keyword ele guarda o valor inteiro, agrupa e ordena.

# 1) sem mapping, o campo virou text e a agregacao falha
POST /logs-dinamico/_search
{ "size": 0, "aggs": { "por_servico": { "terms": { "field": "service.name" } } } }

# HTTP 400
# "Fielddata is disabled on [service.name] in [logs-dinamico]. Text fields
#  are not optimised for operations that require per-document field data
#  like aggregations and sorting (...). Please use a keyword field instead."

# 2) com mapping explicito, o mesmo campo agrega
PUT /app-logs-000001
{
  "settings": { "number_of_shards": 1, "number_of_replicas": 0, "refresh_interval": "1s" },
  "mappings": {
    "properties": {
      "@timestamp":  { "type": "date" },
      "service":     { "properties": { "name":  { "type": "keyword" } } },
      "log":         { "properties": { "level": { "type": "keyword" } } },
      "message":     { "type": "text", "analyzer": "standard" },
      "http":        { "properties": { "status": { "type": "short" } } },
      "duration_ms": { "type": "float" },
      "host":        { "properties": { "name":  { "type": "keyword" } } }
    }
  }
}

 
Com o tipo keyword no lugar, a mesma agregação respondeu em 8 ms sobre 5.000 documentos. Portanto, o mapping é decisão de operação, não detalhe de implantação.

Arquitetura distribuída

O Elasticsearch opera em clusters compostos por múltiplos nós. Cada índice é dividido em shards (fragmentos) que são distribuídos entre os nós e replicados para alta disponibilidade. Consequentemente, quando um nó falha, as réplicas garantem continuidade de serviço sem intervenção manual.

Essa arquitetura escala na horizontal: para crescer, você adiciona nós ao cluster. Por isso o Elasticsearch atende tanto ambientes de dezenas de gigabytes quanto pipelines com petabytes de telemetria.

Indexação e busca em tempo quase real

Quase real não quer dizer instantâneo. No laboratório, a escrita voltou em 8 ms, porém o documento só apareceu na busca 1.008 ms depois, na mediana de vinte sondas. Inclusive, em nenhuma das vinte a busca imediata encontrou o registro recém-gravado.

 
A causa é o refresh_interval, que a documentação da Elastic fixa em um segundo por padrão. É importante notar um detalhe: esse refresh automático só roda em índice que recebeu alguma busca nos últimos 30 segundos.

Por isso, o modo de escrita muda o que a aplicação enxerga logo depois de gravar. Os três modos abaixo saíram de dez escritas cada, no mesmo índice de 5.000 documentos.

 
Para equipes de NOC e SRE, o efeito prático aparece no incidente. O log de uma falha fica pesquisável em cerca de um segundo, sem esperar ciclo de batch ou ETL.

O Elastic Stack: os componentes que compõem a plataforma

O Elasticsearch raramente opera isolado. Ele é o núcleo do Elastic Stack, que integra quatro componentes principais com funções distintas.

Elasticsearch: motor de indexação, armazenamento e consulta. Responde às queries e processa as agregações. Portanto, é o componente que determina a velocidade e a escala de toda a plataforma.

Logstash: pipeline de ingestão e transformação de dados. Recebe eventos de múltiplas fontes (syslog, JDBC, Kafka, S3) e aplica filtros e parsers, como o Grok para log não estruturado. Em seguida, envia o dado transformado para o Elasticsearch.

Kibana: interface de visualização e exploração. Permite criar dashboards, consultas ad hoc via linguagem KQL, alertas e relatórios. Ou seja, é a camada com a qual gestores de TI e analistas de operações interagem diariamente.

Beats: agentes leves de coleta. Filebeat para logs, Metricbeat para métricas de sistema e rede, Packetbeat para tráfego de rede. Instalados nos hosts monitorados, enviam dados diretamente ao Elasticsearch ou ao Logstash com overhead mínimo.

Em ambientes modernos, o Elastic Agent unifica os Beats num único agente, gerenciado via Fleet. Dessa forma, o deployment e a atualização de políticas de monitoramento escalam sem esforço manual.

Casos de uso operacionais para equipes de TI

Para gestores e analistas de TI, o valor do Elasticsearch está nos problemas concretos que ele resolve na operação.

Centralização e análise de logs

Ambientes corporativos geram logs de dezenas de fontes: sistemas operacionais, aplicações, firewalls, switches, bancos de dados. No entanto, sem centralização, cada análise de incidente exige acesso manual a vários sistemas.

Com o Elastic Stack, um único índice recebe todos esses logs, correlacionados por timestamp e pesquisáveis em segundos. Assim, o analista chega à causa raiz cruzando log de aplicação com evento de infraestrutura numa consulta só.

 
Na prática, essa consulta combina três filtros e uma busca textual no mesmo corpo.

# 5.000 documentos no indice, janela de duas horas
POST /app-logs-000001/_search
{
  "size": 2,
  "query": {
    "bool": {
      "filter": [
        { "term":  { "service.name": "checkout" } },
        { "term":  { "log.level": "ERROR" } },
        { "range": { "@timestamp": { "gte": "2026-09-01T09:00:00Z", "lt": "2026-09-01T11:00:00Z" } } }
      ],
      "must": [ { "match": { "message": "timeout" } } ]
    }
  },
  "sort": [ { "@timestamp": "desc" } ]
}

# resposta do servidor, primeiro dos 93 documentos
{
  "took": 2,
  "hits": {
    "total": { "value": 93, "relation": "eq" },
    "hits": [ { "_source": {
      "@timestamp": "2026-09-01T09:58:13.700Z",
      "service": { "name": "checkout" },
      "log": { "level": "ERROR" },
      "message": "gateway timeout no provedor (id=4991)",
      "http": { "status": 500 },
      "duration_ms": 2581,
      "host": { "name": "app-01" }
    } } ]
  }
}

 
O filter não pontua e fica em cache, enquanto o must pontua e ordena por relevância. Logo, a resposta segue em milissegundos mesmo quando o índice cresce.

Agregada por serviço, a mesma janela mostra onde doeu. O checkout somou 1.532 eventos com 132 erros e p95 de 2.754 ms, contra 218 ms do catálogo.

 
No Kibana, essa consulta vira a tela que o analista abre durante o incidente.

Observabilidade de infraestrutura e aplicações

O Elastic Stack suporta os três pilares da observabilidade: logs, métricas e traces (rastreamento distribuído via Elastic APM).

Equipes de SRE usam essa combinação para diagnosticar degradação de performance em microsserviços. A correlação aponta em qual serviço a latência nasce e qual transação ela atinge. Como resultado, cai o MTTD e o MTTR em incidentes de produção.

SIEM (Security Information and Event Management)

O Elastic Security usa o Elasticsearch como backend para correlacionar eventos de segurança em tempo real: logins suspeitos, movimentação lateral, exfiltração de dados.

Indexar e consultar volumes altos de eventos de várias fontes ao mesmo tempo faz do Elasticsearch uma alternativa ao SIEM proprietário. Sobretudo em ambientes de médio e grande porte, a vantagem de custo pesa na decisão. Assim, o SOC corta o tempo de triagem de alerta.

Monitoramento de performance de aplicações (APM)

O Elastic APM instrumenta aplicações em Java, Python, Node.js, .NET e Go. A instrumentação captura transações, queries de banco de dados e chamadas a serviços externos.

Como resultado, o time enxerga em qual ponto o tempo de resposta se concentra. Com isso, times de desenvolvimento e operações priorizam otimizações com base em dados reais de produção.

Elasticsearch e OpenTelemetry: a integração que muda o padrão

Nas versões mais recentes, o Elastic Stack padronizou sua ingestão no OpenTelemetry, protocolo aberto para coleta de telemetria.

Ou seja, dado coletado por qualquer ferramenta compatível com OTel entra direto no Elasticsearch, sem lock-in de agente proprietário. Isso vale, inclusive, para Prometheus, Jaeger e para a instrumentação nativa dos frameworks.

Para gestores de TI, essa integração reduz a resistência de adoção em ambiente heterogêneo. Além disso, facilita unificar stacks de monitoramento fragmentadas numa plataforma só.

Conclusão

O Elasticsearch deixou de ser só uma ferramenta de busca. Hoje é a plataforma de análise operacional para equipes de TI que precisam de velocidade, escala e correlação em tempo real.

Para gestores de operações, o valor está em centralizar logs, métricas e traces num único pipeline pesquisável. Dessa forma, o diagnóstico encurta, a infraestrutura ganha visibilidade e práticas de SRE e DevOps passam a rodar com dados confiáveis.

A OpServices integra o Elastic Stack em ambientes corporativos complexos. O trabalho combina coleta de dados, dashboards operacionais e alertas para equipes de NOC e SRE. Para estruturar a observabilidade da sua operação, fale com nossos especialistas.