We have multiple sites running on the same server using Check MK 2.0.0p31. The Check MK server itself can send out SMS messages using a mobile phone and we have looked at using logwatch to monitor any issues with sending the SMS messages. More than one site has the checkMK server configured as a host so that the dashboard will show the stats for that team’s Check MK site. This results in logwatch resetting the errors it finds depending on which site telnets first after an error occurs and then doesn’t show up on the other site.
I noticed that $REMOTE can be used but I don’t quite understand how this works or could help us here as the IP is the same and so is the remote hostname.
Is there a way that 2 sites on the same server can check a single agent without issues with Logwatch?
Is there a way that 2 sites on the same server can check a single agent without issues with Logwatch?
No.
You need to setup 2 Agents on the mention host as well and you have to take care the agents did not share any directories.
BTW: The mention setup did not make any sense for me, most likely there is a better approach to achieve the needs.
E.g. Distributed Monitoring Setup / CMC Dump / etc.
Sorry If I was not clear… We have one Check MK Server. It hosts a site for a server team and a separate site for a networks team. Both sites have the check MK server as a host so that the main dashboard page can show the site stats.
Personally I see more issues as benefits with such a setup. For me it don’t make sense. CheckMK already has a good Multi User functionality included.
It is recommended to assign Systems to a Group/Users and create Dashboards and Views for Group/Users. So different Teams of course can have different Dashboards.
Thanks both. Architecturally I would agree with you, practically this wasn’t really possible at the time. Really this should be 2 separate servers for performance (once site has 25,000 SNMP services across 100 devices) and the other is about 54,000 services across agents 800 agents. Hardware availability was limited at the time and migration to new hardware was pencilled “in the future” so having a site that could be backed up and moved easily to a new server was the main driver I believe (I inherited this setup) but the hardware never materialised. Sounds like I have another good reason to push for the new hardware for the more intensive site (with the SNMP counters that we host for our network team) as well as separating them onto new hardware just for performance.