Servicio · KumoMTA
Panel de control para KumoMTA
KumoMTA no trae interfaz web por diseño: expone los datos y deja que cada quien construya su vista. Eso es libertad, y también un hueco. Te montamos el panel de operador que falta —observabilidad, acciones y, si lo necesitas, vista por cliente— sobre las métricas nativas del motor, sin atarte a una plataforma.
Un panel de control de KumoMTA es la interfaz web operativa que el motor deliberadamente no incluye: una vista segura de las colas programadas, el estado de la automatización del modelado de tráfico, la gestión de IPs y dominios, DKIM, la monitorización de listas negras y acciones rápidas seguras, conectada a tu parque. KumoMTA expone los datos —más de 100 métricas, una API HTTP completa y registros estructurados— y deja la interfaz a los operadores, así que un panel es un añadido que se monta sobre el listener HTTP existente en vez de una reinstalación, y la tarea central es blindarlo porque puede vaciar colas, recargar la política y rotar IPs.
En breve
- → KumoMTA no incluye consola web por diseño; expone los datos y deja la interfaz a los operadores, así que un panel de control es un añadido, no una reinstalación del motor.
- → Monitorizar y controlar son trabajos distintos: Prometheus y Grafana leen métricas, mientras que un panel actúa —pausar una cola, recargar la política, descansar una IP— y los parques serios usan ambos.
- → Un panel puede vaciar colas, recargar la política y rotar IPs, así que debe estar blindado: listener HTTP atado a localhost, tras un proxy inverso con autenticación, doble factor y registro de auditoría.
- → Pone la visibilidad diaria y las acciones rutinarias al alcance de un equipo sin CLI —un responsable de entregabilidad o de operaciones— sin tocar Lua ni SSH.
- → Se monta sobre el listener HTTP y los endpoints de métricas existentes, así que se añade a un parque ya en producción, y un panel puede agregar un clúster entero.
KumoMTA tomó una decisión que sorprende a quien llega desde PowerMTA o desde una plataforma comercial: no incluye una interfaz web de informes. No es un olvido ni una carencia provisional, es una postura de diseño. El proyecto parte de que ninguna interfaz única puede contentar a todos los operadores, así que en lugar de imponer una, expone los datos —muchos datos— para que cada quien construya la vista que necesita. Esa libertad es real y valiosa, y también deja un hueco: el motor te entrega cifras crudas, pero no un sitio donde plantarte a mirarlas y, sobre todo, a actuar sobre ellas. Esta página explica por qué existe ese hueco, qué debe mostrar y permitir el panel de un operador serio, qué lo alimenta por debajo, y cómo lo montamos sobre herramientas abiertas que quedan en tu poder. Lo hacemos sin vender una plataforma de panel con licencia: las piezas son tuyas, y tú decides si lo operas o lo operamos nosotros.
¿Por qué KumoMTA no incluye un panel de control?
El razonamiento de KumoMTA tiene mérito y conviene entenderlo antes de criticarlo. En lugar de una interfaz cerrada que intente servir a todos y acabe sirviendo mal a cada uno, el proyecto expone más de cien métricas nativas a través de una API pensada para ser consumida por herramientas estándar como Prometheus y Grafana. Esos datos van mucho más allá de las estadísticas de correo habituales: incluyen señales internas del motor como la latencia de los eventos en Lua, el tamaño de los pools de hilos o el espacio libre del volumen de spool, junto a la profundidad de las colas y la entrega por destino. La filosofía es clara y defendible: máxima visibilidad, máxima flexibilidad, integraciones abiertas. El hueco aparece en la práctica del día a día, cuando un operador necesita una vista coherente para vigilar y una forma de actuar cuando algo va mal, y descubre que tiene un caudal de datos pero ningún tablero donde estén ordenados ni ninguna palanca a mano. Ese tablero y esas palancas son lo que hay que construir, y son justo lo que ofrecemos.
Qué pasa si no montas panel
Operar KumoMTA sin un panel es enviar a ciegas, y el coste de esa ceguera no se nota hasta que duele. Sin una vista, te enteras de los problemas tarde y por el peor canal: por los rechazos de los proveedores, por una caída de entrega que ya lleva días, o por un cliente que pregunta antes de que tú lo supieras. La cola se atasca y nadie lo ve hasta que el spool se acerca a llenarse; un proveedor empieza a frenar y la reputación se erosiona mientras tú sigues empujando volumen contra una puerta que se cierra; un flujo dispara quejas y se descubre cuando ya cruzó el umbral que activa la aplicación. Diagnosticar a posteriori, leyendo registros crudos en mitad de la urgencia, es lento justo cuando los minutos cuentan. Un panel convierte todo eso en señales que ves venir, con tiempo para actuar antes de que un problema pequeño se vuelva un incidente. La pregunta no es si te puedes permitir montar el panel, es si te puedes permitir operar sin él.
¿Un panel sustituye a Grafana y Prometheus?
Es la distinción que más se confunde, y la que define qué tipo de panel necesitas. Monitorizar es ver: un dashboard que muestra colas, tasas de entrega y salud del sistema, y que te avisa cuando algo se sale de rango. Eso, con Prometheus y Grafana sobre las métricas de KumoMTA, se consigue relativamente pronto y ya es muchísimo. Controlar es otra cosa: es poder actuar sobre lo que ves sin bajar a la línea de comandos en mitad de un incidente —pausar una cola que se está atascando, retener un flujo que dispara quejas, ajustar un límite ante un freno de un proveedor—. Un panel de pura observación te deja mirar cómo arde el problema; un panel de operador te deja apagarlo. La mayoría de los montajes caseros se quedan en lo primero, porque lo segundo exige diseñar acciones con cuidado y rodearlas de seguridad. Distinguir las dos cosas desde el principio evita acabar con un panel precioso que, en la urgencia, no sirve para hacer nada.
¿Qué muestra de verdad un panel de control de KumoMTA?
Un panel útil no es el que más gráficos tiene, es el que pone delante las señales que de verdad gobiernan la entrega. La tabla recoge un núcleo de métricas que combinamos en las vistas, mezclando las nativas del motor con las del sistema.
| Métrica | Qué te dice |
|---|---|
| Profundidad de cola | Cuánto correo espera por entregar, por destino y por pool, antes de que sea un problema |
| disk_free_percent | Espacio libre del volumen de spool, para actuar antes de que se llene |
| lua_event_latency | La latencia de tu lógica en Lua, para encontrar cuellos de botella |
| thread_pool_size | El tamaño de los pools de hilos, para dimensionar el motor con datos |
| Diferimientos y rebotes por proveedor | Quién te frena y por qué, en tiempo casi real |
| CPU y memoria (con node_exporter) | La salud del sistema, junto a las métricas de correo, en una sola vista |
KumoMTA expone más de cien métricas nativas. Fuente: documentación y blog de KumoMTA.
Métricas que importan, y ruido que distrae
Con más de cien métricas disponibles, el riesgo no es quedarse corto, es ahogarse. Un panel que lo muestra todo no muestra nada, porque entierra las tres o cuatro señales que de verdad gobiernan tu entrega bajo decenas de gráficos que se miran una vez y nunca más. El oficio está en elegir. Para la entrega, las que mandan son la profundidad de cola por destino —que avisa de atascos antes que cualquier otra cosa—, las tasas de diferimiento y rebote por proveedor —que dicen quién te frena y por qué— y la evolución de la reputación allí donde se puede medir. Para la salud del motor, el espacio libre del spool es la que más incidentes evita, seguida del uso de procesador y memoria y de la latencia de tu lógica en Lua. El resto son métricas de apoyo: útiles cuando investigas algo concreto, contraproducentes si compiten por tu atención en la vista principal. Diseñar la jerarquía —qué va en primera plana, qué a un clic, qué solo en investigación— es lo que separa un panel que se usa de uno que se ignora.
# 1. Ata el listener HTTP del motor a localhost, nunca a 0.0.0.0 (init.lua)
kumo.start_http_listener { listen = '127.0.0.1:8000' }
# 2. Confirma que nada escucha en una interfaz pública
$ ss -tlnp | grep 8000
LISTEN 0 1024 127.0.0.1:8000 0.0.0.0:* users:(("kumod"))
# 3. Al panel solo se llega por el proxy Nginx autenticado (TLS + 2FA arriba)
location / { proxy_pass http://127.0.0.1:8000; auth_request /2fa; }
# 4. Puerto cerrado en el cortafuegos; cada acción cae en el registro de auditoría
$ ufw status | grep 8000
8000 DENY Anywheress que nada responde en una interfaz pública, llega al panel solo por un proxy Nginx autenticado y cierra el puerto en el cortafuegos. Salta cualquiera de estos pasos y el panel se vuelve una superficie de control de todo tu envío, accesible para cualquiera que la encuentre.Qué alimenta el panel
Por debajo de las vistas hay una tubería de datos sencilla de explicar y fácil de equivocar. KumoMTA expone sus métricas a través de un listener HTTP que se activa en su configuración; ese endpoint publica las cifras en un formato que Prometheus recoge a intervalos cortos, guardando la serie temporal. Grafana lee de Prometheus y dibuja los tableros. Para las métricas del sistema —procesador, memoria, disco— se despliega node_exporter junto al motor, de modo que la salud de la máquina y la del correo quedan en la misma pantalla en lugar de en dos mundos separados. A esa base se suman, según el caso, el procesado de los registros del motor para análisis más finos y la automatización de modelado de tráfico que KumoMTA ofrece para ajustar el envío ante los frenos de los proveedores. Es una arquitectura estándar y documentada; el valor no está en descubrirla, está en montarla con seguridad, decidir qué se recoge y a qué frecuencia, y construir encima las vistas y las alertas que tu operación usa de verdad.
Alertas: avisar sin agotar
Un panel sin alertas obliga a mirarlo todo el rato, y nadie lo hace; un panel con demasiadas alertas entrena a tu equipo para ignorarlas, que es peor. El equilibrio —avisar de lo que importa, callar de lo que no— es de las partes más delicadas y menos visibles del trabajo. Una buena capa de alertas distingue niveles: un aviso informativo que no despierta a nadie, una advertencia que pide atención en horario laboral, y una urgencia que justifica una llamada de madrugada, cada una con su umbral pensado. Distingue también lo accionable de lo inevitable: alertar de un diferimiento puntual de un proveedor que se resuelve solo es ruido; alertar de una cola que crece sin parar o de un spool que se acerca al límite es señal. Y prevé la escalada y el silenciamiento, para que un problema conocido no dispare el mismo aviso cien veces. La fatiga de alertas mata más sistemas de monitorización que los fallos técnicos, porque convierte la herramienta en fondo de pantalla. Afinar esto es un trabajo de criterio, no de configuración.
Registros frente a métricas: para qué sirve cada uno
Métricas y registros responden a preguntas distintas, y un buen panel se apoya en ambos sin confundirlos. Las métricas son la tendencia: números agregados en el tiempo que dicen cómo va el conjunto —cuánta cola, qué tasa de rebote, cuánto disco libre— y que brillan para ver problemas venir y para vigilar la salud general. Los registros son el detalle: el rastro de cada mensaje, cada conexión y cada respuesta de un proveedor, que sirven para el forense, para entender por qué un envío concreto falló o qué dijo exactamente un buzón al rechazar. Querer hacer forense con métricas es imposible, y querer ver tendencias leyendo registros crudos es agotador. Un montaje serio recoge las métricas en Prometheus para los tableros y procesa los registros aparte para la búsqueda y el análisis fino, de modo que cada pregunta vaya a la fuente que la responde bien. Saber cuál mirar en cada momento es parte de operar con cabeza.
Acciones rápidas, y el peligro que esconden
El salto de monitorizar a controlar es donde un panel gana su sueldo y también donde más fácil se hace daño. Poder pausar una cola, retener un tenant que dispara quejas o ajustar un límite desde una pantalla, en mitad de un incidente y sin pelearse con la configuración, vale oro cuando los segundos cuentan. El peligro es el reverso de esa comodidad: un botón que actúa sobre producción es un botón que, pulsado por error o por la persona equivocada, detiene tu correo o lo dispara. Por eso las acciones rápidas se diseñan con red: permisos que limitan quién puede hacer qué, confirmaciones para lo irreversible, un registro de quién tocó qué y cuándo, y un alcance acotado para que un error afecte a un flujo y no a todo el envío. Un panel que ofrece poder sin esas salvaguardas no es una herramienta, es un accidente esperando su turno. El equilibrio entre comodidad y seguridad es buena parte del oficio aquí.
¿Es seguro un panel web en un MTA de producción?
Hay una regla que no se negocia: nada de esto se expone abiertamente a Internet. El endpoint de métricas del motor, la instancia de Prometheus, los tableros de Grafana y cualquier consola de acciones quedan tras autenticación y restringidos por red, accesibles solo desde direcciones de confianza o a través de una VPN. La razón es doble. Por un lado, las métricas revelan mucho de tu operación —volúmenes, clientes, comportamiento— y son información que no debe quedar a la vista de cualquiera. Por otro, en cuanto el panel incluye acciones, exponerlo es ofrecer las palancas de tu envío a quien dé con la dirección. Un endpoint de métricas abierto es un descuido común y caro, porque parece inofensivo hasta que alguien lo encuentra. Cerramos esta capa desde el primer paso, antes de pensar en gráficos bonitos, porque un panel filtrado o secuestrado hace más daño que la falta de panel que vino a resolver.
Paneles de la comunidad, con honestidad
Conviene ser justo con lo que ya existe. Hay tableros de KumoMTA publicados, oficiales y de la comunidad, listos para conectarse a Prometheus y dar en poco tiempo una vista respetable de colas, entrega y salud del sistema. Son un excelente punto de partida, y montarlos es lo primero que hacemos: regalan kilómetros de trabajo y enseñan deprisa qué se puede ver. Donde se quedan cortos es en lo que es tuyo y solo tuyo: no conocen tus pools, tus clientes, los proveedores que más te importan, ni los umbrales a los que quieres que salte una alerta para ti en concreto. Tampoco traen, por lo general, la capa de acciones ni la seguridad ajustada a tu red. Por eso los tratamos como cimiento y no como casa terminada: arrancamos con lo que la comunidad ofrece y lo moldeamos a tu operación, que es el trabajo que convierte un tablero genérico en el panel desde el que de verdad operas.
¿Puede un panel gestionar un parque multicliente o en clúster?
Si operas como un ESP o sirves a varias marcas, el panel cobra una dimensión extra, y el modelo de KumoMTA ayuda. Como el motor permite gobernar el envío por Tenant —una entidad que puede representar a cada cliente o flujo—, se puede construir una vista de cara al cliente que muestre únicamente sus datos: su entrega, su reputación, sus colas, sin dejar ver el resto de tu operación. Eso es un servicio valioso que puedes ofrecer a tus clientes y un ahorro de soporte para ti, porque dejan de preguntar lo que pueden ver. La sutileza está en la frontera: enseñar a un cliente sus métricas es una cosa, y darle acceso a acciones que tocan infraestructura compartida es otra muy distinta y peligrosa. Diseñar qué ve cada quién y qué puede hacer —separando con nitidez la vista del cliente de la consola del operador— es donde un panel multicliente se hace bien o se convierte en un problema de seguridad y de confianza.
Un panel no es de poner y olvidar
Como toda infraestructura viva, un panel se mantiene o se degrada. KumoMTA evoluciona y añade métricas; Prometheus y Grafana publican versiones; tus pools, tus clientes y los proveedores que vigilas cambian con el tiempo. Un tablero montado y abandonado va perdiendo sentido: aparecen métricas nuevas que nadie incorpora, alertas que avisan de cosas que ya no importan y silencios sobre cosas que sí, y vistas que reflejan una operación que ya no es la tuya. Mantenerlo vivo significa revisar de vez en cuando qué se mide y qué se alerta, incorporar lo que el motor expone de nuevo, y podar lo que se ha vuelto ruido. No es un trabajo pesado, pero es un trabajo continuo, y plantearlo desde el principio —con o sin nosotros operándolo— evita que el panel pase de herramienta de confianza a decorado que nadie mira.
Alta disponibilidad del propio panel
Hay una ironía que conviene evitar: montar un panel para no quedarte ciego y luego dejar que ese panel sea el primero en caer cuando hay problemas. Si tu observabilidad vive en la misma máquina que el motor, un incidente que tumba el servidor te deja a la vez sin envío y sin la vista para entender qué pasó, justo cuando más la necesitas. Por eso el panel se diseña con algo de independencia: Prometheus y Grafana en un sitio que sobreviva a la caída de un nodo de envío, con retención suficiente de la serie temporal para poder mirar hacia atrás y ver cómo se gestó el problema. En despliegues de varios nodos, la recogida de métricas se plantea para seguir funcionando aunque uno caiga, de modo que la vista del clúster no dependa de la pieza que podría estar fallando. No hace falta una arquitectura compleja para esto, basta con pensarlo: un panel que se cae con el motor es un panel que falta precisamente en el momento para el que se montó.
El coste del stack, sin sorpresas
Una de las ventajas de este enfoque es que el panel no añade coste de licencia. KumoMTA es de código abierto, y las herramientas sobre las que se monta la observabilidad —Prometheus, Grafana, node_exporter— también lo son, así que no hay una cuota por métrica, por panel ni por volumen como la que cobran las plataformas comerciales. El coste real es de infraestructura y de trabajo: los recursos modestos de una máquina que aloje Prometheus y Grafana con su retención de datos, y el tiempo de montarlo bien y mantenerlo. Comparado con una plataforma de panel con licencia, el ahorro recurrente es notable, y a cambio te quedas con piezas abiertas que son tuyas y que puedes mover, versionar y adaptar sin pedir permiso a nadie. Nosotros cobramos por montarlo y, si quieres, por operarlo; no hay un producto con margen escondido en la recomendación, porque las herramientas que usamos no son nuestras ni las revendemos.
La automatización del modelado de tráfico
Hay una pieza de KumoMTA que merece su lugar en cualquier conversación sobre control: su automatización del modelado de tráfico, el subsistema que ajusta el ritmo de envío en respuesta a cómo reaccionan los proveedores. En lugar de límites fijos que tú revisas a mano, el motor puede aprender de los códigos de respuesta —diferimientos, frenos, rechazos temporales— y bajar o subir el ritmo hacia un destino de forma automática, frenando ante un proveedor que se queja y recuperando cuando vuelve a aceptar. Para un panel, esto cambia el papel del operador: parte del control que tendrías que ejercer a mano lo ejerce el propio motor, y la vista pasa a mostrarte qué está haciendo esa automatización y por qué, además de dejarte intervenir cuando el juicio humano debe imponerse. Integrar la observabilidad de ese subsistema en el panel —ver qué reglas se están aplicando, a qué destinos y con qué efecto— es lo que cierra el círculo entre mirar y actuar, porque buena parte de la acción ya ocurre sola y lo que necesitas es entenderla y poder corregirla.
¿Cómo se construye o monta un panel de KumoMTA?
Empezamos por la auditoría gratuita de 25 puntos, que sitúa tu KumoMTA y tu operación y deja claro qué necesitas ver y controlar. A partir de ahí, el trabajo sigue una secuencia ordenada: activar y asegurar el listener de métricas del motor; desplegar Prometheus y node_exporter; montar Grafana con los tableros de la comunidad como base y adaptarlos a tus pools, tus clientes y tus proveedores; definir las alertas con umbrales que avisen sin agotar; añadir, si lo quieres, la capa de acciones rápidas con sus permisos, confirmaciones y registro; y, si operas multicliente, construir la vista de cara al cliente sobre el modelo de Tenant. Todo queda restringido por red y tras autenticación desde el primer momento. Al cerrar, te entregamos el panel documentado para que lo lleve tu equipo, o lo operamos nosotros como servicio. Las herramientas son abiertas y tuyas, y la relación se factura por el trabajo, sin una plataforma de panel que vender al otro lado. Conviene cerrar con la idea con la que abrimos: la decisión de KumoMTA de no traer interfaz no es una pereza, es una invitación a construir la vista que tu operación de verdad necesita en lugar de conformarte con la que un fabricante decidió por ti. El precio de esa invitación es el trabajo de montarla, y ese es justo el trabajo que hacemos: traducir un caudal de métricas crudas en un sitio donde un operador se planta, entiende de un vistazo cómo va su envío, y actúa con seguridad y con criterio cuando algo se tuerce. Hecho así, el hueco que el motor deja a propósito se convierte en una ventaja, porque acabas con un panel que encaja contigo y no con el promedio de todos.
Preguntas frecuentes
FAQ
Common questions
¿KumoMTA de verdad no tiene panel propio?
No trae una interfaz web de informes empaquetada, y es una decisión deliberada del proyecto. Su razonamiento es que ninguna interfaz única puede satisfacer las necesidades de todos los operadores, así que en lugar de imponer una, exponen una cantidad enorme de datos —más de cien métricas nativas— a través de una API que herramientas como Prometheus y Grafana consumen. El resultado es flexible: puedes construir exactamente la vista que necesitas. El precio de esa flexibilidad es que la vista hay que construirla, y ahí es donde aparece el hueco que cubrimos. KumoMTA te da los datos; el panel es el sitio donde te plantas a mirarlos y a actuar.
¿Sirve un dashboard de Grafana de la comunidad?
Como punto de partida, sí, y es lo primero que montamos. Hay dashboards de KumoMTA publicados, oficiales y de la comunidad, que se conectan a Prometheus y dan en minutos una vista decente de cola, entrega y salud del sistema. Lo que un dashboard genérico no conoce es tu operación concreta: tus pools, tus clientes, los proveedores que más te importan, los umbrales a los que quieres que salte una alerta. Por eso lo tratamos como base y no como destino: arrancamos con lo que la comunidad ofrece y lo adaptamos a cómo envías tú, que es lo que convierte un panel bonito en un panel útil.
¿Qué necesito para que el panel reciba datos?
KumoMTA expone sus métricas a través de un listener HTTP que se activa en la configuración; ese endpoint publica las cifras que Prometheus recoge a intervalos regulares. A partir de ahí, Grafana lee de Prometheus y dibuja. Para las métricas del sistema —CPU, memoria, disco— se añade node_exporter junto al motor, de modo que la salud de la máquina y la del correo viven en la misma vista. Es una arquitectura estándar y bien documentada; el trabajo no está en inventarla, está en configurarla con seguridad, afinar qué se recoge y construir encima las vistas y alertas que de verdad usas.
¿Puedo dar acceso a mis clientes?
Sí, y el modelo de KumoMTA lo facilita. Como el motor permite gobernar el envío por Tenant —una entidad que puede representar a un cliente o a una marca—, se puede construir una vista de cara al cliente que muestre solo sus datos, sin exponer el resto de tu operación ni los controles internos. Eso es muy útil si operas como un ESP. La clave es separar con cuidado lo que un cliente puede ver y hacer de lo que es solo para tu equipo: una cosa es enseñarle su entrega y su reputación, y otra muy distinta darle acceso a acciones que afectan a la infraestructura compartida. Diseñar esa frontera es parte del trabajo.
¿Es seguro montar un panel sobre el motor?
Lo es si se hace bien, y es un desastre si se descuida, porque un panel concentra datos sensibles y, cuando incluye acciones, poder sobre la entrega. La regla innegociable es que nada de esto se expone abiertamente a Internet: el endpoint de métricas, Prometheus, Grafana y cualquier consola de acciones quedan tras autenticación y restringidos por red, accesibles solo desde direcciones de confianza o tras una VPN. Las acciones que tocan producción se protegen con permisos y con confirmaciones que eviten el clic fatal. Un panel inseguro no es una comodidad, es una vía de entrada; por eso la seguridad es lo primero que cerramos, no lo último.
¿Por qué contar con vosotros y no montarlo yo?
Puedes montarlo tú, y si tienes el equipo y el tiempo, te animamos a hacerlo: la arquitectura es abierta y está documentada. Donde aportamos es en el atajo y en el criterio. Sabemos qué métricas importan de verdad para la entrega y cuáles son ruido, qué umbrales de alerta evitan tanto el silencio peligroso como la fatiga de avisos, cómo asegurar la exposición y cómo diseñar las vistas por cliente sin filtrar lo que no toca. No vendemos una plataforma de panel con licencia: montamos sobre herramientas abiertas que son tuyas, y te dejamos la opción de operarlo tú o de que lo llevemos nosotros. La recomendación no tiene un producto detrás que vender.
Tienes los datos. Te damos dónde plantarte.
La auditoría gratuita de 25 puntos sitúa tu KumoMTA y tu operación, el punto de partida para montar el panel de operador que el motor no trae.