[jira] [Resolved] (FINERACT-2438) Add Micrometer Observability to Reporting API

["Adam Saghy (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FINERACT-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adam Saghy resolved FINERACT-2438.
----------------------------------
    Fix Version/s: 1.15.0
       Resolution: Fixed

> Add Micrometer Observability to Reporting API
> ---------------------------------------------
>
>                 Key: FINERACT-2438
>                 URL: https://issues.apache.org/jira/browse/FINERACT-2438
>             Project: Apache Fineract
>          Issue Type: Improvement
>          Components: Performance, Reports
>            Reporter: Shiv Deshpande
>            Priority: Minor
>              Labels: beginner-friendly
>             Fix For: 1.15.0
>
>
> *Problem:*
> I have been working on and studying the report generation process, contributing to the ASF and Mifos community. In high-volume production environments, report generation is often a source of performance bottlenecks. I noticed currently operators lack visibility into which specific reports are consuming thread resources.
> The standard Spring Boot metrics (`http.server.requests`) aggregate all reporting traffic under the /runreports/\{reportName} endpoint. This makes it impossible to distinguish between a fast "Client Listing" HTML view and a resource-intensive "General Ledger" PDF export without parsing verbose text logs.
> *Proposed Solution*
> 1. Inject MeterRegistry into RunreportsApiResource.
> 2. Wrap the `processReportRequest` execution logic in a Timer.
> 3. Expose a new metric named fineract.report.execution, and apply tags to distinguish the execution contexts, e.g. name, format, type, status, etc.
> This allows operators to set up Prometheus/Grafana alerts for specific heavy reports (e.g., "Alert if General Ledger PDF > 30s") and visualize reporting load over time.
> This observability is an important prerequisite for future modularization efforts, such as extracting reporting into a dedicated microservice or sidecar. By establishing a clear baseline of execution costs and concurrency patterns currently, the community, and the organisations utilizing this feature can make data-driven decisions about which specific workloads justify offloading to an asynchronous architecture in the future.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)