Loki para a gestão centralizada de registos na hospedagem

Separar claramente o Loki, o Alloy e o Grafana

A gestão centralizada de registos começa nos sistemas que geram eventos: hosts Linux, servidores virtuais, contentores e aplicações. É aí que são criadas, por exemplo, entradas de registo do systemd, registos de acesso e de erros do Nginx ou as saídas padrão dos contentores Docker. Grafana Alloy Lê essas fontes, pode processá-las antes do envio e encaminhá-las para o Loki. O Alloy é, portanto, o coletor de dados, e não o armazenamento central de registos.

Grafana Loki recebe os dados de registo, agrupa-os e armazena-os para consultas posteriores. Um armazenamento de objetos pode, nesse contexto, acolher os dados persistidos. O Grafana, por sua vez, fornece frequentemente a interface para o Explore, os painéis e os alertas, mas, do ponto de vista técnico, não faz parte do próprio Loki. Esta separação facilita a atribuição clara de responsabilidades em caso de alterações, falhas e direitos de acesso.

Num pequeno exemplo de alojamento, o Alloy lê, num VPS, o journal do systemd, bem como os ficheiros do Nginx e os registos dos contentores. Envia as linhas selecionadas para o Loki; um administrador analisa-as posteriormente no Grafana, em vez de ter de iniciar sessão em cada host individualmente para uma primeira análise de erros. Antes do Loki, um proxy reverso ou uma camada de identidade deve garantir o controlo de autenticação, TLS, encaminhamento e, se necessário, a atribuição de clientes.

A agregação centralizada reduz os percursos de pesquisa, mas não substitui nem a análise das causas nem os processos operacionais. Proteção do acesso deve definir quem pode aceder a quais dados; o princípio da minimização de dados determina, ainda antes do envio, quais os campos a eliminar. Também a definição de um plano de cópias de segurança e recuperação continua a ser uma tarefa à parte: o Loki permite localizar os registos existentes, mas não garante, por si só, a sua proteção, integridade ou conservação em conformidade com a legislação.

Na prática, o Loki só se justifica após um inventário das fontes: que registos ajudam na operação e na resolução de incidentes, quais contêm segredos ou dados pessoais e quem precisa de acesso? Só estas respostas determinam os filtros, o período de retenção e as autorizações. Centralizar todos os registos do Linux sem os verificar apenas transfere informações sensíveis para um armazenamento mais fácil de pesquisar.

Compreender streams, labels e LogQL

O Loki não organiza as linhas recebidas principalmente como um índice de texto completo. Agrupa-as com base no ID do cliente e no seu conjunto de etiquetas, formando um Fluxo em conjunto. Os dados de registo propriamente ditos encontram-se comprimidos em blocos; o índice associa conjuntos de etiquetas a esses blocos. Por isso, durante uma pesquisa, o Loki começa por filtrar os fluxos adequados com base nas etiquetas e, em seguida, carrega os dados em questão para os filtrar ou analisar posteriormente.

As etiquetas devem expressar um contexto duradouro e claro: por exemplo, env, service e com servidores estáveis host. Em ambientes de contentores, também pode fazer sentido utilizar clusters, namespaces ou aplicações. No entanto, cada combinação única constitui um fluxo. Os IDs de pedido, de utilizador e de rastreio, bem como os IDs de contentores variáveis ou os endereços IP dos clientes, geram um grande número de valores e, por isso, normalmente não devem ser incluídos nas etiquetas.

Para análises detalhadas pontuais, esses dados dinâmicos permanecem na linha de registo e só são avaliados aquando da consulta, por exemplo, através da análise de JSON ou Logfmt. Os dados de contexto frequentemente necessários e de elevada cardinalidade podem ser mais adequados na forma de metadados estruturados. É fundamental testar o modelo de dados em fontes reais antes da implementação, em vez de rotular todos os campos disponíveis sem qualquer filtragem.

Uma consulta LogQL exclusivamente de leitura para erros do Nginx pode ter este aspeto. Deve ser executada, por exemplo, no Grafana Explore ou no LogCLI e pressupõe que as etiquetas selecionadas tenham sido efetivamente atribuídas durante a recolha.

{env="prod", service="nginx"} |= " 500 "

O seletor a montante do pipeline reduz, numa primeira fase, aos fluxos de produção do serviço Nginx; só |= " 500 " procura o texto. No entanto, a qualidade de uma consulta depende do período de tempo, do volume de registos, das latências de armazenamento e da conceção das etiquetas. O Loki não garante, por isso, um tempo de resposta fixo. Intervalos de tempo curtos e seletores precisos e estáveis constituem um ponto de partida sensato para uma análise gradual.

Que arquitetura Loki é a mais adequada para o alojamento

Para um único VPS, um laboratório ou volumes reduzidos de registos, o funcionamento monolítico muitas vezes, o ponto de partida mais compreensível: um processo Loki agrupa os componentes necessários. A documentação indica este modo para experiências, bem como para pequenos volumes de leitura e gravação até cerca de 20 GB de registos por dia. Trata-se de uma orientação do fabricante para esta área de aplicação, não de uma garantia de capacidade para qualquer estrutura de armazenamento, consulta ou etiquetagem.

Se os requisitos de disponibilidade aumentarem sem que seja necessário dimensionar de forma específica as funções individuais do Loki, pode considerar-se uma operação monolítica de alta disponibilidade. Para clusters de grande dimensão ou ambientes Kubernetes, nos quais os componentes devem ser dimensionados separadamente, está previsto o modo de microsserviços. No entanto, esta granularidade não elimina a necessidade de planeamento: aumenta o número de componentes operacionais e, consequentemente, também o esforço de diagnóstico e manutenção.

O modo «Simple Scalable Deployment» não é uma opção neutra para novas decisões. O Grafana classificou o SSD como obsoleto e anunciou a sua remoção com o Loki 4.0. Quem estiver a implementar uma solução hoje deve, por isso, avaliar uma abordagem monolítica com disponibilidade adequada ou microsserviços com base nas necessidades reais de escalabilidade, em vez de planear uma arquitetura de transição a longo prazo.

Para ajudar na tomada de decisão, não bastam apenas os gigabytes gerados diariamente. Também são relevantes os picos de gravação, o número e a cardinalidade dos fluxos, a separação necessária entre clientes, a retenção de dados, bem como os conhecimentos da equipa em matéria de Kubernetes e componentes distribuídos. Os projetos com distribuição global necessitam, de qualquer forma, de uma delimitação clara entre os serviços operacionais centrais e os componentes de perifeira; neste contexto, é também relevante o artigo sobre Alojamento Web para renderização de ponta e entrega descentralizada.

Comece por pequenos passos, caso as fontes de registo, as etiquetas e os acessos ainda não estejam definidos de forma estável. Uma mudança de arquitetura deve ser justificada por requisitos observados, como, por exemplo, uma escalabilidade específica ou uma maior disponibilidade, e não por uma expectativa genérica de crescimento futuro. Desta forma, o esforço necessário para Gestão de registos em relação aos benefícios da pesquisa centralizada e do tratamento de incidentes.

Recolher registos do Linux de forma segura com o Alloy

Antes da configuração, é necessário fazer um inventário das fontes: que registos ajudam efetivamente na operação e na resolução de incidentes? Num servidor web Linux, trata-se frequentemente do systemd-Journal, dos registos de acesso e de erros do Nginx, do PHP-FPM, dos eventos SSH e das tarefas Cron. No caso dos contentores, acrescentam-se as saídas do tempo de execução e os registos específicos da aplicação. Igualmente importante é a verificação prévia de palavras-passe, chaves de API, IDs de sessão e dados pessoais; esses conteúdos não podem ser transmitidos centralmente sem serem analisados.

Para novas instalações, é Grafana Alloy o método suportado para a recolha e o encaminhamento. O Promtail já não deve ser considerado como padrão para este fim: o seu ciclo de vida terminou a 2 de março de 2026 e a documentação remete para o Alloy ou outro cliente suportado no que diz respeito a migrações e novas configurações. Uma instalação existente do Promtail requer, portanto, uma migração planeada em vez de uma atualização automática.

O padrão de configuração mantém-se simples: uma fonte lê ficheiros, o diário ou os registos dos contentores; um processamento opcional pode descartar linhas indesejadas ou preparar campos; em seguida, transfere loki.write os dados para o Loki. O Alloy disponibiliza componentes para, entre outros, ficheiros, registos do systemd, Docker, Kubernetes, Syslog e eventos do Windows. A escolha da fonte depende do local onde a aplicação transmite os seus eventos de forma fiável.

Um modelo ainda não é uma configuração pronta para produção. Os direitos de acesso aos ficheiros devem conceder ao processo Alloy apenas o acesso de leitura necessário; o acesso ao diário, a endereço de destino, a verificação de certificados, o TLS, o armazenamento em buffer em caso de perturbações na rede e a gestão de falhas devem ser verificados consoante a instalação. Os dados de acesso e as informações dos clientes não devem constar em ficheiros de exemplo partilhados. Comece com poucas fontes, verifique o conteúdo e o volume e só depois alargue a recolha de dados.

A filtragem no agente não reduz a responsabilidade pela origem nem substitui um conceito de autorização. No entanto, impede que saídas de depuração conhecidas ou segredos claramente identificados cheguem, de todo, ao repositório central. No que diz respeito a conteúdos necessários do ponto de vista técnico, deve ser possível determinar qual o serviço que os envia, quem os pode ler posteriormente e durante quanto tempo são necessários.

Conceito da marca e planeamento antes do lançamento

A Conceito da marca define em que contexto estável os registos podem ser encontrados. Para vários anfitriões e ambientes, são adequados, por exemplo, env, cluster, namespace, app, service e, se a referência for útil a longo prazo, um nome de anfitrião. Os seus valores devem ser limitados e previsíveis. Cada conjunto distinto de rótulos constitui um fluxo próprio; por isso, o modelo influencia diretamente a gravação, a indexação e as consultas posteriores.

Por outro lado, os IDs de pedido, de rastreio e de utilizador, os endereços IP dos clientes, bem como os IDs dinâmicos de contentores, não são etiquetas adequadas. Geram demasiados valores diferentes e, consequentemente, muitos fluxos pequenos. As informações de alta cardinalidade podem, se necessário, ser incluídas como metadados estruturados. Para uma análise ocasional, é frequentemente mais sensato só recuperar o conteúdo do registo no momento da consulta com json, logfmt, pattern ou regexp analisar.

A tabela não fornece uma previsão de espaço de armazenamento, mas sim uma base para a tomada de decisões. A retenção, em particular, faz parte do plano, uma vez que não pode ser deduzida a partir do volume dos registos: as obrigações legais de conservação, os requisitos de segurança e as diretrizes de eliminação podem diferir entre si. A capacidade de recuperação é também um requisito específico; a eliminação automática de registos expirados não substitui um plano de cópias de segurança ou de recuperação.

Uma primeira norma viável pode ser, por exemplo, env, service e host utilizar para servidores Web clássicos; as plataformas de contentores só complementam cluster e namespace, se estas forem realmente utilizadas de forma seletiva durante a deteção de erros. O esquema deve ser coordenado com os programadores e a equipa de operações. Etiquetas adicionadas posteriormente e inconsistentes dificultam as comparações entre ambientes e tornam a pesquisa centralizada menos fiável.

No planeamento, não conta apenas o que é tecnicamente possível registar, mas também as competências. Uma equipa deve ser responsável pelas fontes e pelos filtros, e outra, se for caso disso, pelo armazenamento e pelo acesso. Desta forma, torna-se claro se um campo em falta no formato de registo deve ser acrescentado, tratado como metadados estruturados ou, deliberadamente, não recolhido.

Proteger adequadamente os clientes e os acessos

O Loki consegue processar dados de registo de forma compatível com múltiplos clientes. Se a separação de clientes estiver ativada, o Loki espera receber o cabeçalho em cada pedido X-Scope-OrgID. No entanto, este cabeçalho não constitui um registo nem uma prova de autorização: caso contrário, um cliente poderia determinar ele próprio o seu valor. O Loki não inclui uma camada de autenticação completa; a proteção e a atribuição obrigatória têm de ser implementadas antes disso.

Um fluxo seguro começa no proxy reverso ou na camada de identidade de confiança. Após o início de sessão bem-sucedido, esta camada identifica a organização autorizada, define o ID do cliente do lado do servidor, impõe o uso de TLS e reencaminha apenas as solicitações autorizadas para o Loki. Os pontos finais do Loki acessíveis diretamente a partir da rede contornariam este controlo. Também os acessos de escrita por parte de agentes requerem uma identidade claramente delimitada e um canal de transmissão protegido.

O conceito de autorizações determina quem pode ler ou introduzir registos. Não substitui nem a filtragem de informações confidenciais nem a verificação da proteção de dados: tokens, IDs de sessão e dados pessoais podem também constituir um problema, mesmo no âmbito de um cliente corretamente atribuído. A minimização de dados deve, por isso, ser aplicada já na fonte e durante o tratamento, enquanto os direitos limitam o conjunto de dados remanescente de acordo com as tarefas e os mandantes.

Em arquiteturas de alojamento distribuídas, é útil tratar o ponto de acesso como uma barreira de segurança independente. O artigo sobre Hospedagem descentralizada e as suas questões de arquitetura explica por que razão os componentes distribuídos não eliminam a responsabilidade centralizada pelas identidades e pelo acesso aos dados. No caso do Loki, isto significa, concretamente, que cada reencaminhamento deve estar associado, de forma rastreável, a uma instância fiável e a uma regra de cliente definida.

Por isso, as verificações regulares não devem limitar-se apenas aos painéis de controlo. Verifique se o proxy rejeita acessos anónimos, se um cabeçalho de cliente predefinido pode ser substituído pelo cliente e se as contas de escrita atingem apenas os destinos previstos. Estas verificações não garantem uma segurança total, mas permitem detetar precocemente falhas típicas entre o início de sessão, o encaminhamento e o armazenamento de registos.

Gerir a retenção e o armazenamento de forma controlada

Os registos centrais não devem ser armazenados simplesmente enquanto houver espaço no armazenamento de objetos. Os Retenção deve estar em conformidade com as obrigações legais, contratuais e operacionais de conservação de dados – e também com o momento a partir do qual os dados deixam de ser úteis para a análise de erros. Sem a retenção ativada, os registos enviados para o Loki são mantidos por tempo ilimitado, de acordo com a documentação. Isso pode aumentar os custos, os riscos de proteção de dados e a dimensão de uma eventual recuperação posterior.

No TSDB e no BoltDB-Shipper, o Compactor aplica os prazos de eliminação configurados. Deve ser executado como uma instância única e dispor de um diretório de trabalho persistente, para que o seu trabalho não se perca parcialmente em caso de reinício. O armazenamento de objetos contém tanto blocos de registo como dados de índice; por isso, a sua conceção faz parte do conceito operacional e não apenas do planeamento de capacidade.

Pode fazer sentido definir prazos diferentes para cada fluxo de registos, por exemplo, quando os eventos de segurança precisam de ser mantidos por mais tempo do que as saídas detalhadas de depuração. Essas regras relacionadas com fluxos exigem um período mínimo de retenção de 24 horas e funcionam exclusivamente com seletores de etiquetas. Não estão previstos filtros de conteúdo nem expressões LogQL arbitrárias para este efeito. Por isso, as etiquetas têm de refletir de forma fiável o contexto técnico antes de as regras de retenção se basearem nelas.

Aviso: Uma regra de ciclo de vida genérica aplicada a todo o bucket de armazenamento pode remover objetos de índice ou de estado do cluster e comprometer as consultas. É preferível adotar uma estratégia de eliminação direcionada, que tenha em conta a retenção do Loki, as classes de armazenamento e buckets ou prefixos separados. Além disso, a retenção não substitui o backup: determina a eliminação planeada dos dados de registo, enquanto os requisitos de recuperação definem quais as configurações, vias de acesso e, se for caso disso, dados de armazenamento que devem estar disponíveis após uma falha.

Detetar ondas de erro e verificar problemas de gravação

No Grafana Explore, é possível analisar eventos de vários anfitriões num período de tempo comum. Isto agiliza o processo em caso de incidente: em vez de iniciar sessão nos servidores web um a um, a análise pode ser inicialmente restringida por ambiente e serviço. No entanto, uma pesquisa centralizada mostra correlações, mas não a causa automaticamente; métricas, rastreios, implementações e o estado da aplicação continuam a ser complementos importantes para o diagnóstico.

No caso de uma onda de erros, o LogQL pode calcular uma métrica a partir das linhas relevantes. A consulta seguinte, a título de exemplo, conta as linhas do Nginx com o estado HTTP 500, calculando a taxa ao longo de cinco minutos. Esta consulta serve de base para uma análise ou um alerta, mas não indica qual o valor crítico em cada aplicação.

sum(rate({env="prod", service="nginx"} |= " 500 " [5m]))

Uma forma sensata de Limite de alerta resulta da taxa normal de erros, do comportamento da aplicação e dos sinais de monitorização existentes. Um único erro 500 pode ser avaliado de forma diferente numa função administrativa raramente utilizada do que num processo de checkout. Por isso, analisa primeiro os padrões históricos e atribui a alarme a uma equipa responsável específica, antes de a escalar para o ambiente de produção.

Se o Loki responder com o código 429 durante a escrita, os limites não devem ser aumentados de forma automática. Em primeiro lugar, é necessário esclarecer se um serviço está a gerar um número invulgarmente elevado de linhas, se um ciclo está a repetir erros ou se os rótulos dinâmicos estão a gerar um grande número de pequenos fluxos. O Loki limita a gravação globalmente e por fluxo, para proteger a plataforma. Só após esta verificação é que se pode decidir se são necessários filtragem, correções de etiquetas ou um ajuste justificado dos limites.

Utilizar o Loki de forma adequada e responsável

Para um único VPS com Nginx, systemd e poucos contentores, o Loki pode proporcionar uma pesquisa centralizada e fácil de gerir no modo monolítico, desde que as fontes de registo, o armazenamento e os acessos estejam claramente definidos. A documentação atribui este modo a experiências e a pequenos volumes de leitura e escrita; cerca de 20 GB de registos por dia constituem uma orientação do fabricante, não uma garantia de capacidade para qualquer estrutura de armazenamento, consulta ou etiquetagem.

Vários servidores Web Linux beneficiam particularmente de uma linha temporal comum para eventos da Web, de registo e de aplicações. Nas implementações em contentores, um modelo de etiquetas estável para o ambiente e o serviço determina se esta pesquisa se mantém viável. Ambientes Kubernetes de grande dimensão ou funções que necessitem de ser dimensionadas separadamente podem justificar o modo de microsserviços, mas implicam, nesse caso, um esforço significativamente maior em termos de operações e análise de erros. Para novos projetos, o SSD não é uma opção padrão permanente, uma vez que este modo está marcado como obsoleto.

Uma plataforma multicliente necessita, além disso, de uma cadeia de acesso robusta. O Loki separa as solicitações através do identificador do cliente, mas não fornece uma camada de autenticação completa. Um proxy fiável ou uma camada de identidade deve autenticar os acessos, impor o uso de TLS e definir a atribuição do lado do servidor. Um agente compatível também faz parte da base: o Promtail já não é suportado; para novas instalações, o Grafana Alloy é a opção recomendada.

• VPS individual: definir um inventário de fontes, filtros para informações confidenciais e uma política de retenção simples e verificável antes da implementação.
• Vários hosts: definir etiquetas consistentes para o ambiente e o serviço, para que a pesquisa centralizada reduza efetivamente os percursos dos incidentes.
• Plataforma de contentores: não utilizar IDs dinâmicos como etiquetas; monitorizar continuamente o número de fluxos e o comportamento de gravação.
• Funcionamento multicliente: implementar a autenticação, a atribuição de clientes no lado do servidor e as autorizações antes da partilha dos terminais Loki.
• Qualquer ambiente: documentar os requisitos de recuperação e verificar regularmente a configuração, o conceito de armazenamento e os prazos de eliminação.

Caso não existam responsáveis pelas fontes de registo, um plano para conteúdos sensíveis ou objetivos claros de recuperação, deve-se, em primeiro lugar, definir estes Princípios de funcionamento deve ser esclarecido. O Loki permite agregar registos e torná-los pesquisáveis, mas não substitui nem a minimização de dados, nem as cópias de segurança, nem o controlo de acesso, nem uma análise técnica das causas. A utilidade só se concretiza quando a tecnologia, as responsabilidades e a conservação dos dados são planeadas em conjunto.