Observabilidade e análise no Azure Operator 5G Core Preview

A observabilidade tem três pilares: métricas, rastreamento e logs. O Azure Operator 5G Core Preview reúne essas ferramentas de observabilidade para ajudá-lo a identificar, investigar e resolver problemas. Além disso, os alertas do Azure Operator 5G Core fornecem notificações com base em métricas e logs.

Visão geral da observabilidade

Os seguintes componentes fornecem observabilidade para o Azure Operator 5G Core:

Componentes de código aberto de observabilidade

O Azure Operator 5G Core usa os seguintes componentes de código aberto para funções de observabilidade.

Estrutura de registro em log

O Elasticsearch, o Fluentd e o Kibana (EFK) fornecem um sistema de log distribuído usado para coletar e visualizar os logs para solucionar problemas de microsserviços.

Arquitetura

O diagrama a seguir mostra a arquitetura EFK:

A estrutura de registro em log inclui os seguintes componentes:

• Fluentd - Fluentd é um coletor de log de código aberto. O Fluentd permite unificar a coleta e o consumo de dados para melhor uso e compreensão dos dados. Fluentd é implantado como um DaemonSet no cluster Kubernetes. Ele coleta os logs em cada nó K8s e transmite os logs para o Elasticsearch. Consulte Logs suportados pelo Fluentd.

• Elasticsearch - O Elasticsearch é um back-end de pesquisa de código aberto, distribuído e em tempo real. O Elasticsearch armazena os logs com segurança e oferece uma interface Web HTTP para análise de logs.

• Kibana - O Kibana é usado para visualizar os logs armazenados no Elasticsearch. O Kibana extrai os logs do Elasticsearch.

  Para obter mais informações sobre o Elasticsearch e o Kibana, consulte a documentação do Elastic.

• ElastAlert - ElastAlert é uma estrutura simples para alertar sobre anomalias, picos ou outros padrões de interesse de dados no Elasticsearch. Ele funciona combinando o Elasticsearch com dois tipos de componentes: tipos de regras e alertas. O Elasticsearch é consultado periodicamente e os dados são passados para o tipo de regra, que determina quando uma correspondência é encontrada. Quando ocorre uma correspondência, um ou mais alertas são acionados com base na correspondência.

  Para obter mais informações sobre o ElastAlert, consulte a documentação do ElastAlert.

Funcionalidades

A estrutura de registro em log fornece os seguintes recursos:

• Coleta e streaming de logs - O Fluentd coleta e transmite os logs para o Elasticsearch.

• Suporte a logs de auditoria - O Fluentd lê os logs de auditoria do Kube-Apiserver do nó mestre do Kubernetes e grava esses logs no Elasticsearch. O auditlogEnabled sinalizador fornecido em fed-paas-helpers é usado para habilitar/desabilitar a leitura de logs de auditoria. Se o sinalizador auditlogEnabled estiver definido como true, Fluentd também será implantado no nó principal junto com os nós de trabalho.

• Log de eventos - O Fluentd cria um índice Elasticsearch separado para todos os logs de eventos de um namespace específico. Isso ajuda a aplicar regras e pesquisar os logs de eventos de uma maneira melhor. O índice começa com o prefixo fluentd-event. Todos os outros logs de depuração regulares vão para um índice separado do Elasticsearch, prefixado com a cadeia de caracteres fluentd-*.

• Armazenamento e análise de logs - O Elasticsearch armazena os logs com segurança e oferece uma linguagem de consulta para pesquisar e analisar os logs.

• Visualização de logs - O Kibana extrai os logs do Elasticsearch e visualiza os logs. O Kibana permite criar dashboards para visualizar os logs.

• Mecanismo de alerta - O ElastAlert fornece regras para consultar os logs do Elasticsearch. Quando ocorre uma correspondência, os alertas são acionados.

Personalização do leme

O Azure Operator 5G Core fornece um conjunto padrão de valores Helm que você pode usar para implantar a estrutura de log do EFK. Você pode personalizar esses valores para melhorar a escalabilidade e o desempenho, se necessário.

Observabilidade

Esta seção descreve os recursos de observabilidade (painéis, estatísticas, logs e alarmes) da estrutura de log do EFK.

Dashboards

Vários painéis são suportados, incluindo:

• Painéis do Grafana (consulte Painéis da estrutura de registro)
• Painéis do Kibana (veja a visão geral do painel do Kibana)
• Painéis do Grafana Kibana (consulte os painéis do Kibana Grafana)
• Painel do operador fluente (consulte Painel do operador fluente Grafana)
• Painel do Elasticsearch Grafana (consulte Painel do Elasticsearch)

Estatísticas

Para obter informações sobre estatísticas suportadas para componentes EFK, consulte:

• Estatísticas do Elasticsearch
• Outras estatísticas do Elasticsearch
• Estatísticas de operadores fluentes

Para obter informações sobre alertas baseados em métricas, consulte:

• Alertas baseados em métricas do operador fluente
• Alertas baseados em métricas elásticas

evento

Para obter informações sobre eventos elásticos, consulte Eventos elásticos.

Visualização de log

A estrutura agrega logs de nós e aplicativos em execução dentro de sua instalação do Azure Operator 5G Core. Quando o registro em log está habilitado, a estrutura do EFK usa o Fluentd para agregar logs de eventos de todos os aplicativos e nós no Elasticsearch. A estrutura EFK também fornece uma interface do usuário da Web Kibana centralizada, onde os usuários podem visualizar os logs ou criar visualizações e painéis avançados com os dados agregados.

Estrutura de métricas

A estrutura de métricas consiste em Prometheus, Grafana e AlertManager.

Prometheus (o componente principal) é um sistema de monitoramento de código aberto, baseado em métricas. Ele fornece um modelo de dados e uma linguagem de consulta para analisar o desempenho dos aplicativos e da infraestrutura. O Prometheus coleta métricas de trabalhos instrumentados diretamente e armazena todas as amostras raspadas no armazenamento externo local. Com base em regras definidas, o Prometheus agrega e regista uma nova série temporal a partir de dados existentes ou gera alertas. O AlertManager lida com os alertas enviados por aplicativos cliente desduplicando, agrupando e roteando-os para as integrações corretas do recetor.

O Grafana fornece painéis para visualizar os dados coletados.

Arquitetura

O diagrama a seguir mostra como os diferentes componentes da estrutura de métricas interagem entre si.

Os principais componentes da estrutura de métricas são:

• Servidor Prometheus - O servidor Prometheus coleta métricas de destinos configurados em intervalos determinados, avalia expressões de regras, exibe os resultados e dispara alertas se determinadas condições forem verdadeiras. O Azure Operator 5G Core suporta a integração com o servidor Prometheus pronta a utilizar, com o mínimo de configuração necessária.
• Bibliotecas de cliente - As bibliotecas de cliente instrumentam o código do aplicativo.
• AlertManager - O AlertManager lida com alertas enviados por aplicativos cliente, como o servidor Prometheus. Ele lida com a desduplicação, agrupamento e roteamento de alertas para as integrações corretas do recetor (e-mail, folga, etc.). O AlertManager também suporta silenciamento e inibição de alertas.
• Grafana - Grafana fornece um conjunto pronto para uso de painéis ricos com 3GPP e outros KPIs para consultar, visualizar e entender os dados coletados. O recurso de auditoria do Grafana fornece um mecanismo para restaurar ou recriar painéis no servidor Grafana quando o pod do servidor Grafana é reiniciado. O recurso de auditoria também ajuda a excluir quaisquer painéis obsoletos do servidor Grafana.

Funcionalidades

A estrutura de métricas suporta os seguintes recursos:

• Modelo de dados multidimensional com dados de séries cronológicas identificados por nome métrico e pares chave/valor.
• PromQL, uma linguagem de consulta flexível que usa os dados multidimensionais.
• Sem dependência de armazenamento distribuído: nós de servidor único são autônomos.
• Coleção de séries temporais usando um modelo pull sobre HTTP.
• Os destinos são descobertos por meio de descoberta de serviço ou configuração estática.
• Vários modos de suporte a gráficos e painéis.

Para obter mais informações sobre Prometheus, consulte a documentação do Prometheus. Para obter mais informações sobre o Grafana, consulte a documentação de código aberto do Grafana.

Observabilidade

Esta seção descreve os recursos de observabilidade (painéis, estatísticas, logs e alarmes) fornecidos pela estrutura de métricas.

Dashboards

A estrutura de métricas suporta os seguintes painéis:

• Painéis do Grafana (consulte o painel do Grafana)
• Painéis do Prometheus Grafana (consulte o painel do Prometheus Grafana)

Estatísticas

Para obter informações sobre estatísticas suportadas para componentes da estrutura de métricas, consulte:

• Estatísticas Grafana
• Estatísticas Prometheus
• Estatísticas de erro do servidor Prometheus

Para obter informações sobre alertas baseados em métricas Prometheus, consulte Alertas baseados em métricas Prometheus.

Eventos/Logs

Para obter informações sobre eventos da estrutura de métricas, consulte:

• Eventos Prometheus
• Eventos de infraestrutura

Alertas baseados em métricas para falhas de rede/HTTP

As regras de alerta do Prometheus geram alertas se forem detetadas falhas de HTTP/rede no sistema. Os alertas a seguir são gerados para falhas de rede.

Alertas globais no nível do aplicativo:

• IstioGlobalHTTP5xxRatePercentageHigh - Um aplicativo que faz parte da malha de serviço do Istio está respondendo com erro 5xx e a porcentagem da taxa de erro é maior do que o <valor > configurado %
• IstioGlobalHTTP4xxRatePercentageHigh - Uma aplicação está a responder com erro 4xx e a percentagem da taxa de erro é superior aos <configured_value> %. IstioHTTPRequestLatencyTooHigh: As solicitações estão demorando mais do que os <configured_value> segundos.

Alertas de nível de pod e contêiner:

• HTTPServerError5xxPercentageTooHigh - O servidor HTTP responde com erro 5xx e a percentagem de erro é superior aos <configured_value> %.
• HTTPServerError4xxPercentageTooHigh - O servidor HTTP responde com erro 4xx e a percentagem de erro é superior aos <configured_value> %.
• HTTPServerRequestRateTooHigh - O total de solicitações recebidas no servidor HTTP é maior do que o <configured_value>.
• HTTPClientRespRcvd5xxPercentageTooHigh - A resposta do cliente HTTP recebeu com erro 5xx e a percentagem de erro recebida é superior aos <configured_value> %.
• HTTPClientRespRcvd4xxPercentageTooHigh - Resposta do cliente HTTP recebida com erro 4xx e a percentagem de erro recebida é superior aos <configured_value> %.

Quadro de rastreio

Rastreamento Jaeger com OpenTelemetry Protocol

O Azure Operator 5G Core usa o Protocolo OpenTelemetry (OTLP) no rastreamento Jaeger. OTLP substitui o agente Jaeger em fed-paas-helpers. O Azure Operator 5G Core implanta a federação de otel_collector alimentado. O OpenTelemetry (OTEL) Collector é executado como parte do namespace fed-otel_collector:

O rastreamento Jaeger usa o seguinte fluxo de trabalho:

1. O aplicativo com a biblioteca de cliente OTLP envia rastreamentos para o OTEL Collector no protocolo OTLP GRPC. O Coletor OTEL tem três componentes: recetores, processadores e exportadores.
2. O recetor OTLP GRPC no Coletor OTEL recebe rastreamentos e os envia para o exportador Jaeger.
3. O exportador Jaeger envia vestígios para o coletor Jaeger funcionando como parte do fed-jaeger.
4. O coletor Jaeger armazena os traços no armazenamento de back-end elástico (fed-elastic).

Conteúdos relacionados

• O que é o Azure Operator 5G Core Preview?
• Guia de início rápido: implantar a observabilidade do Azure Operator 5G Core (visualização) nos Serviços Kubernetes do Azure (AKS)

[def]: