Preços do Cloud Monitoring
Os preços da observabilidade do Google Cloud permitem controlar o uso e gastos. Os preços dos produtos de observabilidade do Google Cloud são determinados por volume de dados ou uso. Você pode usar as cotas de uso de dados para começar sem adiantamento de taxas ou compromissos.
As tabelas a seguir resumem as informações de preços do Cloud Logging, do Cloud Monitoring e do Cloud Trace:
Resumo dos preços do Cloud Logging
Recurso | Preço1 | Cota gratuita por mês |
---|---|---|
Armazenamento do Logging* | US$ 0,50/GiB; Cobrança única pelo streaming de registros no armazenamento do bucket de registros para indexação, consulta e análises; inclui até 30 dias de armazenamento em buckets de registros. Não há cobranças extras para consultar e analisar dados de registros. |
Primeiros 50 GiB/projeto/mês |
Retenção de registros† | US$ 0,01 por GiB por mês para registros retidos por mais de 30 dias; faturado mensalmente de acordo com a retenção. | Os registros retidos pelo período de armazenamento padrão não geram custo de retenção. |
Roteador de registros‡ | Sem custo extra | Não relevante |
Análise de registros♣ | Sem custo extra | Não relevante |
_Required
.† Não há cobranças de retenção para registros armazenados no bucket de registros
_Required
,
com um período de armazenamento fixo de 400 dias.‡ O roteamento de registros é definido como o encaminhamento de registros recebidos pela API Cloud Logging para um com suporte. Cobranças de destino podem ser aplicadas aos registros roteados.
♣ Não há custos para fazer upgrade de um bucket de registros para usar a Análise de dados de registros ou emitir consultas SQL na página Análise de dados de registros.
Observação: a linguagem de preços do Cloud Logging mudou em 19 de julho de 2023. No entanto, as cotas e as taxas não mudaram. Sua fatura pode se referir ao antigo linguagem de preços.
Resumo dos preços do Cloud Monitoring
Recurso | Preço | Cota gratuita por mês | Início da vigência |
---|---|---|---|
Todos os dados do Monitoring exceto dados ingeridos usando o Managed Service para Prometheus |
US$ 0,2580/MiB1: primeiros 150–100.000 MiB US$ 0,1510/MiB: próximos 100.000–250.000 MiB US$ 0,0610/MiB : mais de 250.000 MiB |
Todas as métricas não faturáveis do Google Cloud Primeiros 150 MiB por conta de faturamento para métricas cobradas por bytes ingeridos |
1º de julho de 2018 |
Métricas ingeridas usando Google Cloud Managed Service para Prometheus, incluindo Métricas do plano de controle do GKE | US$ 0,06/milhão de amostras†: primeiras 0 a 50 bilhões de amostras ingeridas† US$ 0,048/milhão de amostras: próximas 50 a 250 bilhões de amostras ingeridas US$ 0,036/milhão de amostras: próximas 250 a 500 bilhões de amostras ingeridas US$ 0,024/milhão de amostras: mais de 500 bilhões de amostras ingeridas |
Não relevante | 8 de agosto de 2023 |
Chamadas de API do Monitoring | US$ 0,01/1.000 chamadas de API de leitura (as chamadas de gravação são gratuitas) |
Primeiro milhão de chamadas de API de leitura incluídas por conta de faturamento | 1º de julho de 2018 |
Execução de verificações de tempo de atividade de monitoramento. | USD 0,30/1.000 execuções‡ | 1 milhão de execuções por projeto do Google Cloud | 1º de outubro de 2022 |
Execução de Como monitorar monitores sintéticos | USD 1,20/1.000 execuções* | 100 execuções por conta de faturamento | 1 de novembro de 2023 |
Políticas de alertas | US$ 1,50 por mês para cada condição em uma política de alertas US$ 0,35 por 1.000.000 série temporal retornadas pela consulta de uma condição de política de alertas de métricas♣ |
Não relevante | 7 de janeiro de 2025 |
# As amostras são contadas por conta de faturamento.
‡ As execuções são cobradas na conta de faturamento em que são definidas. Para mais informações, consulte Preços para execução da verificação de tempo de atividade.
* As execuções são cobradas na conta de faturamento em que são definidas. Para cada execução, você pode ter cobranças adicionais de outros serviços do Google Cloud, incluindo serviços como o Cloud Functions, Cloud Storage e Cloud Logging. Para informações sobre essas cobranças adicionais, consulte o documento de preços do respectivo serviço do Google Cloud.
♣ Para mais informações, consulte Preços para alertas.
Resumo dos preços do Cloud Trace
Recurso | Preço | Cota gratuita por mês | Início da vigência |
---|---|---|---|
Processamento do Trace | US$ 0,20/milhão de períodos | Os primeiros 2,5 milhões de períodos por conta de faturamento | 1º de novembro de 2018 |
Para informações detalhadas sobre os custos dos produtos de observabilidade do Google Cloud, consulte as seguintes seções desta página:
Para informações sobre os preços do GKE Enterprise, consulte GKE Enterprise
Como visualizar o uso
Para acessar seu uso atual, acesse a página Relatórios do Cloud Billing do console do Google Cloud
Com base nos dados de uso atuais, é possível fazer uma estimativa das faturas usando a calculadora de preços.
Por exemplo, uma configuração em que toda instância de VM do Compute Engine gera 10 GiB de registros sujeitos a cobrança e 20 MiB de métricas sujeitas a cobrança por mês. Ao usar a calculadora de preços, você determina o custo estimado do Cloud Monitoring e do Cloud Logging:
1 VM | 10 VMs | 100 VMs | 1.000 VMs | |
---|---|---|---|---|
Custo de métricas por mês | US$ 0,00 | US$ 12,90 | US$ 477,30 | US$ 5.121,30 |
Custo da geração de registros por mês | US$ 0,00 | US$ 25,00 | US$ 475,00 | US$ 4.975,00 |
Custo total: | US$ 0,00 | US$ 37,90 | US$ 952,30 | US$ 10.096,30 |
Como configurar um alerta de faturamento
Para receber notificações caso as cobranças faturáveis ou previstas excedam um orçamento, Crie um alerta na página Orçamentos e alertas do console do Google Cloud:
-
No console do Google Cloud, abra a página Faturamento:
Também é possível encontrar essa página usando a barra de pesquisa.
Se você tiver mais de uma conta do Cloud Billing, siga um destes procedimentos: seguinte:
- Para gerenciar o Cloud Billing no projeto atual, selecione Acessar a conta de faturamento vinculada.
- Para localizar outra conta do Cloud Billing, selecione Gerenciar contas de faturamento e escolha a opção em que você quer definir um orçamento.
- No menu de navegação de faturamento, selecione Orçamentos e alertas.
- Clique em Criar orçamento.
- Preencha a caixa de diálogo do orçamento. Nesse campo, selecione projetos e produtos do Google Cloud e depois crie um orçamento para a combinação. Por padrão, você recebe notificações ao atingir 50%, 90% e 100% do orçamento. Para ver a documentação completa, consulte Definir orçamentos e alertas.
Cloud Logging
Os buckets de registros são os contêineres do Logging que armazenam dados de registros.
O Logging faz a cobrança pelo volume de dados de registro armazenados
no bucket de registros _Default
e nos buckets definidos pelo usuário
quando esse volume exceder
cota mensal gratuita.
Para os bucket de registros _Default
e definidos pelo usuário,
O Logging também cobra quando os registros são
retido por mais tempo do que o período de armazenamento padrão, que é
30 dias.
Não há cobranças extras do Logging para rotear registros,
para usar a API Cloud Logging ou para registros armazenados no bucket de registros _Required
,
com um período de armazenamento fixo de 400 dias.
Esta seção fornece informações sobre os seguintes tópicos:
- Modelo de armazenamento do Cloud Logging
- Preços de armazenamento
- Preços de retenção
- Reduzir seu armazenamento de registros
- Preços das métricas com base em registros
- Criar uma política de alertas sobre bytes de registro ingeridos mensalmente
Para um resumo das informações de preços, consulte Resumo de preços do Cloud Logging.
Para saber os limites que se aplicam ao seu uso do Logging, incluindo períodos de armazenamento de dados, consulte Cotas e limites.
Para ver e entender seus dados de uso do Cloud Logging, consulte Como estimar suas faturas.
Modelo de armazenamento do Cloud Logging
Para cada projeto do Google Cloud, o Logging
cria dois buckets de registros: _Required
e _Default
.
Para esses dois buckets, o Logging cria coletores de registros automaticamente
chamados _Required
e _Default
, que encaminham registros para a rede
buckets de registros. Não é possível desativar ou modificar o coletor _Required
. É possível desativar
ou modificar o coletor _Default
para evitar que o bucket _Default
seja
para armazenar novos registros.
Você pode Criar buckets de registros definidos pelo usuário em qualquer um dos seus projetos do Google Cloud. Também é possível configurar coletores para rotear qualquer combinação de registros, mesmo em projetos do Google Cloud na sua organização do Google Cloud a esses buckets de registro.
Nos bucket de registros _Default
e definidos pelo usuário, é possível
configure um período de armazenamento personalizado.
É possível fazer upgrade dos buckets de registros Análise de dados de registros. O upgrade de um bucket de registros para usar a Análise de dados de registros não é cobrado.
Para mais informações sobre buckets e coletores do Cloud Logging, consulte Visão geral de roteamento e armazenamento.
Preços de armazenamento
O Logging não cobra por registros armazenados no bucket _Required
.
Não é possível excluir o bucket _Required
ou modificar o coletor _Required
.
O bucket _Required
armazena os seguintes registros:
- Registros de auditoria de atividade do administrador
- Registros de auditoria de eventos do sistema
- Registros de auditoria do administrador do Google Workspace
- Registros de auditoria do Grupos do Google Enterprise
- Registros de auditoria de login
- Registros de transparência no acesso Para informações sobre como ativar os registros da Transparência no acesso, consulte Documentação dos registros de Transparência no acesso.
O Logging cobra pelo volume pré-indexado de dados de registros que
armazenadas no bucket de registros _Default
e em buckets de registro definidos pelo usuário,
quando o volume total exceder a cota mensal gratuita.
Toda gravação de uma entrada de registro no bucket de registros _Default
ou em um
o bucket de registros definido pelo usuário é contabilizado na cota de armazenamento.
Por exemplo, se você tem coletores que roteiam uma entrada de registro para
três buckets de registro, essa entrada de registro é armazenada três vezes.
Preço de retenção
A tabela a seguir lista os períodos de armazenamento de dados para registros armazenados em buckets de registros:
Bucket | Período de armazenamento padrão | Armazenamento personalizado |
---|---|---|
_Required |
400 dias | Não configurável |
_Default |
30 dias | Configurável |
Definido pelo usuário | 30 dias | Configurável |
O Logging cobra os custos de retenção quando os registros são mantidos por mais tempo
do que o período de armazenamento padrão. Não é possível configurar o período de armazenamento
para o bucket de registros _Required
.
Não há custos de retenção quando os registros são armazenados apenas para
o período de armazenamento padrão do bucket de registros.
Se você reduzir o período de armazenamento de um bucket de registros, período de carência em que os registros expirados não são excluídos. Não é possível consultar ou visualizar registros expirados. No entanto, nesses sete dias, você poderá restaurar o acesso total extensão do período de armazenamento do bucket de registros. Os registros armazenados durante o período de carência são contabilizados nos custos de retenção.
Se você encaminhar uma entrada de registro para vários buckets, poderá receber cobranças
os custos de armazenamento e retenção várias vezes. Por exemplo, suponha que você direcione
uma entrada de registro no bucket de registros _Default
e em um definido pelo usuário.
Além disso, imagine que você configurou um período de armazenamento personalizado para os dois buckets
há mais de 30 dias. Para essa configuração,
você receberá duas cobranças de armazenamento e duas de retenção.
Reduzir o armazenamento de registros
O Logging permite identificar e excluir manualmente entradas de registro estão sendo armazenadas em buckets de registros ao configurar filtros de exclusão nos seus coletores. Ao usar filtros de exclusão, é possível reduzir os custos de armazenamento. Como alternativa, considere rotear os registros para fora do Cloud Logging.
Os filtros de exclusão podem remover todas as entradas de registro que correspondem ao filtro ou pode remover apenas uma porcentagem dos registros que correspondem ao filtro. Quando uma entrada de registro corresponde ao filtro de exclusão de um coletor, esse coletor não encaminha a entrada de registro para o destino. Como resultado, e um destino não ingere a entrada de registro. As entradas de registro excluídas não contam em relação à cota de armazenamento. Para instruções sobre como configurar filtros de exclusão, consulte Exclusões de registros.
Para manter o acesso a registros que não são armazenados em buckets, também é possível usar para rotear entradas de registro do Cloud Logging para um destino. O Cloud Logging não cobra para rotear registros. No entanto, os serviços do Google Cloud que recebem os registros cobram pelo uso. Para mais informações, consulte estes documentos:
Para informações sobre como rotear registros do Cloud Logging, consulte Rotear registros para destinos compatíveis.
Preços das métricas com base em registros
As métricas com base em registros definidas pelo sistema são fornecidas para todos os projetos do Google Cloud e não estão sujeitas a cobranças.
As métricas com base em registros definidas pelo usuário são uma classe de métricas personalizadas do Cloud Monitoring e são faturáveis. Para ver detalhes de preços, consulte Métricas faturáveis.
Para mais informações, consulte Visão geral das métricas com base em registros.
Criar uma política de alertas sobre bytes de registro ingeridos mensalmente
Para criar uma política de alertas que é acionada quando o número de bytes de registro gravados nos buckets de registros excedem o limite definido pelo usuário para Cloud Logging, use as configurações a seguir.
Novo estado Campo |
Valor |
---|---|
Recurso e métrica | No menu Resources, selecione Global. No menu Categorias de métrica, selecione Métrica com base em registros. No menu Métricas, selecione Bytes de registro mensais ingeridos. |
Filtrar | Nenhuma. |
Várias séries Agregação de série temporal |
sum |
Janela contínua | 60 m |
Função de janela contínua | max |
Campo Configurar gatilho de alerta |
Valor |
---|---|
Tipo de condição | Threshold |
Acionador de alerta | Any time series violates |
Posição do limite | Above threshold |
Valor do limite | Você determina o valor aceitável. |
Teste a janela novamente | O valor mínimo aceitável é de 30 minutos. |
Cloud Monitoring
O Monitoring cobra pelos seguintes itens:
Métricas medidas por bytes ingeridos, quando os dados de métricas ingeridos excedem a cota de métricas mensal gratuita.
Métricas não sujeitas a cobrança não contam para o limite de cota.
Métricas medidas pelo número de amostras ingeridas.
Chamadas de leitura da API Cloud Monitoring que excedem a cota de API mensal gratuita.
As chamadas de gravação da API Monitoring não são contabilizadas no limite de cotas.
Execução de verificações de tempo de atividade.
Execução de monitores sintéticos.
Condições da política de alertas medidas pelo número de condições ativas por mês.
Séries temporais retornadas pela consulta de uma condição da política de alertas.
No Monitoring, ingestão refere-se ao processo de gravação de série temporal no Monitoring. Cada série temporal inclui um número de pontos de dados; esses pontos de dados são a base para as cobranças de processamento. Para informações sobre preços, consulte Preços do Cloud Monitoring.
Nesta seção, você encontra as informações a seguir:
- Definições de métricas sujeitas a cobrança e não faturáveis.
- Descrições de estratégias de processamento baseadas em byte e amostra.
- Exemplos de preços para métricas cobradas por bytes ingeridos.
- Exemplos de preços para métricas cobradas por amostras ingeridos.
- Exemplos de preços para execução de verificações de tempo de atividade (Início da vigência: 1o de outubro de 2022).
- Exemplos de preços para execução de monitores sintéticos (Início da vigência: 1o de novembro de 2023).
- Descrições e exemplos de preços de alertas (Início da vigência: 7 de janeiro de 2025).
Para informações sobre os preços atuais, consulte Preços do Cloud Monitoring.
Para saber os limites que se aplicam ao uso do Monitoring, consulte Cotas e limites.
Para ver o uso atual, siga um destes procedimentos:
-
No console do Google Cloud, abra a página Faturamento:
Também é possível encontrar essa página usando a barra de pesquisa.
-
No console do Google Cloud, acesse a página settings Configurações de monitoramento:
Acessar Configurações do Monitoring
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.
Com base nessas informações, faça uma estimativa das suas faturas.
Métricas não faturáveis
Os dados de métricas do Google Cloud, GKE Enterprise e Knative não são sujeito a cobrança. Estas são as métricas não sujeitas a cobrança (gratuitas):
- Métricas do Google Cloud. Para mais informações, consulte a nota de rodapé 2.
- Métricas do GKE Enterprise. Para mais informações, consulte a nota de rodapé 2.
- Métricas do Istio
- Métricas do Knative
- Métricas do sistema do Google Kubernetes Engine
- métricas
agent.googleapis.com/agent/
Métricas sujeitas a cobrança
Todos os dados de métricas, exceto os listados na seção Métricas não faturáveis, são faturáveis. A maior parte da ingestão de métricas é cobrada pelo número de bytes, mas algumas são cobradas pelo número de amostras. descritos nas seções a seguir.
Os fatores a seguir contribuem para os custos de ingestão:
O tipo de pontos de dados, valores escalares ou de distribuição, coletados pelas métricas.
- Para informações sobre o tipo de dados associado a um tipo de métrica específico, consulte a lista de métricas.
- Para informações sobre tipos de dados escalares e de distribuição, consulte Tipos de valor.
O número de pontos de dados gravados em séries temporais. Esse valor depende da frequência com que os dados são amostrados e da cardinalidade dos seus dados. A cardinalidade determina quantas séries temporais são geradas para uma combinação de tipos de recursos monitorados e de métrica. Para mais informações, consulte Cardinalidade.
Os valores dos rótulos de métricas e recursos que fazem parte da série temporal não contribuem para as cobranças.
Métricas cobradas por bytes ingeridos
As métricas a seguir podem ser cobradas e cobradas pelo número de bytes ingeridos:
Métricas do agente em
agent.googleapis.com
, exceto a Grupoagent.googleapis.com/agent/
A partir de 6 de agosto de 2021, as métricas
agent.googleapis.com/processes/
serão cobradas a 5% da taxa de volume de outras métricas sujeitas a cobrança. Por exemplo, processar 100 MiB de métricas de processo custará o mesmo que processar 5 MiB de outras métricas sujeitas a cobrança.3Métricas de integrações de terceiros com agente de operações. Essas métricas são ingeridos no Cloud Monitoring com identificadores de formato
workload.googleapis.com/APPLICATION.METRIC
; Por exemplo, o tipo de métricaworkload.googleapis.com/nginx.requests
se enquadra nessa categoria.Métricas do OpenTelemetry Protocol (OTLP) ingeridas no Cloud Monitoring como
workload.googleapis.com
métricas pelo Agente de operações. Esta é uma configuração opção Para mais informações, consulte Formatos de transferência para OTLP métricas.Métricas personalizadas, incluindo, mas não se limitando às métricas enviadas usando o a API Cloud Monitoring ou bibliotecas de cliente de linguagens específicas, o OpenCensus e pelo OpenTelemetry.
Para fins de preços, o volume de ingestão é calculado da seguinte forma:
- Para um tipo de dados escalar: 8 bytes para cada ponto de dados gravado em uma série temporal. Métricas de contagem com base em registros definidas pelo usuário se enquadram nessa categoria.
- Para um tipo de dados de distribuição: 80 bytes para cada ponto de dados gravado em uma série temporal.
Para informações sobre pontos de dados em séries temporais, consulte Séries temporais: dados de um recurso monitorado.
Métricas cobradas pelas amostras ingeridas
As métricas a seguir podem ser cobradas e cobradas pelo número de amostras ingeridas:
- Métricas do Google Cloud Managed Service para Prometheus:
métricas
prometheus.googleapis.com
.
Para fins de preços, a contagem de amostra é calculada da seguinte forma:
- Para um tipo de dados escalar: 1 para cada ponto gravado em uma série temporal.
- Para um tipo de dados de distribuição: 2 para cada ponto gravado em uma série temporal, mais 1 para cada bucket de histograma com uma contagem diferente de zero.
Para informações sobre pontos de dados em séries temporais, consulte Séries temporais: dados de um recurso monitorado.
Criação de alertas sobre métricas ingeridas
Não é possível criar um alerta com base nas métricas ingeridas mensalmente. No entanto, é possível fazer isso para seus custos com o Cloud Monitoring. Se quiser mais informações, consulte Como configurar um alerta de faturamento.
Exemplos de preços com base em bytes ingeridos
Veja nos exemplos a seguir como ter uma estimativa de custos para a coleta de dados de métricas cobradas por bytes ingeridos. Esses exemplos têm o objetivo de ilustrar os cálculos. Para estimativas mais abrangentes, use a calculadora de preços. Se você acessar essa ferramenta, use Produto de observabilidade do Google Cloud para inserir dados de métrica, geração de registros e rastreamento.
Este é o cenário básico: você tem alguns recursos monitorados (como Compute Engine, Kubernetes Engine ou App Engine) que gravam dados de algumas métricas a cada mês.
As variáveis em todos os cenários incluem:
- O número de recursos
- O número de métricas
- Se as métricas são do Google Cloud ou não
- A taxa em que os dados da métrica são gravados
Os exemplos desta seção mostram os preços do Monitoring desde julho de 2020.
Contexto comum
Nos exemplos de preços a seguir, pressupomos que cada ponto de dados de métrica ingerido é dos tipos duplo, int64 ou bool, que contam como 8 bytes para fins de determinação de preços. Há cerca de 730 horas (365 dias / 12 meses * 24 horas) em um mês, ou 43.800 minutos.
Para uma métrica que grava dados à taxa de 1 ponto de dados/minuto por um mês, considere as seguintes informações:
- O total de pontos de dados é 43.800.
- O volume total ingerido é:
- 350.400 bytes (43.800 pontos de dados * 8 bytes)
- 0,33416748 MiB (350.400 bytes / 1.048.576 bytes/MiB)
Para uma métrica que grava dados à taxa de 1 ponto de dados/hora por um mês, considere as seguintes informações:
- O total de pontos de dados é 730.
- O volume total ingerido é:
- 5.840 bytes (730 pontos de dados * 8 bytes)
- 0,005569458 MiB (5.840 bytes / 1.048.576 bytes/MiB)
Exemplos
Cenário 1: você tem 1.000 recursos e cada um grava 75 métricas. Essas são apenas métricas do Google Cloud, com taxa de gravação de um ponto de dados por minuto.
- Ingestão mensal: 25.063 MiB: 0,33416748 MiB para uma métrica * 75.000 (ou seja, 1.000 recursos, 75 métricas)
- Custo aproximado por mês: US$ 0,00 (as métricas do Google Cloud são gratuitas)
MiB ingeridos | Taxa (US$/MiB) | Custo (US$) | |
---|---|---|---|
Ilimitados | 0,00 | US$ 0,00 | |
Total | 25.063 | US$ 0,00 |
Cenário 2: você tem 1.000 recursos e cada um grava 75 métricas personalizadas. Essas gravações de métricas estão sujeitas a cobranças e têm uma taxa de um ponto de dados por minuto.
- Ingestão mensal: 25.063 MiB (mesmo cenário acima)
- Custo aproximado por mês: US$ 6.427,55
MiB ingeridos | Taxa (US$/MiB) | Custo (US$) | |
---|---|---|---|
150 | 0,00 | US$ 0,00 | |
24.913 | 0,258 | US$ 6.427,55 | |
Total | 25.063 | US$ 6.427,55 |
Cenário 3: você tem 1.000 recursos e cada um grava 75 métricas personalizadas. Essas gravações de métricas estão sujeitas a cobranças e têm uma taxa de um ponto de dados por hora.
- Ingestão mensal: 418 MiB = 0,005569458 MiB para uma métrica * 75.000
- Custo aproximado por mês: US$ 69,14
MiB ingeridos | Taxa (US$/MiB) | Custo (US$) | |
---|---|---|---|
150 | 0,00 | US$ 0,00 | |
267 | 0,258 | US$ 69,14 | |
Total | 417 | US$ 69,14 |
Cenário 4: você tem um recurso que grava 500.000 métricas. Essas gravações de métricas estão sujeitas a cobranças e têm uma taxa de um ponto de dados por minuto.
- Ingestão mensal: 167.084 MiB: 0,33416748 MiB para uma métrica * 500.000
- Custo aproximado por mês: US$ 35.890,98
MiB ingeridos | Taxa (US$/MiB) | Custo (US$) | |
---|---|---|---|
150 | 0,00 | US$ 0,00 | |
99.850 | 0,258 | US$ 25.761,30 | |
67.084 | 0,151 | US$ 10.129,68 | |
Total | 167.084 | US$ 35.890,98 |
Preços para controle e previsibilidade
Os preços do Managed Service para Prometheus foram projetados controlável. Como as cobranças são geradas por amostra, use os seguintes fatores para controlar os custos:
Período de amostragem: alterar o período de extração de métricas de 15 segundos para 60 segundos pode gerar uma economia de 75%, sem sacrificar a cardinalidade. É possível configurar períodos de amostragem por job, por destino ou global.
Filtragem: você pode usar a filtragem para reduzir o número de amostras enviadas para ao repositório de dados lobal (lobal) do serviço. Para mais informações, consulte Filtrar as métricas exportadas Use as configurações de nova rotulagem de métricas nas Configuração de raspagem de dados do Prometheus para descartar métricas no momento da ingestão, com base sobre correspondentes de rótulo.
Mantenha dados locais de alta cardinalidade e baixo valor. É possível executar o Prometheus padrão junto com o serviço gerenciado, usando as mesmas configurações de cenário e mantendo os dados localmente que não vale a pena enviar para o repositório de dados global do serviço.
Os preços do Managed Service para Prometheus foram projetados previsível.
Você não recebe penalizações por ter histogramas esparsos. As amostras são contadas apenas para o primeiro valor diferente de zero e, em seguida, quando o valor do bucketn é maior que o valor no bucketn-1. Por exemplo, um histograma com valores
10 10 13 14 14 14
conta como três amostras, para o primeiro, terceiro e quarto buckets.Dependendo de quantos histogramas você usa e para que eles são usados, a exclusão de buckets inalterados dos preços geralmente pode fazer com que 20% a 40% menos amostras sejam contadas para fins de faturamento do que o número absoluto de buckets de histograma indicaria.
Ao cobrar por amostra, você não receberá penalizações por contêineres com escalonamento rápido e não escalonados, preemptivos ou temporários, como os criados pelo HPA ou pelo Autopilot do GKE.
Se o Managed Service para Prometheus for cobrado por métrica, você pagaria pela cardinalidade de um mês inteiro, uma vez, a cada vez que um novo contêiner foi ativado. Com o preço por amostra, você paga apenas enquanto o contêiner está em execução.
Consultas, incluindo consultas de alerta
Todas as consultas emitidas pelo usuário, inclusive aquelas emitidas quando o Prometheus regras de gravação são executadas e são cobradas por meio das chamadas da API Cloud Monitoring. Para a taxa atual, consulte a tabela de resumo dos preços do Serviço gerenciado para o Prometheus ou do Monitoring.
Exemplos de preços com base em amostras ingeridas
Veja nos exemplos a seguir como estimar os custos para coletar métricas cobradas pelas amostras ingeridas. Com base em amostra cobrança é usada para o Google Cloud Managed Service para Prometheus.
Esses exemplos têm o objetivo de ilustrar técnicas de cálculo, não de fornecer dados de faturamento.
O cenário básico é o seguinte: você tem algum número de contêineres ou pods que estão gravando pontos em algum número de séries temporais por mês. Os dados podem consistir em valores escalares ou distribuições.
As variáveis em todos os cenários incluem:
- O número de contêineres ou pods.
- O número de séries temporais.
- Se os dados consistem em valores escalares, distribuições ou ambos.
- A taxa em que os dados são gravados.
Contagem de amostras
Antes de estimar os preços, é preciso saber como contar amostras. O número de amostras contadas para um valor depende do seguinte:
- Se o valor é uma escalar ou uma distribuição
- A taxa em que os valores são gravados
Nesta seção, você verá como estimar o número de amostras gravadas para uma série temporal durante o período de faturamento mensal.
Em um mês, há cerca de 730 horas (365 dias / 12 meses * 24 horas), 43.800 minutos ou 2.628.000 segundos.
Se uma série temporal gravar valores escalares, cada valor será contabilizado como uma amostra. O número de amostras gravadas em um mês depende apenas da frequência em que os valores são gravados. Veja estes exemplos:
- Para valores gravados a cada 15 segundos:
- Taxa de gravação: 1 valor/15s = 1 amostra/15s
- Amostras por mês: 175.200 (1 amostra/15s * 2.628.000 segundos/mês)
- Para valores gravados a cada 60 segundos:
- Taxa de gravação: 1 valor/60s = 1 amostra/60s
- Amostras por mês: 43.800 (1 amostra/60s * 2.628.000 segundos/mês)
Se uma série temporal gravar valores de distribuição, cada valor poderá conter 2 + n amostras, em que n é o número de buckets no histograma. O número de amostras gravadas em um mês depende do número de buckets nos histogramas e da frequência com que os valores são gravados.
Por exemplo, cada instância de um histograma de 50 intervalos pode conter 52 amostras. Se os valores forem gravados uma vez a cada 60 segundos, um histograma de 50 buckets gravará no máximo 2.277.600 amostras por mês. Se o histograma tiver 100 buckets e for gravado uma vez a cada 60 segundos, cada histograma poderá conter 102 amostras e gravar no máximo 4.467.600 amostras por mês.
A maioria das séries temporais de distribuição contém menos do que o número máximo de amostras. Na prática, entre 20% e 40% dos buckets de histograma estão vazios. Essa porcentagem é ainda maior para usuários com histogramas esparsos, como os gerados pelo Istio.
Ao contar amostras de preços, somente buckets com valores não vazios são incluídos. O número máximo de amostras por histograma é 2 + n. Se 25% dos buckets estiverem vazios, o número esperado de amostras será 2 + 0,75 n por histograma. Se 40% dos buckets estiverem vazios, o número esperado de amostras será de 2 + 0,60n por histograma.
Os seguintes cálculos e a tabela de resumo mostram o número máximo de amostras e os números mais realistas de amostras esperadas:
Para valores de histograma de 50 intervalos gravados a cada 15 segundos:
- Taxa de gravação: 1 valor/15 s
- Máximo de amostras:
- Por histograma: 52
- Por mês: 9.110.400 (52 * 1 valor/15s * 2.628.000 segundos/mês)
- Amostras esperadas, supondo que 25% estejam vazias:
- Por histograma: 39,5 (2 + 0,75(50) ou 2 + (50 - 12,5))
- Por mês: 6.920.400 (39,5 * 1 valor/15s * 2.628.000 segundos/mês)
- Amostras esperadas, supondo que 40% estejam vazias:
- Por histograma: 32 (2 + 0,6(50) ou 2 + (50 - 20))
- Por mês: 5.606.400 (32 * 1 valor/15s * 2.628.000 segundos/mês)
Para valores de histograma de 50 intervalos gravados a cada 60 segundos:
- Taxa de gravação: 1 valor/60 s
- Máximo de amostras:
- Por histograma: 52
- Por mês: 2.277.600 (52 * 1 valor/60s * 2.628.000 segundos/mês)
- Amostras esperadas, supondo que 25% estejam vazias:
- Por histograma: 39,5 (2 + 0,75(50) ou 2 + (50 - 12,5))
- Por mês: 1.730.100 (39,5 * 1 valor/60s * 2.628.000 segundos/mês)
- Amostras esperadas, supondo que 40% estejam vazias:
- Por histograma: 32 (2 + 0,6(50) ou 2 + (50 - 20))
- Por mês: 1.401.600 (32 * 1 valor/60s * 2.628.000 segundos/mês)
Para valores de histograma de 100 intervalos gravados a cada 15 segundos:
- Taxa de gravação: 1 valor/15 s
- Máximo de amostras:
- Por histograma: 102
- Por mês: 17.870.400 (102 * 1 valor/15s * 2.628.000 segundos/mês)
- Amostras esperadas, supondo que 25% estejam vazias:
- Por histograma: 77 (2 + 0,75(100) ou 2 + (100 - 25))
- Por mês: 13.490.400 (77 * 1 valor/15s * 2.628.000 segundos/mês)
- Amostras esperadas, supondo que 40% estejam vazias:
- Por histograma: 62 (2 + 0,6(100) ou 2 + (100 - 40))
- Por mês: 10.862.400 (62 * 1 valor/15s * 2.628.000 segundos/mês)
Para valores de histograma de 100 intervalos gravados a cada 60 segundos:
- Taxa de gravação: 1 valor/60 s
- Máximo de amostras:
- Por histograma: 102
- Por mês: 4.467.600 (102 * 1 valor/60s * 2.628.000 segundos/mês)
- Amostras esperadas, supondo que 25% estejam vazias:
- Por histograma: 77 (2 + 0,75(100) ou 2 + (100 - 25))
- Por mês: 3.372.600 (77 * 1 valor/60 s * 2.628.000 segundos/mês)
- Amostras esperadas, supondo que 40% estejam vazias:
- Por histograma: 62 (2 + 0,6(100) ou 2 + (100 - 40))
- Por mês: 2.715.600 (62 * 1 valor/60s * 2.628.000 segundos/mês)
A seguinte tabela resume as informações anteriores:
Contagem em lote | Taxa de gravação | Amostras por mês (máx.) |
Amostras por mês (25% vazias) |
Amostras por mês (40% vazias) |
---|---|---|---|---|
50 | 1 amostra/15s | 9.110.400 | 6.920.400 | 5.606.400 |
50 | 1 amostra/60s | 2.277.600 | 1.730.100 | 1.401.600 |
100 | 1 amostra/15s | 17.870.400 | 13.490.400 | 10.862.400 |
100 | 1 amostra/60s | 4.467.600 | 3.372.600 | 2.715.600 |
Exemplos
Para estimar os preços, conte o número de amostras gravadas durante um mês e aplique os valores. Os preços das amostras são definidos por milhão, para intervalos empilhados, da seguinte maneira:
Intervalo de ingestão | Serviço gerenciado para o Prometheus | Máximo do intervalo |
---|---|---|
Até 50 bilhões (50.000 milhões) | US$ 0,06/milhão | USD 3.000,00 |
50 bilhões a 250 bilhões (250.000 milhões) | US$ 0,048/milhão | USD 9.600,00 |
250 bilhões a 500 bilhões (500.000 milhões) | US$ 0,036/milhão | USD 9.000,00 |
Mais de 500 bilhões (500.000 milhões) | US$ 0,024/milhão |
O restante desta seção apresenta possíveis cenários.
Cenário 1: você tem 100 contêineres, cada um gravando uma série de mil séries temporais escalares.
Variante A: se cada série temporal for gravada a cada 15 segundos (1 amostra/15s), o número de amostras gravadas por mês será de 17.520.000.000 (175.200 amostras/mês * 1.000 séries temporais * 100 contêineres) ou 17,520 milhões de contêineres.
Variante B: se cada série temporal for gravada a cada 60 segundos (1 amostra/60s), o número de amostras gravadas por mês será de 4.380.000.000 (43.800 amostras/mês * 1.000 séries temporais * 100 contêineres), ou 4.380 milhões.
Em ambos os casos, há menos de 50.000 das amostras. Portanto, somente a primeira taxa será aplicada. Nenhuma amostra é cobrada no outras taxas.
Variante | Amostras ingeridas | Intervalo de ingestão | Managed Service para Prometheus (US$ 0,06, US$ 0,048, US$ 0,036, US$ 0,024) |
---|---|---|---|
A (1 amostra/15 segundos) Total |
17.520 milhões 17.520 milhões |
Até 50.000 milhões Até 250.000 milhões Até 500.000 milhões Mais de 500.000 milhões |
US$ 1.051,20 US$1.051,20 |
B (1 amostra/60 s) Total |
4.380 milhões 4.380 milhões |
Até 50.000 milhões Até 250.000 milhões Até 500.000 milhões Mais de 500.000 milhões |
US$ 262,80 US$262,80 |
Cenário 2: você tem 1.000 contêineres, cada um gravando 1.000 séries temporais escalares.
Variante A: se cada série temporal for gravada a cada 15 segundos (1 amostra/15s), o número de amostras gravadas por mês será de 175.200.000.000, ou 175.200 milhões:
- Os primeiros 50.000 milhões de amostras são cobrados de acordo com a primeira taxa.
- As 125.200 milhões de amostras restantes são cobradas de acordo com a segunda taxa.
- Não há amostras cobradas nas outras taxas.
Variante B: se cada série temporal for gravada a cada 60 segundos (1 amostra/60s), o número de amostras gravadas por mês será de 43.800.000.000, ou 43.800 milhões. Esse valor mensal é menor que 50.000 milhões de amostras. Portanto, apenas a primeira taxa se aplica.
Variante | Amostras ingeridas | Intervalo de ingestão | Managed Service para Prometheus (US$ 0,06, US$ 0,048, US$ 0,036, US$ 0,024) |
---|---|---|---|
A (1 amostra/15 segundos) Total |
50.000 milhões 125.200 milhões 175.200 milhões |
Até 50.000 milhões Até 250.000 milhões Até 500.000 milhões Mais de 500.000 milhões |
US$ 3.000,00 US$ 6.009,60 US$9.009,60 |
B (1 amostra/60 s) Total |
43.800 milhões 43.800 milhões |
Até 50.000 milhões Até 250.000 milhões Até 500.000 milhões Mais de 500.000 milhões |
US$ 2.628,00 US$2.628,00 |
Cenário 3: você tem 100 contêineres, cada um gravando uma série temporal de distribuição de 1.000 buckets de 100 buckets. Você espera que 25% dos buckets estejam vazios.
Variante A: se cada série temporal for gravada a cada 15 segundos (1 amostra/15s), o número de amostras gravadas por mês será de 1.349.040.000.000 (13.490.400 amostras/mês * 1.000 séries temporais * 100 contêineres) ou 1.349.040 milhões de contêineres.
- Os primeiros 50.000 milhões de amostras são cobrados de acordo com a primeira taxa.
- As próximas 200.000 milhões de amostras são cobradas a partir da segunda taxa.
- As próximas 250.000 amostras serão cobradas com a terceira taxa.
- As 749.040 milhões de amostras restantes são cobradas com a quarta taxa.
Variante B: se cada série temporal for gravada a cada 60 segundos (1 amostra/60s), o número de amostras escritas por mês será de 337.260.000.000 (3.372.600 amostras/mês * 1.000 séries temporais * 100 contêineres) ou 337.260 milhões,
- Os primeiros 50.000 milhões de amostras são cobrados de acordo com a primeira taxa.
- As próximas 200.000 milhões de amostras são cobradas a partir da segunda taxa.
- As 87.260 milhões de amostras restantes são cobradas pela terceira taxa.
Variante | Amostras ingeridas | Intervalo de ingestão | Managed Service para Prometheus (US$ 0,06, US$ 0,048, US$ 0,036, US$ 0,024) |
---|---|---|---|
A (1 amostra/15 segundos) Total |
50.000 milhões 200.000 milhões 250.000 milhões 749.040 milhões 1.349.040 milhões |
Até 50.000 milhões Até 250.000 milhões Até 500.000 milhões Mais de 500.000 milhões |
US$ 3.000,00 US$ 9.600,00 US$ 9.000,00 US$ 17.976,96 US$39.576,96 |
B (1 amostra/60 s) Total |
50.000 milhões 200.000 milhões 87.260 milhões 337.260 milhões |
Até 50.000 milhões Até 250.000 milhões Até 500.000 milhões Mais de 500.000 milhões |
US$ 3.000,00 US$ 9.600,00 US$ 3.141,36 US$15.741,36 |
Cenário 4: você tem 1.000 contêineres, cada um gravando uma série temporal de distribuição de 10.000 buckets de 100 buckets. Você espera que 40% dos buckets estejam vazios.
Variante A: se cada série temporal for gravada a cada 15 segundos (1 amostra/15s), o número de amostras gravadas por mês será de 108.624.000.000.000 (10.862.400 amostras/mês). * 10.000 séries temporais * 1.000 contêineres, ou 108.624.000 milhões.
- Os primeiros 50.000 milhões de amostras são cobrados de acordo com a primeira taxa.
- As próximas 200.000 milhões de amostras são cobradas a partir da segunda taxa.
- As próximas 250.000 amostras serão cobradas com a terceira taxa.
- As 108.124.000 amostras restantes são cobradas com a quarta taxa.
Variante B: se cada série temporal for gravada a cada 60 segundos (1 amostra/60s), o número de amostras gravadas por mês será de 27.156.000.000.000 (2.715.600 amostras/mês * 10.000 séries temporais * 1.000 contêineres), ou 27.156.000 milhões.
- Os primeiros 50.000 milhões de amostras são cobrados de acordo com a primeira taxa.
- As próximas 200.000 milhões de amostras são cobradas a partir da segunda taxa.
- As próximas 250.000 amostras serão cobradas com a terceira taxa.
- As 26.656.000 milhões de amostras restantes são cobradas com a quarta taxa.
Variante | Amostras ingeridas | Intervalo de ingestão | Managed Service para Prometheus (US$ 0,06, US$ 0,048, US$ 0,036, US$ 0,024) |
---|---|---|---|
A (1 amostra/15 segundos) Total |
50.000 milhões 200.000 milhões 250.000 milhões 108.124.000 milhões 108.624.000 milhões |
Até 50.000 milhões Até 250.000 milhões Até 500.000 milhões Mais de 500.000 milhões |
US$ 3.000,00 US$ 9.600,00 US$ 9.000,00 US$ 2.594.976,00 US$2.616.576,00 |
B (1 amostra/60 s) Total |
50.000 milhões 200.000 milhões 250.000 milhões 26.656.000 milhões 27.156.000 milhões |
Até 50.000 milhões Até 250.000 milhões Até 500.000 milhões Mais de 500.000 milhões |
US$ 3.000,00 US$ 9.600,00 US$ 9.000,00 US$ 639.744,00 US$661.344,00 |
Cenário 5: você tem o seguinte:
1.000 contêineres, cada um com 1.000 séries temporais escalares a cada 15 segundos. O número de amostras escritas por mês é 175.200.000.000 ou 175.200 milhões. (Cenário 2, variante A)
1.000 contêineres, cada um gravando 10.000 séries temporais de distribuição de 100 intervalos a cada 15 segundos. Você espera que 40% dos buckets estejam vazios. O número de amostras escritas por mês é 108.624.000.000.000 ou 108.624.000 milhões. (Cenário 4, variante A)
O número total de amostras por mês é de 108.799.200 milhões (175.200 milhões + 108.624.000 milhões).
- Os primeiros 50.000 milhões de amostras são cobrados de acordo com a primeira taxa.
- As próximas 200.000 milhões de amostras são cobradas a partir da segunda taxa.
- As próximas 250.000 amostras são cobradas com a terceira taxa.
- As 108.299.200 milhões de amostras restantes são cobradas com a quarta taxa.
Variante | Amostras ingeridas | Intervalo de ingestão | Managed Service para Prometheus (US$ 0,06, US$ 0,048, US$ 0,036, US$ 0,024) |
---|---|---|---|
2A + 4A Total |
50.000 milhões 200.000 milhões 250.000 milhões 108.299.200 milhões 108.799.200 milhões |
Até 50.000 milhões Até 250.000 milhões Até 500.000 milhões Mais de 500.000 milhões |
US$ 3.000,00 US$ 9.600,00 US$ 9.000,00 US$ 2.599.180,80 US$2.620.780,80 |
Preços da execução da verificação de tempo de atividade (início da vigência: 1o de outubro de 2022)
O Monitoring cobra por cada execução regional de um tempo de atividade além da cota mensal gratuita de um milhão de execuções. Uma verificação realizada em três regiões conta como três execuções.
O custo da verificação de tempo de atividade é de US $0,30/1.000 execuções. A cobrança aparece na sua fatura como SKU "CA14-D3DE-E67F" "Como monitorar verificações de tempo de atividade".
Os exemplos a seguir ilustram como estimar os custos para a execução de verificações de tempo de atividadee. Esses exemplos servem para ilustrar técnicas de cálculo, não para fornecer dados de faturamento.
Contagem de execuções de verificações de tempo de atividade
Para estimar o custo das verificações de tempo de atividade, você precisa saber quantas as execuções regionais ocorrem em um mês. Monitoramento de cobranças US$ 0,30/1.000 execuções, com uma cota mensal gratuita de 1 milhão de execuções.
Para estimar o custo das verificações de tempo de atividade, use o seguinte: cálculo:
(EXECUTIONS_PER_MONTH - 1,000,000) * .0003
Para cada verificação de tempo de atividade, o número de execuções depende do seguinte: opções de configuração:
Com que frequência a verificação de tempo de atividade é executada: a cada minuto, a cada cinco minutos 10 ou 15 minutos.
O número de regiões em que a verificação de tempo de atividade é executada.
O número de destinos para os quais a verificação de tempo de atividade está configurada. Se o tempo de atividade estiver configurado para uma única VM, então o número de destinos será 1. Se a verificação de tempo de atividade estiver configurada para um grupo de recursos, o número de destinos é o número de recursos no grupo.
Ao configurar uma verificação de tempo de atividade, você especifica o local da verificação de tempo de atividade, e cada local é mapeado para uma ou mais regiões. O A tabela a seguir mostra os locais válidos para verificações de tempo de atividade e as regiões aos quais eles são mapeados:
Local para configuração da verificação de tempo de atividade | Inclui regiões do Google Cloud |
---|---|
ASIA_PACIFIC |
asia-southeast1 |
EUROPE |
europe-west1 |
SOUTH_AMERICA |
southamerica-east1 |
USA |
us-central1 ,
us-east4 ,
us-west1
|
GLOBAL |
Todas as regiões incluídas por outros locais |
Configure as verificações de tempo de atividade para serem executadas em pelo menos três regiões.
Para estimar o número de execuções de uma verificação de tempo de atividade, você precisa saber quantas regiões são cobertas pelo local de verificação de tempo de atividade:
ASIA_PACIFIC
,EUROPE
eSOUTH_AMERICA
incluem uma região.USA
inclui três regiões.GLOBAL
inclui seis regiões.
Em um mês, há cerca de 730 horas (365 dias / 12 meses * 24 horas) ou 43.800 minutos.
Uma verificação de tempo de atividade configurada para ser executada uma vez por minuto em
USA
é executada em 3 regiões. Se essa verificação de tempo de atividade estiver configurada para verificar um único VM, essa verificação de tempo de atividade executará 131.400 (3 * 43.800) vezes em um mês. Se a verificação estiver configurada para verificar um grupo de recursos de 10 membros, a verificação de tempo de atividade é executada 1.314.000 (10 * 131.400) vezes em um mês.Uma verificação de tempo de atividade configurada para ser executada uma vez por minuto em
ASIA_PACIFIC
.EUROPE
eUSA
são executados em cinco regiões. Essa verificação de tempo de atividade é executada 219.000 vezes em um mês configurados para um único destino.
A tabela a seguir mostra as contagens de execução por hora e por mês para um único verificação de tempo de atividade configurada para ser executada com frequências diferentes em números de regiões:
Frequência de execução da verificação, uma vez a cada: |
Número de regiões |
Execuções por hora por meta |
Execuções mensais por meta |
---|---|---|---|
1 minuto | 3 4 5 6 |
180 240 300 360 graus |
131.400 175.200 219.000 262.800. |
5 minutos | 3 4 5 6 |
36 48 60 72 |
26.280 35.040 43.000 52.660. |
10 minutos | 3 4 5 6 |
18 24 30 36 |
13.140 17.520 21.900 26.280 |
15 minutos | 3 4 5 6 |
12 16 20 24 |
8.760 11.680 14.600 17.520 |
Exemplos
Para estimar preços, determine o total de execuções mensais e subtraia 1.000.000. Quaisquer execuções restantes são cobradas a US $0,30/1.000 execuções, portanto, multiplicar as execuções restantes por 0,0003.
(EXECUTIONS_PER_MONTH - 1,000,000) * .0003
Cenário 1: você tem uma verificação de tempo de atividade no local USA
que verifica uma VM uma vez por minuto. Essa verificação é executada em três regiões.
A verificação é executada 131.400 vezes por mês e não custa nada.
Total de execuções mensais |
Execuções mensais sujeitas a cobrança (mais de 1.000.000) |
Custo (US$ 0,30/1.000 execuções) |
---|---|---|
131.400 | 0 | US$ 0,00 |
Cenário 2: você tem uma verificação de tempo de atividade no local USA
que verifica um grupo de recursos de 10 membros uma vez por minuto. Essa verificação é executada em três
ou várias regiões. A verificação é executada 10 * 131.400 vezes por mês e
custa US $94,20/mês. A única diferença entre este cenário e o cenário 1
é o número de alvos.
Total de execuções mensais |
Execuções mensais sujeitas a cobrança (mais de 1.000.000) |
Custo (US$ 0,30/1.000 execuções) |
---|---|---|
1.314.000 (10 metas) | 314 mil | US$ 94,20 |
Cenário 3: você tem 10 verificações de tempo de atividade GLOBAL
,
que verificam uma VM uma vez por minuto. Essas verificações são executadas em seis regiões,
Portanto,cada verificação é executada 262.800 vezes por mês. O valor mensal total
é 2.628.000 (10 * 262.800). Este cenário custa
US$ 488,40/mês.
Total de execuções mensais |
Execuções mensais sujeitas a cobrança (mais de 1.000.000) |
Custo (US$ 0,30/1.000 execuções) |
---|---|---|
2.628.000 | 1.628.000 | US$ 488,40 |
Cenário 4: você tem cinco verificações de tempo de atividade no local USA
que verificam uma VM uma vez a cada cinco minutos. Essas verificações são executadas em três regiões. Portanto, cada
é executado 26.280 vezes por mês. O total de execuções mensais
para esse conjunto de verificações é 105.120 (4 * 26.280).
Você também tem 2 verificações de tempo de atividade GLOBAL
que verificam 1 VM uma vez a cada 15
minutos. Essas verificações são executadas em seis regiões, e cada uma delas é executada
17.520 vezes por mês. O total de execuções mensais para esta
de verificações é 35.040 (2 * 17.520).
O total de execuções mensais é de 140.160 (105.120 + 35.040). Este cenário não custa nada.
Total de execuções mensais |
Execuções mensais sujeitas a cobrança (mais de 1.000.000) |
Custo (US$ 0,30/1.000 execuções) |
---|---|---|
140.160 | 0 | US$ 0,00 |
Preços da execução de monitoramento sintético (início da vigência: 1o de novembro de 2023)
O Cloud Monitoring cobra por cada execução de um monitor sintético, além a cota gratuita de 100 execuções por mês por conta de faturamento. Por exemplo, se você criar três monitores sintéticos e configurar cada um que sejam executadas a cada cinco minutos, então o número total de execuções mensais por mês é de 26.784:
Number of executions per month = 3 synthetic monitors * 1 execution per monitor per 5 minutes *
1440 minutes per day * 31 days per month
= 26,784
Para determinar o número de execuções sujeitas a cobrança, subtraia a cota gratuita a partir do número total de execuções e, a seguir, multiplicar o resultado pelo custo:
Total de execuções mensais |
Execuções mensais sujeitas a cobrança (mais de 100 execuções por conta de faturamento) |
Custo (US$ 1,20/1.000 execuções) |
---|---|---|
26.784 | 26.684 | US$ 32,02 |
Preços para alertas
A partir de 7 de janeiro de 2025, o Cloud Monitoring começará a cobrar por alertas. O modelo de preços é o seguinte:
- US$ 1,50 por mês para cada condição em uma política de alertas.
- US$ 0,35 por 1.000.000 série temporal retornadas pela consulta de uma condição de política de alertas de métricas.
Nesta seção, você encontra as informações a seguir:
- Definições da terminologia de alertas.
- Exemplos de cobranças por diversos alertas configurações de política.
- Sugestões para reduzir custos em consolidar ou excluir políticas de alertas.
- Informações sobre como desativar o faturamento políticas de alertas.
Definições
Condição: a condição de um A política de alertas descreve quando um recurso ou grupo de recursos está em um estado que requer uma resposta.
- Políticas de alertas que usam filtros para criar metric-threshold ou As consultas de ausência de métrica podem combinar até seis condições.
- As políticas de alertas com os seguintes tipos de consulta podem ter apenas um condição única:
A cobrança é de US $1,50 por mês para cada condição. Para deixar de ser cobrado por uma condição, exclua a política de alertas. Adiar ou desativar a política não evitar que isso aconteça.
Políticas de alertas com base em registros e métricas: políticas de alertas que usam Qualquer tipo de condição, exceto as condições de correspondência de registro, são alertas de metric. políticas As condições das políticas de alertas de métricas retornam série temporal. Durante cada período de execução, as condições nas políticas de alertas de métricas são executadas as consultas deles ao repositório de dados do Cloud Monitoring. O série temporal são, então, avaliadas em relação a um limite para determinar se a política de alertas é disparada.
As políticas de alertas com base em registros usam condições de correspondência de registro. Condições de correspondência de registro não retornam série temporal.
Período de execução: a frequência com que o Cloud Monitoring executa sua condição. Para a maioria dos tipos de condição, esse tempo é de 30 segundos e não pode ser alterado. As condições que usam uma consulta PromQL podem definir esse período. Para mais informações, consulte Aumentar a duração do período de execução (somente PromQL).
Série temporal retornada: durante cada período de execução, uma métrica que alerta executa a consulta da condição no Cloud Monitoring datastore. O Cloud Monitoring retorna dados de série temporal como resposta para cada consulta. Cada série temporal na resposta é contabilizada como uma única série temporal retornados.
O número de série temporal retornadas em um mês é determinado por três fatores:
- A forma e o escopo dos dados subjacentes.
- Os filtros e as agregações que você usa na consulta da sua condição.
- O período de execução.
Por exemplo, considere uma configuração em que você tem o seguinte:
- 100 máquinas virtuais (VMs), em que cada VM pertence a um serviço.
- Cada VM emite uma métrica,
metric_name
, que tem um rótulo com 10 valores. - Cinco serviços no total.
Como você tem 100 VMs, cada uma pode gerar 10 série temporal (uma para cada valor de rótulo), terá um total de mil série temporal subjacentes. Cada VM também tem um rótulo semelhante a metadados que registra a qual dos cinco serviços a VM pertence.
É possível configurar políticas de alertas das seguintes maneiras usando PromQL, em que cada configuração resulta em um número diferente de série temporal retornadas por período de execução:
Configuração Consulta PromQL Séries temporais retornadas por período Sem agregação rate(
metric_name
[1m])1.000 Agregar à VM sum by (vm) (rate(
metric_name
[1m]))100 Agregar ao valor do rótulo sum by (label_key) (rate(
metric_name
[1m]))10 Agregar ao serviço sum by (service) (rate(
metric_name
[1m]))5 Agregar para valor do rótulo e serviço sum by (service, label_key) (rate(
)metric_name
[1m])50 Agregar à frota sum (rate(
metric_name
[1m]))1 Filtrar e agregar a uma VM sum (rate(
metric_name
{vm="my_vm_name"}[1m]))1 Filtrar e agregar a um serviço sum (rate(
metric_name
{service="my_service_name"}[1m]))1
Exemplos de preços
Os exemplos a seguir ocorrem em um mês de 30 dias, resultando no seguinte períodos de avaliação:
- 86.400 períodos de execução de 30 segundos por mês
- 172.800 períodos de execução de 15 segundos por mês (somente consultas PromQL)
Exemplo 1: uma política de agregação à VM, 30 segundos
Neste exemplo, use as seguintes configurações:
Dados
- 100 VMs
- Cada VM emite uma métrica,
metric_name
. metric_name
tem um rótulo, que tem 10 valores
- Uma condição de alerta
- A condição é agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 1,50 por mês = US$ 1,50 por mês
- Custo da série temporal: 100 série temporal retornadas por período * 86.400 períodos por mês = 8,6 milhões de série temporal retornadas por mês * US$ 0,35 por milhão série temporal = US$ 3,02 por mês
- Custo total: US$4,52 por mês
Exemplo 2: 100 políticas (uma por VM), agregando à VM, 30 segundos
Neste exemplo, use as seguintes configurações:
Dados
- 100 VMs
- Cada VM emite uma métrica,
metric_name
. metric_name
tem um rótulo, que tem 10 valores
- 100 condições
- Cada condição é filtrada e agregada a uma VM
- Período de execução de 30 segundos
- Custo da condição: 100 condições * US$ 1,50 por mês = US $150 por mês
- Custo da série temporal: 100 condições * 1 série temporal retornada por condição e por período * 86.400 períodos por mês = 8,6 milhões de série temporal retornadas por mês * US$ 0,35 por milhão série temporal = US$ 3,02 por mês
- Custo total: US$153,02 por mês
Exemplo 3: uma política de agregação à VM, 15 segundos
Neste exemplo, use as seguintes configurações:
Dados
- 100 VMs
- Cada VM emite uma métrica,
metric_name
. metric_name
tem um rótulo, que tem 10 valores
- Uma condição de alerta do PromQL
- A condição é agregada ao nível da VM
- Período de execução de 15 segundos
- Custo da condição: 1 condição * US$ 1,50 por mês = US$ 1,50 por mês
- Custo da série temporal: 100 série temporal retornadas por período * 172.800 períodos por mês = 17,3 milhões de série temporal retornadas por mês * US$ 0,35 por milhão série temporal = US$ 6,05 por mês
- Custo total: US$7,55 por mês
Exemplo 4: agregar uma política a cada serviço, 30 segundos
Neste exemplo, use as seguintes configurações:
Dados
- 100 VMs, em que cada VM pertence a um serviço
- Cinco serviços no total
- Cada VM emite uma métrica,
metric_name
. metric_name
tem um rótulo, que tem 10 valores
- Uma condição
- A condição é agregada ao nível de serviço
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 1,50 por mês = US$ 1,50 por mês
- Custo da série temporal: 5 série temporal retornadas por período * 86.400 períodos por mês = 432.000 série temporal retornadas por mês * US$ 0,35 por milhão série temporal = US$ 0,14 por mês
- Custo total: US$1,64 por mês
Exemplo 5: agregar uma política à VM maior cardinalidade subjacente por VM, 30 segundos
Neste exemplo, use as seguintes configurações:
Dados
- 100 VMs
- Cada VM emite uma métrica,
metric_name
. metric_name
tem 100 rótulos com 1.000 valores cada
- Uma condição
- A condição é agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 1,50 por mês = US$ 1,50 por mês
- Custo da série temporal: 100 série temporal retornadas por período * 86.400 períodos por mês = 8,5 milhões de série temporal retornadas por mês * US$ 0,35 por milhão série temporal = US$ 3,02 por mês
- Custo total: US$4,52 por mês
Exemplo 6: agregar uma política à VM unir duas métricas em uma condição, 30 segundos
Neste exemplo, use as seguintes configurações:
Dados
- 100 VMs
- Cada VM emite duas métricas,
metric_name_1
emetric_name_2
- As duas métricas têm um rótulo com 10 valores cada
- Uma condição
- A condição é agregada ao nível da VM
- A condição usa um operador
OR
para unir as métricas. - Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 1,50 por mês = US$ 1,50 por mês
- Custo da série temporal: 2 métricas * 100 série temporal retornadas por métrica por período * 86.400 períodos por mês = 17,3 milhões de série temporal retornadas por mês * US$ 0,35 por milhão série temporal = US$ 6,05 por mês
- Custo total: US$7,55 por mês
Exemplo 7: 100 políticas de alertas com base em registros
Neste exemplo, use a seguinte configuração:
Políticas de alertas
- 100 condições (uma por política de alertas com base em registros)
- Custo da condição: 100 condição * US$ 1,50 por mês = US$ 150,00 por mês
- Custo da série temporal: US$ 0 As políticas de alertas com base em registros não retornam série temporal.
- Custo total: US$150,00 por mês
Sugestões para reduzir sua fatura de alertas
Ao configurar suas políticas de alertas com base em métricas, use o seguinte sugestões para ajudar a reduzir o custo de contas de alertas.Consolidar políticas de alertas para operar em mais recursos
Devido ao custo de US $1,50 por condição, mais econômico usar uma política de alertas para monitorar vários recursos do que usar uma política de alertas para monitorar cada recurso. Por exemplo: compare o Exemplo 1 com o Exemplo 2: Nos dois exemplos, você monitora o mesmo número de recursos. No entanto, o exemplo 2 usa 100 políticas de alertas, enquanto o exemplo 1 usa apenas uma. Como resultado, o Exemplo 1 é quase US $150 mais barato por mês.
Agregue somente ao nível em que você precisa criar alertas
A agregação a níveis mais altos de granularidade resulta em custos maiores do que e agregados a níveis mais baixos de granularidade. Por exemplo: agregar no nível do projeto do Google Cloud é mais barato do que agregar para no nível do cluster e a agregação ao nível do cluster é mais do que agregar ao cluster e ao namespace.
Por exemplo, compare o Exemplo 1 com o Exemplo 4: Os dois exemplos operam com os mesmos dados subjacentes e têm um único alerta política. No entanto, como a política de alertas no Exemplo 4 é agregada ao serviço, ela é mais barata que a política de alertas do Exemplo 1, que são agregados de forma mais granular à VM.
Além disso, compare o Exemplo 1 com o Exemplo 5: Nesse caso, a cardinalidade da métrica no Exemplo 5 é 10.000 vezes maior do que a cardinalidade da métrica no exemplo 1. No entanto, como a política de alertas Os exemplos 1 e 5 agregam à VM e, como o de VMs é o mesmo nos dois exemplos, os exemplos são equivalentes em preço.
Ao configurar suas políticas de alertas, escolha níveis de agregação que funcionam melhor para seu caso de uso. Por exemplo, se você quer receber alertas sobre de dados, convém agregar ao nível da VM e da CPU. Se você se preocupar com alertas de latência por endpoint, convém agregar no nível do endpoint.
Não alertar sobre dados brutos e não agregados
O monitoramento usa um sistema de métricas dimensionais, em que qualquer métrica a cardinalidade total é igual ao número de recursos monitorados. multiplicado pelo número de combinações de rótulos nessa métrica. Para exemplo, se 100 VMs estão emitindo uma métrica e essa métrica tem 10 rótulos com 10 valores cada, então sua cardinalidade total será 100 * 10 * 10 = 10.000.
Devido ao escalonamento da cardinalidade, os alertas sobre dados brutos podem ser extremamente caro. No exemplo anterior, 10.000 série temporal foram retornadas para cada período de execução. No entanto, se agregar à VM, você terá apenas 100 série temporal retornadas por período de execução, independentemente do rótulo cardinalidade dos dados.
Alertar sobre dados brutos também o coloca em risco de aumentar a série temporal quando as métricas receberem novos rótulos. No exemplo anterior, se um usuário adicionar um novo rótulo à métrica, a cardinalidade total aumentará como 100 * 11 * 10 = 11.000 série temporal. Nesse caso, o número de aumenta em 1.000 em cada período de execução,mesmo que o valor política não foi alterada. Se você agregar à VM, mesmo aumento da cardinalidade subjacente, você ainda tem apenas 100 série temporal retornadas.
Filtrar respostas desnecessárias
Configure suas condições para avaliar somente os dados necessários para sua para atender a necessidades específicas de alertas. Se você não tomaria medidas para corrigir algo, exclua nas políticas de alertas. Por exemplo, você provavelmente não precisa alertar na VM de desenvolvimento de um estagiário.
Para reduzir custos e alertas desnecessários, é possível filtrar série temporal que não são importantes. É possível usar os rótulos de metadados do Google Cloud para marcar recursos com categorias e, em seguida, filtrar as categorias de metadados desnecessárias.
Usar operadores de fluxo superior para reduzir o número de série temporal retornadas
Se a condição usar uma consulta PromQL ou MQL, será possível usar um operador top-streams para selecionar várias série temporal retornadas com os valores mais altos:
Por exemplo, uma cláusula topk(metric, 5)
em uma consulta PromQL limita a
o número de série temporal retornadas a cinco em cada período de execução.
Limitar a um número maior de série temporal pode resultar na ausência de dados e alertas defeituosos, como:
- Se mais de N série temporal violarem seu limite, você não dados fora das principais série temporal N.
- Se uma série temporal em violação ocorrer fora das principais séries temporais N, então: seus incidentes poderão ser fechados automaticamente, apesar da série temporal excluída ainda ultrapassando o limite.
- Talvez suas consultas de condição não mostrem um contexto importante, como valor de referência série temporal que funcionem conforme o esperado.
Para mitigar esses riscos, escolha valores grandes para N e use os principais fluxos de operações apenas em políticas de alertas que avaliam várias série temporal, como alertas para contêineres individuais do Kubernetes.
Aumentar a duração do período de execução (somente PromQL)
Se a condição usa uma consulta PromQL, é possível modificar o comprimento
do período de execução definindo a
campo evaluationInterval
na
condition [estado].
Intervalos de avaliação mais longos resultam em menos série temporal retornadas por mês. por exemplo, uma consulta de condição com um intervalo de 15 segundos é executada duas vezes mais como uma consulta com intervalo de 30 segundos e uma com intervalo de 1 minuto é executada metade da frequência de uma consulta com um intervalo de 30 segundos.
Recusando
Se você tem um contrato do Google Cloud que não expira até 7 de janeiro de 2025, será possível adiar o faturamento por alertas até o contrato precisa ser renovada ao solicitar uma isenção do Programa Cloud Monitoring e a equipe de faturamento de alertas. As isenções para clientes com contratos ativos serão considerados caso a caso.
Você pode pedir uma isenção até 1o de novembro de 2024. Para solicitar uma isenção de faturamento até a renovação do contrato, preencha o formulário de solicitação de isenção de faturamento.
Error Reporting
Para informações sobre os preços atuais, consulte Preços do Error Reporting.
Para saber os limites que se aplicam ao uso do Error Reporting, consulte Cotas e limites.
Cloud Profiler
Não há custo associado ao uso do Cloud Profiler.
Para saber os limites que se aplicam ao uso do Profiler, consulte Cotas e limites.
Cloud Trace
As cobranças do Trace são baseadas no número de períodos de traces ingeridos e verificados. Quando os dados de latência são enviados ao Trace, eles são agrupados como um trace composto por períodos. Esses períodos são ingeridos pelo back-end do Cloud Trace. Ao visualizar dados do trace, os períodos armazenados são verificados pelo Cloud Trace. Nesta seção, você encontra as informações a seguir:
- Definição de períodos de traces sujeitos a cobrança ou não faturáveis
- Exemplo de preços
- Como reduzir a ingestão de períodos de traces
- Configurações de uma política de alertas que notifica você se a ingestão de períodos de traces chegar ao limite
Para informações sobre os preços atuais, consulte Preços do Cloud Trace.
Para saber os limites que se aplicam ao uso do Trace, consulte Cotas e limites.
Para informações sobre como visualizar seu uso atual ou passado, consulte Como estimar suas faturas.
Períodos de traces não faturáveis
Os preços do Cloud Trace não se aplicam aos períodos gerados automaticamente pelo ambiente padrão do App Engine, pelo Cloud Functions ou pelo Cloud Run: a ingestão desses traces não é cobrada.
Períodos de traces sujeitos a cobrança
A ingestão de períodos de traces, exceto os listados na seção Traces não faturáveis, são faturáveis e cobrados por volume ingerido. Isso inclui períodos criados pela instrumentação que você adicionou ao aplicativo do ambiente padrão do App Engine.
Exemplos de preços
O exemplo a seguir mostra os preços do Trace desde julho de 2020.
- Se você ingerir 2 milhões de períodos em um mês, o custo será de US$ 0. Os primeiros 2,5 milhões de períodos ingeridos em um mês são gratuitos.
- Se você ingerir 14 milhões de períodos em um mês, seu custo será de US$ 2,30. Os primeiros 2,5 milhões de períodos em um mês são gratuitos. O custo dos períodos restantes é calculado como 11,5 milhões de períodos * US$ 0,20/milhão de períodos = US$ 2,30.
- Se você ingerir um bilhão de períodos em um mês, seu custo será de US$ 199. Os primeiros 2,5 milhões de períodos em um mês são gratuitos. O custo dos períodos restantes é calculado como 997,5 milhões de períodos * US$ 0,20/milhão de períodos = US$ 199,50.
Como reduzir o uso de traces
Para controlar o volume de ingestão de períodos do Trace, gerencie a taxa de amostragem de traces. Assim, será possível equilibrar a quantidade necessária para analisar o desempenho com a tolerância de custo.
Para sistemas de tráfego intenso, a maioria dos clientes pode coletar amostras de uma em 1.000 transações, ou até uma em 10.000 transações, e ainda ter informações suficientes para analisar o desempenho.
A taxa de amostragem é configurada com as bibliotecas de cliente do Cloud Trace.
Criação de alertas sobre períodos ingeridos mensalmente
Para criar uma política de alertas que é acionada quando os dados Períodos do Cloud Trace ingeridos exceder um limite definido pelo usuário, use as configurações a seguir.
Novo estado Campo |
Valor |
---|---|
Recurso e métrica | No menu Resources, selecione Global. No menu Categorias de métrica, selecione Faturamento. No menu Métricas, selecione Períodos de trace mensais ingeridos. |
Filtrar | |
Várias séries Agregação de série temporal |
sum |
Janela contínua | 60 m |
Função de janela contínua | max |
Campo Configurar gatilho de alerta |
Valor |
---|---|
Tipo de condição | Threshold |
Acionador de alerta | Any time series violates |
Posição do limite | Above threshold |
Threshold value |
Você determina o valor aceitável. |
Teste a janela novamente | O valor mínimo aceitável é de 30 minutos. |
GKE Enterprise
Os registros e métricas do sistema do GKE Enterprise não são cobrados. Registros do plano de controle, métricas do plano de controle e uma subconjunto selecionado de métricas de estado do Kube ativado por padrão para clusters do GKE no Google Cloud que são registrados no momento da criação do cluster em um projeto ativado para o GKE Enterprise. Os registros do plano de controle geram cobranças do Cloud Logging, e as métricas ativadas por padrão estão incluídos sem custo adicional.
Para acessar a lista de registros e métricas incluídos do GKE, consulte Quais registros são coletados e Métricas disponíveis.
Em um cluster do Google Distributed Cloud, os registros e as métricas do sistema do GKE Enterprise incluem o seguinte:
- Registros e métricas de todos os componentes em um cluster de administrador
- Registros e métricas de componentes nesses namespaces em um cluster de usuário:
kube-system
,gke-system
,gke-connect
,knative-serving
,istio-system
,monitoring-system
,config-management-system
,gatekeeper-system
,cnrm-system
Perguntas frequentes
Quais recursos do produto são gratuitos?
O uso dos produtos de observabilidade do Google Cloud é cobrado pelo volume de dados. Além do de volume de dados descritos nesta página, o uso de todos os Os recursos do produto Google Cloud Observability são gratuitos.
Quanto preciso pagar?
Para estimar os custos de uso, consulte Como estimar suas faturas.
Consulte Perguntas de faturamento para receber ajuda sobre esse tema.
Como entender os detalhes do meu uso?
Várias métricas permitem analisar o volume de registros e métricas usando o Metrics Explorer. Consulte Visualizar o uso detalhado no Metrics Explorer para mais detalhes.
Se quiser aprender a gerenciar seus custos, confira estas postagens:
- Preços do Cloud Logging para administradores do Cloud: como abordar e economizar
- Quatro etapas para gerenciar os custos do Cloud Logging com base no orçamento
Como o escopo das métricas afeta o faturamento?
Na maioria das vezes, o escopo das métricas não afeta o faturamento. Registros e métricas são cobrados no projeto do Google Cloud que recebe os dados. O escopo das métricas define a coleção de projetos que terão métricas visíveis e monitoráveis. Ao definir essa configuração, você não muda os projetos que recebem dados de métricas nem causa duplicação.
Por exemplo, imagine que sua organização tenha 100 máquinas virtuais (VMs): 60 delas são hospedadas pelo Projeto A e 40 estão no Projeto B. O Projeto A recebe e armazena as métricas das VMs que hospeda, e é cobrado quando elas estão sujeitas a cobrança. A mesma coisa acontece no Projeto B. Se você criar um escopo de métricas que inclua os dois projetos, será possível ver as métricas combinadas de todas as 100 VMs. Agora, você tem a opção de ver somente as métricas do Projeto A, do Projeto B ou a combinação de ambas. Apesar de haver duas maneiras de visualizar as métricas do Projeto-A, isso não afeta o faturamento.
Para monitorar contas AWS, você deve conectar uma conta da AWS ao Google Cloud criando uma Projeto do conector da AWS. O projeto conector mantém os registros e os dados de monitoramento da conta da AWS.
O que acontece se eu ultrapassar as cotas gratuitas?
Você receberá cobranças automáticas quando o uso ultrapassar as cotas gratuitas. Você não perderá registros ou métricas. Para entender melhor os possíveis custos, consulte Como estimar suas faturas.
Crie uma política de alertas que monitore o uso e envie notificações quando você estiver prestes a atingir o limite de faturamento.
Tenho um grande volume de registros do Google Cloud que não são utilizados nos meus projetos. Quais são as cobranças aplicadas a esses registros? O que fazer para evitá-las?
Exclua registros para controlar quais são ingeridos no Logging. Consulte Como reduzir seu uso de registros para ver detalhes.
Os serviços que enviam registros para meu projeto receberão um erro se os registros forem excluídos?
Não. Os serviços que enviam entradas de registros não podem determinar se elas são processadas no Logging ou não.
Serei cobrado duas vezes pelos registros de fluxo da nuvem privada virtual?
Se você enviar seus registros de fluxo da VPC para o Logging, as cobranças de geração desses registros de fluxo serão dispensadas, e apenas as cobranças do Logging serão aplicadas. No entanto, se enviá-los e, em seguida, excluí-los do Logging, haverá cobranças por eles. Para mais informações, consulte Calculadora de preços do Google Cloud e selecione a guia "Cloud Load Balancing and Network Services".
1 Para fins de definição de preços, todas as unidades são tratadas como medidas binárias, por exemplo, como mebibytes (MiB, ou 220 bytes) ou gibibytes (GiB ou 230 bytes).
2 Não há custo financeiro para métricas do Google Cloud ou do GKE Enterprise que estão medido em até 1 ponto de dados por minuto (a resolução mais alta no momento). Futuramente, as métricas medidas em resoluções mais altas poderão ser cobradas.
3 Atualmente, as métricas do processo são coletadas a uma taxa padrão predefinida de uma vez por minuto, o que não pode ser alterado. Em geral, esses dados mudam lentamente. Por isso, essas métricas estão sendo amostradas. Portanto, as métricas do processo de cobrança a 5% da taxa padrão se alinham à taxa padrão se as métricas forem amostradas em intervalos de 20 minutos. Os usuários que coletam 100 MiB de dados dessas métricas são cobrados por apenas 5 MiB.
A seguir
- Leia a documentação de observabilidade do Google Cloud.
- Use a calculadora de preços.
- Saiba mais sobre as soluções e os casos de uso de observabilidade do Google Cloud.