Internal TCP/UDP Load Balancing monitoring

Internal TCP/UDP Load Balancing exports monitoring data to Cloud Monitoring. Monitoring metrics can be used for the following purposes:

  • Evaluate an internal TCP/UDP load balancer's configuration, usage, and performance
  • Troubleshoot problems
  • Improve resource utilization and user experience

In addition to the predefined dashboards in Monitoring, you can create custom dashboards, set up alerts, and query the metrics through the Monitoring API.

Viewing Monitoring dashboards

  1. Go to Monitoring in the Google Cloud Console.
    Go to Monitoring
  2. If Resources appears in the navigation pane, select Resources and then select Google Cloud Load Balancers. Otherwise, select Dashboards and then select the dashboard named Google Cloud Load Balancers.
  3. Click the name of your load balancer.

In the left pane, you can see various details for the selected load balancer. In the right pane, you can see time series graphs. Click the Breakdowns link to see specific breakdowns. The left pane presents currently configured data, while the right pane can present data served by historical configurations not currently reflected in the left pane.

Defining alerting policies

You can create alerting policies to monitor the values of metrics and to notify you when those metrics violate a condition.

To create an alerting policy that monitors one or more Internal TCP Load Balancer or Internal UDP Load Balancer resources, follow these steps:

  1. In the Google Cloud Console, go to the Monitoring page.

    Go to Monitoring

  2. In the Monitoring navigation pane, select Alerting, and then select Create policy.
  3. If the button Return to Legacy UI is displayed and if you want to follow these instructions, then click it. You can create an alerting policy by using the Preview interface; however, these instructions are for the Legacy UI.
  4. Click Add condition:
    1. The settings in the Target pane specify the resource and metric to be monitored. In the Find resource type and metric field, select the resource Internal TCP Load Balancer or Internal UDP Load Balancer. Next, select a metric from the metrics list.
    2. The settings in the Configuration pane of the alerting policy determine when the alert is triggered. Most fields in this pane are populated with default values. For more information about the fields in the pane, see Configuration in the Alerting policies documentation.
    3. Click Add.
  5. To advance to the notifications section, click Next.
  6. Optional: To add notifications to your alerting policy, click Notification channels. In the dialog, select one or more notification channels from the menu, and then click OK.

    If a notification channel that you want to add isn't listed, then click Manage notification channels. You are taken to the Notification channels page in a new browser tab. From this page, you can update the configured notification channels. After you have completed your updates, return to the original tab, click Refresh, and then select the notification channels to add to the alerting policy.

  7. To advance to the documentation section, click Next.
  8. Click Name and enter a name for the alerting policy.
  9. Optional: Click Documentation, and then add any information that you want included in a notification message.
  10. Click Save.
For more information, see Alerting policies.

Defining Monitoring custom dashboards

You can create custom Monitoring dashboards over Internal TCP/UDP Load Balancing metrics:

  1. Go to Monitoring in the Google Cloud Console.
    Go to Monitoring
  2. Select Dashboards > Create Dashboard.
  3. Click on Add Chart.
  4. Give the chart a title.
  5. Select metrics and filters. For metrics, the resource type is Google Cloud TCP Load Balancer (Internal) Rule (internal_tcp_lb_rule) or Google Cloud UDP Load Balancer (Internal) Rule (internal_udp_lb_rule).
  6. Click Save.

Metrics for internal TCP/UDP load balancers

The following metrics for internal TCP/UDP load balancers are reported into Monitoring.

Metric Description
Inbound Throughput The number of bytes sent towards internal TCP/UDP load balancer forwarding rules, as received by the backends.
Inbound Packets The number of packets sent towards internal TCP/UDP load balancer forwarding rules, as received by the backends.
Outbound Throughput The number of bytes sent by internal load balanced backends on connections bound to forwarding rule IPs.
Outbound Packets The number of packets sent by internal load balanced backends on connections bound to forwarding rule IPs.
Latency(*) A by packets distribution of the RTT measured for bundles of packets over each internal load balanced connection. Typically reduced to 95th-%tile in Monitoring views.

(*) Available only for TCP traffic.

Filtering dimensions for internal TCP/UDP load balancer metrics

Metrics are aggregated for each internal TCP/UDP load balancer. Metrics can be further broken down by the following dimensions:

Property Description
INSTANCE GROUP The name of the instance group that received the connection.
BACKEND SCOPE The scope (region or zone) of the instance group that received the connection.
BACKEND ZONE If the instance group was a zonal instance group, the zone of the instance group that served the connection.
CLIENT NETWORK The network from which the instance that connected to internal load balancing sends traffic.
CLIENT SUBNETWORK The subnetwork from which the instance that connected to internal load balancing sends traffic.
CLIENT ZONE The Google Cloud zone of the instance that connected to the internal TCP/UDP load balancer's forwarding rule.
FORWARDING RULE The name of the forwarding rule used by the instance to connect to the internal TCP/UDP load balancer.

Metric reporting frequency and retention

Metrics for the internal TCP/UDP load balancers are exported to Monitoring in 1-minute granularity batches. Monitoring data is retained for six (6) weeks. The dashboard provides data analysis in default intervals of 1H (one hour), 6H (six hours), 1D (one day), 1W (one week), and 6W (six weeks). You can manually request analysis in any interval from 6W to 1 minute.

What's next