[
https://issues.apache.org/jira/browse/AMBARI-26318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933769#comment-17933769
]
zrain commented on AMBARI-26318:
--------------------------------
[~nikitapande]
This is a great idea! The previous dependency upgrades in ambari-web, combined
with the fact that most unit tests were skipped, have led to an increased
frequency of errors. As a result, the log size in LocalStorage is likely to
reach its threshold much faster than anticipated. I’ve also noticed that
[IndexedDB|https://caniuse.com/indexeddb] is supported by most modern browsers,
and for older browsers, we could fall back to LocalStorage for compatibility.
This change could improve UI rendering performance in certain complex scenarios
while also pushing forward the overall modernization of ambari-web.
I’m aware of a library that could help implement this feature more quickly:
[idb|https://github.com/jakearchibald/idb]. It provides a convenient way to
work with IndexedDB, though it doesn’t support IE.
That said, I think there are a few considerations when it comes to introducing
additional libraries, such as compatibility and bundle size. Currently, the
ambari-web build process doesn’t support tree-shaking, which means that
including extra libraries could inflate the size of app.js and vendor.js,
potentially increasing page load times and blocking. My suggestion would be to
manually implement the core functionality first to establish a solid logical
framework. Once we transition to a more advanced bundler in the future, we
could then revisit using a library like idb for a smoother switch.
As for the server side, I’m not too familiar with it. From what I can tell,
logs are currently stored in the database via an API. How about [~jialiang]
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]
