RUN_MODE selecciona sus superficies activas: el manager de la API, el worker de informes, o ambos. Las configuras al momento del despliegue, mediante valores de Helm, Docker Compose o el entorno de tu orquestador. Las variables marcadas como obligatorias hacen que el servidor falle al iniciar si no están configuradas.
Para los bloques de configuración que comparten todos los productos de Lerian (postura de TLS, OpenTelemetry, autenticación de Access Manager, multi-tenancy, service discovery y event streaming), consulta la referencia de configuración de BYOC. Esta página se centra en lo que es distintivo de Reporter.
Modo de ejecución y puertos
RUN_MODE decide qué superficies sirve el proceso. Ejecuta la API y el worker como un solo proceso (all) para despliegues pequeños, o sepáralos en desplegables independientes (api y worker) para escalar la generación de informes por separado. Consulta la referencia de salud y readiness para conocer el contrato de las sondas.
Despliegue y TLS
CORS y proxies
Paginación de la API
Vistas previas de plantillas
Base de datos (MongoDB)
Almacena los metadatos de los informes, las plantillas y el historial de ejecuciones.Broker de mensajes (RabbitMQ)
Lleva la cola de comandos de generación de informes entre la API y el worker.Almacenamiento de objetos (compatible con S3)
Dónde se almacenan los informes renderizados. Funciona con cualquier endpoint compatible con S3.Caché (Redis / Valkey)
Renderizado de PDF (worker)
Fuentes de datos de informes
Los informes leen de fuentes de datos de PostgreSQL y MongoDB en el registro persistido. Crea y administra las entradas ordinarias mediante la API de fuentes de datos. El bloque de entorno de abajo es una vía de arranque opcional para un solo tenant. Los despliegues multi-tenant crean fuentes de datos ordinarias por tenant mediante la API.DATASOURCE_{NAME}_CONFIG_NAME hace que exista un bloque de siembra por entorno. Reporter escanea las claves que coinciden con DATASOURCE_*_CONFIG_NAME. El prefijo cuenta tanto como el sufijo, así que una clave que solo termina en _CONFIG_NAME no declara nada. Al iniciar el Manager, un bloque completo siembra su configName solo cuando ninguna entrada del registro, incluida una eliminada de forma lógica, ya usa ese nombre. El valor es el nombre que usan tus plantillas para dirigirse a la fuente.
Dentro de un bloque, las variables marcadas como obligatorias son las que Reporter necesita antes de leer el bloque.
A continuación, un bloque de siembra completo por fuente de datos. Configura la
DATASOURCE_CRED_ENC_KEY global por separado, como se describió arriba. Recomendamos usar el mismo nombre para CONFIG_NAME y {NAME}, con el segmento de la variable de entorno en mayúsculas (por ejemplo, ONBOARDING para CONFIG_NAME=onboarding). Eso mantiene la clave del esquema intuitiva, porque SCHEMAS usa el valor de CONFIG_NAME como su clave, mientras que los demás campos usan {NAME}:
{{ onboarding.accounts }}. Usa la API para agregar o actualizar una fuente de datos ordinaria. En modo de un solo tenant, un bloque de entorno solo siembra una entrada previamente ausente. Nunca sobrescribe una entrada administrada por la API ni restaura una eliminada de forma lógica.
Fuente de datos de CRM reservada
plugin_crm es la fuente de datos de CRM reservada y administrada por entorno. No la crees ni le apliques PATCH mediante la API de fuentes de datos ordinaria: Reporter rechaza esa vía con RPT-0073. Una plantilla de CRM debe usar exactamente el nombre de configuración plugin_crm y un bloque completo de MongoDB:
DATASOURCE_CRM_PASSWORD, CRYPTO_HASH_SECRET_KEY_CRM y CRYPTO_ENCRYPT_SECRET_KEY_CRM en tu almacén de secretos. Los valores criptográficos de CRM deben ser las mismas claves que ya usa CRM; no generes claves de reemplazo para Reporter. Mantén DATASOURCE_CRED_ENC_KEY estable también: cambiarla le impide a Reporter descifrar las credenciales de fuentes de datos almacenadas.
En un despliegue de un solo tenant, el Manager usa este bloque al iniciar para sembrar plugin_crm y para completar un metadata.midazOrganizationId ausente o vacío. Un ID de organización persistido y no vacío prevalece y no se sobrescribe por el entorno. Si es incorrecto, no uses la API ordinaria para cambiarlo; detente y usa la vía de recuperación de ingeniería compatible. En un despliegue multi-tenant, el Manager omite esta siembra por entorno, así que este bloque no es un mecanismo de aprovisionamiento multi-tenant.
Para la ubicación en Helm y un ejemplo completo de valores, consulta Reporter mediante Helm. Para las plantillas que usan plugin_crm, valida la vía completa: importa o guarda la plantilla, genera un informe, confirma que los campos de CRM se descifran, y confirma que sus registros están acotados a la organización de Midaz prevista.
Backbone de configuración compartido
Los siguientes bloques son idénticos en todos los productos de Lerian. La referencia de configuración de BYOC los documenta en su totalidad. Están desactivados de forma predeterminada.- Autenticación de Access Manager:
PLUGIN_AUTH_ENABLED,PLUGIN_AUTH_ADDRESS. Habilítala en producción. - Multi-tenancy:
MULTI_TENANT_*, además deRABBITMQ_MULTI_TENANT_SYNC_INTERVALyRABBITMQ_MULTI_TENANT_DISCOVERY_TIMEOUT. Desactivada de forma predeterminada. - Service discovery:
SD_*(Consul, y Reporter también acepta los alias heredadosSD_ADVERTISE_*/CONSUL_ADDR). Desactivado de forma predeterminada. - Event streaming:
STREAMING_ENABLED,STREAMING_BROKERS,STREAMING_CLOUDEVENTS_SOURCE, además deRABBITMQ_REPORT_EVENTS_EXCHANGEpara el exchange de eventos. Desactivado de forma predeterminada. - OpenTelemetry:
ENABLE_TELEMETRY,OTEL_*,OTEL_INSECURE_EXPORTER. La telemetría es de tipo push OTLP.