Stackdriver Dashboards

[danawillow]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

https://cloud.google.com/monitoring/api/ref_v3/rest/v1/projects.dashboards

New or Affected Resource(s)

• google_monitoring_dashboard

Potential Terraform Configuration

# Propose what you think the configuration to take advantage of this feature should look like.
# We may not use it verbatim, but it's helpful in understanding your intent.

References

• b/123069109

[drigz]

Once a dashboard has been created in the Cloud Console, dashboards.get can retrieve a JSON representation. If google_monitoring_dashboard accepts a JSON file/string for the dashboard, it would be possible to migrate an existing dashboard into Terraform by getting it with curl, removing name/etag, and creating Terraform configuration that references this JSON. Example:

resource "google_monitoring_dashboard" "default" {
  dashboard = file("path/to/dashboard.json")
}

Maybe a field display_name could override the values in the JSON.

IMO this would be easier than rewriting the dashboard configuration in HCL, although I couldn't find an existing resource that follows this pattern (google_bigquery_table's schema is similar).

[danawillow]

If we add import support, would that resolve your concerns? People often use Terraform in order to standardize the process for their teams to not use the console, ever, and so requiring creating one in the console first before exporting it to Terraform feels not great.

[drigz]

How would the import workflow work? I haven't used it extensively, but the phrase "prior to running terraform import it is necessary to write manually a resource configuration block for the resource" would suggest I'd still have to write a complete configuration.

While I also prefer to use Terraform instead of the console, in the case of creating/tweaking a graphical dashboard I would prefer edit-view-repeat to edit-apply-refresh-view-repeat. Of course, handwriting or editing the JSON would be similar editing the dashboard in Terraform config.

My use case would require code review of edits to dashboards, restoring modified dashboards to a known state, and potentially installing the same dashboard to multiple projects. Caveat: I'm currently planning on doing this with Grafana instead, so it would be worth checking instead with the users that are actively using Stackdriver Dashboards and want to use Terraform for them.

[danawillow]

I agree that it would be worth getting opinions from Terraform users on this pattern, since it's super uncommon across providers.

[drigz]

I have contacted three Terraform users who requested this feature. The two that responded prefer the UI+JSON workflow. How does affect the issue size/priority?

I proposed the following workflows:

Stackdriver UI workflow:

• Create and preview dashboard in Stackdriver UI.
• Export dashboard to JSON.
• Add dashboard JSON to Terraform configuration.
• Run terraform import.

Terraform-only workflow:

• Create dashboard with text editor in Terraform configuration.
• Run terraform apply.
• View dashboard in Stackdriver UI, iterate if necessary.

Terraformer + Terraform workflow:

• Create and preview dashboard in Stackdriver UI.
• Run terraformer to auto-generate Terraform configuration and state.

Response from developer advocate:

My sense is that a typical user would want to start in the Stackdriver UI to create a dashboard and adjust as necessary before exporting for use by and/or additional manipulation in Terraform.

This UI would also get you the terraform-only workflow as a developer could just write the json based on their knowledge of the expected structure.

Terraformer looks really cool but I would prioritize any work there for after the UI export to JSON > use that JSON in terraform flow has been shipped.

Response from GCP customer:

From our perspective the preferred way of working with Stackdriver dashboards is the first one (Stackdriver UI Workflow) as this is how we work at the moment except that instead of terraform we use custom scripts to import dashboard JSON files using the API.

[matthias-froomle]

I have contacted three Terraform users who requested this feature. The two that responded prefer the UI+JSON workflow. How does affect the issue size/priority?

I proposed the following workflows:

Stackdriver UI workflow:

• Create and preview dashboard in Stackdriver UI.
• Export dashboard to JSON.
• Add dashboard JSON to Terraform configuration.
• Run terraform import.

Terraform-only workflow:

• Create dashboard with text editor in Terraform configuration.
• Run terraform apply.
• View dashboard in Stackdriver UI, iterate if necessary.

Terraformer + Terraform workflow:

• Create and preview dashboard in Stackdriver UI.
• Run terraformer to auto-generate Terraform configuration and state.

Response from developer advocate:

My sense is that a typical user would want to start in the Stackdriver UI to create a dashboard and adjust as necessary before exporting for use by and/or additional manipulation in Terraform.
This UI would also get you the terraform-only workflow as a developer could just write the json based on their knowledge of the expected structure.
Terraformer looks really cool but I would prioritize any work there for after the UI export to JSON > use that JSON in terraform flow has been shipped.

Response from GCP customer:

From our perspective the preferred way of working with Stackdriver dashboards is the first one (Stackdriver UI Workflow) as this is how we work at the moment except that instead of terraform we use custom scripts to import dashboard JSON files using the API.

I would still prefer the Terraform-only workflow for 2 reasons:

• It enables the definition of charts in terraform syntax which is consistent with the way the google_monitoring_alert_policy resource works
• It allows for easier interpolation of chart parameters such as filters

[danawillow]

Is the developer advocate a terraform user, or someone from the product side? Just want to get a sense of whether their opinion is coming from their expectations of how users use a product or whether it's because they actively are using it.

Regardless, it probably makes sense to have the json ability, but it might make sense to also have a resource that allows for HCL, which makes it easier for our customers to use interpolation and also makes it easier for us to add plan-time checks (rather than just sending over a json blob and waiting for the API to tell us whether or not it's valid).

[drigz]

Is the developer advocate a terraform user, or someone from the product side?

I don't know, although looking at their comments again, I don't get the impression they're heavy user.

[c2h5oh]

@drigz As Stackdriver user I would strongly prefer HCL approach despite the fact I don't like HCL. Console UI-first approach is a bad idea:

1. Console UI constantly lags behind APIs, by a lot.
2. In large enterprise setups number of employees that get any kind of write access to cloud stuff is tiny compared to the number of devs that can open a pull request. Making dashboards is way below pay grade of those with access to make changes via console.
3. If I want to deploy same dashboard for different environments (with env-specific parameters) I'll have to make a template from the exported dashboard json. This is anything but pleasant with HCL except for the simplest of cases. Combined with previous argument about who has access it introduces another problem: how do I know how to hand-create json for something new I want to add if I can't first create it from UI and export?
4. Console UX is meh at best. Ie when creating a chart in a dashboard resource and metric selection is dumb - I have a small handful of resources / metrics, yet I have to go through a list that includes everything and a kitchen sink. Sure filtering as you type helps. but even narrowing to GCE VMs and typing memory leaves you with 20+ entries to select from, because obviously riak, memcached, redis, jvm, elastic search and everything else has to be included despite never having been reported (0 data points).
5. Console performance is really bad and not just on my rather good work laptop with integrated graphics - even on my home water cooled 12 core/24 thread cpu + 1080ti + gigabit connection in the same region as the zone I'm working on. It's not uncommon for me to see it being unresponsive for 3-10 seconds at a time (latest Firefox, the only addon: ublock origin) - sometimes blocking on CPU, other times on network (response times, number of connections), especially if I have different parts of console open in more than one tab.

[ocervell]

@c2h5oh agree with you. I think the HCL approach does make sense. Note that in this approach, we can still download a JSON dashboard and jsondecode it to HCL before passing it to the resource, so both workflows would work.

[megan07]

After some discussion we've decided we might just take the json approach where you can download it from the console and paste it into the HCL. If we went with an HCL approach, this resource would be by far the largest with number of fields and the amount of nesting, the json approach allows us to implement this much faster so users can start using it.

[danawillow]

Hey all, sorry to keep going back and forth on this one. After talking to the Stackdriver team, it sounds like the question of which approach to go with is no longer set in stone, and we'd like to take some more time to think this through.

As usual, if you have preferences that haven't yet been voiced (around the implementation specifically, not just that you want support for the resource), feel free to comment! In the meantime, I moved this back into the Near-Term Goals milestone since we'd like to start working on this soon, but can't actively work on it at the moment.

[george-harness]

If the JSON approach, what will be my options to impact the JSON content based on variables, etc. Would I need to build the whole JSON with string operations?

[danawillow]

You should be able to do it with templatefile and/or jsonencode: https://www.terraform.io/docs/configuration/functions/templatefile.html

[george-harness]

then, please do whatever is faster, I really hate that I have to write shell scripts for this

[luismendezescobar]

So, is anyone developing a new google provider to create stack driver dashboards using HCL terraform?

[ankit-ghub]

I am quite new to gcp and terraform, it seems like google_monitoring_dashboard is till in development and has not yet released for integrating stackdriver dashboard in gcp using terraform. Is my understanding correct ? Or if I can use it and test it ?

[danawillow]

That's correct! The linked PR is currently out for review. If you wanted to try it out, you could check out https://github.com/modular-magician/terraform-provider-google-beta/tree/auto-pr-3490 and then build the provider on your own, but I'm not going to get into the details of how to do that here (basically, clone the modular-magician fork, check out the branch, and run make. there's some more details in CONTRIBUTING.md).

Our documentation at https://www.terraform.io/docs/providers/google/index.html is up to date with what has been released, and you can also always take a look at the https://github.com/terraform-providers/terraform-provider-google/blob/master/CHANGELOG.md to know as well.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!