Apresentamos o Elastic Common Schema
Apresentamos o Elastic Common Schema (ECS), uma nova especificação que oferece uma forma consistente e customizável de estruturar seus dados no Elasticsearch, facilitando a análise dos dados de diversas fontes. Com o ECS, conteúdo de analítica como dashboards e trabalhos de machine learning podem ser aplicados de forma mais ampla, as buscas podem ser elaboradas de maneira mais restrita e os campos de nomes são mais fáceis de lembrar.
Por que usar o Common Schema?
Ao realizar análises interativas (por exemplo, busca, detalhamento e pivoting ou visualização) ou análises automatizadas (por exemplo, alerta, detecção de anomalia orientada por machine learning), você precisa conseguir examinar seus dados com uniformidade. Porém, a menos que seus dados se originem de uma só fonte, você enfrentará inconsistências de formatação como resultado de:
- Tipos de dados díspares (por exemplo, logs, métricas, APM, fluxos, dados contextuais)
- Ambientes heterogêneos com diversos padrões de fornecedor
- Fontes de dados similares, mas diferentes (por exemplo, várias fontes de dados de endpoint, como Auditbeat, Cylance e Tanium)
Imagine fazer uma busca por um usuário específico em dados originários de diferentes fontes. Só para fazer a busca por esse único campo, você precisaria conhecer diversos nomes de campos, como user, username, nginx.access.user_name e login. Fazer detalhamento e pivoting nesses dados seria um desafio ainda maior. Agora imagine desenvolver conteúdo de analítica, como uma visualização, alerta ou trabalho de machine learning; cada nova fonte de dados adicionaria complexidade ou duplicidade.
O que é o Elastic Common Schema?
O ECS é uma especificação open source que define um conjunto comum de campos de documentos para dados ingeridos no Elasticsearch. Ele foi criado para dar suporte à modelagem de dados uniforme, permitindo que você analise de maneira centralizada dados de diversas fontes com técnicas interativas e automatizadas.
O ECS oferece a previsibilidade de uma taxonomia criada para fins específicos e a versatilidade de uma especificação inclusiva que se adapta para atender a casos de uso customizados. A taxonomia do ECS distribui os elementos de dados entre os campos, que são organizados nos seguintes níveis:
| Nível | Descrição | Recomendação |
| Campos centrais do ECS | Um conjunto totalmente definido de nomes de campos que existe sob um conjunto definido de objetos top-level do ECS | Estes campos são comuns à maioria dos casos de uso. É aqui que deve começar o seu trabalho. |
| Campos estendidos do ECS | Um conjunto parcialmente definido de nomes de campos que existe sob o mesmo conjunto de objetos top-level do ECS | Os campos estendidos podem se aplicar a casos de uso mais restritos ou ser mais abertos a interpretação, dependendo do caso. |
| Campos customizados | Um conjunto de campos indefinidos e sem nome que existe sob um conjunto fornecido pelo usuário de objetos top-level não ECS que não pode estar em conflito com campos ou objetos do ECS | É aqui que você pode adicionar campos para os quais o ECS não tem um campo correspondente. Também é possível manter uma cópia dos campos de evento originais aqui, por exemplo, na hora de fazer a transição dos seus dados para o ECS. |
Elastic Common Schema em ação
Exemplo 1: análise
Vamos colocar o ECS para trabalhar no seguinte log do Apache:
10.42.42.42 - - [07/Dec/2018:11:05:07 +0100] "GET /blog HTTP/1.1" 200 2571 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"
O mapeamento dessa mensagem para o ECS organiza os campos do log da seguinte maneira:
| Nome do campo | Valor | Notas |
| @timestamp | 2018-12-07T11:05:07.000Z | |
| ecs.version | 1.0.0 | |
| event.dataset | apache.access | |
| event.original | 10.42.42.42 - - [07/Dec ... | Log completo sem modificação para auditoria |
| http.request.method | get | |
| http.response.body.bytes | 2571 | |
| http.response.status_code | 200 | |
| http.version | 1.1 | |
| host.hostname | webserver-blog-prod | |
| message | "GET /blog HTTP/1.1" 200 2571 | Representação em texto das significativas informações do evento para exibição sucinta em um visualizador de log |
| service.name | Company blog | Seu nome customizado para esse serviço |
| service.type | apache | |
| source.geo.* | Campos para geolocalização | |
| source.ip | 10.42.42.42 | |
| url.original | /blog | |
| user.name | - | |
| user_agent.* | Campos que descrevem o agente do usuário |
Conforme mostrado acima, o log bruto é preservado no campo event.original do ECS para dar suporte a casos de uso de auditoria. Observe também que, para fins de simplicidade, esse exemplo omite detalhes sobre o agente de monitoramento (em agent.*), alguns detalhes sobre o host (em host.*) e mais alguns campos. Para uma representação mais completa, veja este evento de exemplo em JSON.
Exemplo 2: busca
Considere uma investigação sobre a atividade de um IP específico em uma web stack completa: Palo Alto Networks Firewall, HAProxy (conforme processado pelo Logstash), Apache (usando o módulo Beats), Elastic APM e, para completar, Suricata IDS (customizado, usando o formato EVE JSON).
Antes do ECS, sua busca por esse IP seria mais ou menos assim:
src:10.42.42.42 OR client_ip:10.42.42.42 OR apache2.access.remote_ip:10.42.42.42 OR context.user.ip:10.42.42.42 OR src_ip:10.42.42.42
Mas se você mapeasse todas as fontes para o ECS, sua consulta seria muito mais simples:
source.ip:10.42.42.42
Exemplo 3: visualização
É mais fácil ver o poder do ECS ao observar como ele pode ser aplicado a dados normalizados uniformemente de diversas fontes diferentes. Talvez você esteja monitorando sua web stack para ameaças com diversas fontes de dados de rede, um Palo Alto Next-Gen Firewall no perímetro e o Suricata IDS gerando eventos e alertas. Como você extrai os campos source.ip e network.direction de cada mensagem de forma a possibilitar a visualização centralizada no Kibana e detalhamento e pivoting independente de fornecedor? Com o ECS, é claro. Que permite que você realize um monitoramento centralizado de forma muito mais fácil.
Vantagens do Elastic Common Schema
A implementação do ECS unifica todos os modos de análise disponíveis no Elastic Stack, incluindo busca, detalhamento e pivoting, visualização de dados, detecção de anomalia com base em machine learning e alerta. Ao adotá-lo de forma completa, o usuário pode fazer buscas com parâmetros de consulta estruturada e não estruturada. O ECS também simplifica a correlação de dados automática de diferentes fontes de dados, seja em dispositivos diferentes de um único fornecedor ou de tipos de fontes de dados completamente diferentes.
O ECS também reduz o tempo que sua equipe gasta desenvolvendo conteúdo de analítica. Em vez de criar novas buscas e dashboards toda vez que sua organização adicionar uma nova fonte de dados, você poderá continuar aproveitando os existentes. Com o ECS, também é mais fácil para o seu ambiente adotar conteúdo de analítica diretamente de outras partes que usem o ECS, seja a Elastic, um parceiro ou um projeto open source.
Na realização de uma análise interativa com o ECS, é mais fácil lembrar nomes de campos comumente usados porque só existe um conjunto, não um conjunto diferente para cada fonte de dados. Deduzir nomes de campos esquecidos também é mais fácil com o ECS porque (com algumas poucas exceções) a especificação segue uma convenção de nomenclatura simples e padrão.
Não quer começar a adotar o ECS? Não tem problema. Ele estará aqui quando você precisar.
Como começar a usar o Elastic Common Schema
O ECS está disponível para a sua análise por meio de um repositório público do GitHub. A especificação está em Beta2 e deve passar para disponibilidade geral em breve. Ele está publicado sob a licença Apache 2.0 open source, o que garante adoção universal pela comunidade Elastic mais ampla.
Parece “automágico”, não? Bom, assim como qualquer esquema, implementar o ECS não é exatamente simples. Mas se você já configurou um modelo de índice do Elasticsearch e escreveu algumas funções transform com o Logstash ou o nó de ingestão do Elasticsearch, já tem uma noção do que isso envolve. As próximas versões dos módulos do Elastic Beats produzirão eventos formatados para ECS por padrão, o que facilita essa parte da transição. O novo módulo do sistema para o Auditbeat é o primeiro de muitos.
Saiba mais sobre o ECS em nosso webinar do Elastic Common Schema (ECS). Nos próximos posts do blog, falaremos sobre como mapear seus dados para o ECS (o que inclui campos que não estão definidos no esquema) e estratégias para migrar para o ECS.
Seja qual for o seu feedback sobre o ECS, gostaríamos de saber a sua opinião. Você pode compartilhar suas ideias por meio de um problema no GitHub ou sugerir atualizações de código por meio do protocolo descrito no ECS Contribution Guide (Guia de Contribuição do ECS).
O que vem a seguir para o Elastic Common Schema?
Com o tempo, esperamos que o alinhamento com o ECS se torne uma prática recomendada para muitos casos de uso de logging, métricas e APM (se não todos). Planejamos continuar investindo em seu desenvolvimento contínuo, com a inclusão de suporte para mais casos de uso.
Somos gratos a todos que contribuíram para o desenvolvimento do ECS — agradecemos a sua ajuda para garantir sua relevância para os diversos casos de uso da comunidade Elastic mais ampla.