This document describes how to configure a private uptime check.
Private uptime checks enable HTTP requests into a customer
Virtual Private Cloud (VPC)
network while enforcing
Identity and Access Management (IAM)
restrictions and
VPC Service Controls perimeters.
Private uptime checks can send requests over the private network to resources
like a virtual machine (VM) or an L4 internal load balancer (ILB).
The internal IP addresses for resources on the private network are recorded by
Service Directory
services with
private network access
enabled. To use private uptime
checks, you must configure private network access by using the
Service Directory product.
The Google Cloud project that stores the private uptime check and
the Google Cloud project that stores the Service Directory
service can be different projects. Cloud Monitoring lets you monitor
resources in multiple
Google Cloud projects from one project by using a metrics scope.
The project in which the uptime check is defined is the
scoping project of a metrics scope; the metrics scope is a list of all projects
the scoping project monitors.
The Service Directory service might be defined in the
scoping project or in a project in the metrics scope.
For more information about metrics scopes, see
Metrics scopes overview
.
The private network and its resources, like VMs or load balancers, can
also be in a different Google Cloud project. This project does not have
to be in the metrics scope of the uptime check's scoping project.
The Service Directory service collects the uptime metrics, so
it must be in the metrics scope, but the resources it encapsulates don't.
This document describes how to set up a private network and configure
Service Directory resources for it by using the Google Cloud console
or the API. The API examples assume that
the private network and the Service Directory service are in
the scoping project of the uptime check. However,
Create a private
uptime check
also describes how to use the API to
create an uptime check that uses a Service Directory service in
the metrics scope.
For information about how to configure uptime checks that use public
IP addresses, see
Create public uptime checks
.
For information about managing and monitoring your uptime checks, see the
What's next
section of this document.
Before you begin
Enable the following APIs:
- Cloud Monitoring API:
monitoring.googleapis.com
- Service Directory API:
servicedirectory.googleapis.com
- Service Networking API:
servicenetworking.googleapis.com
- Compute Engine API:
compute.googleapis.com
You can enable the APIs by using the gcloud CLI or the
Google Cloud console. The following tabs describe how to install the
gcloud CLI and enable the Cloud Monitoring API:
Google Cloud console
In the Google Cloud console, select the Google Cloud project for
which you want to enable the API,
and then go to the
APIs & Services
page:
Go to
APIs & Services
Click the
Enable APIs and Service
button.
Search for "Monitoring".
In the search results, click through to "Stackdriver Monitoring API".
If "API enabled" is displayed, then the API is already enabled. If
not, then click
Enable
.
gcloud CLI
If you have not already installed the Google Cloud CLI on your
workstation, see
Installing the gcloud CLI
.
To see if the Monitoring API is enabled, run the following
command on your workstation, after replacing
PROJECT_ID
with the
ID of the project for which you want to enable the API:
gcloud services list --project=
PROJECT_ID
If
monitoring.googleapis.com
appears in the output, the API is
enabled.
If the API is not enabled, then run the following command to enable it:
gcloud services enable monitoring --project=
PROJECT_ID
For more information, see
gcloud services
.
You can use the same steps for enabling the other APIs:
- To use the Google Cloud console, search for the display name, for example,
"Service Directory API".
- To use the gcloud CLI, specify the first element of the
googleapis.com
name, for example,
servicedirectory
.
Configure the notification channels that you want to use to receive
notifications. We recommend that you create multiple types of notification
channels. For more information, see
Create and manage notification channels
.
Configure a private network and configure a VM or ILB to have
access to that private network.
For more information, see
Private services access
.
Private checks that target ILBs are limited to
the regions with uptime checkers.
The uptime-check region
USA
includes the
USA_OREGON
,
USA_IOWA
, and
USA_VIRGINIA
regions. Each of the
USA_*
regions has one checker, and
USA
includes all three. The other uptime-check regions,
EUROPE
,
SOUTH_AMERICA
, and
ASIA_PACIFIC
, each have one
checker.
To remove
this limitation, you must configure global access to your load balancer.
For more information about how to configure global access, see the ILB tab
in the
Configure Service Directory resources
section of this document.
If you plan to check an ILB that doesn't permit global access, then
select one of the following regions for your ILB:
us-east4
us-central1
us-west1
europe-west1
southamerica-east1
asia-southeast1
Determine which interface to use:
Google Cloud console: Lets you create an uptime
check when a VM is servicing requests. This interface guides you
through configuring Service Directory resources,
authorizing the service account, and configuring the network firewall
rules.
Command line interfaces: You can use Google Cloud CLI and the
Cloud Monitoring API to create private uptime checks when ILBs and VMs
are servicing requests.
If you plan to use the command line to configure your private uptime checks,
then complete the
Prerequisite steps
.
Create a private uptime check
This section explains how to create and configure private uptime checks
of Service Directory services:
To use the Google Cloud console, select the
Google Cloud console
tab.
To use the Cloud Monitoring API and to configure the
Service Directory service to be in the same Google Cloud project as
the uptime check, select the
API: Scoping project
tab.
To use the Cloud Monitoring API and to configure the
Service Directory service to be in a project monitored
by the metrics scope of the
uptime check's project, select the
API: Monitored project
tab.
Google Cloud console
To create an uptime check by using the Google Cloud console, do the following:
-
In the Google Cloud console, go to the
Uptime checks
page:
Go to
Uptime checks
If you use the search bar to find this page, then select the result whose subheading is
Monitoring
.
Click
Create Uptime Check
.
Specify a private uptime check:
Select the protocol, either
HTTP
or
HTTPS
. Don't select
TCP
for a private uptime check.
Choose the
Internal IP
resource type.
If you don't have a Service Directory service configured
for your project or if you want to create a
Service Directory service, then click
View
and complete the
Private Uptime Check Prerequisites
pane:
If prompted, enable the Compute Engine API or the
Service Directory API.
Enabling the APIs might take a minute to complete.
Expand
arrow_drop_down
Service Account
, if shown,
and then click
Create Service Account
.
When a Monitoring service account doesn't exist, one
is created. Then, Monitoring grants the service account
two Service Directory roles.
Expand
arrow_drop_down
Service Directory
menu and
then do the following:
- Expand
arrow_drop_down
Region
and
then select the region of the VM that is serving requests.
- Expand
arrow_drop_down
Namespace
and then either select an
existing Service Directory namespace or
click
Create namespace
and create a namespace.
- Click
Service name
and enter a service
name. Services are the targets of private uptime checks.
- Click
Endpoint name
and enter a name for the endpoint name.
An endpoint is a pair of IP address and port values that
a service can use to handle requests.
When your service contains multiple
endpoints, one endpoint is chosen at random.
- Expand
arrow_drop_down
Network
and then
select your private network.
- Expand
arrow_drop_down
Instance
and then select the VM
on the private network that is serving requests. After you select
the instance, its internal IP address is displayed.
- Click
Done
.
Expand
arrow_drop_down
Firewall rules
:
Expand
arrow_drop_down
Network
and select the network
to which the network rule is attached.
Click
Create Firewall Rules
.
The firewall rule enables inbound TCP traffic from routes
35.199.192.0/19.
A route from 35.199.192.0/19 supports connectivity to forwarding
targets that use private routing.
For more information, see
VPC routes
.
In the
Private Uptime Check
pane, to specify the
Service Directory service to use, do one of the following:
Select
Use fully qualified service name
and then enter the fully
qualified name of the service:
projects/
SERVICE_DIRECTORY_PROJECT_ID
/locations/
REGION
/namespaces/
PRIVATE_NAMESPACE
/services/
PRIVATE_SERVICE
Select the
Region
,
Namespace
, and
Service
by using the
menus. If you created a service, then these fields are selected for you.
In the
Private Uptime Check
pane, complete the description of the
target of the uptime check:
Optional: Enter a path component for the request.
Private uptime checks that use the HTTP or HTTPS protocol
send a request to
http://target/path
. In this
expression, the
target
is the internal IP address configured
in the Service Directory endpoint.
If you leave the
Path
field blank or if you set the value to
/
,
then the request is issued to
http://target/
.
Optional: To set how often the uptime check executes, use the
Check frequency
field.
Optional: To select checker regions, or to configure
authentication, headers for HTTP and HTTPS checks, and other values,
click
More target options
:
- Regions
: Select the regions where the uptime checks are to
receive requests. An uptime check must have at least three checkers.
There's one checker in all regions except the
United States
,
which has three checkers. The default setting,
Global
,
includes all regions.
- Request Method
: Select
GET
or
POST
.
- Body
: For HTTP
POST
checks, enter the URL-encoded body; you
must do the encoding yourself. For all other checks, leave this
field empty.
- Host header
: Don't set this field when configuring
private uptime checks.
- Port
: Any value you set here overrides the port in your
Service Directory endpoint configuration. Don't set
a value here if you want the endpoint configuration to be used.
- Custom Headers
: Supply custom headers, and optionally,
encrypt them. Encryption hides the values in the header in the form.
Use encryption for headers related to authentication that you
don't want visible to others.
- Authentication
: Provide a single username and password. These
values are sent as an Authorization header. If you set values here,
don't set a separate Authorization header; if you set an
Authorization header, don't set values here. Passwords are always
hidden in the form.
Click
Continue
and configure the response requirements.
All settings in this section have default values:
To set a timeout period for the uptime check, use the
Response Timeout
field. An uptime check fails when no
response is received from more than one location within this period.
To configure the uptime check to perform content matching,
ensure that the toggle label is
Content matching is enabled
:
- Select the
Response Content Match Type
from the menu of options.
This field determines how the response content is compared to the
returned data. For example, assume that the response content is
abcd
and the content match type is
Contains
. The uptime check
is successful only when the response data contains
abcd
.
For more information, see
Validate response data
.
- Enter the
Response content
. The response content must be a string
no longer than 1024 bytes. In the API, this field is the
ContentMatcher
object.
To prevent log entries from being created due to uptime checks,
clear
Log check failures
.
For the HTTP uptime checks, configure the acceptable response codes.
By default, HTTP uptime checks mark any
2xx
response as a successful response.
Click
Continue
and configure alerting policies and notifications.
To be notified when an uptime check fails, create an
alerting policy
and
configure
notification channels
for that policy:
- Optional: Update the name of the alerting policy.
- Optional: In the
Duration
field, select how long the uptime checks
must fail before notifications are sent. By default, notifications are
sent when at least two regions report uptime check failures for a
duration of at least one minute.
In the box labeled
Notification channels
,
expand
arrow_drop_down
Menu
, select the channels to add,
and then click
OK
.
In the menu, the notification channels are grouped alphabetically for
each channel type.
If you don't want to create an alerting policy, then ensure
that the text of the toggle button is
Do not create an alert
.
Click
Continue
and complete the uptime check:
Enter a descriptive title for the uptime check.
Optional: To add user-defined labels to your uptime check,
do the following:
- Click
expand_more
Show user labels
.
- In the
Key
field, enter a name for the label.
Label names must start with a lowercase letter, and they can contain
lowercase letters, numerals, underscores, and dashes. For example,
enter
severity
.
- In the
Value
field, enter a value for your label. Label values
can contain
lowercase letters, numerals, underscores, and dashes. For example,
enter
critical
.
- For each additional label, click
Add user label
and then enter
the key and value of the label.
To verify your uptime check configuration, click
Test
.
If the result isn't what you expect, see
Troubleshooting
,
correct your configuration, and then repeat the verification step.
Click
Create
.
API: Scoping project
To create the configuration for a private uptime check, you create an
UptimeCheckConfig
object and pass that
object to the
uptimeCheckConfigs.create
method
in the Cloud Monitoring API.
The
UptimeCheckConfig
object for a private uptime check differs
from the object for a public uptime check in the following ways:
The monitored resource specified in the uptime-check configuration must be
of type
servicedirectory_service
. This resource type
has the following labels:
project_id
: The project ID associated with the
Service Directory service.
location
: The cloud region associated with the service.
namespace_name
: The Service Directory namespace.
service_name
: The name of the Service Directory service.
You don't need to specify a
port
value in the uptime-check configuration.
The port value from the Service Directory endpoint overrides
any value set in the uptime-check configuration, and the check fails if
no port is specified in the Service Directory configuration.
The uptime-check configuration must specify the
checker_type
field
with the value
VPC_CHECKERS
. This value is required for private uptime
checks. By default, uptime checks are public, so public uptime checks
don't need to specify this field.
The following JSON code illustrates an
UptimeCheckConfig
object for a
private uptime check using the Service Directory resources
configured for a VM instance on a private network:
{
"displayName": "private-check-demo",
"monitoredResource": {
"type": "servicedirectory_service",
"labels": {
"project_id": "
SERVICE_DIRECTORY_PROJECT_ID
",
"service_name": "
PRIVATE_SERVICE
",
"namespace_name": "
PRIVATE_NAMESPACE
",
"location": "
REGION
"
}
},
"httpCheck": {
"requestMethod": "GET"
},
"period": "60s",
"timeout": "10s",
"checker_type": "VPC_CHECKERS"
}'
To create a private uptime check when the
Service Directory service
is in the same Google Cloud project as the uptime check, do the following:
Set the default Google Cloud project for the gcloud CLI:
gcloud config set project
PROJECT_ID
Create an environment variable to store your project ID:
export PROJECT_ID=$(gcloud config get-value core/project)
Create an environment variable hold an access token:
export TOKEN=`gcloud auth print-access-token`
Use the
curl
tool to invoke the
uptimeCheckConfigs.create
method
and post a configuration object to it:
curl https://monitoring.googleapis.com/v3/projects/${PROJECT_ID}/uptimeCheckConfigs \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
--request POST --data '{
"displayName": "private-check-demo",
"monitoredResource": {
"type": "servicedirectory_service",
"labels": {
"project_id": "'"$PROJECT_ID"'",
"service_name": "
PRIVATE_SERVICE
",
"namespace_name": "
PRIVATE_NAMESPACE
",
"location": "
REGION
"
}
},
"httpCheck": {
"requestMethod": "GET"
},
"period": "60s",
"timeout": "10s",
"checker_type": "VPC_CHECKERS"
}'
If the creation of the uptime check fails, then verify that the
service account has the necessary roles. For more information,
see
Create of uptime check fails
.
API: Monitored project
To create the configuration for a private uptime check, you create an
UptimeCheckConfig
object and pass that
object to the
uptimeCheckConfigs.create
method
in the Cloud Monitoring API.
The
UptimeCheckConfig
object for a private uptime check differs
from the object for a public uptime check in the following ways:
The monitored resource specified in the uptime-check configuration must be
of type
servicedirectory_service
. This resource type
has the following labels:
project_id
: The project ID associated with the
Service Directory service.
location
: The cloud region associated with the service.
namespace_name
: The Service Directory namespace.
service_name
: The name of the Service Directory service.
You don't need to specify a
port
value in the uptime-check configuration.
The port value from the Service Directory endpoint overrides
any value set in the uptime-check configuration, and the check fails if
no port is specified in the Service Directory configuration.
The uptime-check configuration must specify the
checker_type
field
with the value
VPC_CHECKERS
. This value is required for private uptime
checks. By default, uptime checks are public, so public uptime checks
don't need to specify this field.
The following JSON code illustrates an
UptimeCheckConfig
object for a
private uptime check using the Service Directory resources
configured for a VM instance on a private network:
{
"displayName": "private-check-demo",
"monitoredResource": {
"type": "servicedirectory_service",
"labels": {
"project_id": "
SERVICE_DIRECTORY_PROJECT_ID
",
"service_name": "
PRIVATE_SERVICE
",
"namespace_name": "
PRIVATE_NAMESPACE
",
"location": "
REGION
"
}
},
"httpCheck": {
"requestMethod": "GET"
},
"period": "60s",
"timeout": "10s",
"checker_type": "VPC_CHECKERS"
}'
To create a private uptime check when the
Service Directory service is in a Google Cloud project
that is monitored by the metrics scope of the uptime check's
Google Cloud project, do the following:
Configure the gcloud CLI to default to the Google Cloud project
where the uptime check is to be created:
gcloud config set project
PROJECT_ID
Create an environment variable to store your project ID:
export PROJECT_ID=$(gcloud config get-value core/project)
Create an environment variable to store the project ID of the
Google Cloud project
in which the Service Directory service is defined:
export MONITORED_PROJECT_ID=
MONITORED_PROJECT_ID
This project must be in the metrics scope of the uptime check's
project.
Create an environment variable hold an access token:
export TOKEN=`gcloud auth print-access-token`
Use the
curl
tool to invoke the
uptimeCheckConfigs.create
method
and post a configuration object to it:
curl https://monitoring.googleapis.com/v3/projects/${PROJECT_ID}/uptimeCheckConfigs \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
--request POST --data '{
"displayName": "private-check-demo",
"monitoredResource": {
"type": "servicedirectory_service",
"labels": {
"project_id": "'"$MONITORED_PROJECT_ID"'",
"service_name": "
PRIVATE_SERVICE
",
"namespace_name": "
PRIVATE_NAMESPACE
",
"location": "
REGION
"
}
},
"httpCheck": {
"requestMethod": "GET"
},
"period": "60s",
"timeout": "10s",
"checker_type": "VPC_CHECKERS"
}'
If the creation of the uptime check fails, then verify that the
service account has the necessary roles. For more information,
see
Create of uptime check fails
.
There can be a delay of up to 5 minutes
before the uptime check results start to flow into Monitoring.
During that time, the uptime check dashboard reports the status as
"no data available."
Prerequisite steps
If you plan to use the Google Cloud console interface,
then go to
Create a private uptime check
. The
Google Cloud console guides you through all prerequisite steps.
If you plan to use the
command line to configure your private uptime checks, then you must
complete the following steps before you can create the uptime check:
- Configure Service Directory resources
- Authorize the service account
- Configure firewall rules
Configure Service Directory resources
Private uptime checks determine the availability of a resource by using an
internal IP address that is recorded by a
Service Directory
service. You can configure a
Service Directory for the following resources:
- VMs on a private network
- L4 internal load balancers (ILBs)
To use private uptime checks, you must configure the following
Service Directory resources:
- Endpoint
: An endpoint is a pair of IP address and port values that
a service can use to handle requests. When your service contains multiple
endpoints, one endpoint is chosen at random.
- Service
: A service is a collection of endpoints that provide a set
of behaviors. Services are the targets of private uptime checks.
- Namespace
: A namespace holds a set of service names and their associated
endpoints. Namespaces let you group services together for consistent
management.
You can configure these resources with the gcloud CLI or the
Google Cloud console. When you use the console, the configuration steps
are included in the
Create Uptime Check
dialog.
Google Cloud console
When you use the Google Cloud console, after you select
Internal IP
as the
resource type for an uptime check, you are prompted to create a
Service Directory and a service.
gcloud CLI - VM
For information about the commands used in this document for services,
namespaces, and endpoints, see the
gcloud service-directory
command group
.
To create Service Directory resources for a VM,
do the following:
Configure the Google Cloud CLI to default to the Google Cloud project where
the Service Directory resources are to be created:
gcloud config set project
PROJECT_ID
Create environment variables to store your project ID and project number:
export PROJECT_ID=$(gcloud config get-value core/project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')
Create a Service Directory namespace:
gcloud service-directory namespaces create
PRIVATE_NAMESPACE
--location=
REGION
Create a Service Directory service in the namespace:
gcloud service-directory services create
PRIVATE_SERVICE
\
--namespace
PRIVATE_NAMESPACE
--location=
REGION
Create an environment variable to hold the IP address of the VM on the
private network:
export INTERNAL_IP=$(gcloud compute instances describe --zone=
ZONE
\
PRIVATE_SERVICE_INSTANCE
--format='get(networkInterfaces[0].networkIP)')
Create a Service Directory endpoint that contains the
internal IP address and a port:
gcloud service-directory endpoints create
PRIVATE_ENDPOINT
\
--location=
REGION
--namespace=
PRIVATE_NAMESPACE
\
--service=
PRIVATE_SERVICE
\
--network=projects/$PROJECT_NUMBER/locations/global/networks/
PRIVATE_CHECK_NETWORK
\
--address=$INTERNAL_IP --port=80
gcloud CLI - L4 ILB
For information about the commands used in this document for services,
namespaces, and endpoints, see the
gcloud service-directory
command group
.
You can use private uptime checks to monitor availability of an L4 internal
load balancer (ILB) by creating Service Directory resources
for the L4 ILB.
When you create new L4 ILBs, you can use the automatic integration provided by
Service Directory; for more information, see
Configure
internal load balancers in Service Directory
for more information.
If you have L4 ILBs that were created without using the automatic integration
provided by Service Directory, then you can manually configure
the Service Directory resources by doing the following:
Configure the Google Cloud CLI to default to the Google Cloud project where
the Service Directory resources are to be created:
gcloud config set project
PROJECT_ID
Create environment variables to store your project ID and project number:
export PROJECT_ID=$(gcloud config get-value core/project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')
To permit all uptime checkers to transfer data to your L4 ILB,
enable global access to the ILB:
gcloud compute forwarding-rules update
ILB_FORWARDING_RULE_NAME
\
--region=
ILB_REGION
--allow-global-access
If your L4 ILB does not permit global access, then uptime metrics are
available only if
ILB_REGION
is one of the following:
us-east4
us-central1
us-west1
europe-west1
southamerica-east1
asia-southeast1
Create a Service Directory namespace:
gcloud service-directory namespaces create
PRIVATE_NAMESPACE_FOR_ILB
\
--location=
REGION
Create a Service Directory service in the namespace:
gcloud service-directory services create
PRIVATE_SERVICE_FOR_ILB
\
--namespace
PRIVATE_NAMESPACE_FOR_ILB
--location=
REGION
Create an environment variable to hold the IP address of the load balancer
on the private network:
export INTERNAL_IP=$( gcloud compute forwarding-rules describe
ILB_FORWARDING_RULE_NAME
\
--region=
ILB_REGION
--format='get(IPAddress)')
Create a Service Directory endpoint that contains the
internal IP address and a port:
gcloud service-directory endpoints create
PRIVATE_ENDPOINT_FOR_ILB
\
--location=
ILB_REGION
--namespace=
PRIVATE_NAMESPACE_FOR_ILB
\
--service=
PRIVATE_SERVICE_FOR_ILB
\
--network=projects/$PROJECT_NUMBER/locations/global/networks/
PRIVATE_CHECK_NETWORK
\
--address=$INTERNAL_IP --port=80
Authorize the service account
Uptime checks use a Monitoring-owned service account to
manage interactions with the Service Directory service. The
service account name has the following format:
service-
PROJECT_NUMBER
@gcp-sa-monitoring-notification.iam.gserviceaccount.com
When this service account doesn't exist, Monitoring creates
the service account when you create the private uptime check. You
can't create this service account.
When you create a private uptime check, Monitoring attempts
to grant the service account two Service Directory roles.
However, when you use the API, your Google Cloud project settings might
prevent Monitoring from granting roles to the service account.
In this situation, the creation of the uptime check fails.
This section describes how you can grant the required roles to an
existing service account:
Google Cloud console
When you use the Google Cloud console, after you select
Internal IP
as the
resource type for an uptime check, you are prompted to authorize the
service account.
API: Scoping project
To grant the
Service Directory roles
to
an existing service account, do the following:
Configure the gcloud CLI to default to the Google Cloud project
where the uptime check is to be created:
gcloud config set project
PROJECT_ID
Create environment variables to store the project ID and project number:
export PROJECT_ID=$(gcloud config get-value core/project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')
Run the following commands:
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
--role='roles/servicedirectory.viewer'
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
--role='roles/servicedirectory.pscAuthorizedService'
The previous commands grant the following roles to the service account:
roles/servicedirectory.viewer
roles/servicedirectory.pscAuthorizedService
API: Monitored project
To grant the
Service Directory roles
to
an existing service account, do the following:
Configure the gcloud CLI to default to the Google Cloud project
where the uptime check is to be created:
gcloud config set project
PROJECT_ID
Create environment variables to store the project ID and project number:
export PROJECT_ID=$(gcloud config get-value core/project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')
Create an environment variable hold the project ID of the project
in which the Service Directory service is defined:
export MONITORED_PROJECT_ID=
MONITORED_PROJECT_ID
This project must be in the metrics scope of the uptime check's
project.
Create an environment variable hold the project ID of the project
where the network is defined:
export NETWORK_PROJECT_ID=
NETWORK_PROJECT_ID
This project does not need to be in the metrics scope of the
uptime check's project.
Run the following commands:
gcloud projects add-iam-policy-binding $MONITORED_PROJECT_ID \
--member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
--role='roles/servicedirectory.viewer'
gcloud projects add-iam-policy-binding $NETWORK_PROJECT_ID \
--member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
--role='roles/servicedirectory.pscAuthorizedService'
The previous commands grant the following roles to the service account:
roles/servicedirectory.viewer
for the monitored project in which the
Service Directory service is configured,
$SERVICE_MONITORED_PROJECT_ID
.
roles/servicedirectory.pscAuthorizedService
for the project in which
the private network is configured,
$NETWORK_PROJECT_ID
.
Configure firewall rules
You must create a firewall rule that enables inbound TCP traffic from routes
35.199.192.0/19. A route from 35.199.192.0/19 supports connectivity to
forwarding targets that use private routing. For more
information, see
VPC routes
.
Google Cloud console
When you use the Google Cloud console, after you select
Internal IP
as the
resource type for an uptime check, you are prompted to configure the
firewall rules.
gcloud CLI
To create a firewall rule that permits inbound TCP traffic
through the firewall for private network access, run the following command:
Configure the gcloud CLI to default to the Google Cloud project
where the uptime check is to be created:
gcloud config set project
PROJECT_ID
Create environment variables to store the project ID and project number:
export PROJECT_ID=$(gcloud config get-value core/project)
Create the network rule:
gcloud compute firewall-rules create
PRIVATE_CHECK_NETWORK_HOPE_RULE
\
--network="
PRIVATE_CHECK_NETWORK
" \
--action=allow --direction=ingress --source-ranges="35.199.192.0/19" \
--rules=tcp --project="$PROJECT_ID"
In the previous command,
PRIVATE_CHECK_NETWORK
is the network to which this rule is
attached while
PRIVATE_CHECK_NETWORK_HOPE_RULE
is the name of the firewall rule.
For more information about this step, see
Configure the network project
.
Limitations
When using private uptime checks, validation of SSL certificates is disabled,
regardless of configuration.
Private uptime checks don't support endpoints that have redirections.
Troubleshooting
This section describes some errors you might encounter when using
private uptime checks and provides information for resolving them.
Create of uptime check fails
Your Google Cloud project settings might prevent modification of the roles assigned
to the service account that uptime checks use to
manage interactions with the Service Directory service.
In this situation, the creation of the uptime check fails.
This section describes how you can grant the roles that the service account
requires:
Google Cloud console
When you use the Google Cloud console to create the private uptime check,
the Google Cloud console issues the commands to grant the
Service Directory roles to the service account.
For information about how to grant roles to a service account,
see
Authorize the service account
.
API: Scoping project
The first time you create a private uptime check for a
Service Directory service and private resources
in a single Google Cloud project,
the request might succeed or fail. The result depends on whether you
have disabled
automatic role grants for service accounts
in your project:
The first uptime-check creation succeeds if your project permits
automatic role grants for service accounts. A service account is
created for you and is granted the necessary roles.
The first uptime-check creation fails if your project doesn't permit
automatic role grants for service accounts. A service account is
created, but no roles are granted.
If the creation of the uptime check fails, then do the following:
- Authorize the service account
.
- Wait a few minutes for the permissions to propagate.
- Try creating the private uptime check again.
API: Monitored project
The first time you create a private uptime check that targets a
Service Directory service in a monitored project or
private resources in different Google Cloud project,
the request fails and results in the creation of a
Monitoring service account.
How you authorize the service account depends on the number of
Google Cloud projects you are using and their relationships.
You might have up to four projects involved:
- The project in which you defined the private uptime check.
- The monitored project in which you configured the
Service Directory service.
- The project in which you configured the VPC network.
- The project in which network resources like VMs or load balancers are
configured. This project has no role in the service-account authorization
discussed here.
When the creation of the first uptime check fails, do the following:
- Authorize the service account
.
- Wait a few minutes for the permissions to propagate.
- Try creating the private uptime check again.
Access denied
Your uptime checks are failing with
VPC_ACCESS_DENIED
results. This result
means that some aspect of your network configuration or service-account
authorization isn't correct.
Check your service-account authorization for using a scoping
project or a monitored project as described in
Create of uptime check fails
.
For more information about accessing private networks, see
Configure the network project
.
Anomalous results from private uptime checks
You have a Service Directory service with
multiple VMs, and your service configuration contains multiple endpoints.
When you shut down one of the VMs, your uptime check still indicates success.
When your service configuration contains multiple endpoints, one is
chosen at random. If the VM associated with the chosen endpoint is running,
the uptime check succeeds even though one of the VMs is down.
Your uptime checks are returning errors or unexpected results. This might
occur if you have overridden default header values.
When a request is sent for a private uptime check to a target endpoint,
the request includes the following headers and values:
Header
|
Value
|
HTTP_USER_AGENT
|
GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)
|
HTTP_CONNECTION
|
keep-alive
|
HTTP_HOST
|
IP of Service Directory endpoint
|
HTTP_ACCEPT_ENCODING
|
gzip
,
deflate
,
br
|
CONTENT_LENGTH
|
Calculated from uptime post data
|
If you attempt to override these values, the following might happen:
- The uptime check reports errors
- The override values are dropped and replace with the values in the table
No data visible
You don't see any data on the uptime check dashboard when your
uptime check is in a different Google Cloud project than the
Service Directory service.
Ensure that the Google Cloud project that contains the uptime check
monitors the Google Cloud project that contains the
Service Directory service.
For more information about how to list monitored projects and add additional
ones, see
Configure a metrics scope for multiple projects
.
What's next