Known Limitations

Generic Known Limitations

• The dropdown filter on the Actions page might not work after a search filter is applied.
• The “Save Search” option is not available in the Logs view in the new UI.
• The filters applied on the Database page may not be reflected in the Table Usage by Query Count chart.
• In time-series charts, x-axis timestamp labels may overlap when there are large gaps between data points.
• On the HBase Dashboard, clicking a Regions by State Count graph does not apply the corresponding filter correctly in the search filter.
• Pulse will not be able to collect logs when the readonlyrootfs flag is enabled for Docker containers.
• Cluster-specific permissions are not applied correctly for LDAP users with multiple roles. When a user is assigned different roles across different clusters, Pulse allows users to access all the assigned permissions for each cluster.
• You might see an issue when importing alerts. Drag-and-drop may not work, and uploading through the file picker can result in errors.
• A Pulse user without any role would be able to access the Home, Incidents, Services, and Dashplots pages. These pages should be restricted, but access is granted even when the required role is not defined.
• The refresh buttons on charts do not update the charts with the latest data. Users can access the latest data by refreshing the browser window.
• In the YARN Application Explorer search, a long list of search options can appear truncated at the bottom, causing the dropdown to appear cut off.
• In the Impala Query Plan view, queries with a large number of nodes take a long time to load, showing incorrect results.
• Issue: The MySQL JDBC URL used to connect to Hive does not include the required parameter allowPublicKeyRetrieval=true by default. This results in connection failures, especially when SSL is enabled on the Hadoop cluster. Workaround: Manually append allowPublicKeyRetrieval=true to the JDBC connection URL in the configuration.
• Issue: Hadoop service logs are not displayed in the Pulse UI if any one of the Elasticsearch pods is down, even when Elasticsearch is deployed on multiple VMs. This issue applies to Kubernetes-based Pulse deployments. Workaround: Ensure that all ElasticSearch pods are running and healthy to maintain consistent log visibility in the Pulse UI.
• When using the YARN Fair Scheduler, Pulse and Ambari may not capture statistics for jobs that complete in under 60 seconds
• For Standalone Spark 3.x.x, the number of actual waiting jobs might not match the waiting job count displayed in the Pulse UI.
• When performing a log search on the Logs page, the 'Source' field corresponds to log.file.path, and the 'Services' field maps to fields.component as defined in the database schema. Use these corresponding fields to fetch log details accurately.
• Changes made to the JDBC URL of the Oozie metastore in the acceldata.conf file does not persist after executing the acceldata reconfig cluster command.
• The MySQL JDBC URL for Oozie requires the allowPublicKeyRetrieval=true parameter, whereas it works without this parameter for Hive.
• When the multiple HDFS Paths Usage reaches the alert threshold, sometimes you might not receive notification for all paths.
• In a multi-cluster setup, a user can open only one cluster at a time, even when using different browser windows or tabs.
• Pulse does not support HBase version 2.5.8 at this time. You can use a compatible version for optimal functionality.
• The dashboard created using the elastic data source does not work when imported on a different cluster.
• The count of queries on the Impala Queries page and Impala Queries Details page might mismatch for the last 15 minutes in case of a larger number of queries.
• The vertex duration on the Tez page can be incorrect for some queries.
• The application logs for short-duration Yarn applications may not persist long enough for the log collector agent (Pulse Logs) to scrape. This may result in missing metrics (usedContainers) dependent on the parsed application logs.

Pulse on Kubernetes: Performance-Specific Known Limitations

Pulse runs reliably on Kubernetes. In certain scenarios, such as high workloads or resource constraints, you might notice performance impacts, including data loss, alert delays, POD restarts, etc. The following points describe these conditions and provide workarounds to help you maintain stability and performance.

• PODs restart when data operations exceed allocated resources

  • Impact: Event data loss due to a restart.
  • Workaround: Analyze workload patterns and allocate sufficient resources for jobs and queries to execute. Also, you can fine-tune the service-specific configurations.

• Alert delays under POD failures or high workload:

  • When a POD goes down (scale factor > 1) and continuously restarts:

    • Cluster rebalancing causes alerts to take longer to resume on other available PODs.
    • Some alerts may be temporarily delayed until the cluster stabilizes.

  • Under high workload conditions:

    • Alert execution may experience latency.
    • Alerts are eventually processed, but delivery is slower than normal.

  • Impact: Overall alerting is delayed, but no alerts are lost; processing resumes once resources stabilize.

• POD performance depends on the cluster and infrastructure

  • Impact: Unstable clusters, limited network bandwidth, or insufficient storage throughput can reduce performance.
  • Workaround: Ensure cluster stability, sufficient network bandwidth, and adequate storage throughput.