[Check_mk (english)] Check_MK Infra Queries

Archive checkmk-en
1

Hello Team,

I have a few open points that I would like to discuss in
this round in regards to the use of CheckMK monitoring. Please feel free to correct any points you feel that need to be corrected.

Firstly, the installation and distribution of the agent will
be automated. The configuration and Host registration has to be completed via
CheckMK portal, as well as moving the Host to its respective folder and applying
the required ruleset to achieve effective monitoring.

Secondly, there should be a specific service account used
for the agent itself, to prevent any security vulnerabilities connected to
using the local system account. I am suggesting either MSA (managed service
account) which requires domain functional level 2008 R2 or gMSA (group managed
service account) that requires domain functional level 2012 R2 and higher. From
these two options the obviously simpler to use and set up would be gMSA as this
could be a single service account used for all hosts. This service would also
gain the read rights to specific objects and databases in MS SQL, interactive
logon will be disabled. The biggest advantage of this setup is that there is no
need to manage passwords as the domain will fulfill this role.

Thirdly, we should have a standard way of building
infrastructure for the purpose of enabling monitoring. As an addition to this
standard I would like to suggest that there will be a “Slave” CheckMK
monitoring site for each customer per environment, in most cases this would
result in 3 monitoring sites per customer (PROD, REF/UAT, TEST/SIT). By
following this setup we would not need to request FW rules for each new or
already existing Host, but instead only allow the “slave” monitoring site
server to communicate with the “master” monitoring site server on port 6556.

Hope for a quick Reply…

···

Regards,

Sandeep Kumar Ballari

2

Hi Sandeep,

Firstly, the installation and distribution of the agent will be
automated. The configuration and Host registration has to be completed
via CheckMK portal, as well as moving the Host to its respective folder
and applying the required ruleset to achieve effective monitoring.

Installation of the agent is outside the scope of a monitoring system.
The agent comes packaged so that an existing software deployment process
can use it for the distribution.

As the agent itself is read-only there can never be a host registration
process out of the checkMK web portal. This is also a taks of your
software deployment processes.

How should checkMK know which folder is the destination of the newly
created host? This information also comes from the outside.

CheckMK does automatically apply all matching configuration rules.

All of the steps above can be automated via checkMK WATO API. As checkMK
is running on a diverse set of infrastructures this has to be customized
each time.

Secondly, there should be a specific service account used for the agent
itself, to prevent any security vulnerabilities connected to using the
local system account. I am suggesting either MSA (managed service
account) which requires domain functional level 2008 R2 or gMSA (group
managed service account) that requires domain functional level 2012 R2
and higher. From these two options the obviously simpler to use and set
up would be gMSA as this could be a single service account used for all
hosts. This service would also gain the read rights to specific objects
and databases in MS SQL, interactive logon will be disabled. The biggest
advantage of this setup is that there is no need to manage passwords as
the domain will fulfill this role.

You can already let the agent run under an account different from root
or LOCAL SYSTEM. This is just a configuration issue. But you may need to
tweak settings on the monitored host so that the agent still is able to
collect data. Your MS SQL example is one of these.

Thirdly, we should have a standard way of building infrastructure for
the purpose of enabling monitoring. As an addition to this standard I
would like to suggest that there will be a “Slave” CheckMK monitoring
site for each customer per environment, in most cases this would result
in 3 monitoring sites per customer (PROD, REF/UAT, TEST/SIT). By
following this setup we would not need to request FW rules for each new
or already existing Host, but instead only allow the “slave” monitoring
site server to communicate with the “master” monitoring site server on
port 6556.

This is basically distributed monitoring which is built into checkMK's
multisite web application from the start.

Kindest Regards

···

Am 14.12.19 um 12:42 schrieb sandeep kumar:
--
Robert Sander
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

Tel: 030 / 405051-43
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin

3

Hi Team,
As per my query listed can You provide me a solution & information I.e document/link on how it can be managed.

We should have a standard way of building infrastructure for the purpose of enabling monitoring. As an addition to this standard I would like to suggest that there will be a “Slave” CheckMK monitoring site for each customer per environment, in most cases this would result in 3 monitoring sites per customer (PROD, REF/UAT, TEST/SIT). By following this setup we would not need to request FW rules for each new or already existing Host, but instead only allow the “slave” monitoring site server to communicate with the “master” monitoring site server on port 6556.

Regards,

Sandeep Kumar Ballari

···

Regards,

Sandeep Kumar Ballari