Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cloud.google.com/stackdriver/pricing below:

Pricing | Google Cloud Observability

The pricing for Google Cloud Observability lets you control your usage and spending. Google Cloud Observability products are priced by data volume or usage. You can use the free data usage allotments to get started with no upfront fees or commitments.

You might also be interested in the following documents:

• Pricing examples.
• Estimate your bills.
• Optimize and monitor your costs.

The following tables summarize the pricing information for Cloud Logging, Cloud Monitoring, and Cloud Trace.

No charge for write API calls

Read API calls: $0.50/million time series returned^♥

Write API calls: Not applicable

Read API calls: First 1 million time series returned per billing account

For detailed information about the costs for Google Cloud Observability products, see the following sections of this page:

• Cloud Logging
• Cloud Monitoring
• Error Reporting
• Cloud Profiler
• Cloud Trace

Log buckets are the Logging containers that store logs data. Logging charges for the volume of log data that is stored in the _Default log bucket and in user-defined log buckets. Pricing applies to non-vended network logs when the volume exceeds the free monthly allotment, and to vended network logs.

For the _Default log bucket and for user-defined log buckets, Logging also charges when logs are retained for more than the default retention period, which is 30 days.

There are no additional charges by Logging for the following:

• Routing logs.
• Using the Cloud Logging API.
• Creating log scopes.
• Creating analytics views.
• Logs stored in the _Required log bucket, which has a fixed retention period of 400 days.

This section provides information about the following topics:

• Cloud Logging storage model
• Storage pricing
• Retention pricing
• Vended network logs pricing
• Log-based metrics pricing

For limits that apply to your use of Logging, including data retention periods, see Quotas and limits.

For each Google Cloud project, Logging automatically creates two log buckets: _Required and _Default. For these two buckets, Logging automatically creates log sinks named _Required and _Default that route logs to the correspondingly named log buckets. You can't disable or modify the _Required sink. You can disable or otherwise modify the _Default sink to prevent the _Default bucket from storing new logs.

You can create user-defined log buckets in any of your Google Cloud projects. You can also configure sinks to route any combination of logs, even across Google Cloud projects in your Google Cloud organization, to these log buckets.

For the _Default log bucket and for user-defined log buckets, you can configure a custom retention period.

You can upgrade your log buckets to use Log Analytics. There is no charge to upgrade a log bucket to use Log Analytics.

For more information on Cloud Logging buckets and sinks, see Routing and storage overview.

Logging charges the project where the logs are streamed into log buckets for storage, after the free monthly allotment is exceeded. For each project, charges are based on the volume of logs streamed into its user-defined log buckets and its _Default log bucket.

Logging doesn't charge for routing logs. Suppose a log entry originates in a project but the project doesn't store the log entry in one of its log buckets. In this scenario, the project isn't charged for the log entry. However, if the project routes the log entry to a log bucket in another project, then the destination project is charged for that log entry.

When a log entry is written to any log bucket except the _Required log bucket, the project that contains that log bucket is charged for the storage of that log entry. For example, if a log entry is routed to three log buckets that are in the same project, then that project is charged three times for the log entry. Similarly, if a log entry is routed to two log buckets, but these log buckets are in different projects, then the projects that store those log buckets are each charged for one log entry.

Logging doesn't charge for logs stored in the _Required bucket. You can't delete the _Required bucket or modify the _Required sink. The _Required bucket stores the following logs:

• Admin Activity audit logs
• System Event audit logs
• Google Workspace Admin Audit logs
• Enterprise Groups Audit logs
• Login Audit logs
• Access Transparency logs. For information about enabling Access Transparency logs, see the Access Transparency logs documentation.

The following table lists the data retention periods for logs stored in log buckets:

Logging charges retention costs when the logs are retained longer than the default retention period. You can't configure the retention period for the _Required log bucket. There are no retention costs when logs are stored only for the default retention period of the log bucket.

If you shorten the retention period of a log bucket, then there is a seven-day grace period in which expired logs aren't deleted. You can't query or view expired logs. However, in those seven days, you can restore full access by extending the retention period of the log bucket. Logs stored during the grace period count toward your retention costs.

If you route a log entry to multiple log buckets, then you can be charged storage and retention costs multiple times. For example, suppose you route a log entry to the _Default log bucket and to a user-defined log bucket. Also, assume that you configure a custom retention period for both buckets that is longer than 30 days. For this configuration, you receive two storage charges and two retention charges.

Vended network logs are available only when you configure log generation. The services that generate vended network logs charge for log generation. If you store these logs in a log bucket or route them to another supported destination, then you are also subject to charges from Cloud Logging or the destination. For information about log-generation costs, see Network telemetry pricing.

To learn how to enable vended network logs, see Configure VPC Flow Logs, Use Firewall Rules Logging, and Cloud NAT: Logs and metrics.

To find your vended network logs, in the Logs Explorer filter by the following log names:

• projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows
• projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall
• projects/PROJECT_ID/logs/compute.googleapis.com%2Fnat_flows
• projects/PROJECT_ID/logs/networkmanagement.googleapis.com%2Fvpc_flows

System-defined logs-based metrics are provided for all Google Cloud projects and are non-chargeable.

User-defined logs-based metrics are a class of Cloud Monitoring custom metrics and are chargeable. For pricing details, see Chargeable metrics.

Monitoring charges for the following:

• Metrics measured by bytes ingested, when the ingested metric data exceeds the free monthly metric allotment.

  Non-chargeable metrics don't count towards the allotment limit.

• Metrics measured by number of samples ingested.

• Cloud Monitoring API read calls that exceed the free monthly API allotment.

  Monitoring API write calls don't count towards the allotment limit.

• Execution of uptime checks.

• Execution of synthetic monitors.

• Alerting policy conditions measured by number of active conditions per month.

• Time series returned by the query of an alerting policy condition.

In Monitoring, ingestion refers to the process of writing time series to Monitoring. Each time series include some number of data points; those data points are the basis for ingestion charges. For pricing information, see Cloud Monitoring pricing.

This section provides the following information:

• Cloud Monitoring API pricing.
• Definitions of chargeable and non-chargeable metrics.
• Descriptions of byte- and sample-based ingestion strategies.

For limits that apply to your use of Monitoring, see Quotas and limits.

There is no charge for Monitoring write API calls.

From July 1, 2018 through October 1, 2025, Monitoring read API calls are charged one unit per call.

From October 2, 2025, Monitoring read API costs are determined by the number of time series returned:

• There is no charge for read API calls issued through the Google Cloud console, excluding those issued through the Cloud Shell.

• There is no charge for read API calls that can't return time-series data.

• All other read API calls are charged by the number of time series that are returned or for one time series, which ever is larger. For example, a call to timeSeries.list might return multiple time series. The Cloud Monitoring API can be invoked indirectly. For example, Google Cloud CLI commands, client libraries, and third-party tools like Grafana might issue read API commands.

  You can use the time_series_billed_for_queries_count metric to monitor the number of time series that have been queried. For more information, see View the number of time series billed for queries.

Metric data from Google Cloud and Knative isn't chargeable. Non-chargeable (free) metrics include the following:

• Google Cloud metrics. For additional information, see Footnote 2.
• Istio metrics
• Knative metrics
• Google Kubernetes Engine system metrics
• agent.googleapis.com/agent/ metrics

All metric data, except for those metrics listed in the section titled Non-chargeable metrics, is chargeable. Most metric ingestion is charged by the number of bytes, but some is charged by the number of samples; these pricing models are described in the following sections.

The following factors contribute to ingestion costs:

• The type of data points—scalar values or distribution values—collected by the metrics.

  • For information about the data type associated with a specific metric type, see the list of metrics.
  • For information about scalar and distribution data types, see Value types.

• The number of data points written to time series. This value depends on the frequency with which the data is sampled and the cardinality of your data. The cardinality determines how many time series are generated for a combination of metric and monitored-resource types; for more information, see Cardinality.

The values for the metric and resource labels that are part of your time series don't contribute to your charges.

The following metrics are chargeable and priced by the number of bytes ingested:

• Agent metrics under agent.googleapis.com, except the agent.googleapis.com/agent/ group

  As of August 6, 2021, the agent.googleapis.com/processes/ metrics will be charged at 5% of the volume rate for other chargeable metrics. For example, ingesting 100 MiB of process metrics will cost the same as ingesting 5 MiB of other chargeable metrics.³

• Metrics from third-party integrations with the Ops Agent. These metrics are ingested into Cloud Monitoring with identifiers of the form workload.googleapis.com/APPLICATION.METRIC; for example, the metric type workload.googleapis.com/nginx.requests falls into this category.

• OpenTelemetry Protocol (OTLP) metrics ingested into Cloud Monitoring as workload.googleapis.com metrics by the Ops Agent. This is a configuration option; for more information, see Ingestion formats for OTLP metrics.

• Custom metrics, including but not limited to those metrics sent by using the Cloud Monitoring API or language-specific client libraries, OpenCensus, and OpenTelemetry.

• External metrics

• User-defined logs-based metrics

For pricing purposes, the ingestion volume is computed as follows:

• For a scalar data type: 8 bytes for each data point written to a time series. User-defined logs-based counter metrics fall into this category.
• For a distribution data type: 80 bytes for each data point written to a time series.

For information about data points in time series, see Time series: data from a monitored resource.

The following metrics are chargeable and priced by the number of samples ingested:

• Metrics from Google Cloud Managed Service for Prometheus: prometheus.googleapis.com metrics.

For pricing purposes, the sample count is computed as follows:

• For a scalar data type: 1 for each point written to a time series.
• For a distribution data type: 2 for each point written to a time series, plus 1 for each histogram bucket that has a non-zero count.

For information about data points in time series, see Time series: data from a monitored resource.

Monitoring charges for each regional execution of an uptime check, beyond the free monthly allotment of 1 million executions. A check that executes in three regions counts as three executions.

The cost for uptime-check execution is $0.30/1,000 executions. The charge appears on your bill as SKU "CA14-D3DE-E67F" for "Monitoring Uptime Checks".

Cloud Monitoring charges for each execution of a synthetic monitor, beyond the free allotment per month of 100 executions per billing account.

Starting no sooner than May 1, 2026, Cloud Monitoring will begin charging for alerting. The pricing model is as follows:

• $0.10 per month for each condition in an alerting policy.
• $0.35 per 1,000,000 time series returned by the query of a metric alerting policy condition.

This section provides the following information:

• Definitions of alerting terminology.
• Information about opting out of billing for alerting policies.

• Condition: The condition of an alerting policy describes when a resource, or a group of resources, is in a state that requires a response.

  • Alerting policies that use filters to create metric-threshold or metric-absence queries can combine up to six conditions.
  • Alerting policies with a the following query types can have only a single condition:
    • Prometheus Query Language (PromQL) query,
    • Monitoring Query Language (MQL)
    • Log match, used in log-based alerts.

  The charge is for each condition $0.10 per month. To stop being charged for a condition, you must delete the alerting policy. Snoozing or disabling the policy doesn't stop you from being charged.

• Metric and log-based alerting policies: Alerting policies that use any condition type except log-match conditions are metric alerting policies; the conditions of metric alerting policies return time series. During each execution period, conditions in metric alerting policies execute their queries against the Cloud Monitoring datastore. The returned time series are then evaluated against a threshold to determine whether the alerting policy fires.

  Log-based alerting policies use log-match conditions. Log-match conditions return no time series.

  Metric alerting policies that use Billing, Quota, or Uptime metrics are not charged. Log-based alerting policies for Personalized Service Health logs are not charged.

• Execution period: How frequently Cloud Monitoring executes your condition. For most condition types, this is 30 seconds and can't be changed. Conditions that use a PromQL query can set this period. For more information, see Increase the length of the execution period (PromQL only).

• Time series returned: During every execution period, a metric alerting policy executes the query of its condition against the Cloud Monitoring datastore. Cloud Monitoring returns time series data as a response to each query. Each time series in the response counts as one time series returned.

  The number of time series returned in a month is determined by three factors:

  • The shape and scope of the underlying data.
  • The filters and aggregations you use in the query of your condition.
  • The execution period.

If you have an existing Google Cloud contract that doesn't expire until May 1, 2026, you can delay billing for alerting until your contract is due for renewal by requesting an exemption from the Cloud Monitoring alerting billing team. Exemptions for customers with active contracts will be considered on a case-by-case basis.

You can request an exemption until November 1, 2025. To request a billing exemption until contract renewal, fill out the billing-exemption request form.

Error data can be reported to your Google Cloud project by using the Error Reporting API or the Cloud Logging API.

There are no charges for using Error Reporting. However, you might incur Cloud Logging costs because log entries are generated and then stored by Cloud Logging.

For limits that apply to your use of Error Reporting, see Quotas and limits.

There is no cost associated with using Cloud Profiler.

For limits that apply to your use of Profiler, see Quotas and limits.

Trace charges are based on the number of trace spans ingested and scanned. Trace data can be ingested through the Cloud Trace API or the Telemetry API. There are no charges to configure trace scopes.

When latency data is sent to Trace, it's packaged as a trace that is composed of spans, and the spans are ingested by the Cloud Trace backend. When you view trace data, the stored spans are scanned by Cloud Trace. This section provides the following information:

• Defines chargeable and non-chargeable trace spans
• Provides a pricing example
• Provides information on how to reduce your trace span ingestion.
• Provides settings for an alerting policy that can notify you if your trace span ingestion reaches a threshold.

For limits that apply to your use of Trace, see Quotas and limits.

Cloud Trace pricing doesn't apply to spans auto-generated by App Engine Standard, Cloud Run functions or Cloud Run: ingestion of these traces are non-chargeable.

Auto-generated traces don't consume Cloud Trace API quota, and these traces are excluded from Cloud Trace API usage metrics.

Ingestion of trace spans except for those spans listed in the section titled Non-chargeable traces, are chargeable and are priced by ingested volume.

Which product features are free to use?

Usage of Google Cloud Observability products is priced by data volume. Other than the data volume costs described on this page, usage of all additional Google Cloud Observability product features is free.

How much will I have to pay?

To estimate your usage costs, see Estimating your bills.

To get help with billing questions, see Billing questions.

How do I understand the details of my usage?

Several metrics let you drill into and understand your logs and metrics volume using Metrics Explorer. see View detailed usage in Metrics Explorer for details.

If you're interested in learning how to manage your costs, see these blog posts:

• Cloud Logging pricing for Cloud Admins: How to approach it & save cost
• Four steps to managing your Cloud Logging costs on a budget

How do metrics scopes, log scopes, and trace scopes affect billing?

For the most part, metrics scopes, log scopes, and trace scopes don't affect billing.

Logs, metrics, and traces are charged by the project, billing account, folder, or organization that receives the data. The metrics scope for a project defines the collection of the resources whose metrics the project can view and monitor. When you define a metrics scope, you don't affect which resource receives metric data or cause data to be duplicated. A log scope only lists the resources that store or route the log entries that you want to view. Similarly, a trace scope only lists the resources that store the trace data that you want to view.

For example, suppose your organization has 100 virtual machines (VMs): 60 VMs are hosted by Project-A and 40 VMs are in Project-B. Project-A receives and stores the metrics for its VMs, and it's charged when metrics are chargeable. Similarly, Project-B receives and stores the metrics for its VMs, and it's charged when metrics are chargeable. If you create a metrics scope that includes Project-A and Project-B, then you can view the combined metrics for your 100 VMs. You can now view just the metrics for Project-A, just the metrics of Project-B, or the combination of metrics. Even though you have two ways to view the metrics of Project-A, there aren't billing implications.

What happens if I go over the free allotments?

You are automatically billed for any usage over your free allotments. You don't lose any logs or metrics. To better understand your potential costs, review Estimating your bills.

You can create an alerting policy that monitors your usage and notifies you when you approach the threshold for billing.

I have a large number of Google Cloud logs in my project(s) that I do not use. I am concerned about charges for these logs. How do I avoid this?

You can exclude logs to control which logs are ingested into Logging. See Reducing your logs usage for details.

Will services that send logs to my project receive an error if logs are excluded?

No. Services that send log entries cannot determine whether the log entries are ingested into Logging or not.

Will I be charged twice for Virtual Private Cloud flow logs?

If you send your VPC flow logs to Logging, VPC flow logs generation charges are waived, and only Logging charges apply. However, if you send them and then exclude your VPC flow logs from Logging, VPC flow logs charges apply. For more information, see Google Cloud Pricing Calculator and then select the tab titled "Cloud Load Balancing and Network Services".

¹ For pricing purposes, all units are treated as binary measures, for example, as mebibytes (MiB, or 2²⁰ bytes) or gibibytes (GiB, or 2³⁰ bytes).

² There is no charge for Google Cloud metrics that are measured at up to 1 data point per minute, the current highest resolution. In the future, metrics measured at higher resolutions might incur a charge.

³ Process metrics are currently collected at a pre-defined default rate of once per minute, which can't be changed. This data generally changes slowly, so these metrics are currently over-sampled. Therefore, charging process metrics at 5% of the standard rate aligns with the standard rate if the metrics were sampled at 20-minute intervals. Users who collect 100 MiB of data from these metrics are charged for only 5 MiB.

• Read the Google Cloud Observability documentation.
• Try the Pricing calculator.
• Learn about Google Cloud Observability solutions and use cases.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.5