A diferença entre dados de uso auditáveis e operacionais

Com a adoção da IA, a atribuição de uso e os casos de uso de chargeback estão aumentando. As empresas modernas também estão ansiosas para coletar e atribuir dados de uso a seus clientes e departamentos internos, para impulsionar o faturamento, as vendas, o desenvolvimento de produtos e a análise de custos da nuvem.

A FinOps Foundation também revelou recentemente o rascunho inicial de seu FOCUS (Open Cost & Usage Specification). Por que os dados de uso podem ser complexos e o que diferencia a medição de eventos das métricas de séries temporais?

Casos de uso de dados de uso

Antes de nos aprofundarmos nas complexidades dos casos de uso de cobrança, análise e monitoramento, vamos definir o que queremos dizer com dados de uso. O uso descreve alguém consumindo um bem em um período de tempo. Por exemplo, entre 13h e 14h, Alice enviou 100 SMS via Twillio API.

O uso geralmente é descrito por um período de tempo em vez de uma única data porque os computadores são rápidos, mas os humanos são lentos. Vejamos alguns dos casos de uso comuns que requerem dados de uso:

Faturamento: Isso requer dados de uso precisos, pois os clientes são cobrados com base em termos de contrato juridicamente vinculativos. Embora as dimensões de dados geralmente sejam limitadas, a cardinalidade é alta, pois os dados de uso devem ser rastreados para cada cliente.

Dados em tempo real são opcionais, mas notificações imediatas são necessárias quando um usuário atinge um limite de cobrança. A retenção de dados é crucial para validar as faturas, embora isso se torne menos importante uma vez que a fatura seja liquidada.

Monitoramento: Isso requer dados de uso em tempo real para fins de alerta. A precisão é importante, mas é mais flexível do que o faturamento. Os sistemas de monitoramento geralmente são limitados em torno da cardinalidade.

A retenção de dados geralmente é curta devido aos custos de armazenamento de grandes volumes de dados de monitoramento, que raramente são utilizados após algumas semanas.

Analytics: Casos de uso típicos, como custo de nuvem, análise de margem e precificação, exigem dados históricos precisos dos últimos três a cinco anos para treinar modelos e identificar tendências de maneira eficaz. Analytics raramente é em tempo real.

Resumido em uma tabela:

Como você pode ver, cada caso de uso tem necessidades diferentes, o que pode ser confuso ao discutir os dados de uso.

Noções básicas sobre dados auditáveis e operacionais

O conceito de classificar os dados como auditáveis ou operacionais chamou minha atenção pela primeira vez em 2018 por meio de um tweet de Charity Majors, cofundador da Honeycomb.io .

Os dados auditáveis são classificados como tal quando a perda de qualquer registro de dados é intolerável e a retenção total dos registros é necessária. Ao utilizar um conjunto de dados auditáveis, espera-se que seja abrangente e completo.

Exemplos de dados auditáveis incluem logs de transações, logs de replicação e eventos de faturamento/finanças.

Os dados operacionais , por outro lado, não exigem integridade estrita. Para manter os custos gerenciáveis, a amostragem é frequentemente empregada e algum grau de perda de dados é aceitável.

As ferramentas projetadas para gerenciar dados operacionais geralmente priorizam a eficiência do esforço, ignorando novas tentativas e garantias caras de exatamente uma entrega. Exemplos de dados operacionais incluem telemetria, métricas e dados contextuais que descrevem cada solicitação e componente do sistema.

Antes de decidir sobre a metodologia de coleta, processamento e armazenamento de seus dados de uso, é importante determinar se seus dados precisam ser auditáveis ou operacionais.

Na seção a seguir, compararemos duas estratégias de coleta de dados: medição orientada a eventos, geralmente mais adequada para casos de uso auditáveis, e monitoramento de séries temporais, o método preferido para coletar dados de uso operacional.

Medição baseada em eventos versus métricas de séries temporais

Há duas maneiras principais de coletar dados de uso:

1. medição orientada a eventos e

   
   

2. sistemas de monitoramento de séries temporais .

   
   

Veja como eles se comparam:

Medição orientada a eventos: as empresas de cobrança com base no uso favorecem essa abordagem, pois ela é auditável devido à sua consistência inerente ao lidar com eventos exclusivos. Os eventos podem ser entregues duas vezes em sistemas distribuídos e desduplicados usando identificadores exclusivos para evitar superfaturamento ou subfaturamento.

A medição lida bem com alta cardinalidade, que é necessária para rastrear o uso de cada cliente. O desafio, no entanto, está na coleta de dados. A indústria possui coletores de infraestrutura robustos para monitoramento, mas eles foram projetados com algo diferente de eventos em mente.

A maioria dos fornecedores fornece uma API POST para envio de eventos, deixando o processo de coleta para o usuário.

Monitoramento de séries temporais: sistemas de monitoramento como o Prometheus raspam contadores e histogramas para armazenar e fornecer métricas como dados operacionais de séries temporais.

É recomendável manter a cardinalidade baixa, dificultando o rastreamento do consumo de recursos do usuário individual em grande escala. A coleta de métricas é um caminho bem pavimentado no setor, com extratores de métricas prontos para uso disponíveis para a maioria dos componentes de infraestrutura.

Os fornecedores de APM investiram significativamente em padrões como OpenTelemetry para simplificar a coleta de dados. O desafio reside nas garantias limitadas do coletor de métricas em relação à entrega e desduplicação, uma vez que foram projetadas tendo em mente os casos de uso de dados operacionais.

Os colaboradores do Prometheus compartilham algumas ideias sobre precisão aqui . Se você quiser se aprofundar, também pode encontrar algum debate sobre como ajustar a raspagem para aumentar a precisão do contador aqui .

Resumido em uma tabela:

O futuro do uso: consolidação

O desafio atual está na coleta e integração de dados de uso. Essas tarefas são complexas porque a coleta de uso deve equilibrar os aspectos de precisão, cardinalidade e tempo real de maneira diferente por caso de uso (conforme ilustrado na comparação de eventos x métricas), enquanto a integração é demorada devido à necessidade de um padrão de especificação de uso.

Basta pensar em todas as APIs personalizadas do fornecedor ou na interface genérica do PromQL. Essa falta de consolidação cria dificuldades na integração de dados de uso em casos de uso de faturamento, estorno e análise de custos, muitas vezes resultando em sistemas separados para coleta de dados de uso, em vez de compartilhamento entre eles.

FOCO do FinOps: uma nova especificação para integração de uso

O FOCUS (Open Cost & Usage Specification) da FinOps visa abordar os desafios de integração dos dados de uso. O FOCUS descreve uma especificação para produzir e consumir uso normalizado e dados de cobrança por provedores de nuvem e fornecedores de SaaS.

O FOCUS permitirá que você integre perfeitamente os dados de uso entre fornecedores, para cobrança e casos de uso de análise de custos de nuvem.

A especificação FOCUS está atualmente em desenvolvimento; a versão de visualização 0.5 acabou de ser lançada no final de junho de 2023 e a especificação está atualmente mais focada no faturamento do que nos dados de uso.

Você pode seguir ou juntar-se ao grupo de trabalho FOCUS aqui .

Reconciliando precisão, cardinalidade e pontualidade

Não prevejo uma convergência de medição de eventos e sistemas de métricas, pois cada um deles equilibra compensações distintas de negócios e engenharia para atender a seus casos de uso. Basta pensar nas diferenças entre dados auditáveis e operacionais.

Mas espero convergência nos padrões em torno da integração de dados de uso entre fornecedores como o FOCUS da FinOps.

Precisamos da sua opinião. O OpenMeter deve ingerir métricas e integrar-se ao Prometheus para simplificar os casos de uso de cobrança e chargeback?

Informe-nos em nosso repositório de código aberto: https://github.com/openmeterio/openmeter