Nikita Pande created AMBARI-26318:
-------------------------------------
Summary: 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
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: [email protected]
For additional commands, e-mail: [email protected]
