I understand groups want their 'stuff' separate from others BUT this doesn't mean you have to create separate services. Best practice, don't create services based on how people work, create them based on their dependency of the components. You can still give them a view of their own stuff either through a Glass Table OR you can create views in Service Analyzer, Deep Dives or Episodes. Personally I like Glass tables because you can create boxes and show whatever you want based on a splunk search. Instead of dragging over a KPI that may have entities they don't care about, instead write a search pulling from itsi_summary index and filter to the entities you do care about. This allows them to see just what they care about without you breaking a service apart to accomodate how they work. Best practice, if you are measuring the same thing on 5 hosts that serve the same purpose (app servers, web servers, databases, or business service) that is one service. For entities and entity filtering you always want to try and filter by something other than a host name. If you use only a host name or even an alias with the combo of a host and something else, you move towards 'static' membership. If instead you create enrichment fields that you can then filter by, then membership becomes dynamic. For instance, if you have a host naming convention on something like this CHDBBNK3455 where the first two characters are the location (Chicago), the 2nd two are the role (Database), the 3rd are the apps it serves or service (Banking) you can regex those into new fields and create a lookup. OR if you have info from a cmdb you can create a lookup. Then you do entity import searches that are scheduled like this: index=main host=* |lookup myenrichmentdata.csv host ON host. This is basically saying..."hey lookup this is who I am, what do you know about me?" and all the fields in the lookup become enrichment in your entities. This way if you wanted to create some view based on something like Support group, you can easily filter by those fields. They become dynamic instead of static because you schedule it so when a new host starts reporting in, it too will do the lookup, pull it's new info, and then be imported in as an entity. You never want to have duplicate entites even if the name is different and the underlying 'machine' or CI is the same thing because it will throw of your aggregate health scores. Hope that helps!
... View more