feat: simplify service dashboards

[daniel-sanche]

• Previously, terraform was setting up duplicate dashboards; some created by istio, and some created manually. This PR removes the custom ones, so the Cloud Monitoring interface is easier to read
• I also loosened some of the SLO definitions. Currently they would instantly fail and send out alerts. We would prefer a fresh sandbox to be within its SLO budget

[github-actions[bot]]

You can also use the Stage Website Action if there were updates to the website.

Note: Open in Cloud Shell may not work properly if this PR contains changes to the custom Cloud Shell image

[arbrown]

I re-read the previous comment, and I do recall seeing some violations during deployment. I think I'm correct in assuming that the latencies are generally well within even the old threshold after that though, right?

[daniel-sanche]

I re-read the previous comment, and I do recall seeing some violations during deployment. I think I'm correct in assuming that the latencies are generally well within even the old threshold after that though, right?

These changes were based on the SLOs that I saw turning red on the dashboard. I didn't spend too much time looking into why the latencys are so high. It may just be warm-up costs, or it may be something else. I've been doing testing without the ratingservice for quicker deployment, so that may also be adding extra latency to the app.

In general, my thinking has been that we should use high SLO values for our sandbox dashboards instead of realistic production ones, to make sure everything looks good on a fresh deployment. Let me know if you think keeping it low is a better idea