Is there possible to enable infrastructure monitor based on the OS type?

[joanne_quan]

hello,

We have oneagent deployed on both linux and Windows servers; however, the base monitors (CPU, memory, etc) for  Windows servers will be monitored by SCOM and Linux servers will be monitored by Dynatrace.  Is it possible to enable the infrastructure monitors base of the OS type?  so infrastructure alerts for Windows servers will never generated problem record even though infrastructure monitors are enable at the global level.

Thanks in advance for your response 

[natanael_mendes · Accepted solution]

i think its not possible but you can do this configuration with the host group anomaly detection

[cesarsaravia · Accepted solution]

Yes! You can disable the anomaly detection for infra using the Host Group by OS for example. 
Another option is creating an Alerting profile for Windows which doesn't notify for specific OS tag rules like infra CPU, memory, and disk. In this case, you still have problems in Dynatrace but are not integrated with another ITSM, Event tool, or email team.

[joanne_quan]

Thanks for your reply 

[joanne_quan]

Thanks for your reply....it seems like there is only way to disable the infra abnormally detection based on host group;  that means we will define a host group based on the OS 

1.  is there a quick way to add the hostgroup based on OS type

2.  is there a way to add the OS hostgroup at the installation of the OneAgent?

Also, we have the similar situation for the network zone (i.e. aws/ on-prem);  i think we will have to define  the host group for the network zone as well if we do not want the alert on aws servers.

Thanks,

Joanne

[SjoerdB · Accepted solution]

Hi Joanne,

It is always a good practice to immediately assign host groups to your hosts. As you can find in the documentation, you can do this either during the installation of the oneagent (--set-host-group=XYZ) or with the oneagent commandline tool afterwards (oneagentctl).

Host Groups are not only important for anomaly detection settings for groups of servers, but you can also determine a number of other settings (like automatic agent updates / logmonitoring / OS process monitoring / naming / etc). Also you can use the hostgroup in various configurations as filter.

In my projects I tend to use strict naming policy for the hostgroups, so that I can also use them for tagging.

What I could suggest for you is using a naming like e.g.:

<DC>.<OS>.<ENV>.<FUNCTION>

• DC=ONPREM/AWS/GCP/...
• OS=WIN/LIN/...
• ENV=PROD/TEST/ACC/...
• FUNCTION=FRONTEND/DB/BACKEND/...

So: ONPREM.LIN.PROD.BACKEND or AWS.WIN.TEST.FRONTEND

If you have a larger landscape with multiple dedicated servergroups for specific application landscape, it also makes sense to add a Application/landscape to the HostGroup name, because in that way you can differentiate between servers running your GOLD applications to have other rules than the "internal tools" servers.

Of course you could use any schema, as long as you are consistent in naming, so that you can re-use the information in tags (think of an automated tag "Environment" with the regexp value of the third field in the HostGroupName).

The good thing is that you can embed this logic in the installscripts of your servers, so that you can always rely on the correct values.

Just my 2ct 😉

https://www.dynatrace.com/support/help/platform-modules/infrastructure-monitoring/hosts/configuratio...

https://www.dynatrace.com/support/help/setup-and-configuration/dynatrace-oneagent/oneagent-configura...

So in short the answer to your question 1+2: you can add the hostgroup definition to the installer scripts you use to roll-out the agents on your platform.

[joanne_quan]

Thanks cesarsaravia and SjoerdB for your insights on the topic;  it is really helpful