Dress4Win has configured a new uptime check with Google Stackdriver for several of their legacy services. The Stackdriver dashboard is not reporting the services as healthy. What should they do?
A.
Install the Stackdriver agent on all of the legacy web servers.
B.
In the Cloud Platform Console download the list of the uptime servers' IP addresses and create an inbound firewall rule
C.
Configure their load balancer to pass through the User-Agent HTTP header when the value matches GoogleStackdriverMonitoring-UptimeChecks (https:// cloud.google.com/monitoring)
D.
Configure their legacy web servers to allow requests that contain user-Agent HTTP header when the value matches GoogleStackdriverMonitoring- UptimeChecks (https://cloud.google.com/monitoring)
If the resource you are checking isn't publicly available, you must configure the resource's firewall to permit incoming traffic from the uptime-check servers. See Getting IP addresses to download a list of the IP addresses
If the resource you are checking doesn't have an external IP address, uptime checks are unable to reach it.
D. Configure their legacy web servers to allow requests that contain the User-Agent HTTP header when the value matches GoogleStackdriverMonitoring-UptimeChecks (https://cloud.google.com/monitoring).
Here's why:
Google Cloud Monitoring uptime checks use a specific User-Agent (GoogleStackdriverMonitoring-UptimeChecks) to make health checks on services. If the legacy web servers are not configured to accept these requests or block certain User-Agent headers, they will reject the checks, causing them to be reported as unhealthy.
By configuring the legacy web servers to allow traffic from uptime checks that include the proper User-Agent header, Dress4Win ensures that the uptime check traffic can reach the services, allowing Google Monitoring to report accurate health status.
Why other options are less ideal:
Option A (install the Stackdriver agent) is not relevant to this issue. The Stackdriver agent is used for logging and monitoring system metrics but does not directly relate to uptime checks.
Option B (creating inbound firewall rules) is unnecessary unless there's evidence that the firewall is blocking traffic from Google's uptime check servers. Typically, Google uptime check servers should not require special rules.
Option C (configuring the load balancer to pass through the User-Agent header) is relevant if there’s a load balancer in place, but it only solves part of the problem. The legacy web servers still need to accept requests with the appropriate User-Agent header.
Option D suggests configuring legacy web servers to allow requests with the specific User-Agent header. While this might seem appropriate, it's unnecessary and potentially risky. Modifying the servers' configuration introduces additional steps and potential security implications. Since the uptime checks are already reaching the web servers, the key is ensuring the load balancer doesn't interfere with them, not modifying the servers themselves.
IMPORTANT: Dress4Win is not anymore part of the officially listed case studies: https://cloud.google.com/certification/guides/professional-cloud-architect
B: If the resource you are checking isn't publicly available, you must configure the resource's firewall to permit incoming traffic from the uptime-check servers. See List uptime-check server IP addresses to download a list of the IP addresses.
I don't understand why everyone's saying it's B. The question talks about "legacy services". They are not on GCP, are they? So setting up inbound rules on a firewall in GCP will have no effect.
I think B is ok, "Your use of uptime checks is affected by any firewalls protecting your service." from https://cloud.google.com/monitoring/uptime-checks
B) (if the answer talk about firewall of legacy services ant not firewall on GCP) and D) are valid solutions.
I prefer D) because with B) you have to modify firewall rules once per quarter as Ips can change (https://cloud.google.com/monitoring/uptime-checks/using-uptime-checks#get-ips).
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
jcmoranp
Highly Voted 5 years agotartar
4 years, 3 months agoGopiSivanathan
4 years, 1 month agonitinz
3 years, 8 months agogcp2019
Highly Voted 4 years, 12 months agoJohnJamesB1212
Most Recent 1 month, 4 weeks agoJohnJamesB1212
1 month, 4 weeks ago6a8c7ad
3 months, 2 weeks agomesodan
8 months, 3 weeks agojabrrJ68w02ond1
2 years agoamxexam
2 years, 6 months agoDivAl272829
2 years, 7 months agomesodan
2 years, 9 months agonagibator163
2 years, 10 months agoAndrea67
2 years, 11 months agojoe2211
2 years, 12 months agokopper2019
3 years, 4 months ago[Removed]
3 years, 4 months agovictory108
3 years, 4 months agoMamthaSJ
3 years, 4 months agoAusias18
3 years, 7 months ago