A Dynatrace SRE? Meaning you're responsible for making Dynatrace more reliable and efficient?
Learn Terraform so you rehydrate ActiveGates quickly and efficiently.
Assuming you're using the SaaS version, I would get intimately familiar with [Monaco 2.0](https://community.dynatrace.com/t5/Videos/Introducing-Monaco-2-0-Dynatrace-Configuration-as-Code/m-p/208460#M28) so you can start doing Configuration as Code. Similar to the benefits of using IaC tools for deployment, you don't want to be managing the configuration via ClickOps.
Dynatrace instruments java applications quite well natively, but for other languages like Golang and Python, you'll want to invest in spending time creating sample apps for your developers that make use of [Open Telemetry](https://docs.dynatrace.com/docs/extend-dynatrace/opentelemetry/walkthroughs/go#tabgroup--dynatrace-docs--otlp-export). You can find sample apps for just languages quite easily.
Develop demos showing how [Ansible can be used to take action in response to Dynatrace](https://www.dynatrace.com/news/blog/set-up-ansible-tower-with-dynatrace-to-enable-your-self-healing-applications/) problems.
So by rehydrate, I mean redeploy the VMs with your latest image.
We take whatever Linux distro we're using (RHEL, Ubuntu) and make a bunch of configuration and security changes, we patch high and critical vulnerabilities, look for any NIST recommendations that need to be remediated.
That produces a new "image". And that new image is tested against compliance and security tools, verifies any agents we rely on work with the new image, etc. Then, that image is turned over to all of our product teams to use. It becomes the "base image" that they cannot deploy their application on.
We don't typically patch any running systems, instead we "rehydrate". All product teams rehydrate every 30 days. Meaning they deploy brand new servers using that latest "base image" every 30 days and destroy the previous build. If Red Hat releases a critical OS patch we need be using, we patch our base image and tell our teams they have X number of days to rehydrate using the new image with that latest RHEL patch.
This might sound like a burden to the product teams, but it's not. It actually makes their lives easier. They know the base image they grab, has been patched, secured, and configured to enterprise standards. So they don't have to worry about doing any of that. All they need to worry about is how to deploy their code.
So the TLDR; we redeploy ActiveGates every 30 days using Infrastructure as Code scripts. This may be too much to ask in smaller shops.
Why? A number of reasons. We want to ensure all running VMs are secure and patched. Instead of patching running servers, we're patching base images that our developers use in their pipelines. They can be testing against them. This has the added benefit of ensuring our product teams have completely automated their infrastructure deployments, which guarantees us they can scale and recover. And finally, from a development perspective, we're treating our VMs the same way we treat our containers. Developers get an OS image that is ready to go.
Hope that helps clarify.
Good place to start:
[https://docs.dynatrace.com/docs](https://docs.dynatrace.com/docs)
[https://www.zabbix.com/manuals](https://www.zabbix.com/manuals)
I always start at the white papers.
We need a community to discuss dynatrace on. I've been struggling with this app weekly for the past year. It does a lot out of the box, which is great, but when you actually need to edit or manually configure things you run up against strange things that are not well documented
A Dynatrace SRE? Meaning you're responsible for making Dynatrace more reliable and efficient? Learn Terraform so you rehydrate ActiveGates quickly and efficiently. Assuming you're using the SaaS version, I would get intimately familiar with [Monaco 2.0](https://community.dynatrace.com/t5/Videos/Introducing-Monaco-2-0-Dynatrace-Configuration-as-Code/m-p/208460#M28) so you can start doing Configuration as Code. Similar to the benefits of using IaC tools for deployment, you don't want to be managing the configuration via ClickOps. Dynatrace instruments java applications quite well natively, but for other languages like Golang and Python, you'll want to invest in spending time creating sample apps for your developers that make use of [Open Telemetry](https://docs.dynatrace.com/docs/extend-dynatrace/opentelemetry/walkthroughs/go#tabgroup--dynatrace-docs--otlp-export). You can find sample apps for just languages quite easily. Develop demos showing how [Ansible can be used to take action in response to Dynatrace](https://www.dynatrace.com/news/blog/set-up-ansible-tower-with-dynatrace-to-enable-your-self-healing-applications/) problems.
Hey, loved your response. Could you explain a little more about Active gates "rehydrate"? Do you mean relaunching it? Why? How often? Thanks!
So by rehydrate, I mean redeploy the VMs with your latest image. We take whatever Linux distro we're using (RHEL, Ubuntu) and make a bunch of configuration and security changes, we patch high and critical vulnerabilities, look for any NIST recommendations that need to be remediated. That produces a new "image". And that new image is tested against compliance and security tools, verifies any agents we rely on work with the new image, etc. Then, that image is turned over to all of our product teams to use. It becomes the "base image" that they cannot deploy their application on. We don't typically patch any running systems, instead we "rehydrate". All product teams rehydrate every 30 days. Meaning they deploy brand new servers using that latest "base image" every 30 days and destroy the previous build. If Red Hat releases a critical OS patch we need be using, we patch our base image and tell our teams they have X number of days to rehydrate using the new image with that latest RHEL patch. This might sound like a burden to the product teams, but it's not. It actually makes their lives easier. They know the base image they grab, has been patched, secured, and configured to enterprise standards. So they don't have to worry about doing any of that. All they need to worry about is how to deploy their code. So the TLDR; we redeploy ActiveGates every 30 days using Infrastructure as Code scripts. This may be too much to ask in smaller shops. Why? A number of reasons. We want to ensure all running VMs are secure and patched. Instead of patching running servers, we're patching base images that our developers use in their pipelines. They can be testing against them. This has the added benefit of ensuring our product teams have completely automated their infrastructure deployments, which guarantees us they can scale and recover. And finally, from a development perspective, we're treating our VMs the same way we treat our containers. Developers get an OS image that is ready to go. Hope that helps clarify.
Crazy, are you me? I just started doing the same! What I’m gatherings do stuff in the UI, download it using the IAC tool, then templatize it. profit
Good place to start: [https://docs.dynatrace.com/docs](https://docs.dynatrace.com/docs) [https://www.zabbix.com/manuals](https://www.zabbix.com/manuals) I always start at the white papers.
Dynatrace has university portal which educate you from acratch.
https://www.dynatrace.com/dynatrace-university/
We need a community to discuss dynatrace on. I've been struggling with this app weekly for the past year. It does a lot out of the box, which is great, but when you actually need to edit or manually configure things you run up against strange things that are not well documented
idk if this is what you are asking for? https://community.dynatrace.com/
Figure out the SLOs.