Skip to main content
Esta referência lista as variáveis de ambiente usadas para configurar o Reporter, o serviço que gera relatórios regulatórios, de compliance e contábeis a partir de templates configuráveis. O Reporter é distribuído como um binário único, e RUN_MODE seleciona suas superfícies ativas: o gerenciador de API, o worker de relatórios, ou ambos. Você define essas variáveis no momento do deploy, por meio de valores do Helm, Docker Compose ou do ambiente do seu orquestrador. Variáveis marcadas como obrigatórias fazem o servidor falhar na inicialização se não forem definidas. Para os blocos de configuração que todo produto Lerian compartilha (postura de TLS, OpenTelemetry, autenticação do Access Manager, multi-tenancy, service discovery e event streaming), veja a referência de configuração BYOC. Esta página foca no que é específico do Reporter.

Modo de execução e portas

RUN_MODE decide quais superfícies o processo atende. Rode a API e o worker como um único processo (all) para deploys pequenos, ou separe-os em deployables distintos (api e worker) para escalar a geração de relatórios de forma independente. Veja a referência de health e readiness para o contrato de probes.

Deploy e TLS

CORS e proxies

Paginação da API

Previews de template

Banco de dados (MongoDB)

Armazena metadados de relatórios, templates e histórico de execuções.

Message broker (RabbitMQ)

Transporta a fila de comandos de geração de relatório entre a API e o worker.

Armazenamento de objetos (compatível com S3)

Onde os relatórios renderizados são armazenados. Funciona com qualquer endpoint compatível com S3.

Cache (Redis / Valkey)

Renderização de PDF (worker)

Datasources de relatório

Os relatórios leem de datasources PostgreSQL e MongoDB no registro persistido. Crie e gerencie entradas comuns pela API de data source. O bloco de ambiente abaixo é um caminho opcional de bootstrap single-tenant. Deploys multi-tenant criam datasources comuns por tenant pela API. DATASOURCE_{NAME}_CONFIG_NAME faz um bloco de seed de ambiente existir. O Reporter varre chaves que correspondem a DATASOURCE_*_CONFIG_NAME. O prefixo conta tanto quanto o sufixo, então uma chave que apenas termina em _CONFIG_NAME não declara nada. Na inicialização do Manager, um bloco completo semeia seu configName apenas quando nenhuma entrada no registro, incluindo uma com soft delete, já usa esse nome. O valor é o nome que seus templates usam para endereçar a fonte. Dentro de um bloco, as variáveis marcadas como obrigatórias são as que o Reporter precisa antes de ler o bloco. Um bloco completo de seed por datasource segue abaixo. Defina o DATASOURCE_CRED_ENC_KEY global separadamente, como descrito acima. Recomendamos usar o mesmo nome para CONFIG_NAME e {NAME}, com o segmento da variável de ambiente em maiúsculas (por exemplo, ONBOARDING para CONFIG_NAME=onboarding). Isso mantém a chave de schema intuitiva, porque SCHEMAS usa o valor de CONFIG_NAME como chave, enquanto todo o resto dos campos usa {NAME}:
Um template então endereça essa fonte pelo seu nome de config, como em {{ onboarding.accounts }}. Use a API para adicionar ou atualizar uma datasource comum. No modo single-tenant, um bloco de ambiente apenas semeia uma entrada previamente ausente. Ele nunca sobrescreve uma entrada gerenciada pela API nem restaura uma com soft delete.

Datasource CRM reservada

plugin_crm é a datasource CRM reservada, gerenciada por ambiente. Não a crie nem faça PATCH nela pela API comum de data source: o Reporter rejeita esse caminho com RPT-0073. Um template de CRM deve usar exatamente o nome de config plugin_crm e um bloco MongoDB completo:
Coloque DATASOURCE_CRM_PASSWORD, CRYPTO_HASH_SECRET_KEY_CRM e CRYPTO_ENCRYPT_SECRET_KEY_CRM no seu secret store. Os valores de criptografia do CRM devem ser as mesmas chaves já usadas pelo CRM; não gere chaves substitutas para o Reporter. Mantenha DATASOURCE_CRED_ENC_KEY estável também: alterá-la impede que o Reporter descriptografe as credenciais de datasource armazenadas. Em um deploy single-tenant, o Manager usa esse bloco na inicialização para semear plugin_crm e preencher um metadata.midazOrganizationId ausente ou vazio. Um ID de organização persistido e não vazio prevalece e não é sobrescrito pelo ambiente. Se estiver errado, não use a API comum para alterá-lo: pare e use o caminho de recuperação de engenharia aprovado. Em um deploy multi-tenant, o Manager pula esse seed de ambiente, então esse bloco não é um mecanismo de provisionamento multi-tenant. Para o posicionamento no Helm e um exemplo completo de values, veja Reporter via Helm. Para templates que usam plugin_crm, valide o caminho completo: importe ou salve o template, gere um relatório, confirme que os campos de CRM descriptografam e confirme que os registros ficam com escopo restrito à organização Midaz pretendida.

Backbone de configuração compartilhado

Os blocos a seguir são idênticos entre os produtos Lerian. A referência de configuração BYOC os documenta por completo. Ficam desabilitados por padrão.
  • Autenticação do Access Manager: PLUGIN_AUTH_ENABLED, PLUGIN_AUTH_ADDRESS. Habilite em produção.
  • Multi-tenancy: MULTI_TENANT_*, além de RABBITMQ_MULTI_TENANT_SYNC_INTERVAL e RABBITMQ_MULTI_TENANT_DISCOVERY_TIMEOUT. Desabilitado por padrão.
  • Service discovery: SD_* (Consul, e o Reporter também aceita os aliases legados SD_ADVERTISE_* / CONSUL_ADDR). Desabilitado por padrão.
  • Event streaming: STREAMING_ENABLED, STREAMING_BROKERS, STREAMING_CLOUDEVENTS_SOURCE, além de RABBITMQ_REPORT_EVENTS_EXCHANGE para a exchange de eventos. Desabilitado por padrão.
  • OpenTelemetry: ENABLE_TELEMETRY, OTEL_*, OTEL_INSECURE_EXPORTER. A telemetria é OTLP push.