This alert detects a sustained increase in the error rate of messages received by your Azure Event Hubs namespace. The alert triggers when the estimated error rate surpasses 5% for a continuous period of 10 minutes. A high error rate could indicate issues with data transmission, message formatting, or authorization problems. Customization Guidance: Threshold: The default threshold is set at 5%. You can adjust this based on your historical data and acceptable error tolerance. A lower threshold might be necessary for critical applications where even a small increase in errors can disrupt downstream processing. Monitoring Period: The monitoring period is now set to 10 minutes. This allows for capturing sustained error occurrences while potentially filtering out short-lived spikes. You can further adjust this period based on your specific needs. Action: Upon triggering, immediate actions can include: - Reviewing recent logs for the Azure Event Hubs namespace, focusing on the 10-minute timeframe corresponding to the alert. - Investigating the specific error messages to identify the root cause (e.g., authorization issues, message format errors, network connectivity problems). - Implementing corrective measures based on the identified cause (e.g., adjusting access permissions, modifying message formats, troubleshooting network connectivity issues). - Analyzing trends in error rates to identify potential recurring issues and implement proactive solutions (e.g., improving data validation on the sending application side). By customizing the threshold and leveraging this alert with a 10-minute monitoring period, you can ensure a more comprehensive detection of sustained error rate increases in your Azure Event Hubs. This allows for earlier identification and resolution of potential problems with message ingestion, maintaining the reliability of your event streaming pipeline.

This alert detects a sudden and significant increase in the rate of data egressed from your Azure Event Hubs namespace. The alert triggers when the outgoing throughput exceeds a threshold that is higher than your usual data egress patterns for a continuous period (e.g., 5 minutes). A high outgoing throughput spike could indicate unexpected behavior in downstream processing or potential resource constraints within your event streaming pipeline. Customization Guidance: Threshold Calculation: "More than usual" is a subjective measure. To create a more effective alert, you'll need to define a specific threshold based on your historical data. You can analyze past outgoing throughput trends to determine a baseline level and set the threshold as a percentage increase above that baseline (e.g., 20% increase over the average outgoing throughput for the past hour). Monitoring Period: The default monitoring period is 5 minutes. This helps filter out short-lived spikes and focus on sustained increases. You can adjust this period based on your needs. For highly volatile data streams, a shorter window might be appropriate. Action: Upon triggering, immediate actions can include: - Investigating recent logs related to message processing and delivery within your event streaming pipeline. - Identifying the source of the increased outgoing throughput (e.g., sudden surge in data ingestion upstream, changes in downstream processing logic). - Assessing the impact on downstream systems. If the increase is causing resource exhaustion, consider scaling up resources or optimizing processing logic to handle the higher volume. - Analyzing trends in outgoing throughput to understand if this is a one-time event or an ongoing pattern. Implement proactive solutions if necessary (e.g., adjusting processing capacity or implementing throttling mechanisms). By customizing the threshold and leveraging this alert, you can proactively monitor for unexpected spikes in outgoing throughput from your Azure Event Hubs. This allows you to identify potential bottlenecks and ensure the smooth operation of your event streaming pipeline.

This alert detects a sudden and significant increase in the rate of data received by your Azure Event Hubs namespace. The alert triggers when the incoming throughput exceeds a level that is higher than your usual data ingestion patterns for a continuous period (5 minutes). A high incoming throughput spike could indicate unexpected behavior in your data source or overwhelm your processing resources. Customization Guidance: Threshold Calculation: While "more than usual" is a good starting point, a specific threshold based on historical data is more effective. Analyze past incoming throughput trends to determine a baseline level. Set the threshold as a percentage increase above that baseline (e.g., 20% increase over the average incoming throughput for the past hour). Monitoring Period: The default monitoring period is 5 minutes. This helps filter out short-lived spikes and focus on sustained increases. You can adjust this period based on your needs. For highly volatile data streams, a shorter window might be appropriate. Action: Upon triggering, immediate actions can include: - Investigating recent logs from your data source to identify the cause of the increased data volume (e.g., scheduled data export, unexpected system behavior). - Assessing the impact on your processing resources. If the high throughput is causing resource exhaustion, consider scaling up resources or implementing throttling mechanisms at the data source if possible. - Analyzing trends in incoming throughput to understand if this is a one-time event or an ongoing pattern. Implement proactive solutions if necessary (e.g., adjusting processing capacity or negotiating data transfer schedules with the data source). By customizing the threshold based on your historical data and leveraging this alert, you can proactively identify potential bottlenecks caused by unexpected spikes in data ingestion to your Azure Event Hubs.

This alert detects a sudden and significant increase in the number of incoming requests to your Azure Event Hubs namespace. The alert triggers when the incoming request rate exceeds a level that is higher than your usual patterns for a continuous period (5 minutes). A high number of incoming requests could indicate unexpected behavior in your data source or potential resource constraints within your Event Hubs. Customization Guidance: Threshold Calculation: "More than usual" is subjective. To create a more effective alert, you'll need to define a specific threshold based on your historical data. You can analyze past incoming request trends to determine a baseline level and set the threshold as a percentage increase above that baseline (e.g., 20% increase over the average incoming requests for the past hour). Monitoring Period: The default monitoring period is 5 minutes. This helps filter out short-lived spikes and focus on sustained high request rates. You can adjust this period based on your needs. For highly volatile data streams, a shorter window might be appropriate. Action: Upon triggering, immediate actions can include: - Investigating recent logs from your data source to identify the cause of the increased request volume (e.g., scheduled data export, unexpected system behavior). - Assessing the impact on your Event Hubs resources. If the high request rate is causing resource exhaustion, consider scaling up resources or implementing throttling mechanisms at the data source if possible. - Analyzing trends in incoming requests to understand if this is a one-time event or an ongoing pattern. Implement proactive solutions if necessary (e.g., adjusting processing capacity or negotiating data transfer schedules with the data source). By customizing the threshold and leveraging this alert, you can proactively identify potential bottlenecks caused by unexpected spikes in incoming requests to your Azure Event Hubs. This helps ensure the smooth operation of your event streaming pipeline.

This alert detects a sudden and significant increase in the number of outgoing messages from your Azure Event Hubs namespace. The alert triggers when the outgoing message rate exceeds a level that is higher than your usual patterns for a continuous period (5 minutes). An unexpected spike in outgoing messages could indicate unintended behavior in your downstream processing or potential resource constraints within your Event Hubs. Customization Guidance: Threshold Calculation: "More than usual" is a good starting point, but a specific threshold based on historical data is more effective. Analyze past outgoing message trends to determine a baseline level. Set the threshold as a percentage increase above that baseline (e.g., 20% increase over the average outgoing messages for the past hour). Monitoring Period: The default monitoring period is 5 minutes. This helps filter out short-lived spikes and focus on sustained increases. You can adjust this period based on your needs. For highly volatile data streams, a shorter window might be appropriate. Action: Upon triggering, immediate actions can include: - Investigating recent logs from your downstream processing systems to identify the cause of the increased message volume (e.g., unexpected logic changes, processing errors). - Assessing the impact on your Event Hubs resources. If the high outgoing message rate is causing resource exhaustion, consider scaling up resources or optimizing processing logic in your downstream systems. - Analyzing trends in outgoing messages to understand if this is a one-time event or an ongoing pattern. Implement proactive solutions if necessary (e.g., adjusting downstream processing logic or negotiating data transfer schedules with downstream systems). By customizing the threshold based on your historical data and leveraging this alert, you can proactively identify potential bottlenecks caused by unexpected spikes in outgoing messages from your Azure Event Hubs. This helps ensure the smooth operation of your event streaming pipeline.