Thanks, I think it was mostly my understanding of the documentation/process was off. will try to distill the major points.
Background: I have CIFS/NFS shares mounted on many systems. I can’t monitor the actual NFS/CIFS servers. A single CIFS/NFS share may appear as services attached to several (e.g., 30x) hosts. So if the share has a problem, I currently receive say 30x notifications, one from each service. So I am leveraging BI to aggregate the services for the same share so that I only receive minimal notifications if say a CIFS/NFS share has issues:
- Create a “BI pack”:
- Click on the “scroll” icon to access the content of the BI pack:
- Add a rule for a monitored CIFS share (service): I used a host regex (e.g., .*[.]mn[.]edu$) so I don’t have to add say 30x child nodes for the “State of a service”. In the “Aggregation Function” section, I used “Worst - take worst of all node states” and “Take n’th worst state for n =1” so that even if one of the hosts has issues with the share, I get notified for that host/service.
- Create a BI aggregate to use the rule (click on the “Aggregations” Icon) I just created:
- Click the “Add aggregation” icon: “Add new element”, then used “Create nodes based on a service search” AND set the “Rule” to the rule I created in the previous step (this was the most important piece I was missing).
- Create a rule to “monitor” the aggregate(s): “Setup” > “Agents” > “Other integrations” > “BI Aggregations” > “Add rule”. Used most of the recommended defaults, and in the “Conditions” section, I set the “Explicit hosts” option to a “dummy” host I had created to represent the CIFS server. This host has its IPv4 address set to 0.0.0.0 and Monitoring Agents settings set to “No API integrations, no Checkmk agent”. I also added a “host monitoring rule” that indicated this host is “Always Up”.
- Create a notification rule for the aggregate(s): I used the “Match services” option in the “Conditions” section, and attached the services that were aggregated e.g., “CIFS mount /integration$”