Developers

Overview

The Developers section contains reference materials for developing on Datadog. You may want to develop on Datadog if there is data you want to see in the product that you are not seeing. If this is the case, Datadog may already support the technology you need. See the table of commonly requested technologies to find the product or integration that may fulfill your needs.

Commonly requested technologies

If there is data you want to monitor with Datadog that you are not seeing, before building something custom, consider the following Datadog products and integrations:

	OpenMetrics	The Agent includes the OpenMetrics check capable of scraping Prometheus endpoints. Metrics retrieved by this integration are considered custom metrics.
	JMX Beans	The JMX integration enables collection of metrics, logs, and traces from JVM-based applications. For example, the JMX integration is already used for official integrations like Solr, Tomcat, Cassandra, and more. Metrics generated through JMX-based integrations not natively supported by Datadog are considered custom metrics.
	Custom metrics and integrations	Submit custom metrics for business stats using DogStatsD and the API. Datadog Agent integrations are Python files querying for metrics. All Agent code is open source, so it’s possible to write your own custom Agent check or custom Agent integration. The integrations-extras GitHub repository contains many community-developed custom integrations.
	Logs	Use Log Management to view, monitor, and analyze the logs from your applications and infrastructure. The Datadog Agent provides advanced functionality for sending logs to your Datadog account, but you can also submit logs directly to the Logs API.
	APM	APM and Continuous Profiler provide out-of-the-box performance dashboards for web services, queues, and databases to monitor requests, errors, and latency. You can use the Datadog Tracing Library for your environment and language, whether you are tracing a proxy or tracing across AWS Lambda functions and hosts, using automatic instrumentation, dd-trace-api, or OpenTelemetry.
	Processes	The Processes integration collects resource usage metrics for specific running processes on any host, such as CPU, memory, I/O, and others. Use Live Process Monitoring (which is like htop without having to SSH) to query across all your running processes.
	Files and Directories	The Directory check measures the age of files, the number of files in a directory, or the size of a directory."
	Endpoint	Use the Agent-based HTTP check, or configure Synthetic Monitoring from the Datadog application to validate if an endpoint or URL is running and accessible. Use either option to test both public and private endpoints. Combine with Service Level Objectives, or SLOs to define clear targets for performance.
	SNMP and Network Traffic	Network Device Monitoring enables you to collect SNMP (Simple Network Management Protocol) metrics emitted from network devices, such as routers, switches, and printers. Network Performance Monitoring tracks all network traffic in and out of a host, providing visibility into your network traffic between services, containers, availability zones, and any other tag in Datadog. Connection data at the IP, port, and PID levels is aggregated into application-layer dependencies between meaningful `source` and `destination` endpoints.
	Cloud Providers	All the major Cloud providers (AWS, Azure, GCP, Alibaba) emit metrics through APIs. Use the Datadog integration tiles in your account to configure these integrations, which use Datadog servers to crawl for metrics.
	Windows Performance Counters	Use the Windows performance counters integration to monitor performance and behavior in Windows environments.

If the solution you require is truly unavailable, you can contact Datadog Support to request a feature. You may also wish to create your own solution by using the reference materials in this section.

Partners and the Datadog Marketplace

You may also be a partner who wants to build on Datadog and contribute to the Datadog Marketplace or to Datadog’s community integrations.

To develop an offering, see the appropriate documentation:

Create an Agent-based Integration

Create an API Integration

Create a Log Integration

Build a Marketplace Offering

For more information about becoming a Datadog partner, navigate to the Datadog Partner Network.

Creating your own solution

Still not seeing the type of data that you need? Developers have several choices for sending unsupported data to Datadog.

DogStatsD is a metrics aggregation service that accepts custom metrics, events, and service checks.
Custom checks enable you to collect metrics from custom applications or systems. Custom Agent checks are suitable for many needs. For more advanced requirements like metrics preprocessing, you may choose to write an OpenMetrics check.
Integrations also enable you to collect metrics, events, and service checks from custom applications or systems. Integrations are reusable. You may keep your integration private, or write a public integration contributing to Datadog’s repository of community integrations to be used by other developers.

Custom check versus integration

The primary difference between custom checks and integrations is that integrations are reusable components that can become part of the Datadog’s ecosystem. They generally take more effort (time to develop) and are best suited for general use-cases such as application frameworks, open source projects, or commonly used software. For more unique scenarios, such as monitoring services that are not widely used outside your team or organization, writing a custom check may be the most efficient option.

However, you may choose to write an integration instead of a custom check if your particular use case requires you to publish and deploy your solution as a Python wheel (.whl). Metrics emitted through custom checks are considered custom metrics, which have a cost associated based on your subscription plan. However, once an integration gets accepted into the Datadog ecosystem, metrics that it emits are no longer considered custom metrics, and do not count against your custom metric count. For more information about how this might impact cost, see Datadog Pricing.

How do I create an integration?

Writing a public integration (that is, one that is part of Datadog’s ecosystem, can be installed with the datadog-agent integration command, and is accepted into Datadog’s integrations-extras or integrations-core repositories) requires more work than a private integration. These integrations must pass all ddev validate steps, have usable tests, and undergo code review. You, as the code author, are the active maintainer of the integration and are responsible for ensuring its functionality.

The initial goal is to generate some code that collects the desired metrics in a reliable way, and to ensure that the general integration framework is in place. Start by writing the basic functionality as a custom Check, then fill in the framework details from Create an Agent Integration.

Next, open a pull request against the integrations-extras repository. This signals to Datadog that you’re ready to start reviewing code together. Don’t worry if you have questions about tests, Datadog internals, or other topics—the Datadog Ecosystems team is ready to help, and the pull request is a good place to go over those concerns.

Once the integration has been validated for functionality, framework compliance, and general code quality, it is merged into integrations-extras where it becomes part of the Datadog ecosystem.

When deciding how to send unsupported data to Datadog, the main considerations are effort (time to develop) and budget (cost of custom metrics). If you are trying to see data that Datadog doesn’t support, start by deciding which method makes the most sense to start sending data:

Type	Effort	Custom Metrics	Language
DogStatsD	Lowest	Yes	Any
Custom check	Low	Yes	Python
Private integration	Medium	Yes	Python
Public integration	High	No	Python

Why create an integration?

Custom Checks are great for occasional reporting, or in cases where the data source is either unique or very limited. For more general use cases - such as application frameworks, open source projects, or commonly-used software - it makes sense to write an integration.

Metrics reported from accepted integrations are not counted as custom metrics, and therefore don’t impact your custom metric allocation. (Integrations that emit potentially unlimited metrics may still be considered custom.) Ensuring native support for Datadog reduces friction to adoption, and incentivizes people to use your product, service, or project. Also, being featured within the Datadog ecosystem is a great avenue for added visibility.

What’s the difference between a custom check and a service check?

A custom check, also know as a custom Agent check, lets you send internal service data to Datadog. A service check is much simpler and lets you monitor the up or down status of the specific service. Even though these are both checks, they have different functionality and can be used separately and together based on your monitoring needs. For more information about each, see the custom check, and service check documentation sections.