Open cstegm opened 5 years ago
@cstegm this concept seems to make sense. I have a few questions about when/where, and by whom this proposed host.parents
field be populated. I assume that the host generating an event would not automatically know its parent(s).
Also, it seems that this would be an array field, possibly populated with multiple values, correct?
Hi @mikepaquette,
some additional information: We are are using ecs fieldnames to create hosttags in our statusmonitoring. The hosts are imported from a CMDB. In the CMDB the parent-child relations are documented, automatically created or found by network discovery on the monitoring server. We are also using the Elastic Stack. We assume that combining information of both worlds will be easy when using the same „language“. Ingestion-time enrichment would be a great idea. The agent will generally not know its parents or childs. Correct, an array field would be the best choice.
Hi @MikePaquette,
yes the host normally does not know its parent - especially not from a monitoring perspective. With configuration management it this field could be set or maybe fetched by the agent (on restart/reload). Ingestion-time enrichment is also a good idea, and maybe easier to implement when you dont have configuration managment for every system.
Parents should be an array field, yes.
In Monitoring it is helpful if you something about the relation of hosts from a monitoring perspective.
In order for monitoring to calculate the UNREACHABLE state, it must know how it can reach each individual host. To do this, you can specify one or more so-called parent hosts for each host. If, for example, server A can only be reached via router B from a monitoring point of view, then B is a parent of A. Only direct parents are configured. The most important task of the Parents is the detection of network failures and the avoidance of mass false alarms in such situations.
I would suggest to add a host.parents field for that to the elastic common scheme.