Page Comparison

• Communication Server <-> Agent

  • Default

    • Checkmk Server trigers Checkmk Agent on Port 6556

    • An agent reads no data from the network — full stop. Consequently it is quite impossible that an attacker could sneak any type of command or script element over the monitoring port 6556

    • SNMP v1/v2/v3
  • Secure
  • Restrict of access over IP-addresses (https://docs.checkmk.com/latest/en/agent_linux.html#security)
    • Can be solved with xinetd and systemd
  • Invoke over ssh https://docs.checkmk.com/latest/en/agent_linux.html#ssh
  • Push the data from agent to server. (https://docs.checkmk.com/latest/en/datasource_programs.html)
    
    
• PW Store

  • This password management module stores the passwords you use in your checks and special agents in a central place. Please note that this password store is no kind of password safe. Your passwords will not be encrypted.

    All the passwords you store in your monitoring configuration, including this password store, are needed in plain text to contact remote systems for monitoring. So all those passwords have to be stored readable by the monitoring.
    
    

• User and role concept
  
  • Within Checkmk you can define your own roles and restrict to specific permissions (https://docs.checkmk.com/latest/en/wato_user.html#roles)
    
    
• Distributed Monitoring (https://docs.checkmk.com/latest/en/distributed_monitoring.html#livestatus)
  
  • Communication central to remote site via tls possible
  • centralized configuration via https possible
  • Restriction of IP Addresses is possible
  • If your remote site is not directly accesible via the central Server, you can push the data from the remote to the central Server (https://docs.checkmk.com/latest/en/distributed_monitoring.html#cmcdump)
    • This is only for viewing. No actions/Notifications are possible on the central site for this remote site
  • Distributed Notifications (https://docs.checkmk.com/latest/en/distributed_monitoring.html#activatemknotifyd)
    • The slave and (notification-)master notification spoolers communicate with each other via TCP. Notifications are sent from slave to master. The master acknowledges to the slaves that the notifications have been received, which prevents notifications being lost even if the TCP connection is broken.

    • There are two alternatives for the construction of a TCP-connection:

      1. A TCP-connection is configured from master to slave. Here the slave is the TCP-server.

      2. A TCP-connection is configured from slave to master. Here the master is the TCP-server.

  • Distributed Event Console (https://docs.checkmk.com/latest/en/distributed_monitoring.html#ec)
    • • The Event Console processes syslog-messages, SNMP traps and other types of events of an asynchronous nature.
  • Checkmk Distributed Agent Bakery (https://docs.checkmk.com/2.0.0/en/agent_deployment.html#_setting_up_automatic_updates)
    • You can deploy automatic agent updates to hosts monitored by the remote site. The configuration is done by the central site. Therefore, the remote and the central site will communicate together

• Checkmk GUI
  
  • You can secure your Checkmk GUI with HTTPS (https://docs.checkmk.com/latest/en/omd_https.html)

• User management with LDAP/AD
  
  • Securing LDAP-connection with SSL (https://docs.checkmk.com/latest/en/ldap.html#ssl)
    
    
• Automatic Disk space cleanup (https://checkmk.com/de/werk/7569)
  • We have now added the functionality to cleanup the host related files to the diskspace cleanup mechanism. This mechanism is enabled by default and cleans up all files of not existing hosts that are older than 1 month by default. If you want to disable this automatic deletion or customize the time horizon, you can configure it in the global settings of WATO using the "Automatic disk space cleanup" option.

Related articles

...