You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Ability to define dashboards (and perhaps alerts, but not much more) via Kubernetes manifests and having them managed via dynatrace-operator would be very beneficial to many teams offering Kubernetes-based PaaS-like solutions.
The rationale is that the teams often provide helm charts or other forms of Kubernetes manifests and dashboards for their team-specific data are often part of the application definition.
Grafana operator currently supports this.
I think this should be mainly dashboards and perhaps custom alerts for business metrics.
Most other settings (such as connections to cloud accounts, management zones, settings) are often part of platform definition and are much easier to manage with existing tools such as Terraform and dynatrace provider. However, Terraform is a very specific tool and provides a significant learning curve. It's also meant to be set up in a centric way.
K8s manifests are often very native for engineering teams building K8s-based applications. As the dashboards are app-specific, it'd also be more convenient to have the app-specific dashboards as part of application, not part of platform definition.
Describe the solution you'd like
Ability for dynatrace-operator to create, update and delete dashboards based on Kubernetes manifests.
This could either be a CRD or, in a simpler version, a ConfigMap with specific labels. The namespaces and/or labels to watch could be defined in DynaKube object.
Describe alternatives you've considered
Using Terraform with the dynatrace provider was considered, but it was problematic to integrate.
Migrating away from grafana-operator, there's already an expectation or hope that dashboards could remain K8s manifests and part of application definition.
Additional context
This was already requested 2 years ago in #500, but I wanted to raise it again with a rationale behind the request.
The text was updated successfully, but these errors were encountered:
Thank you for opening a Dynatrace Operator Issue. We've identified and tagged the issue as a "Feature request".
Dynatrace reviews feature requests in the Dynatrace community rather than Github. This helps our team consolidate, rank, and prioritize important input like yours.
Please search for similar requests, collaborate, and ask questions using the link above. Remember to add the labels "kubernetes" and "dynatrace-operator" to help get the attention you deserve.
Is your feature request related to a problem? Please describe.
Ability to define dashboards (and perhaps alerts, but not much more) via Kubernetes manifests and having them managed via dynatrace-operator would be very beneficial to many teams offering Kubernetes-based PaaS-like solutions.
The rationale is that the teams often provide helm charts or other forms of Kubernetes manifests and dashboards for their team-specific data are often part of the application definition.
Grafana operator currently supports this.
I think this should be mainly dashboards and perhaps custom alerts for business metrics.
Most other settings (such as connections to cloud accounts, management zones, settings) are often part of platform definition and are much easier to manage with existing tools such as Terraform and dynatrace provider. However, Terraform is a very specific tool and provides a significant learning curve. It's also meant to be set up in a centric way.
K8s manifests are often very native for engineering teams building K8s-based applications. As the dashboards are app-specific, it'd also be more convenient to have the app-specific dashboards as part of application, not part of platform definition.
Describe the solution you'd like
Ability for dynatrace-operator to create, update and delete dashboards based on Kubernetes manifests.
This could either be a CRD or, in a simpler version, a ConfigMap with specific labels. The namespaces and/or labels to watch could be defined in DynaKube object.
Describe alternatives you've considered
Using Terraform with the dynatrace provider was considered, but it was problematic to integrate.
Migrating away from grafana-operator, there's already an expectation or hope that dashboards could remain K8s manifests and part of application definition.
Additional context
This was already requested 2 years ago in #500, but I wanted to raise it again with a rationale behind the request.
The text was updated successfully, but these errors were encountered: