[
https://issues.apache.org/jira/browse/FINERACT-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Saghy updated FINERACT-2438:
---------------------------------
Labels: beginner-friendly (was: )
> 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
>
> *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)
