惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 司徒正美
M
MIT News - Artificial intelligence
博客园_首页
IT之家
IT之家
L
LangChain Blog
D
DataBreaches.Net
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Google DeepMind News
Google DeepMind News
Blog — PlanetScale
Blog — PlanetScale
人人都是产品经理
人人都是产品经理
博客园 - Franky
云风的 BLOG
云风的 BLOG
罗磊的独立博客
量子位
G
Google Developers Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
博客园 - 【当耐特】
博客园 - 叶小钗
S
SegmentFault 最新的问题
Stack Overflow Blog
Stack Overflow Blog
B
Blog
T
Tailwind CSS Blog
A
About on SuperTechFans
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com

Datadog | The Monitor blog

Introducing our open source AI-native SAST Instrument and monitor Boomi integration flows with OpenTelemetry and Datadog Not all index scans are equal: How we cut query latency by over 99% Platform engineering metrics: What to measure and what to ignore Integrate Recorded Future threat intelligence with Datadog Cloud SIEM CI/CD security: threat modeling using a MITRE-style threat matrix CI/CD security: How to secure your GitHub ecosystem Ingress NGINX is EOL: A practical guide for migrating to Kubernetes Gateway API Operating agentic AI with Amazon Bedrock AgentCore and Datadog LLM Observability: Lessons from NTT DATA Introducing the Datadog Code Security MCP Capture and analyze custom heatmaps in Session Replay Understand session replays faster with AI summaries and smart chapters Monitor ClickHouse query performance with Datadog Database Monitoring How we designed empathetic alert sounds for on-call engineers Search and act across Datadog to resolve issues faster with Bits Assistant Measure the business impact of every product change with Datadog Experiments Analyzing round trip query latency Configuring JavaScript caches for better performance Introducing Bits AI Dev Agent for Code Security Datadog achieves ISO 42001 certification for responsible AI Monitor Nutanix clusters, hosts, and VMs with Datadog Monitor Juniper Mist in Datadog A new Host Map for modern infrastructure Annotate traces to improve LLM quality with Datadog LLM Observability What’s new in Cloud SIEM: AI-powered investigations, enhanced threat intelligence, and scalable security operations Explore Kubernetes with native OpenTelemetry data Monitor Oracle Fusion Cloud Applications with Datadog Announcing the Datadog Terraform provider v4.0.0 Scaling Kubernetes workloads on custom metrics How to design cloud environments for AI-powered threat analysis
Monitor SQS with Data Streams Monitoring
2024-04-04 · via Datadog | The Monitor blog

Datadog Data Streams Monitoring (DSM) provides detailed visibility into your event-driven applications and streaming data pipelines, letting you easily track and improve performance. We’ve covered DSM for Kafka and RabbitMQ users previously on our blog. In this post, we’ll guide you through using DSM to monitor applications built with Amazon Simple Queue Service (SQS).

As a fully managed message queuing service, SQS helps ensure a highly reliable flow of messages between components through asynchronous processing. It can also increase the overall fault tolerance of your systems and applications by helping you decouple their components in order to prevent cascading failures.

In this post, we’ll show you how you can use DSM for SQS to gain critical visibility into your event-driven applications and track their performance by analyzing message throughput as well as end-to-end latency.

Gain critical visibility into your event-driven applications

DSM provides deep visibility into every component of your application so you can detect, pinpoint, and troubleshoot slowdowns and bottlenecks. The DSM topology map visualizes all of your pipeline components and their dependencies, including every service and queue, from end to end.

The DSM map visualizes all of your pipeline components and their dependencies

The DSM map shows throughput for each service as well as the time messages spend in your queues, clearly highlighting issues such as slow-performing services.

The DSM map displays throughput and other important information for each service

You can select any service or queue from the map to open a side panel of key health and performance metrics—which can help you troubleshoot issues such as abnormal throughput and suboptimal latency—as well as ownership information drawn from the Datadog Service Catalog, so you can easily coordinate with other teams.

Once you’ve installed Datadog’s SQS integration, you’ll have access to a range of supplementary SQS-specific metrics within DSM. You can access them by selecting any SQS queue from the DSM topology map.

Select any SQS queue from the DSM topology map to access a range of metrics

By configuring monitors to alert on these metrics if and when they breach expected limits, you can ensure a timely response to performance issues in your event-driven applications. (You can find our recommended monitors for SQS here.)

Important SQS metrics to monitor include:

  • Age of oldest message and number of messages delayed. These metrics can help you identify stale messages, suboptimal performance, and slowdowns in your application. A spike in either of these metrics can point you to issues such as bottlenecks.
  • Number of messages deleted, sent, and received. Comparing these metrics can bring to light a range of potential and ongoing performance issues. For example, if the number of messages sent is greater than the number of messages deleted (i.e., removed from the queue after having been retrieved), you may have a buildup of unprocessed messages in your queue. On the other hand, if the number of messages deleted is greater than the number of messages sent, there may be multiple consumers attached to one queue, which could cause issues downstream. Or, if the number of messages received is significantly greater than the number of messages sent, your application may be attempting to process the same messages repeatedly.
  • Sent message size. You can track this metric to catch and prevent errors and ensure that the volume of data flowing through your application is as expected. SQS only allows messages between 1 byte and 256 KiB in size. Messages exceeding the upper limit will trigger 413 (Request Entity Too Large) errors. Unexpectedly large or small messages may also indicate incorrect routing of messages in your application.

All of these metrics can help guide your troubleshooting and optimization efforts. Another important metric is the number of messages in dead-letter queues (DLQs). DLQs are a special type of queue for messages that have not been processed due to errors. DLQs play a key role in identifying and isolating failures in message processing, and, therefore, in monitoring the overall health of event-driven systems. DSM provides comprehensive visibility into your DLQs so you can spot recurring failures or misconfigurations that interfere with your message processing. You can inspect the messages accumulating in any DLQ directly from the DSM topology map or side panel.

Monitor the number of messages in your DLQs from the DSM side panel

You can also quickly inspect the contents of the messages in your DLQs for analysis. And DSM builds on this visibility by enabling you to manage your DLQs without leaving the Datadog platform. From within DSM, you can purge DLQ messages and reroute them back to their original queues for reprocessing once underlying issues have been resolved. All of this can help you optimize your incident response workflows, enabling teams to quickly investigate message failures, determine root causes, and restore healthy processing pipelines from DSM’s central interface.

Next, we’ll look at other ways DSM can help you track message throughput and latency so you can optimize the performance of your event-driven application and meet your SLAs.

Ensure the health of your event-driven applications by tracking throughput

With DSM, you can ensure that message throughput never overwhelms your event-driven application by tracking the volume of data flowing from each upstream (producing) service to each downstream (consuming) service in terms of both rate (messages per second) and size (bytes per second). By using these metrics to proactively identify any type of unexpected change in throughput, you can catch upstream performance issues and stay one step ahead of potentially disruptive impact on your downstream services.

Configuring monitors on these metrics can help you catch these changes in throughput and preserve the health of your application. For example, a significant increase in the volume of messages flowing through your SQS queues can be an important indicator that you need to scale up downstream services in order to ensure that they can accommodate the increased volume of data. A significant decrease may be a sign of a bottleneck or other issues upstream. DSM makes these and other common issues easy to catch with its out-of-the-box recommended monitors.

DSM provides a range of OOTB recommended monitors to help you catch common performance issues

Let’s say one of your monitors alerts you to a steep dropoff in the incoming throughput to one of your consumer services. You can select any upstream service via the DSM map to access its Throughput Summary. This summary provides a breakdown of key data on each upstream producer and downstream consumer service, including throughput and service ownership information, so you can quickly coordinate with service owners on the next steps toward resolution.

The Throughput Summary provides a breakdown of key data on each upstream producer and downstream consumer service

Next, we’ll look at how DSM provides a holistic, end-to-end view of the performance of your streaming data pipelines.

Measure the end-to-end latency of your streaming data pipelines

Datadog DSM enables you to measure end-to-end latency between any two services in your event-driven architecture. This lets you analyze the time it takes for messages to traverse your pipelines, allowing you to compare latencies when multiple producers or consumers are involved in one pathway.

Under the Measure tab in DSM, you can select the start and end services for your latency measurement from the DSM map or dropdown selector.

Once you’ve selected a pair of services for your measurement, DSM will show you latency metrics between those two endpoints. DSM also allows you to quickly create monitors on the latency between these services, helping you stay alert to suboptimal performance or slowdowns in your pipelines and pinpoint the sources of these issues. For example, if a monitor alerts on an increase in end-to-end p95 latency in a critical pipeline, you may want to evaluate your configurations and increase batch size to balance throughput and latency.

By providing end-to-end latency metrics, DSM can help you ensure that you are meeting your SLAs and determine where to focus your optimization efforts.

Expand your visibility into event-driven applications that use SQS

Whether you’re using Amazon SQS, Kafka, or RabbitMQ, Datadog DSM allows you to easily monitor and improve the health and performance of your event-driven applications and streaming data pipelines. To get started, you can check out our other blog posts on DSM and its integration with Datadog APM, as well as our docs. Readers of this post may also want to check out our SQS integration docs. If you’re new to Datadog, you can sign up for a 14-day free trial.