kubernetes-mixin VS dhall-aws-cloudformation

I'd suggest looking at the queries used by the kubernetes mixin dashboards for inspiration.

Came across this lib, but realized the last update was 4 years ago.

Take a look at the kubernetes mixins to get an idea and/or starting point

The last step is to use the Mixin dashboard to visualize the usage of PV, you can get it from here

It's working good so far, except for the annoying CPUThrottlingHigh alert that is firing for many pods (including the own Prometheus' config-reloaders containers). This alert is currently under discussion, and I want to silence its notifications for now.

I think it might still have issues figuring out that it needs to apply CRDs first: https://github.com/grafana/tanka/issues/246 Besides that, I found it super-handy for deploying https://github.com/prometheus-operator/prometheus-operator and https://github.com/kubernetes-monitoring/kubernetes-mixin

These all standard dashboards are basically generated from the kubernetes-mixin project.

I would suggest looking at the Kubernetes Mixin: https://github.com/kubernetes-monitoring/kubernetes-mixin, it has both alerts and Grafana dashboards.

I have been writing a fair amount of Dhall using autogenerated CloudFormation bindings ( https://github.com/jcouyang/dhall-aws-cloudformation/ ). It is a fantastic way to reduce boilerplate and factor out recurring blobs. My main frustration is that the type checker is not smart enough (or maybe the type system is undecidable?) - every time you want to use a polymorphic function, you must pass in the type parameters yourself (this is also true for empty lists and `None`). This makes simple FP idioms extremely noisy, to the point where you're better off writing longhand. In a language that's meant to be alleviating YAML/JSON boilerplate.

It's still a massive improvement, but it could be so much better if the typechecker was smarter.