Introdução
A coleta, recuperação e análise de logs é uma parte importante que precisa ser considerada no projeto de arquitetura de cada negócio, e também é uma parte com muitos pontos problemáticos e altos custos de mão de obra. Como reduzir o acesso ao log e os custos subsequentes de operação e manutenção, o Tencent Cloud Big Data ES lhe dará a resposta.
A coleta, recuperação e análise de logs é uma parte importante que precisa ser considerada no projeto de arquitetura de cada negócio, e também é uma parte com muitos pontos problemáticos e altos custos de mão de obra. Este artigo começará com o ciclo de vida do log, analisará os pontos problemáticos da solução ELKB mais madura do setor durante e após o acesso e compartilhará a experiência de acessar logs e índices de operação e manutenção no Tencent Cloud Big Data ES para compartilhar Tencent Cloud Como o Big Data ES resolve esses pontos problemáticos para reduzir o acesso ao log e os custos de operação e manutenção, para que as empresas possam se concentrar na mineração do valor dos dados do log.
1. Log do ciclo de vida
Geralmente, todo o ciclo de vida dos logs pode ser dividido em: geração de log, coleta de log, processamento de log, armazenamento de log, análise de log e consulta.
1. Geração de registros. Componentes de código aberto maduros na indústria geralmente têm seu próprio formato de log padronizado e caminho de armazenamento de log, enquanto os logs inseridos por programas de desenvolvimento de negócios podem ser variados. No K8S, os logs são geralmente enviados para saída padrão ou saída de erro padrão por programas de negócios no POD e, finalmente, colocados no caminho de log especificado pelo K8S (como /var/log/containers), o que fornece conveniência para coleta de log.
2. Coleta de registros. Depois de determinar o caminho do arquivo de log, você pode usar ferramentas comuns de coleta de log (como Filebeat, Fluentd, Flume, etc.) para coletar. O processo de coleta geralmente é leve e não processa o conteúdo original do arquivo de log. Os logs coletados podem ser armazenados diretamente de acordo com os requisitos de negócios ou volume de negócios, ou podem ser inseridos primeiro na fila de mensagens e depois consumidos por outros componentes.
3. Processamento de registros. O conteúdo original do log geralmente é um texto grande, que contém campos como tempo de log, nível de erro, conteúdo detalhado etc. que podem ser divididos por expressões regulares ou formatos JSON. Em geral, pode ser armazenado no texto grande original, mas para cenários que requerem filtragem, agregação e classificação, é necessário separar previamente os campos no texto grande. Esta operação consome recursos e geralmente é executada independentemente da coleção. Por exemplo, arquivos de log brutos são processados por meio de ferramentas como Logstash e Flink. Claro, também pode ser executado nos processadores da extremidade da coleção, como Filebeat ou o pipeline de o fim do armazenamento, como Elasticsearch.
4. Armazenamento de registros. Os logs processados finalmente precisam ser armazenados no mecanismo de recuperação para análise e consulta subsequentes. Os mecanismos de recuperação de log comumente usados no setor incluem Elasticsearch, Clickhouse e Loki. O armazenamento de logs geralmente tem atributos quentes e frios óbvios. O volume de consulta de log é o maior nos últimos dias, e o volume de consulta de log nas últimas semanas é pequeno. No entanto, logs históricos de um mês atrás basicamente não são consultados. Portanto, log o armazenamento precisa ser baseado nisso. O recurso considera o ciclo de vida do armazenamento de logs, melhora o desempenho da consulta de dados quentes e economiza o custo de armazenamento de dados frios.
5. Análise e consulta de registros. Geralmente, a extremidade do armazenamento de log possui recursos de análise e consulta de log. De acordo com a implementação de diferentes mecanismos, alguns são bons na recuperação de texto completo e alguns são bons na classificação e agregação, mas devem ter as características de processamento em tempo real de grandes quantidades de dados, suporte para recuperação arbitrária de palavras-chave e baixo custo. , e para análise e resultados de consultas, é necessário haver uma interface visual para exibição ou desenho de gráficos (como Kibana, Prometheus, etc.).
Nesses ciclos de vida, o lado comercial se concentra na geração de logs e na análise e consulta de logs finais; o lado de operação e manutenção precisa se concentrar no gerenciamento de componentes de coleta, processamento e armazenamento de logs.
2. Pontos problemáticos da solução ELKB
Correspondendo às necessidades de cada estágio no ciclo de vida do log, a indústria formou uma arquitetura de coleta e análise de log de código aberto madura e amplamente utilizada - ELKB (Elasticsearch+Logstash+Kibana+Beats), que fornece coleta de log para visualização final -link solução para apresentar os resultados da análise. Como todos pertencem aos produtos do ecossistema Elastic, cada produto tem boa compatibilidade e consistência em termos de protocolos, especificações e uso. Além disso, a comunidade Elastic é altamente ativa e a iteração do produto é rápida e os problemas encontrados no uso pode ser resolvido. Obtenha uma solução rápida. Portanto, a arquitetura ELKB pode atender às necessidades de gerenciamento de log da maioria das empresas.
Figura 1. Diagrama esquemático da arquitetura ELKB
No entanto, no processo de uso real do ELKB, você descobrirá que o processo de construção, uso e manutenção de todo o link não é fácil e há principalmente dois problemas:
1. Quando os logs são acessados, existem muitos dispositivos terminais e longos links de implantação, portanto, é impossível implantá-los e gerenciá-los de maneira unificada. Cada componente precisa ser implantado separadamente e, finalmente, conectado em série por meio de arquivos de configuração. Isso requer que o pessoal de operação e manutenção esteja familiarizado com o processo de implantação e os parâmetros de configuração de cada componente, caso contrário, o link pode não ser estabelecido.
2. Depois que o log é conectado, é necessário manter e manter um número crescente de índices, gerenciar modelos de ciclo de vida etc., e quando o número de índices e shards continuar a crescer, o cluster pode ficar instável, como gravação rejeição quando o volume de log aumenta repentinamente, falhas de nó causam bloqueio de gravação, etc.
Devido ao amplo uso do ELKB, cada componente em seu link possui produtos baseados em nuvem nas principais plataformas de nuvem, portanto, não é difícil implantar um único produto. A dificuldade está na abertura do caminho de dados de log e posterior operação e manutenção. O problema comum de construir ELK e implantar produtos na nuvem ELK também é uma das razões pelas quais a maioria das empresas não está disposta a migrar para a nuvem. de índices ES também são necessários , Quais são as vantagens de ir para a nuvem?
3. A experiência de acessar logs no Tencent Cloud ES
A Tencent Cloud fornece serviços em nuvem, como clusters Elasticsearch implantados de forma independente, instâncias Logstash e gerenciamento Beats. Para clientes que precisam usar um único produto, ele fornece uma interface de gerenciamento visual muito amigável e conveniente.
Ao mesmo tempo, em resposta aos pontos problemáticos do acesso ao log mencionados acima, o Tencent Cloud ES também fornece uma solução completa de acesso a dados. Entre na página de acesso a dados do Tencent Cloud ES, basta seguir as instruções para selecionar a fonte de dados, o coletor de dados, o middleware opcional (como cache de dados, processamento de dados) e a finalidade dos dados, e você pode criar rapidamente uma cadeia de dados ELKB para estrada de coleta de logs .
Figura 2. Crie e visualize links de dados
1. Cena rica e suporte de fonte de dados. A fonte de dados suporta vários cenários e vários produtos de nuvem para atender a vários requisitos de uso do ES, como coleta de log, coleta de índice, sincronização de dados e aceleração de banco de dados.
(1) O cenário de coleta de log suporta logs gerados por serviços no servidor de nuvem CVM e serviço de contêiner TKE, bem como logs gerados por produtos de nuvem, como firewalls de nuvem e firewalls de aplicativos da web, e está constantemente enriquecendo o acesso de logs de outros produtos de nuvem .
(2) Para cenários de sincronização de dados e aceleração de banco de dados, ele oferece suporte à sincronização de dados do banco de dados em nuvem MySQL, fila de mensagens CKafka, Kafka autoconstruído e tópico elástico para ES, analisa automaticamente e gera mapeamentos de campo dinamicamente, sem a necessidade de componentes adicionais ou desenvolvimento para implantação de negócios.
2. Várias configurações e gerenciamento eficiente. De acordo com diferentes cenários, a coleta de dados oferece suporte ao coletor de logs Filebeat e ao coletor de indicadores Metricbeat, oferece suporte à sintaxe e configuração nativas do Beats e instala automaticamente o Beats na fonte de dados, sem a necessidade de entrega de script de negócios adicional, e oferece suporte à coleta baseada em interface Servidor gerenciamento, não importa quantos CVMs sejam implantados, isso pode ser visto rapidamente.
3. Construção de link flexível e conveniente. O armazenamento em cache e o processamento de dados são opcionais e podem ser configurados sem configuração ou em vários modos, como Logstash, CKafka+Logstash e Elastic Topic para atender às diferentes necessidades de diferentes cenários de negócios.
Comparado com produtos SaaS únicos fixos, o link de dados do Tencent Cloud ES fornece um método de acesso a dados flexível e fácil de usar. As empresas podem escolher componentes apropriados de acordo com suas próprias características, definir configurações de componentes simples ou diversas e todos os componentes são todos compatíveis com o uso de produtos nativos, para que o negócio em nuvem não precise alterar os hábitos de uso originais e não precise modificar o código comercial original.
Figura 3. Links de dados flexíveis e diversificados
4. O índice de experiência de operação e manutenção no Tencent Cloud ES
Os logs foram coletados para ES, e os logs podem ser analisados e consultados sem problemas. Este artigo deve terminar logicamente. Mas, na verdade, de nossa grande quantidade de operação on-line e experiência prática, o trabalho de operação e manutenção está longe de terminar.Com a gravação contínua de logs, também surgem problemas, e esses problemas tornam os programadores com cabelos finos Para adicionar insulto à injúria.
1. Como definir e criar um índice? Com a adição contínua de novos serviços, a carga de trabalho de definição e criação de índices de log só aumentará. Tudo é difícil no começo. Para novos negócios, como criar um novo índice, se criar um índice normal ou um fluxo de dados, como usar um alias, como determinar o número de shards primários, se reutilizar ou criar novos modelos de índice e regras de ciclo de vida são pontos problemáticos para a criação de índice.
2. Como definir o número de fragmentos primários, que podem não apenas lidar com a rejeição de gravação, mas também convergir o número de fragmentos? Normalmente, o índice de log é atualizado diariamente por meio de um modelo de índice, denominado, por exemplo, app-log-2022.12.01. Um número fixo de estilhaços primários é definido no modelo, portanto, o tamanho de cada índice não pode ser razoavelmente controlado. Ao encontrar um dia com uma grande quantidade de logs, o índice pode ser muito grande, fazendo com que os shards não consigam realizar as gravações, e ocorre a rejeição da gravação; ao encontrar um dia com uma pequena quantidade de logs, configurar muitos shards aumenta o ES carga de metadados de gerenciamento de cluster ao longo do tempo.
3. Como evitar que tarefas de criação de índices e atualização de mapeamentos bloqueiem a gravação? Vários índices de negócios nomeados por hora podem criar novos índices no mesmo horário todos os dias, como 0:00 ou 8:00 todos os dias, o que fará com que um grande número de tarefas de criação de shard neste ponto de tempo bloqueie a execução de tarefas de gravação , resultando em falha de gravação ou até mesmo perda de dados. Da mesma forma, em um cenário com um grande número de campos de log, alterações frequentes nos campos de log levam a atualizações frequentes de mapeamentos, que também bloqueiam tarefas de gravação.
4. Como melhorar a taxa de transferência de gravação de log? O volume de gravação de log geralmente é grande, portanto, a escala do nó geralmente é alta, mas às vezes descobre-se que, quando a utilização geral de recursos do cluster é baixa, o atraso de gravação é alto e os recursos do cluster não podem ser totalmente utilizados para melhorar o taxa de transferência de gravação.
5. Como melhorar o desempenho da consulta de log? Os índices nomeados após o tempo geralmente usam curingas durante a consulta, como GET app-log-*/_search. Essa consulta percorrerá todos os fragmentos de índice correspondentes, o que aumenta muito o atraso da consulta. Acima do nível PB, as consultas de log são especialmente perceptíveis.
6. Como lidar com a falha de gravação causada pela falha de hardware do cluster ES de cópia 0? Falhas de hardware são inevitáveis e o ES garante nativamente alta disponibilidade por meio do mecanismo de cópias fragmentadas. No entanto, cenários de log geralmente possuem uma grande quantidade de dados. Considerando o custo, o índice será definido como 0 cópias. Embora isso reduza o custo, quando houver falha de hardware do nó onde o shard está localizado, a gravação falhará.
Para abordar os pontos problemáticos acima no uso, operação e manutenção, o Tencent Cloud ES fornece uma solução exclusiva de gerenciamento de índice - índice autônomo. Como o nome indica, um índice autônomo é um índice capaz de autooperação e manutenção. Com base nas capacidades de adição, exclusão, modificação e consulta do índice nativo ES, ele melhora a facilidade de uso e a capacidade de evitar operação e manutenção . Através da indexação autônoma, os problemas mencionados acima podem ser bem resolvidos.
(1) Como definir e criar um índice
A indexação autônoma é baseada na solução de fluxo de dados nativo do ES, portanto, não há necessidade de considerar como usar aliases. No entanto, o processo de criação do fluxo de dados nativo do ES é relativamente complicado. Conforme mostrado na figura abaixo, cada etapa chama a API do ES e está relacionada entre si.
Figura 4. Processo de criação do fluxo de dados nativo do ES
No índice autônomo, você só precisa chamar a API ES uma vez para concluir a criação. A definição da API oferece suporte a configurações nativas e parâmetros de mapeamento e adiciona uma política de parâmetro de regra de ciclo de vida simplificada e opções de parâmetro de recurso de índice autônomo. Ao mesmo tempo, é autônomo e também fornece uma interface de visualização de console para oferecer suporte à criação de índice de tela branca.
Figura 5. Processo de criação de índice autônomo
(2) Como definir o número de fragmentos primários, que podem não apenas lidar com a rejeição de gravação, mas também convergir o número de fragmentos
O problema mais problemático na operação e manutenção do índice é como definir o número de shards primários do índice, porque esse parâmetro é definido no momento da criação e não pode ser modificado posteriormente. Se o número de shards primários for muito pequeno, a quantidade de gravações realizadas por um único shard é limitada e é provável que ocorra rejeição de gravação; se o número de shards primários for muito alto, com o passar do tempo, o número de shards no cluster aumenta e o gerenciamento de dados cria estresse.
Para resolver esse problema, o índice autônomo é baseado na estrutura dos índices Baking do fluxo de dados e no algoritmo autodesenvolvido para realizar o ajuste automático do número de fragmentos primários, para que a empresa não precise mais se preocupar em como definir o número de fragmentos primários.
Figura 6. Estrutura de índice autônomo
Para o cenário de aumento repentino nas gravações, o índice autônomo monitora o tráfego de gravação e os indicadores de rejeição, calcula o número de fragmentos que podem suportar o aumento repentino no tráfego após um pico de tráfego ou rejeição de gravação e implementa automaticamente um novo índice de backup como O processo de escrever um novo índice é suave e imperceptível e não requer intervenção manual.
Para cenários em que as gravações aumentam constantemente, o índice autônomo preverá a tendência do tráfego de gravação com base nos dados históricos de monitoramento, definirá um número apropriado de estilhaços com antecedência e evitará rejeições de gravação com antecedência.
Para cenários em que as gravações flutuam periodicamente, o índice autônomo considera a taxa de tolerância de ajuste, evitando ajustes frequentes no número de estilhaços e implementando muitos índices de backup, resultando em choques de ajuste e mantendo estilhaços sem rejeições de gravação O número é estável.
Para cenários em que as gravações são reduzidas, o índice autônomo reduzirá cuidadosamente o número de fragmentos de índice, observará em uma janela de tempo mais longa e julgará se deve reduzir o número de fragmentos com base na tendência de mudança do número de fragmentos de vários backups históricos adjacentes índices. Para clusters com um plano irracional para o número de shards, após a adoção do índice autônomo, o número de shards é continuamente reduzido de 9.000+ para menos de 4.000, e a convergência é de cerca de 60%+.
(3) Como evitar que a criação de índices e a atualização de tarefas de mapeamento bloqueiem as gravações
A causa raiz desse problema é que a tarefa de atualização de metadados de criar um novo índice ou atualizar mapeamentos de índice entra em conflito com a tarefa de gravação.
Para resolver este problema, no índice autônomo, a tarefa de atualização de metadados e a tarefa de gravação de dados são separadas pela pré-criação do índice. Antes de o índice ser criado, o índice antigo continuará sendo gravado sem bloquear a gravação até o novo índice de backup é criado. Depois disso, escreva para o novo índice de apoio. Ao mesmo tempo, para reduzir o impacto da atualização de mapeamentos na gravação, o índice autônomo herdará o campo de mapeamentos do índice de backup histórico, e os mapeamentos de campo que foram adicionados dinamicamente antes também serão refletidos no novo índice de backup, reduzindo a frequência de atualização de mapeamentos no novo índice de backup.
(4) Como melhorar a taxa de transferência de gravação de log
A causa raiz desse problema é que, para escrever sem especificar uma rota, centenas ou milhares de documentos contidos em uma solicitação em massa serão distribuídos uniformemente para cada estilhaço pelo algoritmo de hash nativo do ES, e esses estilhaços são distribuídos uniformemente em cada nó, isso faz com que uma solicitação em massa interaja com todos os nós onde o shard do índice está localizado, como um ventilador, expandindo-se de um ponto na raiz do ventilador para uma superfície de ventilador, que é chamada de write fan-out. Nesse caso, desde que qualquer nó onde o shard esteja localizado não consiga processar a solicitação de gravação a tempo, como falha de hardware, acúmulo de tarefas em segundo plano, GC de longo prazo etc., toda a solicitação em massa estará aguardando o nó para concluir o processamento, resultando em gravação A latência de entrada e a taxa de transferência são reduzidas.
Para resolver este problema, no índice autônomo, através da estratégia de roteamento em grupo, as requisições de escrita dos fragmentos são agrupadas, reduzindo o número de fragmentos envolvidos em uma única requisição em massa, diminuindo o fan-out de escritas, diminuindo o impacto de longas tails, e melhorando a escrita TPS A taxa de utilização da CPU aumentou em mais de 50%.
Figura 7. Roteamento de grupo de índice autônomo
(5) Como melhorar o desempenho da consulta de log
Em termos de consulta, os cenários de log geralmente têm características quentes e frias óbvias, como manter 7 dias de dados de log, mas as consultas P90 estão concentradas nas últimas 12 horas; e geralmente usam consultas de prefixo de índice ao consultar logs, como filebeat-* , que A consulta levará mais de 3 vezes mais do que a consulta de nome de índice especificada. Nossa análise constatou que o consumo de tempo está concentrado principalmente na fase de consulta. Devido ao grande número de fragmentos do índice correspondidos pela consulta do prefixo do índice, o consumo total de tempo das solicitações de rede para percorrer esses fragmentos é muito alto.
A fim de reduzir o atraso da consulta em tais cenários, combinado com as características óbvias de comportamento de consulta quente e fria, o índice autônomo realiza a otimização de poda de consulta com base no campo de tempo e adiciona os valores mínimo e máximo do campo de tempo de o documento no índice para os metadados do índice de backup. Ao consultar, o nó coordenador pula rapidamente índices irrelevantes através das informações de intervalo de tempo registradas nos metadados do índice de backup de acordo com o intervalo de tempo especificado nas condições de consulta, reduz o número de solicitações de envio fragmentadas e atinge o desempenho de consulta de log de nível PB 3 vezes mais melhora.
Figura 8. Remoção de consulta de índice autônomo
(6) Como lidar com a falha de gravação causada pela falha de hardware do cluster ES de cópia 0
O índice autônomo é baseado na estrutura do índice de backup do fluxo de dados. No caso de nenhuma cópia de fragmento, quando é detectado que um nó onde o fragmento de índice está localizado está com defeito e o índice está vermelho ou a gravação está anormal, o O índice autônomo lançará automaticamente um novo índice de backup e roteará gravações para o novo índice de backup, eliminará a distribuição de fragmentos de nós anormais, garantirá que os novos fragmentos de índice de backup sejam distribuídos em nós normais e garantirá a disponibilidade de gravações. processo não requer intervenção manual, e o negócio não tem percepção, tudo feito automaticamente pela Indexação Autônoma.
Figura 9. Índice autônomo elimina nós anormais
Acima, analisamos os pontos problemáticos do processo de acesso ao log e operação e manutenção do índice, e os resolvemos um a um por meio do link de dados e da solução de índice autônomo do Tencent Cloud ES, o que reduziu bastante o custo de acesso, operação e manutenção do log, permitindo o negócio para se concentrar na mineração de valor de dados de log. Sejam todos bem-vindos para experimentar a nuvem e apresentar opiniões valiosas!