[
https://issues.apache.org/jira/browse/AMBARI-26318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933649#comment-17933649
]
Nikita Pande commented on AMBARI-26318:
---------------------------------------
[~zrain] thoughts?
> 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: [email protected]
For additional commands, e-mail: [email protected]
