This document describes the Cloud MonitoringMetrics Management page, whichhelps you get the most from your billable metrics. Your Google Cloud projecthas access to all the metrics visible to itsmetrics scope. You can use theMetrics Managementpage to do the following:

• View metric usage at a glance: See how your metrics are being usedinqueries,custom dashboards, oralerting policies.

  • Unused billable metrics are active metrics that have not been queriedin the last 30 days and are not used in a custom dashboard or alertingpolicy.
  • To view alerting policies or custom dashboards for a metric in yourmetrics scope but defined in a different project, use the projectpicker to select the Google Cloud project that stores the metric.

• Identify high-cost, low-value metrics: Filter and sort metrics to seewhich unused billable metrics are contributing the most of your bill. See whichprojects and namespaces are responsible for expensivemetrics.

  • View trends over time to understand the relative costsof your billable metrics.
  • Set up alerts to notify you if your overall usagepatterns change.
  • For information about how billable metrics are billed, seePricing models for billable metrics.

• Manage costs:Create rules to exclude unneededmetrics from being ingested into Cloud Monitoring.Excluded metrics are not billed. Exclusion rules apply regardless of thesource of the metric.

  • Exclude single metrics by using the metric name.
  • Exclude groups of metrics by using a regular expression.

• Make use of valuable metrics: Createalerting policies anddashboardsfor unused billable metrics.

• Troubleshoot metric-ingestion problems

  • Troubleshooterrors in writing metric data.
  • Identify possible problems with thecardinality of billable metrics.
  • Viewaudit logs associated with the collection of billablemetrics. For general information about audit logs, see theCloud Audit Logs overview.

TheMetrics Management page does not report user-definedlog-based metrics. These metrics, which are derived bycounting values in log entries, have the prefixlogging.googleapis.com/user.

Before you begin

To view the charts and logs included on theMetrics Management page,to create alerting policies, and to create metric-exclusion rules, you musthave the correctauthorization.

TheMetrics Management analyzes metrics in terms of data collection and usage.For more information about these categories, seeTerminology.

Authorization

• To get the permissions that you need to view dashboards and create alerting policies by using the Google Cloud console or to create, edit, and delete metric-exclusion rules, ask your administrator to grant you theMonitoring Editor (roles/monitoring.editor) IAM role on your project. For more information about granting roles, seeManage access to projects, folders, and organizations.

  You might also be able to get the required permissions throughcustom roles or otherpredefined roles.

• To get the permissions that you need to view audit logs, ask your administrator to grant you thePrivate Logs Viewer (roles/logging.privateLogViewer) IAM role on your project. For more information about granting roles, seeManage access to projects, folders, and organizations.

  You might also be able to get the required permissions throughcustom roles or otherpredefined roles.

  For more information about roles, seeControl access with Identity and Access Management.

• To view the audit logs generated by the metrics on theMetrics Management page, you must have enabled audit logging in yourGoogle Cloud project. To enable your project to generate audit logs whendata is read or written, do the following:

  1. In the Google Cloud console, go to theAudit Logs page:

     Go toAudit Logs

     If you use the search bar to find this page, then select the result whose subheading isIAM & Admin.

  2. EnterStackdriver Monitoring API on the filter bar.
  3. SelectStackdriver Monitoring API.
  4. In theLog type tab, selectData write andData read, andthen clickSave.

  For more information, seeConfigure Data Access audit logs.

Terminology

TheMetrics Management page uses the following terminology to describe thestatus of metrics and to describe how you are using the metrics:

• Status of the metrics
  • Active metrics are billable metrics from which your projecthas ingested data in the last 25 hours.These metrics incur costs.
  • Inactive metrics are billable metrics from which your projecthasn't ingested data in the last 25 hours.These metrics don't incur costs.

• Usage of the metrics

  • Used metrics are metrics that have been queried in thelast 30 days by the Cloud Monitoring API or other tools, or that are usedin a custom dashboard or alerting policy.

    It is possible have charts and alerting policies that refer to metricswith no data (inactive metrics) and to query such metrics; on theMetrics Management page, these metrics are considered used metrics,even though any read operations return no data.

  • Unused billable metrics are active metrics that have not beenqueried in the last 30 days and are not used in a custom dashboard oralerting policy. These metrics incur ingestion costs but are not providingobservability benefits. If these metrics represent observabilitygaps, you can create charts or alerting policies for them. If thesemetrics don't represent observability gaps, then you can exclude themand eliminate the cost of ingesting them.

  • Idle metrics are inactive metrics that are have not been queriedin the last 30 days and are not used in a custom dashboard or alertingpolicy. These metrics don't incur costs.

The usage status for metrics is computed every 24 hours, to reflect themost recent query history and changes to dashboards and alerting policies.

View summaries of metric usage

To view summaries of the number of billable metrics, rates of metricingestion, and error rate, do the following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. In the toolbar, select your time window. By default, theMetrics Managementpage displays information about the metrics collected in the previous oneday. The following screenshot shows an example:

   

   • To see a summary of how many billable metrics are currentlyactive in the projects in your metrics scope, refer to thetheActive Metrics scorecard. A metric is active if data has beenwritten to it in the last 25 hours.

   • To determine how many of the active billable metrics are beingqueried or used in charts or alerting policies, refer to theMetricUsage scorecard. Unused billable metrics represent possible observabilitygaps that might be filled by creating custom dashboards or alertingpolicies, or opportunities to reduce costs by excluding the metricentirely.

   • To determine what is contributing to your costs, Use theBillable bytes ingested andBillable samples ingested scorecards.For more information, seeView overall trends in metricingestion.

   • To find information that might help you identify problems with thedesign or usage of your billable metrics, use theMetric WriteErrors scorecard. For more information, seeInvestigate problems with your metrics.

TheMetrics Management page shows you the amount of data you are ingesting,not actual costs. To view current billing information, clickView Billingin the toolbar.

View information about your metrics scope

The set of metrics displayed in theMetrics Management page depends on themetrics scope of your project. If your project has only itself in itsmetrics scope, then the metrics on theMetrics Management page arefrom the current project. If your project has multiple projects in itsmetrics scope, then the metrics shown on theMetrics Management pageinclude the metrics from all of those projects. It might be that metriccontributing the most to your cost originates in a different project.

To view a summary of the scoping information for your project,clickMetrics scope. This summary includes the following:

• IAM principals with access to the project. The set ofprincipals includes users, groups, and service accounts.
• The number of both free and billable metrics that are visible to themetrics scope.
• A list of the projects that are monitored by the current project. Thebillable metrics from all these projects are available on theMetrics Management page.
• Information about any projects that can view the metrics of the currentproject.

For more information about metrics scopes, seeConfigure a multi-projectview.

Investigate your billable metrics

TheMetrics Management page provides a table that includes each billablemetric in your metrics scope. You can use this table to do the following:

• Determine any metric's contribution to billable volume.
• Determine how often a metric has been read in the last 30 days. Metric readsinclude API read requests and requests generated by charts.
• Identify metrics that are collected but not used in any alerting policyor dashboard. Metric data that is not used might represent a gap inobservability or an opportunity for cost saving by excluding the metric.
• Create an alerting policy or chart for metrics that don'thave an associated alerting policy or custom dashboard.
• Identify the project in which metric data originated. The table includesmetrics from all the projects in your metrics scope, and you mightneed to know from in project a particular metric is collected.
• Review label and cardinality information about each metric. This informationcan be helpful when you areinvestigating problems withmetric design or usage.

To view the table of usage data for each billable metric, do thefollowing:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. In the toolbar, select your time window. By default, theMetrics Managementpage displays information about the metrics collected in the previous oneday. The following screenshot shows an example of the metrics table:

   

Select the metrics to view

To manage your costs, you need to understand which billable metrics aregenerating the most traffic. It isn't sufficient to only know, for example,that 60 MiB of data are being ingested every hour.However, when you know that most of your billable data is due to one ortwo metrics, you can investigate the usage of those metrics.

To list your billable metrics, do the following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. In the toolbar, select your time window. By default, this tab displaysinformation about the metrics collected in the previous one day.
3. To limit the display to specific groups of metrics,use the quickfilters orfilter the table directly.Looking at categories of metrics might reveal patterns that are hardto detect when looking at all the metrics in the table.

The metrics table lists the billable metrics that are in themetrics scope of the current Google Cloud project. For each metric, the tabledisplays that metric's contribution to billable volume and provides links toto the alerting policies and custom dashboards associated with the metric,as shown in the following screenshot. If there is no alerting policy ordashboard associated with a metric, the table includes a button you can clickto create one.

To sort metrics by their contribution to billable volume, click thecolumn header forBytes billable volume/Total andSamples billablevolume/Total.

The metrics table also shows the domain of the metric, the set of labels for themetric, the project from which the metric was ingested, and the cardinalityof the metric. The following screenshot shows an example of these columns.

The label and cardinality information might be useful in identifyingthe cause of increases in billable volume. In Cloud Monitoring,cardinalityrefers to the number of time series associated a metric and a resource, and isrelated to the labels and their values; there is one time series for eachcombination of label values. For more information, seeCardinality.

Changes in billable volume mean you are ingesting more data, and if thechanges are sudden or unexpected, the cause might be a change in thethe number of labels associated with a metric or a change in the waythe values for the labels are set. Either of these can increase the cardinalityof a metric, with the result of a higher billable volume. For informationabout using theMetrics Management to help identify problems with metrics,seeInvestigate problems with your metrics.

Use quick filters

To view only the metrics in the following groups, select an entry on theQuick filters pane:

• Metric status includes active and inactive metrics. Active metrics haveingested time-series data in the last 25hours. For more information about these statuses, seeTerminology.

• Metric usage. This category classifies metrics by the following:

  • Used, unused, and inactive metrics.

    • Used metrics have been accessed by a metric read orare used in a custom dashboard or alerting policy.
    • Unused billable metrics haven't been accessed by a metric read orare used in a custom dashboard or alerting policy.
    • Idle metrics are both "inactive" and "unused".

    For more information about these usage categories, seeTerminology.

  • Metrics used or not used in an alerting policyin the current Google Cloud project.

  • Metrics used or not used in a custom dashboardin the current Google Cloud project.These filters don't include metrics thatare used in predefined dashboards provided by Cloud Monitoring.

  The usage status for metrics is computed every 24 hours, to reflect themost recent query history and changes to dashboards and alerting policies.

• Sets of metrics by domain, as described insummary of billablemetrics.

If you have metrics that aren't used in an alerting policy or acustom dashboard and are never queried, then you might be paying for metricsand not be getting any observability benefit from them. You can list metricsthat appear in no alerting policy or in no custom dashboard defined in thecurrent Google Cloud project by selecting theNo alert policies orNo customdashboards quick filter.

For more information, seeCreate an alerting policy.

To view alerting policies for a metric in your metrics scope butdefined in a different project, use the project picker to select theGoogle Cloud project that stores the metric.

Create a chart for an unmonitored metric

When a metric in the table has no associated custom dashboard, the tableprovides aCreate chart button. You can use this button to createa chart and place it on a custom dashboard. To create a chartfor a metric, do the following:

1. ClickCreate chart in the row for the metric.

   TheExplorer panel opens and is preconfigured to display theselected metric. You can modify the chart configuration.For more information about using Metrics Explorer,seeCreate charts with Metrics Explorer.

2. To save the chart on a custom dashboard, clickSave to dashboard.

3. On theSave Chart panel, do the following:

   1. Accept or modify the default title for the chart.
   2. Select the existing custom dashboard to which you want to save the chart,or selectNew Dashboard to create a new dashboard for the chart.
   3. ClickSave chart.

To view custom dashboards for a metric in your metrics scope butdefined in a different project, use the project picker to select theGoogle Cloud project that stores the metric.

Work with metrics

While you can use theMetrics Management page to view someinformation about a metric, you might want more information. For example,you might want to view a chart of a specific metric or create analerting policy to notify you when that metric's ingestion rate isunexpected.

To get more details about a specific metric, do the following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. Find the metric in the table, and then clickmore_vert Actions to doany of the following:

   • To view a chart that displays the current metric,selectView in Metrics Explorer.

     Metrics Explorer opens and is preconfigured to display theselected metric. You can modify the chart configuration, discard it,or you can add it to a custom dashboard.

   • To create an alerting policy that monitors the metric, selectCreate alert for metric.

     The alert policy dialog opens with the condition fields populated.We recommend that you review all settings and make the followingmodifications:

     • Update the condition threshold value. The default value might notbe satisfactory.
     • Add the notification channels to the policy.
     • Name the policy.

     For more information, seeCreate an alerting policy.

   • Exclude the metric. For more information about this option, seeExclude unneeded metrics.

   • To view audit logs associated with the metric, selectView metric audit logs.

Exclude unneeded metrics

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

You can create a metric-exclusion rule to prevent selected metricsfrom being ingested into Cloud Monitoring. If, for example, youhave a set of unused billable metrics that you don't need, you can excludethose metrics to eliminate the cost of ingesting them. You can lateredit ordelete exclusion rules ifyour needs change.

To create a metric-exclusion rule, do the following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. Clickadd_box Exclude metric. You can also create exclusions from theExcluded Metrics tab ormore_vert Actions in the row for each metric.
3. Select the metrics to exclude.
   1. To exclude a single metric, select it from theMetric nametable.
   2. To exclude a group of metrics, do the following:
      1. ClickRegex
      2. Enter a regular expression. For example, to exclude all of theagent.googleapis.com/apache metrics, you can enteragent.googleapis.com/apache.* oragent.*/apache.*
      3. ClickShow matches to verify that the expression matchesthe intended metrics
   3. ClickCreate rule.

It takes about 5 minutes for the rule to go into effect.

The following table includes regular expressions that might be usefulfor excluding metrics fromstatsdor similar dynamically named metrics:

Edit a metric-exclusion rule

To edit a metric-exclusion rule, do the following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. Click theExcluded Metrics tab.
3. In the row for the rule you want to delete, clickmore_vert Actionsand selectEdit rule.
4. Clear the selected metric or the regular expression
5. Select a new metric or create a new regular expression.
6. ClickUpdate rule.

Editing a rule deletes the old rule and creates a new one.

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. Click theExcluded Metrics tab.
3. In the row for the rule you want to delete, clickmore_vert Actionsand selectDelete rule.

View the volume of excluded metrics

To see the volume of excluded bytes or samples as a chart inMetrics Explorer, do the following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. Click theExcluded Metrics tab.
3. Clickhistory Exclusion timeline.

The chart is pre-configured to display the metric-exclusion data for you.You can also save the chart to a custom dashboard by clickingSave todashboard.

View and alert on trends in billable metrics

The number of billable bytes and billable samples ingested determines themajority of your costs. To predict your monthly costs due to use ofbillable metrics, you need to know the rate of data ingestion. TheMetrics Management page provides summaries of metric usage, which can helpyou do the following:

• View trends in your usage of billable metrics.
• Determine if a project in your metrics scope is sending more or lessmetric data than you expect.
• Identify the metrics that are generating the most data.
• Identify the namespaces that are responsible for generating the mostPrometheus data.
• View the rate of write errors in your metrics. The error rate is thepercentage of metric writes that return an error status relative to thetotal number of metric writes.

Thesummary pane for metric usage provideslinks to more detailed information about trends over time and links topreconfigured, customizable alerting policies for usage trends.

The summary pane revisted.

View overall trends in metric ingestion

To determine whether your applications are generating a consistent amount ofdata, which is expected behavior for stable applications, view the collectionrates by using the ingestion scorecards. By changing the time window over whichyou view metrics, you might see dips, peaks, or trends.

To view collection rates over time, do the following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. In the toolbar, select your time window.

3. ClickView charts on the scorecard for bytes or samples ingested.This discussion refers to charts for billable samples, but the chartsfor billable bytes work the same way. You see a set of charts likethe following:

   

   By default, chart legends are collapsed. To view thelist of time series shown in a chart,clicklegend_toggle Legend. For information about howto set time references or expand the chart over a specifictime window, seeExplore charted data.

   Note: When a Google Cloud project isn't ingesting any billablemetrics, these charts don't display data. Instead, the charts display"No data is available for the selected timeframe." This message isn't anerror.

For example, if you set the time window to a week and you see a constant butunexpected increase in the data ingested over time, then you might look to seeif the increase is coming from one specific metric or as a general trend acrossa group of metrics. If one metric is responsible, then you could investigateto see if the metric'scardinality is alsoincreasing.

• To view the rate of billable samples ingested into the currentmetrics scope, use theTotal billable samples ingested chart.

• To view the contributions of each project in your metrics scopeto the total billable value, use theProjects by billable samplesingested chart. This chart can tell you which projects are sendingthe most data, and if any project is sending an increasing ordecreasing amount of data.

• (Billable samples only) To find the namespaces that are sendingmetrics with the largest contributions to the billable values,use theNamespace Volume Ingestion chart.

• To view the metrics in your metrics scope with the largestcontributions to the billable values, use theTop 10 metrics bybillable samples ingested chart. You might look for spikes, dips, ortrends in the collection rates, or for a metric with a much differentline from all the others.

• To view the contributions to the billable value of all metrics in yourmetrics scope, use theAll metrics by billable samples ingestedchart. This chart includes the metrics in theTop 10 chart and canshow you the overall distribution of collection rates from your metrics.

To analyze any of these charts in more detail, clickmore_vert More options and selectView inMetrics Explorer. For examples that start with theNamespace Volume Ingestion chart and use Metrics Explorerto perform ingestion-volume attribution, see the following:

• Identify high-volume metrics
• Identify high-volume namespaces

For more information about using Metrics Explorer to analyze data,including actions like comparing the current month's behavior to the lastmonth's behavior, seeExplore charted data.

Create alerts based on metric ingestion

To be notified of a spike, dip, or trend in the metric collection rates for yourbillable metrics, create an alerting policy. For example, a dip incollection of metrics might indicate that your application is performing poorly.Similarly, a spike might result in unexpected charges. Lastly, a upward trendmight indicate that a metric has too many labels or is increasing incardinality. In all situations, an alerting policycan notify you of the unusual behavior, and then you can resolve the situation.

If you have both metrics billed by bytes ingested and metrics billed by samplesingested, you need to create an alerting policy for both billing values.

To create an alerting policy that monitors a metric collection rate, dothe following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. In the toolbar, select your time window.
3. ClickView charts on the scorecard for bytes or samples ingested.

4. In the chart whose data you want to monitor, clickCreate alerting policy.

   The alert policy dialog opens with the condition fields populated.We recommend that you review all settings and make the followingmodifications:

   • Update the condition threshold value. The default value might notbe satisfactory.
   • Add the notification channels to the policy.
   • Name the policy.

   For more information, seeCreate an alerting policy.

Investigate problems with your metrics

You can use theMetrics Management page to investigate problems with structureor usage of your billable metrics. For example, you might beexperiencing the following:

• An increase in billable volume that can be attributed to a specific metric.
• Reports of increasing latency of queries for a specific metric.
• Errors in writing metric data, which might result from reaching limitson the amount or rate of data being written.

The occurrence of errors in writing metric data might correlate withother problems like an unexpected increase in billable volume or increasingquery latency. For example, a change in the configuration of a metric mightresult in acardinality problem, which can affectboth the volume of data ingested and query latency, and might also result inmetric-write errors.

View metric-write errors

From theMetric Write Errors scorecard, you can do the following:

• View the status of metric-write requests.
• Create an alerting policy to notify you if the rate of metric-write errorsexceeds a threshold value.
• View the audit logs for metric-write errors, if you have enabled audit logs.These logs can provide insight into the causes of the metric-write errors.

To view information about errors in writing metric data, do the following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. In the toolbar, select your time window.

3. ClickView errors on theMetric Write Errors scorecard.

   • To view the status of metric-write requests to the Cloud Monitoring API,use theAPI - Create Time Series (Status Codes) chart.This chart shows calls to thetimeSeries.create method.

     Each time series shows the rate of writes for a specific HTTPstatus code. When the chart displays a single line for 2xx statusresults, you have no metric-write errors. The following screenshotshows both 2xx status results and a small number of 4xx and 5xx statusresults:

     

     If you see an increase in the number of metric-write requests, then youmight be seeing acardinality issue.

   • If the chart displays status codes for errors, and if you have enabledaudit logs for your project, then you can use the logs to investigatethe causes of the errors. The preconfigured query for the logs looksfor errors associated with the Monitoring API methodtimeSeries.create. This method iscalled each time a metric is written.

     Logs fortimeSeries.create errors can tell you more about thereason for error status codes. The method can fail if, for example,you try to write too much data at once, or if you exceed a limit onthe number of active time series. For more information, see theUser-defined-metrics section in theMonitoring quotas document.

     Note: The notice starting with "If youdon't see any logs below" and theEnable audit logs buttonare always present, even when audit logs appear in the logs panel.The notice is a reminder that, if you don't see logs, then you mightneed to enable audit logging. If you see no logs, then it's possiblethat there are no logs to show.

Investigate metric creation errors

Another method related to metrics that might fail is themetricDescriptors.create method.ThemetricDescriptors.create method is called the first time youwrite time-series data for a new metric, or if you change the structureof the metric data, most likely by adding new labels. The auditlogs for errors from this method are available from the entry foreach metric in the metric table.

To view audit logs for a specific metric, do the following:

1. In the Google Cloud console, go to the query_stats Metrics management page:

   Go toMetrics management

   If you use the search bar to find this page, then select the result whose subheading isMonitoring.

2. In the toolbar, select your time window.
3. Find the metric in the table, and then clickmore_vert Actions.

4. SelectView metric audit logs.

   The preconfigured query for the logs looks for errors associated withthe Monitoring API methodmetricDescriptors.create.

Errors from themetricDescriptors.create method can help you identify possibleproblems in the design of your metrics. You might see errors from thismethod if you exceed the allowable number of metric descriptors oron the number of labels in a metric descriptor.For more information, see theUser-defined-metricssection in the Monitoring quotas document.

Pricing models for billable metrics

In general, Cloud Monitoring system metrics are free, and metricsfrom external systems or applications are not. Billable metrics arebilled by either the number of bytes or the number of samples ingested.This section describes byte- and sample-based ingestion.

For detailed information about chargeable features in Cloud Monitoring, seethe Cloud Monitoring sections of theGoogle Cloud Observability pricing page.

Billing by bytes or samples ingested

Billable metrics are billed either by the number of bytes or by the numberof samples that are ingested. Each time a metric is written, the write operationincludes a data value. The data value can be a scalar, like an integer or afloating-point number, or it can be distribution, a complex data typethat includes several different values. For more information on the typesof values a metric might write, seeValue type.

Both the frequency with which the metric is written—thesamplingrate—and the type of data the metric writes—scalars ordistributions—affectthe amount of data ingested, regardless of whether ingestion is charged bybytes ingested or samples ingested.

• "Bytes ingested" means that charges are based on the volume of data ingested,measured in bytes. For pricing purposes, each scalar value is counted as 8bytes, and each distribution is counted as 80 bytes.

• "Samples ingested" means that charges are based on the number of measurementsingested. For pricing purposes, each scalar value is counted as one sample,and each distribution is counted as two samples plus one for each histogrambucket that has a non-zero count.

The biggest difference between the two pricing models is for distributionvalues. Byte-based ingestion charges a flat rate for distributions, butsample-based ingestion takes into account the data in the distribution;distributions with sparse histograms—few histogram buckets with non-zerovalues—count as fewer samples than distributions with dense histograms,in which most buckets have non-zero values.

Billable metrics on theMetrics Management page

TheMetrics Management page reports billable metrics by domain.The domain gives you information about how the metric was collected andfrom where.

The following table describes the categories of billable metricsavailable on theMetrics Management page and whether they are measured bybytes or samples ingested:

Other billable metrics

TheMetrics Management page does not report user-definedlog-based metrics. These metrics, which are derived bycounting values in log entries, have the prefixlogging.googleapis.com/user.User-defined log-based metrics are charged by bytes ingested.

What's next

• Use the Ops Agent to collect metrics:
  • Configure the Ops Agent
  • Monitor third-party applications
  • Collect Prometheus metrics
  • Collect OTLP telemetry
• Use the Google Cloud Managed Service for Prometheus to collect metrics:
  • Use managed collection
  • Use self-deployed collection
  • Use the OpenTelemetry Collector
  • Use custom metrics inCloud Run
• Collect on-premises and hybrid-cloud metrics by usingBindPlane
• Create user-defined metrics by usingthe Monitoring API
• Google Cloud Observability pricing