Log¶
control.audit.log
Quién ve el diario¶
La sección Registro de auditoría la ven dos roles:
- security — el rol de supervisión: el registro de auditoría y su propia cuenta (entrar, cambiar su contraseña, salir). Los ajustes, los streams y el estado observado le están cerrados por completo, incluida la lectura.
- superadmin — como todo lo demás en el panel.
Los roles admin y viewer no tienen acceso: la supervisión de los operadores no pertenece a los propios operadores, y a un espectador el diario le revelaría los usuarios de los administradores y las direcciones desde las que entran. La prohibición la aplica el servidor, no el menú: a un rol sin acceso se le rechaza también por enlace directo.
Los roles se asignan en la sección Cuentas. A quien vigila lo que hacen los operadores se le crea una cuenta propia con el rol security, en lugar de darle un superadministrador.
Qué entra en el diario¶
Deja anotación un cambio que llegó a producirse y el inicio de sesión:
- la edición de ajustes — de un stream, de una máquina, de una plantilla, de una fuente de la guía, del acceso, de la propia instalación de control;
- el trabajo con las máquinas del clúster — registro, revocación, eliminación, apertura y cierre de la ventana de unión;
- el trabajo con las cuentas — creación, edición, eliminación, cambio de contraseña;
- la migración de ajustes desde Flussonic v3 — tanto la construcción del plan como su aplicación;
- la ejecución manual de la asignación;
- el inicio de sesión de un administrador y el intento fallido;
- el trabajo con el registro de clientes — crear, editar y eliminar un cliente, vincular y desvincular una cuenta.
Una operación masiva deja una anotación por cada objeto afectado, no una por llamada: migrar trescientos streams se ve como trescientas anotaciones, y la búsqueda por nombre encuentra cualquiera de ellas.
Aparte queda la revelación de un token de unión vigente: es una lectura, pero revelar un secreto equivale a entregarlo, así que la anotación se mantiene. El valor del token nunca entra en ella.
El listado y sus columnas¶
Las anotaciones van de las nuevas a las antiguas. El botón Cargar más trae la siguiente página: el listado no termina en las primeras cincuenta anotaciones.
La tabla tiene cinco columnas:
- Hora — el momento de la acción.
- Actor — quién actuó. O bien el usuario de un administrador, o bien uno de los tipos de servicio: clave estática (entrada con las credenciales de emergencia de
/etc/mcaster/secrets.env, comunes a todos y por eso sin nombre detrás) y nodo (el registro de una máquina del clúster, donde el actor es su identificador). - Acción — qué se hizo, con un nombre de máquina de la forma
<recurso>.<verbo>:stream_config.put,node_config.patch,admin.create,auth.login. Los nombres son estables, lo que resulta cómodo para buscar y filtrar. - Recurso — sobre qué: tipo y nombre, por ejemplo
stream/program-a. - Resultado — éxito en una acción consumada y fallo en un inicio de sesión fallido.
La flecha a la izquierda de la fila despliega los detalles de la anotación: la dirección desde la que llegó la petición, el rol del administrador, la versión del documento después de la edición, la lista de campos modificados y —si la petición llegó con una cabecera de trazado— su identificador, con el que la anotación se coteja con los logs.
Búsqueda en el diario¶
Sobre el listado hay cinco campos que funcionan en conjunto:
- Tipo de recurso y Nombre del recurso — «todo lo que se hizo con este stream».
- Actor — «todo lo que hizo esta persona».
- Desde y Hasta — una ventana de tiempo en formato RFC 3339, por ejemplo
2026-08-14T14:00:00Z.
Aplicar vuelve a leer el listado desde el principio. Un campo vacío significa «no filtrar».
Un incidente suele analizarse en dos consultas: primero por recurso — qué le pasó a este stream — y después por el actor de la anotación encontrada — qué más hizo esa misma persona ese día.