Glosario

Los cambios en la configuración solo surten efecto en la monitorización después de haber sido activados en un segundo paso; de forma similar a como lo manejan los programas de partición, por ejemplo: configurar, check, aplicar.

Más información en Activar cambios.

Una comprobación activa es un pequeño programa o script que establece una conexión directa con un servicio en la red o en internet, desde donde consulta los datos de monitorización. Las comprobaciones activas se utilizan para servicios basados en red como HTTP, SMTP o IMAP, por ejemplo, check_http para consultar páginas web. Una comprobación activa maneja tanto la colección como la evaluación de los datos. Esto difiere de un check plugin, que a veces se denomina comprobación pasiva, ya que una comprobación pasiva solo evalúa los datos existentes.

Más información en Monitorización de servicios de red (Checks activos).

En las ediciones comerciales, el actualizador de agentes es un plugin de agente que permite actualizar los agentes automáticamente.

Más información en Actualizaciones automáticas de agentes.

En las ediciones comerciales, Agent bakery se utiliza para empaquetar agentes de forma individual y, como opción, los paquetes también se pueden distribuir automáticamente.

Más información en Agent bakery.

Un agente en un host recopila datos relevantes para la monitorización. El agente puede ser un pequeño programa instalado en el host (el agente Checkmk), un agente SNMP que se ejecuta de forma independiente de Checkmk en el host, un agente especial que obtiene la información a través de una API proporcionada por el sistema de destino, o una comprobación activa que consulta servicios basados en red.

Más información en Agentes de monitorización.

En algunos sistemas, no se puede instalar el agente Checkmk habitual y SNMP no está disponible (de forma satisfactoria). En su lugar, estos sistemas ofrecen API de gestión basadas en Telnet, SSH o HTTP/XML. A través de un agente especial que se ejecuta en el servidor Checkmk, Checkmk consulta estas interfaces, integrando el host en Checkmk a través de la API.

Más información en Agentes especiales.

El appliance físico es un servidor de 19" con firmware preinstalado y preparado para Checkmk que se puede distribuir de inmediato en centros de datos. Viene con una interfaz de configuración gráfica que elimina la necesidad de tener conocimientos de Linux.

Más información en Appliance físico.

El appliance virtual es un sistema creado para VirtualBox o VMware ESXi con firmware preinstalado preparado para Checkmk. Incluye una interfaz de configuración gráfica que elimina la necesidad de tener conocimientos de Linux.

Más información en Appliance virtual.

La barra de navegación es el panel de navegación principal de la interfaz de Checkmk, situado en el lado izquierdo y que contiene, entre otras cosas, los menús «Monitor», «Setup» y «Customize».

Más información en La barra de navegación.

La barra lateral se puede mostrar desde la barra de navegación con un clic del ratón. Los usuarios pueden añadir varios snap-ins a la barra lateral para facilitar la navegación o para ver datos de estado importantes de un vistazo.

Más información en Barra lateral.

La Business Intelligence en Checkmk permite mostrar claramente el estado general de una vista general de nivel superior derivada de muchos valores de estado individuales. Este nivel superior puede ser una agrupación abstracta de componentes individuales o una aplicación crítica para el negocio. Por ejemplo, el estado de una aplicación de correo electrónico, compuesta por varios hosts, switches y servicios como SMTP e IMAP, se puede combinar en una única vista. Aquí también es posible formular consideraciones completamente intangibles y no técnicas, por ejemplo, la disponibilidad a tiempo de un producto que se va a entregar: Este objetivo se encuentra en el futuro y depende de muchos factores, como la cadena de suministro, el funcionamiento fiable de la producción, el personal disponible, etc. Cualquier amenaza a este objetivo abstracto podría identificarse y registrarse a través del módulo de BI.

Más información en Business Intelligence (BI).

En Checkmk, una comprobación es un script o programa que evalúa un host o servicio según reglas predefinidas, es decir, el proceso que determina el estado de los hosts y servicios y que da como resultado la visualización de un estado de OK , DOWN , UNREACH , WARN , CRIT , PEND o UNKNOWN. Las comprobaciones se pueden implementar, por ejemplo, con un check plugin, una local check o una comprobación activa.

Más información en Checks.

Los check plugins son módulos escritos en Python que se ejecutan en el site de Checkmk y que crean y evalúan los servicios de un host. Por ejemplo, el check plugin df, que se encuentra en un site en ~/local/lib/python3/cmk_addons/plugins/<plug-in_family>/agent_based/ (si usas la API de comprobación V2) o en ~/local/lib/check_mk/base/plugins/agent_based/ (si usas la API de comprobación V1), crea servicios para los sistemas de archivos montados existentes de un host basándose en los datos de un agente del site, y comprueba esos servicios con respecto a esos datos, como por ejemplo cuánto espacio libre queda.

Más información sobre los check plugins.

Una configuración de «Configuración Rápida» consta de cuatro componentes que ya conoces como partes individuales de la configuración de un site de Checkmk. Los componentes son una regla para el agente especial correspondiente, un host, una conexión en la administración dinámica del host y una entrada en el almacén de contraseñas.

Un conjunto de reglas se aplica a un aspecto específico de un host o servicio, como los umbrales de carga de la CPU. Se puede crear cualquier número de reglas individuales dentro de cada conjunto de reglas. Por ejemplo, el conjunto de reglas «CPU utilization on Linux/Unix» podría contener dos reglas que establezcan el estado del servicio como «WARN» al 90 % en ciertos hosts y tan bajo como el 70 % en otros.

Más información en Tipos de conjuntos de reglas.

A la hora de supervisar hosts y servicios, Checkmk se centra en los estados. La Consola de eventos es el módulo que, por el contrario, se encarga de los eventos, es decir, de la monitorización a partir de fuentes como syslog o Traps SNMP, pero opcionalmente también del Registro de eventos de Windows, archivos de registro y aplicaciones propias. Un ejemplo: un mensaje de advertencia del servicio SMTP en un servidor de correo no cambiaría el estado de su host o de sus servicios, pero sigue siendo información relevante que debe incluirse en la monitorización. La Consola de eventos se puede utilizar para registrar y mostrar dichos eventos en Checkmk.

Más información en La consola de eventos.

Los contactos son usuarios de Checkmk responsables de hosts y servicios específicos. La asignación de contactos a hosts y servicios se realiza a través de grupos de contacto. Los contactos también pueden ser cuentas de usuario que existen únicamente para notificaciones, como por ejemplo para reenviar a un sistema de tickets.

Más información en Grupos de contacto.

Un dashboard es una vista general libremente configurable que consta de vistas y/o los llamados «dashlets». Estos elementos están disponibles, por ejemplo, en forma de listas (como problemas de hosts), gráficos de la serie temporal o pequeños «velocímetros» que muestran valores individuales, como la temperatura de la CPU.

Más información en Dashboard.

En cuanto se añade un host a la monitorización, Checkmk detecta automáticamente todos los servicios disponibles que se pueden incluir en la monitorización, y mantiene esta lista actualizada incluso durante el funcionamiento. El descubrimiento de servicios también se puede iniciar manualmente en cualquier momento a través de la configuración de una función de host.

Más información en Comprender y configurar servicios.

Las ediciones de Checkmk son las distintas variantes de software de Checkmk disponibles para descargar e instalar. Estas son: la versión Open Source Checkmk Community (antes Checkmk Raw), para usuarios profesionales la versión Checkmk Pro (antes Checkmk Enterprise) disponible mediante suscripción, la versión Checkmk Ultimate (antes Checkmk Cloud (Self-hosted)) basada en Checkmk Pro, y por último la versión Checkmk Ultimate con multitenencia (antes Checkmk MSP). En este orden, cada edición contiene todas las funciones de la edición anterior y las amplía con funciones adicionales específicas. Por ejemplo, Checkmk Ultimate es una versión de Checkmk Pro ampliada y optimizada para la monitorización de entornos híbridos.

Más información en «Seleccionar una edición de Checkmk».

La interfaz web de Checkmk se divide en entornos de monitorización y de configuración. Este último se refiere a los procesos mediante los cuales se definen reglas, se añaden y definen hosts y servicios, se gestionan usuarios o se especifican opciones generales. Se accede al entorno de configuración a través del menú «Setup» en la barra de navegación.

Más información en La interfaz de usuario para usuarios.

La interfaz web de Checkmk se divide en entornos de monitorización y de configuración. El primero se refiere a los procesos a través de los cuales se muestra el estado de la infraestructura monitorizada; estos incluyen el inventario, los dashboards, las listas de hosts, servicios, eventos o problemas, los datos históricos, etc. Se accede al entorno de monitorización a través del menú «Monitor» de la barra de navegación.

Más información en La interfaz de usuario para usuarios.

El estado de un host, es decir, si se puede acceder a él a través de la red (UP), si no responde a las solicitudes de la red (DOWN) o si su ruta de acceso está bloqueada por dispositivos intermedios averiados (switches, routers, etc.) (UNREACH). Para los hosts recién añadidos que nunca han sido consultados antes, también existe el estado PEND, que no es un estado en el sentido estricto.

Más información en Hosts y servicios.

El estado de un servicio es siempre «OK», «WARN», «CRIT» o «UNKNOWN», y describe el estado actual del servicio según reglas predefinidas. Para los servicios recién añadidos que nunca se han consultado antes, también existe el estado «PEND», que no es un estado en sentido estricto.

Más información en Servicios.

Al igual que los hosts, los servicios también se pueden agrupar para que estos grupos se puedan filtrar más tarde en las vistas de tabla o tratar específicamente en la configuración. Los grupos se pueden formar mediante carpetas, etiquetas de host, etiquetas de host y servicio, y nombres de host y servicio filtrados mediante expresiones regulares.

Más información en Grupos de servicio.

En Checkmk, los hosts se gestionan principalmente mediante carpetas. Los grupos del host permiten agrupar los hosts de forma diferente para seleccionarlos en la monitorización, por ejemplo, en las vistas de tabla. Las etiquetas, los rótulos y las carpetas del host se utilizan para asignar hosts a dichos grupos mediante reglas. Los hosts también se pueden asignar explícitamente a un grupo del host.

Más información en Grupos del host.

En Checkmk, un host es cualquier sistema independiente, físico o virtual, que es supervisado por Checkmk. Suelen ser componentes con su propia dirección IP (servidores, switches, dispositivos SNMP, máquinas virtuales), pero también, por ejemplo, contenedores Docker u otros objetos lógicos que no tienen dicha dirección IP. Cada host tiene siempre uno de los estados «UP», «DOWN», «UNREACH» o «PEND», y siempre tiene al menos un servicio.

Desglosándolo aún más: Para Checkmk, internamente, un host es simplemente un elemento estructurante que contiene elementos que deben supervisarse, es decir, servicios. Cada host tiene necesariamente al menos un servicio para verificar la accesibilidad real (como PING o el propio agente Checkmk, es decir, el servicio Check_MK). En este sentido, «host» significa poco más que el encabezado bajo el cual se agrupan varios servicios.

Más información en Administración de hosts.

Si un objeto (host o servicio) cambia de estado varias veces en un periodo de tiempo corto, se considera que es inestable y se marca con el icono «». Para un objeto identificado como inestable, los cambios de estado sucesivos no activan más notificaciones. La detección de inestabilidad se puede activar o desactivar —globalmente o por regla— por separado para hosts y servicios.

Más información en Hosts y servicios inestables.

Cuando la configuración de Checkmk hace referencia a «API integrations», se refiere a datos de monitorización que utilizan el formato de datos del agente Checkmk, pero que proceden de una fuente diferente. Estas fuentes pueden ser programas de origen de datos, agentes especiales o hosts que transmiten sus datos. Si los datos recibidos a través de una integración de API se van a utilizar en la monitorización, hay que habilitar «API integrations» en las propiedades del host.

Más información en Programas de origen de datos.

A los hosts se les pueden asignar etiquetas del host, pero también se les pueden asignar etiquetas directas. Una etiqueta consta de dos partes (clave y valor), separadas por dos puntos. Estos pares clave-valor arbitrarios (os:linux, os:windows, foo:bar, etc.) se pueden configurar directamente en un host, sin necesidad de configuración por defecto, como ocurre con los tags del host. Por lo tanto, las etiquetas no tienen un ámbito predefinido ni un valor por defecto, sino que son muy dinámicas. En concreto, Checkmk puede incluir en la monitorización como hosts los objetos creados automáticamente por sistemas de contenedores como Kubernetes, Azure o AWS, y luego enriquecerlos con etiquetas generadas automáticamente a partir de sus metadatos. Las etiquetas se pueden usar, por ejemplo, para seleccionar condiciones en reglas o para filtrar en vistas de monitorización.

Más información en Labels.

Livestatus es la interfaz más importante de Checkmk. A través de ella, los usuarios de Checkmk obtienen el acceso en tiempo real más rápido posible a todos los datos de los hosts y servicios que se están monitorizando. Por ejemplo, los datos del snap-in «Overview» se recuperan directamente a través de esta interfaz. El hecho de que los datos se obtengan directamente de la RAM evita los accesos lentos al disco y proporciona un acceso rápido a la monitorización sin sobrecargar demasiado el sistema.

Más información en Recuperación de datos de estado a través de Livestatus.

Un local check es una extensión (escrita por ti mismo), en forma de script en cualquier lenguaje de programación, que se ejecuta en el host supervisado. A diferencia de las comprobaciones habituales, el cálculo del estado se realiza directamente en el host. Los resultados del script se añaden a la salida habitual del agente.

Más información en Local checks.

Valores medibles y calculables para hosts y servicios a lo largo del tiempo, como la temperatura, la utilización o la disponibilidad, que se pueden usar para gráficos, por ejemplo. Los valores históricos se almacenan en RRD (Round Robin Database) y, por defecto, se conservan hasta 4 años.

Más información en Valores medidos y gráficos.

En el modo pull, el agente Checkmk escucha las conexiones entrantes del servidor Checkmk en el puerto TCP 6556. En cuanto el agente recibe una solicitud, envía los datos de monitorización al servidor. Aquí, la iniciativa para la transmisión de datos viene del servidor, que básicamente extrae los datos del agente. El modo pull es la forma predeterminada de transmitir datos desde el agente Checkmk, y funciona en todas las ediciones de Checkmk.

Más información en el agente Checkmk.

En el modo push, el agente Checkmk envía los datos de monitorización al servidor Checkmk una vez por minuto. El agente inicia la transmisión de datos por su cuenta y no espera a recibir una solicitud del servidor. El modo push siempre es necesario si el servidor Checkmk no puede acceder a la red en la que se encuentran el host que se va a monitorizar y su agente, por ejemplo, en una configuración basada en la nube. Por este motivo, el modo push solo está disponible para Checkmk Ultimate .

Más información en El agente Checkmk.

En una monitorización distribuida, todo el sistema de monitorización consta de varios sitios de Checkmk interconectados, es decir, un sitio central y al menos un site remoto. Los datos de todos los sitios se muestran juntos en un solo lugar en el sitio central. Esto se denomina «estado central» en una monitorización distribuida. La monitorización distribuida se puede combinar opcionalmente con una configuración central.

Más información en «Monitorización distribuida».

Con una configuración central, la configuración de todos los sitios de Checkmk conectados entre sí en la monitorización distribuida se lleva a cabo en una única ubicación. La configuración se realiza únicamente en el site central y luego se distribuye a todos los sitios remotos. Una configuración central siempre incluye un estado central.

Más información en «Configuración central».

Con una notificación, se informa activamente a un usuario de Checkmk de problemas u otros eventos de monitorización, a través de correo electrónico HTML, SMS, Slack o similares. Quién recibe la notificación y cómo se determina esto depende de las reglas de notificación. Por ejemplo, si el Sr. Hirsch recibe un correo electrónico informándole de que el servicio filesystem / en el host myserver123 ha cambiado de WARN a CRIT, es porque el Sr. Hirsch es un contacto para ese host y una regla de notificación establece que todos los contactos del host deben recibir un correo electrónico cuando uno de sus servicios cambie a CRIT.

Más información en Conceptos básicos sobre notificaciones.

MKP es el formato de archivo propio de Checkmk para agregar y distribuir extensiones, es decir, check plugins personalizados, plugins de agente, definiciones gráficas de la serie temporal, scripts de notificación, vistas de tabla, dashboards, etc.

Más información en Paquetes de extensiones de Checkmk (MKPs).

En Checkmk es posible restringir aspectos como las notificaciones, los cálculos de disponibilidad e incluso la ejecución general de las comprobaciones a determinados intervalos de tiempo que se repiten periódicamente. Los periodos de tiempo se pueden utilizar, por ejemplo, para definir el horario laboral diario, especificar vacaciones y días festivos, o separar los fines de semana de los días laborables. Estos periodos de tiempo se pueden utilizar luego en las reglas.

Más información en «Periodos de tiempo».

Algunos hosts que forman parte de la monitorización no se consultan directamente porque no son dispositivos físicos, sino máquinas virtuales o contenedores, o porque los datos solo pueden ser proporcionados por un sistema de terceros. Estos sistemas de terceros (los hosts físicos) proporcionan los datos como un archivo adjunto en la salida de su propio agente y los llamamos hosts piggyback. Así, por ejemplo, un servidor Docker incluiría los datos del contenedor junto con sus propios datos. Los contenedores de este ejemplo son, por tanto, los hosts piggyback.

Más información en El mecanismo piggyback.

Un plugin de agente amplía las funciones del agente estándar que viene con Checkmk. Es un pequeño programa o script que llama el agente Checkmk y que mejora la salida del agente con secciones adicionales de datos de monitorización. Un ejemplo de plugin de agente es el actualizador de agentes.

Más información en Ampliar agentes con Plugins.

Las reglas son la base para configurar hosts y servicios en Checkmk. Las reglas de un conjunto de reglas siempre controlan un único aspecto específico de un host o servicio. Las reglas pueden incluir condiciones y pueden «apilarse» unas sobre otras de forma arbitraria dentro de un conjunto de reglas. La evaluación de las reglas se realiza de arriba abajo, de modo que puede haber reglas estándar para cuando no se aplica ninguna condición, así como reglas muy específicas que solo afectan a un host concreto. Muchos conjuntos de reglas en Checkmk ya tienen valores por defecto predefinidos, por lo que solo es necesario crear reglas adicionales para requisitos alternativos.

Más información en Reglas.

Un servicio es un objeto lógico que resume uno o más aspectos de un host. Por ejemplo, el tamaño, la carga de la CPU y las tendencias de los sistemas de archivos, la temperatura, la antigüedad y el número de programas en ejecución, los puertos, los sensores, etc. En cualquier momento dado, cada servicio de la monitorización tiene uno de los estados siguientes: «OK», «WARN», «CRIT», «UNKNOWN» o «PEND», siempre está asignado a un único host y, opcionalmente, puede contener una o más métricas.

Más información en Comprender y configurar servicios.

Un sitio es un único proyecto de monitorización de Checkmk que se está ejecutando actualmente. Checkmk se puede ejecutar en paralelo en el mismo servidor como varios sitios independientes, por ejemplo, para probar diferentes versiones o ediciones de Checkmk, o para ejecutar una monitorización separada de hosts (nuevos) que (todavía) no se van a incluir en la monitorización de producción.

Más información en Crear un site.

Los snap-ins, también llamados elementos de la barra lateral, son los bloques de construcción individuales que se pueden colocar en la barra lateral, por ejemplo, Overview y Master control. Se accede a los snap-ins mediante el icono de más situado en la parte inferior de la barra lateral.

Más información en «Barra lateral».

El «Protocolo simple de gestión de redes» (SNMP) se utiliza para supervisar y configurar dispositivos de red como routers, switches o cortafuegos. Checkmk es compatible con este protocolo, pero, dado que es relativamente ineficiente, solo deberías usar SNMP en dispositivos que no admitan alternativas de monitorización mejores, como los agentes especiales.

Más información en SNMP.

Las etiquetas de host son características que se pueden asignar a los hosts para poder seleccionarlos posteriormente en la configuración de reglas o en la monitorización de vistas. Las etiquetas de host se dividen en grupos; por ejemplo, se puede configurar un grupo de tags «Sistemas operativos» con las etiquetas «Linux» y «Windows». Algunos grupos de tags están predefinidos, como el tipo de agente Checkmk utilizado o la familia de direcciones IP utilizada para registrar si un host debe supervisarse a través de IPv4, IPv6 o ambas versiones. Las etiquetas también tienen valores predefinidos y un valor por defecto que se asigna a cada host siempre que no se haya sobrescrito con otra opción del grupo.

Más información en Tags del host.

Los tiempos de mantenimiento programados son interrupciones planificadas, por ejemplo, para actualizaciones de ciertos hosts. Los tiempos de mantenimiento programados anulan temporalmente las notificaciones y, por ejemplo, se tienen en cuenta en el cálculo de disponibilidad e impiden temporalmente que los hosts y servicios relacionados aparezcan como problemas.

Más información en «Tiempos de mantenimiento programados».

Una cuenta especial para consultar y configurar Checkmk independientemente de la interfaz web, por ejemplo, a través de API, línea de comandos, script o servicio web. Por defecto, el usuario de automatización tiene una contraseña de automatización elegida al azar (secreto de automatización). En un site Checkmk nuevo ya hay al menos un usuario de automatización configurado, para registrar el agente en el servidor Checkmk para la transferencia de datos cifrada con TLS.

Más información en Usuario de automatización (para servicios web).

Además de los dashboards, las vistas son las representaciones más utilizadas de hosts, servicios y otros componentes en la interfaz de Checkmk. Estas vistas se muestran como tablas con atributos relevantes para el contexto actual. Por ejemplo, All hosts y Host problems son vistas de monitorización. Las vistas estándar proporcionadas se pueden personalizar en su visualización y también pueden servir de base para nuevas vistas. También es posible crear vistas desde cero.

Más información en Vistas de host y servicio.

La «Web Administration Tool» era la herramienta GUI para configurar Checkmk hasta la versión 1.6.0. Con la introducción de WATO, los usuarios pudieron por primera vez personalizar Checkmk a través de una interfaz web en lugar de usar archivos de configuración. WATO fue sustituido en la versión 2.0.0 por el menú «Setup» en la barra de navegación.

Más información en el Menú de configuración.

El desarrollo del software Checkmk se organiza en los llamados «Werks». Cada cambio, Corrección de errores o nueva función que afecte a la experiencia del usuario se registra en un Werk independiente, junto con notas sobre el impacto y cualquier posible incompatibilidad. La lista de Werks está disponible directamente en Checkmk a través del menú «Help» de la barra de navegación y en la página de inicio de Checkmk.

Más información en Werks.