21 Oct 2020 07:28 PM
Hey all,
I am new to Dynatrace so I am training up on it now. I am working on a pre-existing environment. I've read the information about HostGroups and it seems like the documentation is point to the fact that HostGroups should be used defining metadata like applications. The problem in the current environment that I am having with that is that here we have some servers that are dual purposed. For example, we have IIS servers that host web frontends for applications. So for example, Server 1 could have Application 1, Application 2, and Application 3 on it but each one of those applications hook to a backend individual application server. The problem with this is that defining Server 1 with a HostGroup of "Application 1" is incorrect.
In this specific instance, it would seem that hostgroups make more sense from an environmental standpoint like production/qa/dev rather than application. The application definition seems easier to deal with using regular tags.
Does anyone have any feedback/thoughts on hostgroup usage? What is the demarcation between Tags and Hostgroups and when is it appropriate to use one over the other.
Solved! Go to Solution.
21 Oct 2020 07:42 PM
First and foremost note that the inclusion of metadata such as that in a hostgroup name is really secondary to the purpose of the affect that they have in breaking apart the environment. For example, two identical hosts with the same app running on them will result in two sets of services and process groups if they are in separate host groups. So focus on that aspect first. When coming up with the host group names themselves and extract that data when you're creating things like tags or management zones. The hostgroup is not required for the tag or zone it is just a convenient way of automating a lot of the configuration if your entire environment follows a standard (e.g. a tag rule that says 'take the first segment of the hostgroup and create an 'app' tag using that value').
Some notes:
In cases where you believe you have a segment of your hostgroup that needs to hold multiple values a common practice is instead to use something like SHARED or MULTI in place of a single app name and then you can define tags separately to specify the individual values.
21 Oct 2020 09:05 PM
> For example, two identical hosts with the same app running on them will result in two sets of services and process groups if they are in separate host groups.
This kind of touches on another issue I am having. Both my production and non production systems are in the same host group and all the services are grouped together. So for instance I know I have a production and a non production "Service X" however all of my measurables in the current system reference a single "Service X" because the hostgroup is "Application A". Application A is running on multiple systems, but some are production and some are non production. Based on what you are saying, this is because both production and non production are in the same hostgroup. Is this correct?
21 Oct 2020 09:17 PM
That's correct and is one of the main usecases for hostgroups; when prod and test are in the same environment. Host groups are the best way to handle this because they force everything to be separate, if for whatever reason you cannot do this you would need to configure a bunch of process group detection rules to separate them out based on some other value. But separate hostgroups would be preferred.
22 Oct 2020 02:44 PM
Hey James, appreciate the feedback on this. I am going to work on revamping the hostgroup configurations for my environment. It appears like whoever originally set these up did not quite understand OR didn't have the need to separate the environments out. I will need to do a deep dive on the system and try to figure out if the hostgroups are being used in any other way, but for the most part it seems like all production and non production systems share the same application name which is represented by a single hostgroup. Most of the metrics that are being gathered are therefore combining information from both environments which is creating inaccurate metrics due to how regression testing in development works. I believe our what we interpret to be our production metrics are being way over inflated.
Thanks again for your help! I really appreciate it.