Hola a todos,
Estoy ejecutando múltiples instancias de n8n en Google Cloud Run usando una única clave de licencia.
¿Cuál es la mejor forma de rastrear el uso por implementación/inquilino (ejecuciones, flujos de trabajo activos, uso de API, etc.)?
Hola @rgrzesk
Creo que la mejor manera es usar insights:
Pero si quieres múltiples instancias de datos en un solo marco, entonces recomendaría esto:
Lo he usado y funciona todo el tiempo.
También puedes simplemente llamar a la API de N8N:
GET /api/v1/executions?status=success&limit=250
Si no estás en n8n cloud, la opción de métricas Ud es la mejor.
¿Te ayuda esto, @rgrzesk?
Para rastrear múltiples instancias de Cloud Run en un único lugar, el enfoque de sondeo de API no escalará bien: cada instancia tiene su propio endpoint de API y no hay una vista unificada. Un patrón más limpio es agregar un flujo de trabajo dedicado de “execution logger” a cada instancia: se ejecuta según una programación, realiza GET /api/v1/executions con una ventana de tiempo, agrega una etiqueta instance_id y publica los resultados en una tabla Postgres compartida o en Google Sheet. Así tendrás un único lugar central para consultar el uso en todas las instancias. Puedes incluir el nombre del servicio Cloud Run como identificador de instancia mediante una variable de entorno inyectada en el momento de la implementación.
Esto suena realmente bien, pero el problema es que no tengo y no tendré acceso a todas las instancias. Puedo orquestarlas, pero no puedo ser un usuario.
Necesitaría crear un flujo de trabajo predefinido de ese tipo al implementar, pero supongo que no es posible hacerlo fácilmente. La única forma es usar de alguna manera datos disponibles públicamente. ¿Es posible usar el endpoint /metric? ¿Obtendré suficientes datos que pudiera usar?
Si no tienes acceso a API/usuario en cada instancia, trataría métrica como una señal de infraestructura parcial, no como un modelo de uso completo.
Puede ayudarte con preguntas como «¿está viva esta instancia?, ¿qué tan ocupada está?, ¿están fallando más ejecuciones de lo habitual?», pero generalmente no te dará una atribución empresarial limpia como uso de inquilino, conteo de flujos de trabajo activos por cliente, o llamadas a API facturables a menos que hayas diseñado la implementación alrededor de esas etiquetas desde el principio.
Para tu caso, como puedes orquestar la implementación, empujaría el límite del seguimiento hacia la plantilla de implementación:
-
asigna a cada servicio Cloud Run una etiqueta
deployment_id/tenant_idestable -
habilita la exportación de métricas/registros en tiempo de implementación, no después de que el cliente comience a usarla
-
haz que los registros de Cloud Run incluyan la misma etiqueta de implementación
-
si es posible, preinstala un pequeño flujo de trabajo de registro interno durante el aprovisionamiento
-
si el acceso al flujo de trabajo no es posible, al menos recopila centralmente la salud de la instancia, totales de ejecuciones, fallos, latencia y señales de reinicio/error
La parte importante es que la ID debe existir también fuera de n8n. Si cada instancia emite métricas pero llegan sin una etiqueta de implementación estable, igual terminarás con una pila global de números que es difícil de reconciliar.
Así que usaría /metrics para monitoreo operacional, pero no dependería únicamente de ello para reportes de inquilino/cliente. Para reportes de uso querría un flujo de trabajo logger predefinido, acceso a API, o etiquetas a nivel de implementación que tu colector agregue antes de que los datos lleguen al almacén central.
Gracias, eso tiene sentido.
¿Qué tal usar la BD como fuente de verdad para el uso histórico/de licencias? ¿Tendría sentido, mantiene los datos que necesito?
¿Verificar por execution_entity y contar todos los que no están marcados como manual?
Hola @rgrzesk
hay otro enfoque para tu configuración que es el rastreo de OpenTelemetry. Como controlas el despliegue, establece estas variables de entorno durante el aprovisionamiento:
N8N_OTEL_TRACE_ENABLED=true
N8N_OTEL_TRACE_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=https://your-central-collector:4318
Cada ejecución emite un span workflow.execute con el modo de ejecución, estado, ID del flujo de trabajo e n8n.instance.id único de la instancia. Apunta todas las instancias a un recopilador (Jaeger, Grafana Tempo, etc.) y obtendrás un rastreo por instancia, por ejecución con filtrado de modo. Sin necesidad de acceso a BD, sin riesgo de poda, protocolo estándar, y se configura completamente en el momento del despliegue, lo que se ajusta perfectamente a tus restricciones.
Para la ruta de BD como alternativa: sí, execution_entity con mode != 'manual' funciona, pero ten en cuenta que la poda elimina estos registros según EXECUTIONS_DATA_MAX_AGE. Agrega en tu propio almacén con una programación más corta que la ventana de poda.
Avísame si te ayuda 
¡Muy bien!
OL es una buena solución para instancias ya nuevas. ¿De alguna manera podemos obtener también datos históricos?
OTel solo captura desde el momento en que se habilita, sin trazas retroactivas.
Para datos históricos en instancias existentes, tienes dos opciones ya que tienes acceso a la BD:
-
Tabla
execution_entity: consultamode != 'manual'para contar producciones. Solo tan atrás como lo permita la poda. -
Tablas Insights: n8n almacena datos de insights comprimidos por separado de execution_entity, retenidos hasta 365 días por defecto (
N8N_INSIGHTS_MAX_AGE_DAYS). Esto sobrevive a la poda de ejecuciones. Revisa las tablasinsight_*en tu esquema de Postgres para contar históricos agregados.
Para cualquier cosa más antigua que lo que está en la BD, se ha perdido.
¡Hola!
Tuve un descanso bastante prolongado del tema, pero estoy volviendo 
Me alegra que a partir de la versión 2.27.0 también pueda configurar OpenTelemetry en la interfaz de usuario.
Sin embargo, tengo dos preguntas:
- ¿Puedo ocultar estas opciones? Porque revela la clave de API del sistema de OpenTelemetry.
- ¿En cuál execution.mode debería buscar en OTL? Es decir, ¿cuáles de ellos son facturables? ¿También los !manual?
EDIT - para la pregunta 2. - Acabo de notar que ya existe una bandera N8N_OTEL_TRACES_PRODUCTION_ONLY
No hay un interruptor integrado para ocultar el campo de clave OTel API en Configuración — es una brecha conocida, registrada como solicitud de función aquí: OpenTelemetry visible UI . Hasta que se implemente, la solución alternativa es restringir quién puede ver Configuración mediante RBAC/roles de proyecto, o configurar las variables de entorno OTel directamente (N8N_OTEL_*) en lugar de la interfaz de usuario para que la clave nunca se represente allí.
En execution.mode: solo las ejecuciones activadas por producción cuentan para tu cuota facturable (webhook, programación, desencadenadores de encuesta con datos). Las ejecuciones «manual» nunca cuentan, ni tampoco las llamadas de subflujo, las ejecuciones de flujo de error o las encuestas vacías. Así que filtra tu consulta OTel/insights en mode != ‘manual’ como sugirió houda_ben, y ya estarás viendo el conjunto facturable correcto.
¿Qué es el modo integrated? ¿También cuenta?
¿Cómo son visibles los sub-flujos de trabajo si no cuentan - como manuales?
«integrated» es el modo que se establece cuando un flujo de trabajo se ejecuta como un subflujo de trabajo llamado a través del nodo Execute Workflow, y no lleva la distinción manual/producción del padre en su propio registro de ejecución. Para la facturación, las llamadas de subflujo de trabajo se cuentan hacia la cuota del padre solo si la ejecución del padre fue activada por producción: un padre de producción activa ejecuciones de hijo integradas facturables, las ejecuciones de hijo integradas de un padre manual permanecen no facturables. Por lo tanto, filtra por el modo del padre, no por el campo de modo propio del subflujo de trabajo, cuando reconcilies los recuentos en OTel/Insights.
Publicidad descarada de LumaTrack, podemos hacer esto bastante fácilmente con nuestro nodo comunitario verificado, OTel, MCP, API, etc.
ok, entonces si entiendo correctamente, si tenemos una ejecución de producción que dispara 5 subflujos diferentes y esos 5 subflujos se ejecutan (por ejemplo, se cumplen las condiciones), ¿pagamos solo UNA VEZ por la ejecución de producción principal?
@rgrzesk Sí, eso es correcto. La facturación se basa en el modo de ejecución del flujo de trabajo principal, no en el de cada subflujo de trabajo individualmente. Entonces, si el flujo de trabajo principal se activa en modo de producción (webhook/cronograma/sondeo) y llama a 5 subflujos de trabajo mediante Execute Workflow, esas ejecuciones secundarias se ejecutan en modo “integrado” y no se facturan por separado; solo se te cobra por la una ejecución de producción principal. Esto solo se aplica si los subflujos de trabajo se invocan como secundarios de esa misma ejecución; si activas cualquiera de ellos independientemente mediante su propio disparador de producción, esa ejecución se factura por su cuenta.