February 2019 Summaries

Microsoft Azure users can now benefit from new out-of-the-box dashboards for several Azure services in Datadog, including Azure DB for PostgreSQL, Azure DB for MySQL, Azure Blob Storage, Azure Table Storage, Azure Queue Storage, and Azure Service Bus. These dashboards provide faster visibility into the health of Azure services without any additional setup. Users can also modify these dashboards to include data from related services and infrastructure components. Datadog unifies metrics, distributed request traces, and logs in a single platform, enabling users to seamlessly navigate between all sources of data while maintaining context during exploration and troubleshooting.

The new release of out-of-the-box dashboards for Azure services in Datadog provides users with faster visibility across their dynamic cloud environments. These pre-selected dashboards allow teams to start viewing meaningful information about their services immediately, identify key metrics, and clone templates to build custom views of their environment. The dashboards provide real-time assessments of the health and performance of specific Azure services, such as PostgreSQL, MySQL, Blob Storage, Table Storage, Queue Storage, and Service Bus, with features like automatic scoping and correlation of metrics across resources. Additionally, Datadog unifies metrics, request traces, and logs in a single platform, enabling seamless navigation between these data sources while maintaining context. The new dashboards are available for users who have enabled the Azure integration, and teams can start exploring them right away, either by cloning templates or utilizing template variables to scope down visualizations.

Amazon MQ is an AWS-managed service that provides a cloud-based message broker using Apache ActiveMQ. It supports various APIs and protocols like JMS, AMQP, MQTT, OpenWire, STOMP, and WebSocket. Datadog's Amazon MQ integration allows users to monitor key metrics from their messaging infrastructure, ensuring proper functioning of brokers sending and receiving messages. Amazon MQ creates and manages brokers that route messages through queues or topics. It supports various configurations and provides high availability by launching instances in other availability zones. Security features include security groups, API authorization through IAM, and automatic encryption. Datadog's integration helps track broker resource usage and message destination metrics to ensure proper scaling and configuration of the messaging infrastructure.

Amazon MQ is a cloud-based, AWS-managed service that offers many advantages of being part of the AWS ecosystem. It allows users to ensure that their brokers are sending and receiving messages properly by providing visibility into key metrics from their messaging infrastructure. Amazon MQ works by creating and managing brokers that route messages through queues or topics, supporting multiple APIs and message protocols like JMS, AMQP, MQTT, OpenWire, STOMP, and WebSocket. The service provides high availability, security features, and scalability, making it easy to migrate existing applications to the cloud. Datadog's integration with Amazon MQ gives users visibility into key metrics from their messaging infrastructure, allowing them to monitor and alert on message broker and destination metrics, ensuring that their brokers have enough resources to handle the volume of messages for their use case.

Amazon Elastic Container Service (ECS) is an orchestration service for Docker containers running within the Amazon Web Services (AWS) cloud. It allows users to declare the components of a container-based infrastructure, and ECS will deploy, maintain, and remove those components automatically. The resulting ECS cluster lends itself to a microservice architecture where containers are scaled and scheduled based on need. ECS integrates with other AWS services, allowing for features such as routing container traffic through Elastic Load Balancing or attaching an Auto Scaling policy to your ECS deployment. It also works with Fargate, which lets users deploy their containers straight to the AWS cloud without needing to provision EC2 instances. Monitoring in layers is important when using ECS, and two groups of metrics provide comprehensive visibility across every layer of your ECS infrastructure: resource metrics and status metrics. These metrics help ensure the availability and performance of your ECS deployment.

In this article, various techniques are discussed for monitoring Amazon Elastic Container Service (ECS) deployments. The methods include using the Amazon CloudWatch console, AWS CLI, third-party monitoring tools that query CloudWatch and ECS API, and tools for monitoring Docker. It also covers how to use these tools to monitor both levels of your ECS deployment - service status and resource usage from underlying compute and storage infrastructure. The article provides detailed instructions on using each method and highlights their benefits in ensuring efficient ECS management.

Datadog offers comprehensive tools for monitoring Amazon ECS deployments, enhancing visibility into clusters, services, and container performance. By integrating with AWS and deploying the Datadog Agent, users can automatically collect and visualize metrics, logs, and request traces from ECS environments, including both Fargate and EC2 launch types. The AWS integration collects ECS metrics from CloudWatch and the ECS API, while the Datadog Agent gathers more granular host-level and container-specific data. Datadog's dashboards provide real-time insights, allowing users to track resource utilization, detect anomalies, and manage ECS infrastructure effectively. Additionally, Datadog's Application Performance Monitoring (APM) and Autodiscovery features enable users to troubleshoot applications by tracing requests across containers and configuring monitoring dynamically as containers are scheduled and terminated. With tools like the container map and host map, users can visualize the ECS infrastructure, and by setting up alerts, they can ensure the availability and performance of ECS clusters. Datadog also offers options for log collection from ECS containers, either directly from EC2 instances or via CloudWatch Logs with AWS Lambda, thereby providing a flexible solution for monitoring complex, scalable applications running on ECS.

ECS (Amazon Elastic Container Service) is an orchestration service that runs Docker containers within the Amazon Web Services (AWS) cloud. It allows users to declare the components of a container-based infrastructure and ECS will deploy, maintain, and remove those components automatically. ECS integrates with other AWS services such as Elastic Load Balancing and Auto Scaling. The service reports resource metrics, including CPU and memory utilization, and provides key metrics for monitoring ECS status. Users can configure task definitions to reserve resources for entire tasks and individual containers, and ECS calculates resource metrics based on reservation and utilization. Monitoring ECS infrastructure is essential to ensure the availability and performance of applications running in the cloud.

This post surveys some techniques you can use to monitor both levels of your ECS deployment, including the Amazon CloudWatch console, the AWS CLI, and third-party monitoring tools that query CloudWatch and the ECS API. It provides detailed information on how to use the CloudWatch console for ECS monitoring, including creating graph widgets, configuring CloudWatch alarms, and tracking the number of running tasks. The post also covers using the AWS CLI to query the ECS API and collecting metrics from individual containers using traditional Docker monitoring tools or by querying the ECS task metadata endpoint.

The MEAN stack is an increasingly popular choice for developing dynamic web applications due to its combination of complementary technologies such as MongoDB, Express, Angular, and Node.js. Monitoring the MEAN stack can be challenging as it grows in complexity; however, Datadog provides comprehensive insights into your application and underlying infrastructure. By installing and configuring the Datadog Agent, enabling specific integrations for each component of the MEAN stack, and instrumenting your application with Datadog APM, you can gain deeper visibility into the performance of your applications and troubleshoot issues more effectively.

The MEAN stack is a popular choice for developing dynamic applications. It bundles together complementary technologies, including MongoDB, Express, Angular, and Node.js. Datadog provides comprehensive monitoring capabilities for the MEAN stack, enabling developers to gain deeper insights into application performance, logs, and infrastructure. The guide covers installing and configuring the Datadog Agent, enabling integrations with MongoDB, Express, and Node.js, and instrumenting applications with Datadog APM. With Datadog's 850+ integrations, users can monitor their MEAN stack alongside other services running in their infrastructure.

CockroachDB is a highly resilient distributed SQL database that aims to make it easy to scale horizontally by adding nodes instead of manually sharding the database. The database is built to be resilient and highly available, recovering from node failures automatically by repairing and rebalancing. Cockroach Labs also offers a fully-managed version called CockroachDB Dedicated, which enables users to focus on developing and optimizing their application without worrying about database provisioning and cluster management. Datadog's integration with CockroachDB allows users to visualize and alert on hundreds of metrics, track data store workloads, track high-level cluster health, set up thresholds for dashboards, monitor database resource utilization, and monitor performance in context alongside other technologies.

NGINX is a popular HTTP server and reverse proxy server that serves static content very efficiently and reliably using relatively little memory. It can also be used as a mail proxy and a generic TCP proxy. Monitoring NGINX allows users to catch resource issues within the server itself, as well as problems developing elsewhere in their web infrastructure. Key NGINX metrics include requests per second, server error rate, and request processing time. By monitoring these metrics, users can gain valuable insights into the health and activity levels of their web infrastructure.

OpenTracing, OpenCensus, and OpenMetrics are projects aimed at creating standards for application performance monitoring and collecting metric data. While they overlap in terms of goals, each project takes a different approach to observability and instrumentation. OpenMetrics focuses on creating a standard format for exposing metric data, while OpenTracing and OpenCensus focus on creating a standard for distributed tracing. Both projects are vendor-neutral but rely on the backend projects and vendors to implement their own tracers and instrumentation. Distributed tracing is critical for understanding how a request moves across multiple services, packages, and infrastructure components, especially in microservices architecture. Projects like OpenTracing, OpenCensus, and OpenMetrics try to address this by providing standards for instrumentation and collecting data, enabling APM vendors and developers the ability to build portable tracers and instrumentation to track a request as it travels through each service within an application.

OpenMetrics aims to create a standard format for exposing metric data, while OpenTracing and OpenCensus focus on creating a standard for distributed tracing. The projects share similarities in their goals but take different approaches. OpenMetrics uses the Prometheus exposition format as its starting point, aiming to include new enhancements and improvements. OpenTracing provides a standardized API for tracing, with a comprehensive interface between traces. OpenCensus is a platform for metric collection and tracing, offering a collection of language-specific libraries with APIs for sampling and metric collection. Both projects are vendor-neutral but have differences in their approaches and supported backends. The OpenMetrics project is currently part of the Cloud Native Computing Foundation (CNCF) sandbox, while OpenTracing and OpenCensus are part of the CNCF as well. The two tracing projects share similarities in their goals but differ in their approach to distributed tracing, with OpenTracing focusing on a standardized API for tracing and OpenCensus providing a platform for metric collection and tracing.