[jira] [Updated] (AMBARI-26318) Ambari Web: Refactor persist UI console errors

["Nikita Pande (Jira)" <ji...@apache.org>]

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

Nikita Pande updated AMBARI-26318:
----------------------------------
    Summary: Ambari Web: Refactor persist UI console errors   (was: Persist UI console errors)

> Ambari Web: Refactor persist UI console errors 
> -----------------------------------------------
>
>                 Key: AMBARI-26318
>                 URL: https://issues.apache.org/jira/browse/AMBARI-26318
>             Project: Ambari
>          Issue Type: Improvement
>          Components: ambari-web
>            Reporter: Nikita Pande
>            Priority: Major
>
> Analysis of current code of 'error_handler_controller.js' of ambari-web:
> It has *Limited Persistence and Scalability:*
>  * Relying heavily on {{localStorage}} is a significant limitation. {{localStorage}} has a small storage capacity, is synchronous (potentially blocking the UI thread), and is not suitable for complex data structures. This makes it unsuitable for production applications where you need to store a large volume of error logs.
>  * The custom logic to limit the size of {{localStorage}} is fragile and can lead to data loss.
>  * The current approach lacks a robust, scalable server-side logging mechanism. While it sends errors to the server via {{{}postUserPref{}}}, it doesn't specify a proper logging infrastructure like a dedicated logging service.
> Potential solution to the problem 
>  * *Client-Side Persistence: IndexedDB:*
>  ** *Why:*
>  *** Provides significantly more storage than {{{}localStorage{}}}.
>  *** Asynchronous operations prevent UI thread blocking.
>  *** Supports structured data storage, ideal for complex error objects.
>  ** *Implementation:*
>  *** Utilize IndexedDB to store the error queue locally.
>  *** Create an object store to hold error objects with relevant metadata (timestamp, user ID, etc.).
>  *** Implement versioning for the IndexedDB schema to handle future updates.
>  *** Use a library to wrap IndexedDB calls, to handle cross browser inconsistencies.
>  *** Implement a strategy to remove old errors, when the database reaches a certain size.
>  * *Robust Server-Side Logging Infrastructure:*
>  ** *Why:*
>  *** Centralized log aggregation for comprehensive analysis.
>  *** Scalability to handle large volumes of error logs.
>  *** Powerful search and filtering capabilities.
>  *** Alerting and monitoring features.
>  ** *Implementation:*
>  *** *Choose a Logging Service: (Connectors to support this)*
>  **** *Cloud-based:* AWS CloudWatch Logs, Google Cloud Logging, Azure Monitor Logs, Datadog, Sentry, Rollbar, LogRocket.
>  **** *Self-hosted:* ELK stack (Elasticsearch, Logstash, Kibana), Graylog.
>  *** *API Endpoint:*
>  **** Create a dedicated API endpoint (e.g., {{{}/api/logs/errors{}}}) to receive error logs from the client.
>  **** Implement proper authentication and authorization for the endpoint.
>  **** Implement rate limiting to prevent abuse.
>  *** *Log Processing:*
>  **** Process incoming error logs and store them in the chosen logging service.
>  **** Add metadata to the logs, such as server-side context, environment information, and correlation IDs.
>  *** *Correlation ID:*
>  **** Generate a unique correlation ID on the client-side when an error occurs.
>  **** Include the correlation ID in the error log sent to the server.
>  **** Store the correlation ID in IndexedDB.
>  **** This allows you to link client-side errors with server-side logs for comprehensive debugging.
>  



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

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ambari.apache.org
For additional commands, e-mail: issues-help@ambari.apache.org