Hermann  Frami

Hermann Frami


Serverless Plugin Datadog

Datadog recommends the Serverless Framework Plugin for developers using the Serverless Framework to deploy their serverless applications. The plugin automatically enables instrumentation for applications to collect metrics, traces, and logs by:

  • Installing the Datadog Lambda library to your Lambda functions as a Lambda layer.
  • Installing the Datadog Lambda Extension to your Lambda functions as a Lambda layer (addExtension) or subscribing the Datadog Forwarder to your Lambda functions' log groups (forwarderArn).
  • Making the required configuration changes, such as adding environment variables or additional tracing layers, to your Lambda functions.

Getting started

To quickly get started, follow the installation instructions for Python, Node.js, Ruby, Java, Go, or .NET and view your function's enhanced metrics, traces, and logs in Datadog.

After installation is complete, configure the advanced options to suit your monitoring needs.


Each version of the plugin is published with a specific set of versions of the Datadog Lambda layers. To pick up new features and bug fixes provided by the latest versions of Datadog Lambda layers, upgrade the serverless framework plugin. Test the new version before applying it on your production applications.

Configuration parameters

To further configure your plugin, use the following custom parameters in your serverless.yml:

siteSet which Datadog site to send data to, such as datadoghq.com (default), datadoghq.eu, us3.datadoghq.com, us5.datadoghq.com, or ddog-gov.com. This parameter is required when collecting telemtry using the Datadog Lambda Extension.
apiKey[Datadog API key][7]. This parameter is required when collecting telemetry using the Datadog Lambda Extension. Alternatively, you can also set the DATADOG_API_KEY environment variable in your deployment environment.
appKeyDatadog app key. Only needed when the monitors field is defined. Alternatively, you can also set the DATADOG_APP_KEY environment variable in your deployment environment.
apiKeySecretArnAn alternative to using the apiKey field. The ARN of the secret that is storing the Datadog API key in AWS Secrets Manager. Remember to add the secretsmanager:GetSecretValue permission to the Lambda execution role.
apiKMSKeyAn alternative to using the apiKey field. Datadog API key encrypted using KMS. Remember to add the kms:Decrypt permission to the Lambda execution role.
envWhen set along with addExtension, a DD_ENV environment variable is added to all Lambda functions with the provided value. Otherwise, an env tag is added to all Lambda functions with the provided value. Defaults to the stage value of the serverless deployment.
serviceWhen set along with addExtension, a DD_SERVICE environment variable is added to all Lambda functions with the provided value. Otherwise, a service tag is added to all Lambda functions with the provided value. Defaults to the service value of the serverless project.
versionWhen set along with addExtension, a DD_VERSION environment variable is added to all Lambda functions with the provided value. When set along with forwarderArn, a version tag is added to all Lambda functions with the provided value.
tagsA comma separated list of key:value pairs as a single string. When set along with extensionLayerVersion, a DD_TAGS environment variable is added to all Lambda functions with the provided value. When set along with forwarderArn, the plugin parses the string and sets each key:value pair as a tag on all Lambda functions.
enableXrayTracingSet true to enable X-Ray tracing on the Lambda functions and API Gateway integrations. Defaults to false.
enableDDTracingEnable Datadog tracing on the Lambda function. Defaults to true.
enableDDLogsEnable Datadog log collection using the Lambda Extension. Defaults to true. Note: This setting has no effect on logs sent by the Datadog Forwarder.
monitorsWhen defined, the Datadog plugin configures monitors for the deployed function. Requires setting DATADOG_API_KEY and DATADOG_APP_KEY in your environment. To learn how to define monitors, see To Enable and Configure a Recommended Serverless Monitor.
captureLambdaPayload[Captures incoming and outgoing AWS Lambda payloads][17] in the Datadog APM spans for Lambda invocations. Defaults to false.
enableSourceCodeIntegrationEnable [Datadog source code integration][18] for the function. Defaults to true.
subscribeToApiGatewayLogsEnable automatic subscription of the Datadog Forwarder to API Gateway log groups. Requires setting forwarderArn. Defaults to true.
subscribeToHttpApiLogsEnable automatic subscription of the Datadog Forwarder to HTTP API log groups. Requires setting forwarderArn. Defaults to true.
subscribeToWebsocketLogsEnable automatic subscription of the Datadog Forwarder to WebSocket log groups. Requires setting forwarderArn. Defaults to true.
forwarderArnThe ARN of the Datadog Forwarder to be subscribed to the Lambda or API Gateway log groups.
addLayersWhether to install the Datadog Lambda library as a layer. Defaults to true. Set to false when you plan to package the Datadog Lambda library to your function's deployment package on your own so that you can install a specific version of the Datadog Lambda library ([Python][8] or [Node.js][9]).
addExtensionWhether to install the Datadog Lambda Extension as a layer. Defaults to true. When enabled, it's required to set the apiKey and site.
excludeWhen set, this plugin ignores all specified functions. Use this parameter if you have any functions that should not include Datadog functionality. Defaults to [].
enabledWhen set to false, the Datadog plugin stays inactive. Defaults to true. You can control this option using an environment variable. For example, use enabled: ${strToBool(${env:DD_PLUGIN_ENABLED, true})} to activate/deactivate the plugin during deployment. Alternatively, you can also use the value passed in through --stage to control this option—see example.
customHandlerWhen set, the specified handler is set as the handler for all the functions.
failOnErrorWhen set, this plugin throws an error if any custom Datadog monitors fail to create or update. This occurs after deploy, but will cause the result of serverless deploy to return a nonzero exit code (to fail user CI). Defaults to false.
integrationTestingSet true when running integration tests. This bypasses the validation of the Forwarder ARN and the addition of Datadog Monitor output links. Defaults to false.
logLevelThe log level, set to DEBUG for extended logging.

To use any of these parameters, add a custom > datadog section to your serverless.yml similar to this example:

    apiKeySecretArn: "{Datadog_API_Key_Secret_ARN}"
    enableXrayTracing: false
    enableDDTracing: true
    enableDDLogs: true
    subscribeToAccessLogs: true
    forwarderArn: arn:aws:lambda:us-east-1:000000000000:function:datadog-forwarder
      - dd-excluded-function


If you are using a bundler, such as webpack, see Serverless Tracing and Webpack.


You may encounter the error of missing type definitions. To resolve the error, add datadog-lambda-js and dd-trace to the devDependencies list of your project's package.json.

If you are using serverless-typescript, make sure that serverless-datadog is above the serverless-typescript entry in your serverless.yml. The plugin will automatically detect .ts files.

  - serverless-plugin-datadog
  - serverless-typescript

Disable Plugin for Particular Environment

If you'd like to turn off the plugin based on the environment (passed via --stage), you can use something similar to the example below.

  stage: ${self:opt.stage, 'dev'}

  staged: ${self:custom.stageVars.${self:provider.stage}, {}}

      dd_enabled: false

    enabled: ${self:custom.staged.dd_enabled, true}

Serverless Monitors

There are seven recommended monitors with default values pre-configured.

MonitorMetricsThresholdServerless Monitor ID
High Error Rateaws.lambda.errors/aws.lambda.invocations>= 10%high_error_rate
Timeoutaws.lambda.duration.max/aws.lambda.timeout>= 1timeout
Out of Memoryaws.lambda.enhanced.out_of_memory> 0out_of_memory
High Iterator Ageaws.lambda.iterator_age.maximum>= 24 hrshigh_iterator_age
High Cold Start Rateaws.lambda.enhanced.invocations(cold_start:true)/
>= 20%high_cold_start_rate
High Throttlesaws.lambda.throttles/aws.lambda.invocations>= 20%high_throttles
Increased Costaws.lambda.enhanced.estimated_cost↑20%increased_cost

To Enable and Configure a Recommended Serverless Monitor

To create a recommended monitor, you must use its respective serverless monitor ID. Note that you must also set the DATADOG_API_KEY and DATADOG_APP_KEY in your environment.

If you’d like to further configure the parameters for a recommended monitor, you can directly define the parameter values below the serverless monitor ID. Parameters not specified under a recommended monitor will use the default recommended value. The query parameter for recommended monitors cannot be directly modified and will default to using the query valued as defined above; however, you may change the threshold value in query by re-defining it within the options parameter. To delete a monitor, remove the monitor from the serverless.yml template. For further documentation on how to define monitor parameters, see the Datadog Monitors API.

Monitor creation occurs after the function is deployed. In the event that a monitor is unsuccessfully created, the function will still be successfully deployed.

To create a recommended monitor with the default values

Define the appropriate serverless monitor ID without specifying any parameter values

    addLayers: true
      - high_error_rate:

To configure a recommended monitor

    addLayers: true
      - high_error_rate:
          name: "High Error Rate with Modified Warning Threshold"
          message: "More than 10% of the function’s invocations were errors in the selected time range. Notify @data.dog@datadoghq.com @slack-serverless-monitors"
          tags: ["modified_error_rate", "serverless", "error_rate"]
          require_full_window: true
          priority: 2
            include_tags: true
            notify_audit: true
              ok: 0.025
              warning: 0.05

To delete a monitor

Removing the serverless monitor ID and its parameters will delete the monitor.

To Enable and Configure a Custom Monitor

To define a custom monitor, you must define a unique serverless monitor ID string in addition to passing in the API key and Application key, DATADOG_API_KEY and DATADOG_APP_KEY, in your environment. The query parameter is required but every other parameter is optional. Define a unique serverless monitor ID string and specify the necessary parameters below. For further documentation on monitor parameters, see the Datadog Monitors API.

    addLayers: true
      - custom_monitor_id:
          name: "Custom Monitor"
          query: "max(next_1w):forecast(avg:system.load.1{*}, 'linear', 1, interval='60m', history='1w', model='default') >= 3"
          message: "Custom message for custom monitor. Notify @data.dog@datadoghq.com @slack-serverless-monitors"
          tags: ["custom_monitor", "serverless"]
          priority: 3
            enable_logs_sample: true
            require_full_window: true
            include_tags: false
            notify_audit: true
            notify_no_data: false
              ok: 1
              warning: 2

Breaking Changes


  • When used in conjunction with the Datadog Extension, this plugin sets service and env tags through environment variables instead of Lambda resource tags.
  • The enableTags parameter was replaced by the new service, env parameters.


  • The Datadog Lambda Extension is now the default mechanism for transmitting telemetry to Datadog.

Opening Issues

If you encounter a bug with this package, let us know by filing an issue! Before opening a new issue, please search the existing issues to avoid duplicates.

When opening an issue, include your Serverless Framework version, Python/Node.js version, and stack trace if available. Also, please include the steps to reproduce when appropriate.

You can also open an issue for a feature request.


If you find an issue with this package and have a fix, open a pull request following the procedures.


For product feedback and questions, join the #serverless channel in the Datadog community on Slack.

Author: DataDog
Source Code: https://github.com/DataDog/serverless-plugin-datadog 
License: View license

#serverless #datadog #plugin 

Serverless Plugin Datadog
Milan  Reilly

Milan Reilly


How to Monitor Containerized ASP.NET Core Applications

Being able to track requests across all of an application’s service and process boundaries helps you identify issues with services and their dependencies, such as slow database calls or overloaded servers. In this post, we’ll walk through how to instrument a sample containerized ASP.NET Core application to send traces to Datadog for monitoring.

#aspdotnet #datadog 

How to Monitor Containerized ASP.NET Core Applications
Aisu  Joesph

Aisu Joesph


Learn About Azure Cosmos DB integrated Cache with Datadog

Datadog’s Azure Cosmos DB integration now includes metrics that can help you track the health and performance of your integrated cache and dedicated gateway. Once you enable the Azure integration, you can clone and customize the out-of-the-box Azure Cosmos DB dashboard to get deep insight into your entire storage layer.

⭐️You can see more at the link at the end of the article. Thank you for your interest in the blog, if you find it interesting, please give me a like, comment and share to show your support for the author.

#azurecosmosdb #azure #datadog 

Learn About Azure Cosmos DB integrated Cache with Datadog
Ruthie  Bugala

Ruthie Bugala


Learn About Azure App Services with Datadog Serverless View

👉Azure App Service is a platform-as-a-service (PaaS) offering for deploying applications to the cloud without worrying about infrastructure. App Service’s “serverless” approach removes the need to provision or manage the servers that run your applications, which provides flexibility, scalability, and ease of use. However, App Service also introduces infrastructure-like considerations that can impact performance and costs. 

⭐️Thank you for your interest in the blog, if you find it interesting, please give me a like, comment and share for everyone to know. Thanks! ❤️️

#datadog #azureappservices  #azure 

Learn About Azure App Services with Datadog Serverless View
Aisu  Joesph

Aisu Joesph


How To Offer Datadog In Azure Marketplace

👉Datadog is a monitoring and analytics platform for large-scale applications. It encompasses infrastructure monitoring, application performance monitoring, log management, and user-experience monitoring. In this video, we learn how Datadog's provisioning in Azure Marketplace allows you to manage Datadog in the Azure console as an integrated service.

⭐️Thank you for your interest in the blog, if you find it interesting, please give me a like, comment and share for everyone to know. Thanks! ❤️️

#azure #datadog 

How To Offer Datadog In Azure Marketplace
Nabunya  Jane

Nabunya Jane


How to Deploy Monitor Azure Government with Datadog

👉Azure Government is a dedicated cloud for public sector organizations that want to leverage Azure’s suite of services in their highly regulated environments. As these organizations migrate their applications to Azure Government, they need to ensure that they can maintain visibility into the status and health of their entire infrastructure. We’re excited to announce that we’ve partnered with Azure to enable you to collect low-latency metrics from all of your workloads and Azure services hosted on Azure Government.

⭐️Thank you for your interest in the blog, if you find it interesting, please give me a like, comment and share for everyone to know. Thanks! ❤️️
#datadog #azure #azuregovernment 

How to Deploy Monitor Azure Government with Datadog

How to Monitor Datadog Database

Learn how Datadog Database Monitoring delivers deep visibility into your databases with historical query performance metrics, explain plans, and host-level metrics.


How to Monitor Datadog Database
Wasswa  Meagan

Wasswa Meagan


How to Check Health with Terminus and Datadog

We should be aware of whether our application is healthy. One way to do that would be to make various API requests to confirm it manually. It might not be the most elegant solution, though. The answer can be health checks. With them, we can verify if various aspects of our system work properly. Creating a health check boils down to exposing an endpoint that tests our application and throws an error if it is unhealthy. Thanks to tools such as Datadog, we can periodically call the health check endpoint to make sure that everything works as expected.

#datadog #terminus 


How to Check Health with Terminus and Datadog
Ruth  Nabimanya

Ruth Nabimanya


Datadog Announces Deep Database Monitoring 2021

Database queries are often the root cause of incidents and application performance issues. Databases do not store historical query performance metrics, which makes it extremely difficult to understand the context around an issue and identify trends. Datadog Database Monitoring builds on the existing ability to monitor the general health and availability of the database and underlying infrastructure by allowing users to pinpoint the exact queries that impact application performance and user experience.

#database #datadog 

Datadog Announces Deep Database Monitoring 2021

Native Bindings for Datadog's SDK (unofficial)

Datadog Flutter .Community implementation of native bindings for Datadog's SDK. This is not an official package.


  1. Generate a client token from Datadog through the Settings > API panel (under Client Tokens).
  2. Initialize:
  3. Associate RUM and log events (optional):

:warning: Your Podfile must have use_frameworks! (Flutter includes this by default) and your minimum iOS target must be >= 11. This is a requirement from the Datadog SDK.


In its default implementation, log data will only be transmitted to Datadog through Logger records. print statements are not guaranteed to be captured.

ddLogger = DatadogLogger(loggerName: 'orders');
// optionally set a value for HOST
// ddLogger.addAttribute('hostname', <DEVICE IDENTIFIER>);

ddLogger.addTag('restaurant_type', 'pizza');

// add attribute to every log
ddLogger.addAttribute('toppings', 'extra_cheese');

// add atttributes to some logs
ddLogger.log('time to cook pizza', Level.FINE, attributes: {
  'durationInMilliseconds': timer.elapsedMilliseconds,

Real User Monitoring

RUM adds support for error, event, and screen tracking. The integration requires additional configuration for each service.

  1. Supply an application ID to initialize:
  2. Acknowledge TrackingConsent at initialization or later within your application. Events will not be logged until trackingConsent is .granted. This value can be updated via DatadogFlutter.updateTrackingConsent.
  3. Automatically track screens:
  4. Automatically report errors:
  5. Manually track additional events:
  6. Manually track additional errors:
  7. Manually track network requests or resources:


Associate your HTTP requests with your backend service. Be sure to setup (usually immediately after DatadogFlutter.initialize):

await DatadogTracing.initialize();

For one-off requests, instantiate a fresh client:

final httpClient = DatadogTracingHttpClient();
// make requests
final response = await httpClient.get('http://example.com');

For frameworks that use an internal client like Brick or Dio, compose the client:

  client: DatadogTracingHttpClient();
// or compose if another client is already being used:
  client: DatadogTracingHttpClient(GZipHttpClient());


How do I disable logging when I'm developing locally?

By default, the DatadogFlutter default constructor will send all logs from Logger to Datadog. To ignore, set bindOnRecord:

DatadogLogger(bindOnRecord: false)

And log conditionally later:

Logger.root.onRecord.listen((record) async {
  if (shouldSendToDatadog) {
  } else {
 await DatadogRum.startResourceLoading(
   url: 'https://example.com',
   method: RUMResources.get,
 await DatadogRum.stopResourceLoading(
   statusCode: 500,
   errorMessage: 'Internal Server Error' ,
 try {
   throw StateError();
 } catch (e, st) {
   DatadogRum.instance.addError(e, st);
 GestureDetector(onTap: () {
 void main() async {
   // Capture Flutter errors automatically:
   FlutterError.onError = DatadogRum.instance.addFlutterError;

   // Catch errors without crashing the app:
   runZonedGuarded(() {
   }, (error, stackTrace) {
     DatadogRum.instance.addError(error, stackTrace);
   // ...your material config...
   home: HomeScreen(),
   navigatorObservers: [
 await DatadogFlutter.initialize(
   clientToken: myDatadogClientToken,
   serviceName: 'my-app-name',
   environment: 'production',
   iosRumApplicationId: myiOSRumApplicationId,
   androidRumApplicationId: myAndroidRumApplicationId,
 await DatadogFlutter.setUserInfo(id: <YOUR_USER_ID>);
 await DatadogFlutter.initialize(
   clientToken: myDatadogClientToken,
   serviceName: 'my-app-name',
   environment: 'production',

Use this package as a library

Depend on it

Run this command:

With Flutter:

 $ flutter pub add datadog_flutter

This will add a line like this to your package's pubspec.yaml (and run an implicit dart pub get):

  datadog_flutter: ^1.2.0

Alternatively, your editor might support flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:datadog_flutter/datadog_flutter.dart'; 


import 'dart:async';
import 'package:datadog_flutter/datadog_observer.dart';
import 'package:datadog_flutter/datadog_rum.dart';
import 'package:datadog_flutter/datadog_logger.dart';
import 'package:datadog_flutter/datadog_tracing.dart';
import 'package:flutter/material.dart';
import 'package:logging/logging.dart';

import 'package:datadog_flutter/datadog_flutter.dart';

// Ideally, your token is encrypted if it must be committed or its added at build
void main() async {

  await DatadogFlutter.initialize(
    clientToken: DATADOG_CLIENT_TOKEN,
    environment: 'production',
    androidRumApplicationId: 'YOUR_IOS_RUM_APPLICATION_ID',
    iosRumApplicationId: 'YOUR_IOS_RUM_APPLICATION_ID',
    serviceName: 'my-cool-app',
    trackingConsent: TrackingConsent.granted,
  final ddLogger = DatadogLogger();
  // Capture Flutter errors automatically:
  FlutterError.onError = DatadogRum.instance.addFlutterError;

  await DatadogTracing.initialize();

  // Catch errors without crashing the app:
  runZonedGuarded(() {
  }, (error, stackTrace) {
    DatadogRum.instance.addError(error, stackTrace);

class MyApp extends StatelessWidget {
  final Logger otherLogger;
  final DatadogLogger datadogLogger;

  MyApp(this.datadogLogger, {Key? key})
      : otherLogger = Logger('other logger'),
        super(key: key);

  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      home: Scaffold(
        appBar: AppBar(
          title: Text('My Flutter Homepage'),
        body: Center(
          child: TextButton(
            onPressed: () => otherLogger.fine('hello datadog'),
            child: Text('Log to Datadog'),
      navigatorObservers: [

Download Details:

Author: greenbits

Source Code: https://github.com/greenbits/datadog_flutter

#flutter  #datadog 


Native Bindings for Datadog's SDK (unofficial)
Aisu  Joesph

Aisu Joesph


Expand your monitoring reach with Datadog's enhanced Azure integration

Microsoft Azure is one of the fastest-growing cloud platforms in the world, offering a wide range of products for deployment, testing, and cloud storage. Datadog is committed to maintaining an extensible monitoring solution for Azure’s growing ecosystem that doesn’t require lots of manual configuration. That’s why we are excited to announce the following enhancements to Datadog’s Azure integration:

Datadog ingests Azure Monitor metrics faster than ever

Up-to-date metrics are essential for maintaining comprehensive visibility into any environment. We have always collected all standard metrics from Azure Monitor, but thanks to our close collaboration with Microsoft’s development team, these metrics now appear in Datadog significantly faster than they did in the past. By reducing Azure Monitor metric collection latency by over 40 percent, we’ve set a new industry standard and ensured that all of your Datadog dashboards and monitors contain the most up-to-date information. You can now rest assured that changes in key metrics, such as deployment failures on Azure App Service and exceeded resource limits on Azure SQL Database, will be reflected in Datadog as quickly as possible.

A streamlined log collection mechanism for Azure logs

Azure logs provide vital, detailed information about activity in your Azure environment, which can help you assess the severity of an error or outage—and identify its root cause. Datadog Log Management enables you to store every ingested log in one place—and provides you with sophisticated search, filter, and alerting tools to help you get the most out of your log data. Our recent updates to our Azure integration include an easily deployable template that streamlines the Azure log collection process. Users can simply modify and run a Powershell script to create and configure the template, so Azure Platform logs can start flowing into Datadog in minutes.

Monitor more Azure services with new out-of-the-box dashboards

At Datadog, we are always looking for opportunities to expand our out-of-the-box offerings, so users can start monitoring the technologies they rely on as quickly as possible. That’s why we are happy to introduce brand new out-of-the-box dashboards for two of Azure’s most popular services: Azure CosmosDB and Azure API Management Service.

Azure CosmosDB is a multi-model, globally distributed, and fully managed NoSQL Database service for modern app development. CosmosDB’s flexible approach enables its users to store data in a variety of forms, which can be accessed through several popular APIs, such as MongoDBCassandra, and Gremlin. Datadog’s new Azure CosmosDB dashboard provides immediate insight into the performance of your CosmosDB instance. For example, you can visualize platform-level metrics, such as total request units consumed, as well as API-level metrics, such as the number of Cassandra keyspaces created, in order to better understand your CosmosDB usage.

#integration #azure #datadog

Expand your monitoring reach with Datadog's enhanced Azure integration

Monitor Azure Service Health events with Datadog

Azure Service Health continuously notifies you of issues that may affect the availability of your environment, such as service incidents, planned maintenance periods, or regional outages.

We’ve recently enhanced our Azure integration to include additional support for monitoring Service Health issues, enabling you to keep tabs on the health of your Azure environment and take proactive measures to mitigate downtime. Within minutes of setting up the integration, you’ll see rich, contextual Service Health events appear within your event stream, where you can monitor and correlate them with data from more than 450 infrastructure technologies (including other Azure services), all in one place.

Get a cohesive view of Azure Service Health issues

When a new issue is identified, Azure reports an Azure Service Health event indicating the nature of the problem and affected resources and regions. Azure then continuously updates the status of the issue via a series of events until it is finally resolved.

With Datadog, you can clearly monitor every stage of Service Health issues within our event stream under the “Azure Service Health” namespace. Datadog collects these events automatically for all subscriptions being monitored with our Azure integration. You’ll see each issue cohesively grouped by its Tracking ID, enabling you to get full visibility into its current status and progression, from start to finish. This makes it easier for you to keep track of high-priority issues and follow up on their progress.

Slice and dice Azure Service Health events using tags

The Azure Events API provides valuable metadata around each Service Health event. Datadog automatically converts this metadata into key:value tags that you can use to easily filter and search through all your events. To point out a few:

  • service: The impacted Azure service(s) (e.g., Azure Virtual Machines)
  • status: The status of the event (i.e., active or resolved)
  • region: The impacted Azure region(s) (e.g., US East, Global)
  • incident_type: The type of Service Health event (ServiceIssue, PlannedMaintenance, SecurityAdvisory, HealthAdvisory)
  • level: The severity level of the event (i.e., informational, warning, or critical)

In addition to these tags, each Azure Service Health event includes a description that captures the essence of the issue from the perspective of the Azure engineers investigating the problem. Some events may also contain mitigation steps for addressing the issue and reducing its impact.

#integration #datadog #azure service health

Monitor Azure Service Health events with Datadog
Ruthie  Bugala

Ruthie Bugala


Monitor Azure IoT Edge with Datadog

Azure IoT Edge is a Microsoft Azure service that allows you to run containerized workloads on IoT devices. With IoT Edge and Azure IoT Hub, Azure’s device-management platform, organizations across science, manufacturing, energy production, and other industries can provision their IoT devices and workloads at the edge of their cloud networks for immediate in-unit computing, a necessity when running AI algorithms or parsing large datasets directly on IoT devices.

Because IoT infrastructure is widely distributed and may contain multiple types of devices or software versions, monitoring the full scope of your system can be a challenge. To help Azure users expand their IoT monitoring reach, we’re excited to announce that Datadog now integrates with IoT Edge. You can easily deploy the Datadog Agent across all of your connected Azure IoT Edge devices using Azure IoT Hub. Once you’ve installed the Agent, Datadog’s integration automatically ingests both device and module metrics and logs. Datadog’s customizable out-of-the-box Azure IoT Edge dashboard visualizes key metrics from your devices, modules, and IoT Edge Hub(s), including device RAM and CPU usage, module operation latency, client connections and hub syncs, and network throughput, giving you immediate insight into your entire IoT infrastructure.

Monitoring on the edge

Devices running IoT Edge execute workloads through modules, which are portable, Docker-compatible containers that you can deploy to your devices via the IoT Hub. Each IoT Edge device in your fleet runs two modules that are its primary runtime components: the IoT Edge Agent and the IoT Edge Hub.

The IoT Edge Agent manages the other modules on the device, monitoring their status and ensuring they are running. The IoT Edge Hub acts as a communication manager between modules on your devices. The IoT Edge Hub also forwards device telemetry to the IoT Hub in order to synchronize communication between your devices and the rest of your cloud infrastructure.

Datadog’s integration includes built-in service checks that help you keep track of the health and connectivity of the IoT Edge Agents and IoT Edge Hubs across your entire fleet. You can easily set alerts to notify you if devices go offline unexpectedly.

#integration #datadog #azure iot edge

Monitor Azure IoT Edge with Datadog

Automatically create and manage Kubernetes alerts with Datadog

Kubernetes enables teams to deploy and manage their own services, but this can lead to gaps in visibility as different teams create systems with varying configurations and resources. Without an established method for provisioning infrastructure, keeping track of these services becomes more challenging. Implementing infrastructure as code solves this problem by optimizing the process for provisioning and updating production-ready resources.

Now, you can go one step further by easily incorporating monitoring as code into your existing Kubernetes infrastructure with the Datadog Operator. We’ve extended the Operator to include a DatadogMonitor custom resource definition (CRD). Much like Prometheus alerting rules, which allow you to configure alert conditions based on Kubernetes metrics, Datadog CRDs enable you to automatically create and manage monitors for Kubernetes resources via your Kubernetes deployment manifests and tools like kubectl.

We’ll show how to get started with the Datadog Operator and look at a few examples of Datadog monitors you can create to proactively track and alert on the performance of your Kubernetes objects.

#kubernetes #datadog

Automatically create and manage Kubernetes alerts with Datadog
Abdullah  Kozey

Abdullah Kozey


Datadog — Azure API Management logs

Azure resources generally have good integration with App Insights for logs and APM (Application performance monitoring). But sometimes your monitoring stack is with a 3rd Party company, like New Relic, Zabbix or Datadog.

In this guide, we are going to how to log every single request hitting an Azure API management into Datadog.

What is Datadog?

Datadog is a monitoring service for cloud-scale applications, providing monitoring of servers, databases, tools, and services, through a SaaS-based data analytics platform. [Wikipedia]

Logging from API Management

The base documentation where I learned this logging flow.

1. Add the event hub namespace

2. Create the event hub in the namespace:

3. Enable the diagnostic logging:

4. Create the Function app:

5. Add the configuration:

6. Deploy the function code:

7. Test the function in isolation


That isn’t a straight forward integration, but hopefully, I showed that is possible to integrate API management logs with Datadog, and that a complex manual setup like this can be automated using Terraform.

#datadog #azure

Datadog — Azure API Management logs