Question - Best Structure for 100s of custom metric events
Closed this issue · 5 comments
Before you proceed
We are happy about your enhancement proposal, but we would like to discuss this with you. Please make sure you've opened a discussion and are creating this feature/improvement request as a result of it. Make sure to link discussion here.
Is your feature request related to a problem? Please describe.
We are working to create what we deem to be necessary shared services metrics and alerts for all of the 15+ shared services in our kubernetes clusters. We are seeing several DRY concerns in trying to structure this and wondering if we can post with monaco an array of anomoly-detection metric events which would keep our config file clean. Additionally if the templates yaml parameter in this file was a list this could also prove most useful. Most of the parameters we have are repeated.
Describe the solution you'd like
What do you suggest as a clean IaC structure for creating 100s of these alerts for our clusters? Note: The notification web hooks will be the same per environment but will change in prod.
Describe alternatives you've considered
- making template a list of json files in the config.yaml
- Making the json file an array
- tried *.json in the template of the config.yaml
- Tried different folders within our service folder where Proj --> Prometheus --> n Anomoly metric events.
Additional context
Add any other context about the feature request here.
@UnseenWizzard any recommendation here? Can you use parameters in environment sections of the manifest file?
Hi @kbocock-krg,
there is no way to map a single config to several templates.
Conceptually every config defined in a YAML matches a config created in the Dynatrace environment.
Note that especially for Settings 2.0 objects, the 'config ID' maps directly to a property used to identify these objects on the API for future updates (by setting an 'externalId' field).
So there is no way around this 1:1 relation of config to a template.
A common practice we also apply internally is defining the JSON templates once and using them in several configs - but I assume you're doing this already.
A possible solution to keeping the amount of re-defined properties to a minimum could be to define more specific/less templated JSONs - if most values are the same and meant to be the same, keep them in the JSON.
Note that it is also possible to overwrite the template as part of an environment or group overwrite.
So you could define one 'non-prod' template and a prod template.
It is not currently possible to define 'global properties' on a manifest or environment-wide level. Still, it's an improvement discussed several times already - so expect this to be possible at some point in the future.
I hope this helps and I fully understood your question/requirements
I suspect the current approach in monaco will lead to a higher big O factor and many DRY violations. We typically like our automation to be clean, methodical, and easy to maintain. I hope to see this improve soon and we will leverage jinja2 templates for now to work around this.
What is the license of monaco? Can we modify the code to allow a config to allow a list of templates and remove the need for unique id. Given monaco is just a wrapper around an interface anything is possible.
Apache 2.0
https://github.com/Dynatrace/dynatrace-configuration-as-code/blob/main/LICENSE
You're very welcome to fork and modify to your needs!
Just be aware that the config ID (or project:type:id "coordinate" tuple) is used both for identifying configs internally for references and to identify Settings 2.0 configurations (as well as upcoming Platform feature configs) on Dynatrace.
So breaking the config ID uniqueness constraint comes with quite some added dangers.
For a list of templates, our internal idea would have been a map of template ID -> file, making the template ID usable as part of still generating unique identifiers. And still allowing for files to change without impacting IDs.
If you have a good idea/solution for this that does not break current constraints, we're also always happy about contributions! :)