Vector en pymes: logs, filtros y salida S3
Cómo leer logs de aplicaciones, quitar datos sensibles con VRL y guardar eventos en S3 sin depender de planillas ni capturas sueltas.
Los logs sueltos cobran caro cuando cada incidente arranca desde cero. Vector permite leer archivos de aplicaciones, transformar eventos y enviarlos a depósitos como S3 antes de que el tablero pago reciba basura repetida. Esta guía técnica muestra una ruta para pymes: fuente de archivo, filtro con VRL, retención por fecha, costo mensual y prueba de recuperación. El objetivo es simple: encontrar errores reales, borrar datos sensibles y guardar evidencia consultable.
Dónde aparece el log que nadie puede leer
El problema operativo aparece después de un reclamo: una venta no impactó, un turno quedó duplicado o una integración falló a la madrugada. Cada aplicación tiene su archivo, cada proveedor pide una captura distinta y sistemas termina buscando líneas por fecha en servidores que nadie documentó con rigor. Un log copiado por chat pierde contexto al primer reenvío. La página de Vector lo presenta como una herramienta liviana para recopilar, transformar y enrutar logs y métricas. La misma documentación lista 47 fuentes, 18 transformaciones y 61 salidas. Para una pyme, el valor práctico está en tomar eventos antes del tablero final, limpiarlos, separarlos por servicio y conservar una copia barata. La cifra puente llega de Stack Overflow 2025: SQL aparece con 58,6 % entre todos los respondentes. El dato importa porque muchos incidentes terminan cruzando log, base de datos y ticket. El archivo sin estructura ayuda a investigar una vez; el evento con campo, servicio, nivel y fecha permite preguntar de nuevo.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, una aplicación escribe archivos de log en disco. Segundo, la fuente de archivo de Vector lee nuevas líneas y recuerda el avance para evitar saltos. Tercero, una transformación remap usa VRL para convertir texto en campos, normalizar fechas, quitar correos, tokens o CUIT y marcar nivel de gravedad. Cuarto, una ruta separa eventos críticos de eventos informativos. Quinto, una salida envía errores a la herramienta de alerta o tablero que ya use la empresa. Sexto, la salida S3 guarda lotes comprimidos por fecha, servicio y entorno. El resultado queda disponible para revisión, auditoría técnica y reconstrucción de incidentes sin pagar consulta caliente por todo el histórico. La documentación de remap es el punto más sensible. Allí se decide qué campo queda, qué dato se borra y qué evento se descarta. La salida hacia AWS S3 permite conservar archivos por lote; en despliegues locales se usa el mismo patrón con almacenamiento compatible, política de retención y prueba de lectura.
Qué se instala o configura primero
El piloto conviene empezar con dos servicios. Uno debe ser ruidoso, por ejemplo una API con errores frecuentes. El otro debe ser administrativo, por ejemplo un sistema de turnos, facturación o stock. Vector se instala en una VM chica o contenedor, toma archivos, aplica remap, envía errores al tablero y archiva todo en S3 o MinIO. La configuración inicial tiene cuatro controles. El primero es una lista de campos permitidos. El segundo es una regla de borrado para datos personales y secretos. El tercero es una partición por fecha, servicio y entorno. El cuarto es una prueba de recuperación que lee un día completo y reconstruye la secuencia de un incidente. El diseño de carpetas define buena parte del resultado. Una ruta por servicio, fecha y ambiente permite borrar sin tocar datos vigentes y leer sin abrir todo el depósito. También conviene guardar una muestra pequeña en PostgreSQL: hash del lote, fecha inicial, fecha final, cantidad de eventos y estado de envío. Esa tabla no reemplaza el archivo; entrega un índice para saber qué buscar cuando una persona pide ver evidencia de un día puntual. El costo mensual puede ubicarse entre USD 15 y USD 70, equivalentes a ARS 23.025 y ARS 107.450 con dólar oficial vendedor de ARS 1.535 publicado por DolarAPI. Ese rango cubre VM, almacenamiento, backup y monitoreo básico. El armado inicial suele ocupar entre 12 y 20 horas, según cantidad de aplicaciones, calidad de logs y reglas de privacidad. UMSA suele cerrar este tipo de piloto con una demostración corta. Se genera un error controlado, Vector lo lee, remap quita el dato sensible, el tablero muestra alerta y S3 conserva el lote. Después se borra el tablero temporal y se recupera el evento desde el archivo. Esa prueba obliga a separar observabilidad de dependencia comercial.
Dónde se rompe y cómo probarlo Primer riesgo: los logs mezclan fechas locales y UTC.
La señal aparece cuando un incidente parece ocurrir en dos horarios. La prueba carga eventos de una madrugada y valida conversión, zona horaria y orden. Segundo riesgo: el filtro deja escapar datos sensibles. La señal es un correo, token o CUIT visible en el lote de S3. La prueba usa casos falsos y revisa el archivo final, no solo el tablero. Tercer riesgo: la retención se decide tarde. La señal aparece cuando el depósito crece sin regla. La prueba crea particiones por día, aplica borrado por antigüedad y conserva una muestra protegida. Cuarto riesgo: el agente se convierte en punto ciego. La señal aparece cuando Vector deja de enviar eventos y nadie recibe aviso. La prueba corta la salida S3, reinicia el servicio y confirma alerta de cola, reintento y recuperación. Un buen sistema de logs vale por la pregunta que responde dos meses después.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.