M365Con 2027 – conferência online gratuita · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Preços do Azure Log Analytics: como impedir que os custos de monitoramento do Azure disparem

By ·

Saiba como controlar os preços do Azure Log Analytics, otimizar os planos de tabelas do workspace, filtrar o ruído da ingestão e impedir que os custos de monitoramento na nuvem disparem.

Automatically translated with AI from the original post. Read the English original

Cover: Log Analytics - Simply Explained

Controlar os preços do Azure Log Analytics exige entender o volume de ingestão, os planos de dados por tabela e os custos de retenção de longo prazo. Ao implementar a filtragem antecipada de dados com KQL, escolher planos de nível adequados, como Básico e Auxiliar, e evitar limites diários perigosos de coleta, os administradores podem impedir que as faturas de monitoramento do Azure saiam do controle.

Principais conclusões

Os verdadeiros fatores de custo do Log Analytics

Quando as organizações implantam o monitoramento na nuvem pela primeira vez, o foco é quase inteiramente na visibilidade: garantir que os sistemas se comuniquem entre si e que cada erro seja capturado. No entanto, a realidade aparece quando a fatura mensal da nuvem chega. O Log Analytics é cobrado principalmente com base em dois vetores de consumo: o volume de gigabytes enviados ao seu workspace e o tempo que esses registros ficam disponíveis para consultas interativas.

Criar um workspace em si não custa nada, o que muitas vezes cria uma falsa sensação de segurança. As equipes tendem a tratar seus repositórios de logs como gavetas de bagunça digital infinitas, despejando em um único contêiner dados verbosos de depuração de aplicativos, sinais de heartbeat redundantes e rastros não verificados. Como você paga por cada gigabyte que chega à sua porta, independentemente de alguém abrir aquela tabela específica, a ingestão de dados sem governança rapidamente leva a estouros de orçamento.

Navegando pelos planos de tabela: Analytics, Básico e Auxiliar

Uma das decisões de maior impacto que um administrador pode tomar é atribuir o plano de preço correto a cada tabela. Nem todos os dados de log exigem o mesmo nível de desempenho, e a Microsoft oferece planos em níveis que refletem essas trocas operacionais.

Nível Analytics padrão

O plano Analytics padrão é feito para dados que você monitora de perto e precisa consultar instantaneamente. Ele oferece suporte à detecção de ameaças em tempo real e à solução rápida de problemas. No entanto, também é a opção mais cara. Ele mantém indexação completa para permitir a execução de consultas em menos de um segundo em instruções complexas da Kusto Query Language (KQL).

Níveis Básico e Auxiliar

Para dados que você analisa apenas de forma reativa, quando algo quebra, ou para registros de alto volume mantidos somente para auditoria, os planos Básico e Auxiliar oferecem economias expressivas. Enquanto o Analytics padrão pode custar cerca de US$ 2,30 por gigabyte, os planos Básico podem reduzir esse preço de forma substancial, e os níveis Auxiliar podem levar os custos a uma fração das tarifas padrão (chegando, em alguns casos, a ser até 46 vezes mais baratos na faixa inferior).

O porém está na funcionalidade operacional. Planos mais baratos são mais lentos para pesquisar, não têm indexação completa e não são adequados para alertas de segurança em tempo real. Combinar esses planos em um único workspace permite direcionar sinais críticos de segurança para tabelas caras e de alta velocidade, enquanto os logs de conformidade mais volumosos ficam em um armazenamento auxiliar barato.

Como reduzir custos com filtragem antecipada e regras de coleta de dados

O maior erro que os administradores cometem é tentar limpar os dados depois que eles já chegaram ao workspace. Quando um registro de log é armazenado, você já está pagando pela sua ingestão.

A abordagem correta utiliza regras de coleta de dados (DCRs, na sigla em inglês) em conjunto com o Azure Monitor Agent. As DCRs funcionam como conjuntos de instruções implantados nas suas máquinas virtuais e nos seus clusters de contêineres. Elas definem exatamente quais eventos coletar, como moldá-los e em qual tabela devem ser armazenados. Mais importante ainda, permitem descartar ruído repetitivo na origem.

Se uma aplicação gera milhares de logs informativos repetitivos por hora que sua equipe nunca consulta, descarte-os na entrada. Reformatar e filtrar os dados antes de chegarem ao mecanismo de armazenamento garante que você nunca receba uma cobrança por telemetria que não usa.

O perigo dos limites diários de ingestão

Diante de faturas de nuvem imprevisíveis, muitos gestores financeiros e de TI recorrem ao recurso de limite diário do Azure Log Analytics como uma rede de segurança absoluta. Um limite diário estabelece um teto rígido para a ingestão de dados: assim que o limite é atingido, o workspace deixa de aceitar novos registros pelo restante do dia.

Embora isso evite picos financeiros inesperados, a Microsoft alerta explicitamente contra depender dele para a gestão rotineira de custos. Quando um limite diário é acionado, a coleta de dados para por completo. Seus analistas de segurança perdem a visibilidade, suas equipes de operações ficam às cegas e você deixa de receber alertas críticos se ocorrer uma falha de sistema durante a noite. Um apagão de visibilidade causado por uma interrupção é quase sempre mais caro do que uma conta de monitoramento em nuvem um pouco mais alta.

Equilibrando retenção interativa e arquivos de longo prazo

O controle de custos vai além da ingestão e envolve também por quanto tempo seus dados permanecem disponíveis. Por padrão, a retenção interativa oferece acesso rápido para consultas por 31 dias (ou 90 dias, se o Microsoft Sentinel estiver habilitado). Depois que essa janela se fecha, os dados não desaparecem; eles passam para o armazenamento de longo prazo.

Manter os dados consultáveis de forma interativa custa significativamente mais por gigabyte, por mês, do que arquivá-los no armazenamento de longo prazo. Para exigências de conformidade que obrigam a reter dados por anos, o armazenamento de arquivo custa centavos por gigabyte. Só lembre que recuperar dados arquivados exige executar trabalhos de pesquisa, em vez de consultas interativas instantâneas, por isso uma estratégia bem planejada desde o início é essencial.

Conclusão e próximos passos

Gerenciar os preços do Azure Log Analytics é um exercício de arquitetura intencional. Ao abandonar uma estratégia de coleta indiscriminada, aproveitar planos específicos por tabela e implementar regras rigorosas de coleta de dados na origem, você consegue manter uma visibilidade de nível corporativo sem estourar o orçamento de nuvem.

Para aprofundar os fundamentos de como esses sistemas funcionam por trás dos panos, não deixe de ouvir o episódio completo do M365 FM Podcast, com uma explicação sem jargões sobre workspaces, tabelas e noções básicas de consultas KQL.

Perguntas frequentes

Criar um workspace do Azure Log Analytics é gratuito?

Sim, criar um workspace não gera nenhuma cobrança base. Você paga apenas pelo volume de dados ingeridos no workspace e pelo período em que esses dados são armazenados.

Qual é a diferença entre os planos Analytics, Basic e Auxiliar?

O plano Analytics oferece armazenamento de alta velocidade, com indexação completa, otimizado para alertas de segurança em tempo real e consultas interativas rápidas. Os planos Basic e Auxiliar oferecem opções de armazenamento muito mais baratas para dados pesquisados com pouca frequência ou mantidos principalmente para fins de conformidade e arquivamento.

Por que devo evitar os limites diários de ingestão?

Os limites diários de ingestão interrompem totalmente a coleta de dados assim que o seu teto de gastos é atingido. Isso deixa seus sistemas de segurança e monitoramento às cegas pelo resto do dia, criando riscos inaceitáveis durante interrupções de sistema ou violações de segurança.

Como posso reduzir os custos de ingestão de dados do Log Analytics?

A estratégia de redução de custos mais eficaz é filtrar os dados de log desnecessários na origem, usando Regras de Coleta de Dados (DCRs), para que logs de depuração ruidosos e que ninguém lê sejam descartados antes de chegar ao workspace faturável.

Fabric workspace Kusto Query Language (KQL)

Related articles

RSS