Uma consulta, projetos ilimitados do Elasticsearch Serverless: apresentamos a busca entre projetos

A busca entre projetos (CPS) agora está disponível no Elastic Cloud Serverless. Com uma única consulta como FROM logs*, você pode buscar dados em vários projetos isolados, sem peering de rede, sem gerenciamento de certificados, sem duplicação de dados. Os projetos permanecem nas próprias regiões e nuvens; só os resultados voltam para você. Para equipes que lidam com requisitos de residência de dados, isolamento de tenants ou altos custos de saída decorrentes da cópia de logs, o CPS significa que seus dados podem residir exatamente onde devem estar e ainda serem consultados como um único conjunto.

O Elastic Cloud Serverless já elimina a dor de cabeça de gerenciar infraestrutura e atualizações de versão. O CPS vai além. Substituímos o complexo peering de rede e o gerenciamento manual de certificados por um modelo de vinculação simples. Agora, você pode tratar seus projetos Elastic Cloud Serverless como espaços de nome simples para seus dados. Seja lidando com leis rígidas de residência de dados, isolando dados de tenant ou apenas tentando evitar as enormes taxas de saída de rede que surgem da duplicação de logs, o CPS permite que você busque seus dados exatamente onde eles estão com uma única consulta.

Neste post, vamos explicar como funciona o CPS, como controlar as buscas usando tags de projeto e como esse novo modelo difere da busca entre clusters (CCS) tradicional.

Como vincular projetos para busca entre projetos

Para começar com a busca entre projetos, vincule os projetos no console Elastic Cloud ou na API. O vínculo é simples e unidirecional: você escolhe um projeto de origem e conecta os projetos que ele deve buscar. Essas ligações podem abranger regiões, provedores de serviços em nuvem e tipos de projeto, para que seus dados permaneçam onde pertencem sem abrir mão de uma experiência de busca unificada.

Depois que o link é criado, ele geralmente está ativo em um minuto. Se você já está com o Kibana aberto, atualize para ver as novas capacidades de busca entre projetos.

Como a busca nos projetos consulta todos os projetos vinculados por padrão

Depois que os projetos estejam vinculados, a busca entre projetos transforma projetos separados em uma única superfície de busca lógica. Se seus logs aparecem em vários projetos, uma consulta como FROM logs* busca o projeto de origem e qualquer projeto vinculado que tenha dados correspondentes. Você não precisa nomear cada alvo remoto antecipadamente.

Isso já é uma melhoria em relação à busca entre clusters. No CCS, alcançar dados locais e remotos geralmente significa algo como FROM logs*,*:logs*. Para os usuários, isso significa menos complexidade de consulta. Para as equipes, isso nos aproxima de um verdadeiro painel único entre os dados distribuídos.

Para mais informações, veja a documentação do modelo de busca do CPS.

Se você tem interesse em saber detalhes técnicos de como criamos isso, veja Como funciona a busca entre projetos (CPS) no Elasticsearch Serverless.

Controle de buscas via roteamento de projetos

A possibilidade de buscar em todos os projetos vinculados por padrão é conveniente e útil para muitos fluxos de trabalho, mas nem toda pesquisa deve abranger todos os lugares. A busca entre projetos introduz o roteamento por projeto, uma forma de limitar uma consulta a um subconjunto específico de projetos.

Ele funciona por meio de tags de projeto definidas no Elastic Cloud. Cada projeto possui atributos integrados, como o alias, provedor de serviços em nuvem e região. Você também pode adicionar suas próprias tags para refletir como sua organização vê seu patrimônio, como environment:prod, environment:test, uma unidade de negócio ou um nome de cliente. O Elasticsearch pode então usar esses metadados para decidir quais projetos vinculados devem participar de uma busca.

Todos os endpoints Elasticsearch compatíveis com busca entre projetos aceitam um parâmetro project_routing. Na pré-visualização técnica, o roteamento é limitado ao uso de alias do projeto. Por exemplo, definir project_routing como _alias:my-linked-project envia a consulta somente para esse projeto vinculado, enquanto _alias:_origin mantém a consulta no projeto de origem. Com o tempo, esse modelo abre as portas para um roteamento muito mais rico, em que o escopo da pesquisa pode seguir a estrutura lógica da sua organização em vez do layout físico da sua infraestrutura.

Consulte os documentos de roteamento do projeto para ver exemplos e mais detalhes sobre como eles funcionam.

Roteamento padrão de projeto em nível de espaço Kibana

Como exemplo de uma situação em que é necessária mais precisão no roteamento da sua busca, pesquisar todos os projetos vinculados pode gerar uma enxurrada de falsos positivos nas suas regras do Kibana ou resultados confusos nos seus dashboards existentes. Para resolver isso, você pode definir um escopo padrão de projeto em nível de espaço no Kibana. Funciona como uma predefinição segura para aquele espaço específico, ou seja, todos os dashboards, sessões de descoberta e regras de alerta o respeitam automaticamente. Analistas ainda podem alterar manualmente o escopo durante uma investigação se precisarem de uma visão mais ampla.

Isso é importante para equipes que compartilham um projeto central, como MSPs, MSSPs e centros de excelência: você pode atribuir a cada equipe o próprio espaço no Kibana e restringir o acesso para consultar apenas os projetos específicos dos seus clientes, garantindo experiências personalizadas para cada tenant. Analistas ainda podem alterar manualmente o escopo durante uma investigação se precisarem de uma visão mais ampla.

Você pode configurar esse padrão do Space antes ou depois de vincular seus projetos na UI da nuvem. Mas como o CPS ativa imediatamente o comportamento de "pesquisar tudo" assim que um link é criado, definir seus padrões de Kibana primeiro garante que suas regras de detecção existentes não sejam executadas repentinamente contra um enorme conjunto global de dados e sobrecarreguem sua equipe.

Uso de tags em pesquisas

Além de usar tags para roteamento de projetos, você também pode usar tags nas suas consultas ES|QL e _search. Isso pode ser útil para identificar de onde veio cada registro ou linha em um conjunto de resultados, ou para ordenar, filtrar ou agregar por essas tags.

Por exemplo, se você quiser ver de qual projeto cada linha em uma resposta ES|QL veio, você pode adicionar a tag _project._alias à consulta ES|QL:

E isso permite que você use _project._alias em outras partes da consulta, incluindo cláusulas KEEP para que ela apareça no resultado final:

Para mais exemplos de uso de tags em consultas, veja este documento que descreve como usá-las tanto em APIs de busca quanto no ES|QL.

Se você tem interesse em saber detalhes técnicos de como adicionamos tags às consultas do Search e ES|QL, veja busca mais rápida entre projetos no Elasticsearch Serverless com tags de projeto e roteamento.

Como a busca entre projetos lida igualmente com projetos de origem e vinculados

Se você já usou CCS, talvez saiba que o cluster local é tratado de forma diferente dos clusters remotos em alguns aspectos.

• Erros do cluster local são tratados de forma diferente dos erros dos clusters remotos. Em particular, o CCS usa a configuração skip_unavailable para controlar como os erros de clusters remotos se comportam, mas essa configuração não existe para o cluster local.
• O cluster local não tem um "alias de cluster", então a expressão de índice *:logs* pesquisa todos os projetos remotos, mas ignora o cluster local. Para buscar ambos, você precisa usar a expressão de índice logs*,*:logs*.

No CPS, mudamos ambos os comportamentos para colocar o projeto de origem e os projetos vinculados em um nível mais equilibrado.

Primeiro, a configuração skip_unavailable não é usada no Elastic Cloud Serverless. Em vez disso, você controla se deseja resultados parciais em uma busca via o parâmetro allow_partial_search_results em _search ou _async_search ou o parâmetro allow_partial_results em ES|QL.

Segundo, no Elastic Cloud Serverless, o projeto de origem tem um alias de projeto. Ele é definido no Elastic Cloud assim como todas as tags de projeto. Assim, no CPS, todas as consultas abaixo são equivalentes, elas direcionam todos os projetos com um índice de "logs":

Observação: existe uma diferença importante entre a expressão de índice qualificada *:logs e a expressão não qualificada logs em termos de como funciona o tratamento de erros em torno de índices ausentes. Para mais detalhes, consulte Expressões de pesquisa não qualificadas e qualificadas na documentação pública.

Controle de acesso e modelo de segurança para fazer busca entre projetos

A Elastic criou um novo modelo de segurança baseado na nuvem, o Gerenciamento universal de identidade e acesso (UIAM), que permite um princípio fundamental para a busca entre projetos: os projetos e dados que você pode acessar não dependem de onde você os acessa.

Independentemente de você iniciar uma pesquisa em seu projeto de observabilidade principal ou em um projeto de análise ad hoc, seu acesso aos dados vinculados permanece consistente, pois os direitos de acesso foram definidos em um local centralizado. O modelo de autenticação e autorização baseado em nuvem utiliza o serviço UIAM em nuvem para garantir que suas permissões de acesso sejam uniformes, independentemente do projeto de origem.

Experimente a busca entre projetos

Por fim, o Elastic Cloud Serverless e o CPS juntos reduzem o atrito operacional e oferecem opções adicionais para organizar os dados com base em considerações lógicas, em vez de considerações físicas ou operacionais. A busca entre projetos permite que seus usuário se concentrem exclusivamente na organização lógica dos dados, oferecendo uma experiência de busca unificada sem as complexidades físicas do passado.

Perguntas frequentes