A sigla SRE (Site Reliability Engineering) é comumente associada à confiabilidade e à operação de sistemas, mas o "S" de SRE tem um significado fundamental: serviço. Este termo engloba tanto aplicações quanto microserviços. Em um ambiente controlado, onde a quantidade de microserviços é limitada, o gerenciamento da confiabilidade pode parecer simples. No entanto, à medida que o número de serviços cresce — chegando a 10.000 microserviços ou mais, com centenas de sistemas legados — a complexidade das operações aumenta exponencialmente. É nesse cenário que as falhas nos serviços se tornam cada vez mais difíceis de resolver.

A detecção do problema, embora possível por meio de um trace distribuído, apresenta um desafio significativo: diferenciar um erro técnico de um erro de negócios. Sem uma compreensão clara do contexto do negócio, é impossível medir a perda e o impacto de uma falha com precisão. Portanto, é essencial adotar uma abordagem que incorpore eventos, que podem conectar a camada de negócios à camada de infraestrutura tecnológica. Com isso, enquanto os traces correlacionam os serviços de aplicação e os recursos de infraestrutura, os eventos fazem a ponte entre o negócio e a TI.

Para entender e agir rapidamente diante de falhas, é necessário desenvolver painéis de observabilidade que permitam correlacionar dados com precisão. A construção de tais painéis exige uma compreensão profunda da estrutura e da relação entre os identificadores (IDs) utilizados para rastrear e agrupar os dados. Por exemplo, em um processo de transferência de fundos, um Payment ID pode englobar múltiplos Trace IDs, os quais, por sua vez, podem ser subdivididos em Span IDs e Thread IDs, todos conectados por System Trace IDs. Cada camada desses identificadores traz informações cruciais para entender o comportamento do sistema e identificar falhas.

Para construir uma solução eficaz, é preciso definir um filtro no painel que organize esses identificadores de forma que facilite a análise da jornada do usuário. Isso é feito seguindo uma ordem que começa pelo nome da jornada do usuário, seguido pelo Payment ID, Trace ID, Span ID, Thread ID, e, finalmente, o System Trace ID. Os dados dos traces distribuídos e da infraestrutura serão exibidos de forma cronológica, permitindo uma visualização clara de latências e falhas. A configuração de painéis também pode ser expandida para incluir ferramentas como o eBPF e PCP, que permitem medições de percentis, como o 99º, para uma análise ainda mais detalhada da performance.

A observabilidade eficaz exige que SREs não apenas compreendam a aplicação e seus microserviços, mas também o contexto do negócio e os recursos do sistema. A compreensão da estrutura dos identificadores é fundamental para integrar de forma eficiente os dados e gerar informações úteis para a análise de falhas. Isso elimina a necessidade de ajustes no código ou de pré-processamento pesado, tornando o processo mais ágil e menos propenso a erros.

Em termos de tecnologia, existe uma distinção clara entre as ofertas comerciais e as soluções de código aberto. As soluções comerciais frequentemente vêm com modelos sofisticados de dados, permitindo uma fácil medição da confiabilidade do serviço e melhoria no MTTR (Mean Time to Repair). No entanto, as configurações comerciais têm limitações e frequentemente necessitam da complementação com ferramentas open-source para preencher as lacunas, como o Grafana, Pyroscope, Promscale, OpenSearch, Performance Copilot, entre outras.

Além disso, a criação de um painel de observabilidade eficiente exige mais do que simplesmente listar os SLOs (Service Level Objectives). O painel deve refletir os processos de negócios e contar uma história clara. Para isso, é fundamental compreender a relação entre Request IDs, Order IDs, Payment IDs e Trace IDs, e como esses elementos se conectam em um fluxo contínuo de dados. Somente assim será possível entender a jornada do usuário, identificar falhas e agir rapidamente.

Para garantir uma implementação bem-sucedida, a estrutura dos dados deve ser armazenada e organizada em uma tabela de estilo big data, que minimize a necessidade de junções desnecessárias e consultas excessivas. Ao estruturar seus dados dessa maneira, os SREs serão capazes de gerar resultados rápidos e precisos com base em uma única tabela de consulta.

Por fim, ao planejar a observabilidade e implementar AIOps, é essencial garantir que os painéis e alertas sejam relevantes para os processos de negócios, pois somente assim a solução será eficaz na detecção e correção de falhas. Quando se compreende completamente a estrutura dos identificadores e sua conexão com os processos de negócios, encontrar a "história" por trás dos dados se torna um processo mais intuitivo e poderoso.

Como construir observabilidade em microserviços e serviços legados com ferramentas open-source

Construir uma observabilidade eficaz utilizando ferramentas open-source é uma tarefa desafiadora e complexa. O processamento interno dessas ferramentas segue um modelo separado de leitura e escrita, tal como ocorre com microserviços, e a escala dos dados que processam é imensa, muitas vezes envolvendo Big Data. Esse ambiente, embora poderoso, está longe de ser perfeito e apresenta várias falhas comuns. Entre os problemas mais frequentes, encontram-se: atrasos nas rotas de leitura e escrita, falhas no pipeline, duplicação e perda de dados, agentes fora do ar, falhas em discos, interrupções no caminho de escrita em grande escala, ou até mesmo a falha de clusters de cache Redis. A coleta de dados em ambientes de múltiplas instâncias, por sua vez, é uma tarefa árdua e repleta de obstáculos.

Não é raro que agentes e o Prometheus sejam reiniciados devido a erros OOM (Out Of Memory). Quando um problema, como um vazamento de memória lento ou um deadlock raro, afeta apenas algumas instâncias, torna-se difícil detectá-lo. Mesmo que a detecção seja bem-sucedida, as instâncias podem já ter sido desligadas, e o problema pode não ser mais visível. Reproduzir o erro em uma instância específica de um processo em execução é um desafio, especialmente quando se tenta coletar um perfil ou um dump da aplicação. No caso de um deadlock de thread, um perfil de CPU pode não estar mais disponível, assim como, em erros OOM, um perfil de memória não seria possível. Para esses casos, é essencial capturar um dump, já que os perfis, muitas vezes, não conseguem fornecer dados completos.

Ao contrário da observabilidade de aplicações sob a perspectiva do serviço do usuário, a observabilidade de infraestrutura depende dos recursos do sistema e envolve interações complexas entre a CPU, o kernel e a I/O. Diferentemente de uma visão mais direta, como os processos de negócios ou o rastreamento distribuído, a observabilidade de infraestrutura tem um caráter mais profundo e técnico, com desafios adicionais, como identificar procedimentos ou pessoas responsáveis. Métricas, perfis e logs, sozinhos, não são suficientes para visualizar o processo que ocorre no nível da infraestrutura. O uso do eBPF, uma ferramenta de perfil, ainda não se popularizou, já que operadores de infraestrutura estão mais acostumados a utilizar utilitários do sistema. A maior parte da observabilidade de infraestrutura ainda se concentra em métricas e logs, o que exige tempo e investimento significativo para identificar e resolver problemas.

As métricas fornecem uma visão geral sobre a atividade do sistema, contabilizando eventos como acessos a disco, interrupções, erros de memória, falhas no cache L1 e quantidade de dados transmitidos pela rede. Embora úteis para identificar uma anomalia, como um aumento abrupto na taxa de erro ou na inacessibilidade repentina de uma unidade de disco, as métricas sozinhas não fornecem detalhes suficientes sobre os processos internos do sistema. Elas ajudam a entender a carga ou a velocidade geral, mas não detalham a causa raiz de um problema. As métricas podem incluir eventos relacionados à CPU, memória, disco, rede, bloqueios e esperas, mas não capturam o contexto das falhas de forma granular.

Por outro lado, os perfis coletam uma quantidade específica de amostras periodicamente. No entanto, o perfil não é capaz de identificar o tempo que um programa ficou aguardando para ser executado, uma vez que o valor do contador de programa (PC) que registra o código do núcleo da CPU pode não refletir a realidade de execuções anormais. Perfis ajudam a entender o desempenho médio da CPU, mas podem ocultar comportamentos anormais, misturando execuções normais e anormais, além de não mostrar latência ou o tempo de início e término do programa.

Os logs, por sua vez, funcionam como um tipo de rastreamento, registrando mensagens com timestamp, úteis para eventos como inicializações, reinicializações e falhas. No entanto, os logs são mais eficazes para desenvolvedores de aplicativos, já que a sua aplicabilidade na observabilidade de infraestrutura é limitada. Para visualizar os processos internos da infraestrutura e identificar rapidamente onde os problemas estão ocorrendo, é preciso de uma ferramenta que permita um rastreamento mais detalhado, como o trace distribuído utilizado para a observabilidade de aplicações.

Traces de sistema coletam eventos dos recursos do sistema e os apresentam em spans. Ferramentas como KUtrace, strace e ftrace permitem rastrear esses eventos, ajudando a identificar a latência nos recursos do sistema de forma semelhante ao trace distribuído em observabilidade de aplicações. Esses traces fornecem um histórico completo de chamadas de sistema, como acessos a disco ou transmissões de pacotes, e possibilitam a identificação de processos que não são externamente visíveis, como o código do kernel e o acesso a bibliotecas do sistema.

Apesar de seu valor, os traces de sistema sozinhos não são suficientes para garantir uma observabilidade completa. Eles devem ser usados em conjunto com outras fontes de dados, como métricas e perfis. As métricas fornecem a utilização dos recursos do sistema e as taxas de saturação, permitindo a configuração de dashboards como o USE (Utilization, Saturation, Errors). O uso de KUtrace, por exemplo, pode ajudar a identificar as áreas onde a latência está ocorrendo. Após essa identificação, pode-se utilizar os perfis para analisar os métodos que causaram a latência no código, utilizando ferramentas como o BCC e o bpftrace, que selecionam métodos problemáticos e analisam o número de chamadas e a latência desses métodos.

A observabilidade de infraestrutura segue uma sequência lógica: métricas, KUtrace, ftrace, e eBPF. O PCP (Performance Co-Pilot) é uma ferramenta útil para visualizar os resultados do eBPF em histogramas e gráficos de chama (flame graphs). Com o PCP, é possível desenvolver rapidamente comandos bpftrace e medir a performance e latência de métodos no kernel, sendo uma ferramenta valiosa quando usada junto com o trace de sistema.

Ao buscar entender o comportamento das transações problemáticas, o conceito de percentil 99, tão relevante na observabilidade de aplicações, também se aplica aqui. Esse conceito permite que a infraestrutura seja monitorada de forma precisa, identificando as transações mais lentas e garantindo que as falhas sejam detectadas antes de se tornarem críticas.

Como Construir Consultas RAG com OpenSearch e LLM para Respostas de Alta Qualidade

A construção de uma consulta que combine OpenSearch com um modelo de LLM (Large Language Model) é uma tarefa avançada, mas extremamente eficaz quando se deseja gerar respostas precisas a partir de grandes volumes de dados. Para isso, é essencial integrar a consulta de correspondência do OpenSearch com parâmetros específicos de um modelo de IA generativa. O primeiro passo nesse processo é definir uma consulta com o OpenSearch que utilize a estrutura de "match", onde se busca uma correspondência de texto, como a seguinte:

json
GET /my_rag_test_data/_search
{
  "query": {
    "match": {
      "text": "What's the population of NYC metro area in 2023"
    }
  },
  "ext": {
    "generative_qa_parameters": {
      "llm_model": "gpt-3.5-turbo",


      "llm_question": "What's the population of NYC metro area in 2023",


      "memory_id": "znCqcI0BfUsSoeNTntd7",
      "context_size": 5,
      "message_size": 5,
      "timeout": 15
    }
  }
}

Aqui, a consulta de texto no OpenSearch busca encontrar documentos que respondam à questão sobre a população da área metropolitana de Nova York. Uma vez que a correspondência é feita, a consulta é complementada por parâmetros adicionais de um modelo LLM, que fornecem a capacidade de processar e refinar as respostas com base no contexto.

Neste cenário, a inteligência do modelo LLM é acionada para examinar os documentos recuperados e oferecer uma resposta mais precisa. No caso descrito, a consulta retorna documentos que contêm informações sobre a população de Nova York, permitindo que o LLM forneça uma resposta bem fundamentada.

Este processo, conhecido como RAG (Retrieval-Augmented Generation), combina a busca tradicional de informações com a capacidade gerativa de um LLM para melhorar a qualidade das respostas. O LLM, ao acessar dados contextuais relevantes, é capaz de gerar respostas mais precisas e contextualizadas.

Integração com AWS Bedrock e Modelos Avançados

A integração com plataformas como AWS Bedrock segue uma abordagem semelhante, mas com a vantagem de fornecer flexibilidade no uso de diferentes modelos de IA. Ao usar o AWS Bedrock, você não depende de um modelo específico, como o GPT-3.5 da OpenAI, mas pode selecionar entre modelos diferentes e até mesmo trabalhar com o modelo Claude 3.5 da Anthropic.

O processo de configuração do modelo no AWS Bedrock é feito por meio da criação de um conector para o serviço, configurando credenciais de acesso, parâmetros do modelo e definindo o comportamento desejado, como temperatura e o número máximo de tokens:

json
POST _plugins/_ml/connectors/_create
{
  "name": "Amazon Bedrock claude v3",


  "description": "Test connector for Amazon Bedrock claude v3",


  "version": 1,
  "protocol": "aws_sigv4",
  "credential": {
    "access_key": "",
    "secret_key": "",
    "session_token": ""
  },
  "parameters": {
    "region": "us-east-1",
    "service_name": "bedrock",
    "model": "anthropic.claude-3-5-sonnet-20240620-v1:0",
    "system_prompt": "you are a helpful assistant.",
    "temperature": 0.0,
    "top_p": 0.9,
    "max_tokens": 1000
  }
}

Após a configuração do conector, o modelo pode ser registrado e implantado para começar a gerar respostas, o que também envolve a criação de pipelines de pesquisa e previsão, como demonstrado em um dos exemplos.

Avanços nas Funcionalidades do RAG

A evolução dos pipelines RAG se reflete nas funcionalidades avançadas que são necessárias para lidar com sistemas mais complexos. Entre elas, destaca-se a técnica de "reranking", que aprimora a precisão das respostas ao reorganizar a ordem dos documentos recuperados com base na relevância semântica, não apenas na correspondência exata de palavras-chave. Esse processo é crucial para aumentar a qualidade das respostas geradas pelo LLM.

Reranking é uma técnica sofisticada que prioriza a relevância semântica dos documentos para fornecer resultados mais precisos. Após a busca inicial, onde técnicas tradicionais como BM25 ou busca por similaridade de vetores são aplicadas, o LLM analisa o conteúdo semântico dos documentos recuperados e os reorganiza com base na relevância. Isso melhora significativamente a qualidade da resposta ao garantir que os documentos mais pertinentes estejam no topo, o que resulta em uma compreensão mais profunda do contexto da consulta.

Além disso, ferramentas como processamento pós-resposta e sistemas de controle de qualidade, como "guardrails", são essenciais para garantir que as respostas geradas sejam relevantes e dentro dos parâmetros definidos. Estas ferramentas são projetadas para monitorar e corrigir a resposta do modelo, evitando respostas errôneas ou irrelevantes.

Importância de Aprofundar o Entendimento sobre o RAG

Ao implementar sistemas RAG, é crucial considerar não apenas a capacidade do modelo de gerar respostas, mas também a importância da integridade e da relevância dos dados. A utilização de fontes externas, como bancos de dados vetoriais, pode enriquecer as respostas, mas também traz desafios de integração e gestão de dados. É vital configurar corretamente os pipelines de pesquisa, controlar os parâmetros de consulta e ajustar as configurações de rede neural para alcançar o melhor desempenho.

Outro ponto fundamental é o entendimento de como a implementação de RAG pode ser escalada para aplicações mais complexas, onde simples configurações de pesquisa não são suficientes. O aprendizado contínuo e a adaptação das respostas aos contextos específicos exigem um ajuste fino dos parâmetros do modelo e do pipeline, além de uma análise constante da qualidade das respostas geradas.

Como Erros Cognitivos e Falhas de Comunicação Impactam Desastres Aviários
Como Resolver Equações Diferenciais de Primeira Ordem: Exemplos e Teoremas
Como a Energia de Neutrons Impacta a Moderação e Termalização em Reatores Nucleares
Como a Holografia Eletrônica In Situ Pode Transformar a Análise de Potenciais Elétricos em Eletrólitos Sólidos
Como a Definição Operacional Impulsiona a Pesquisa Científica e os Processos de Medição