Datadog

190 posts

www.datadoghq.com/blog/engineering

Filter by tag

datadog3 min readCurated summary

How we built the Datadog heatmap to visualize distributions over time at arbitrary scale

Datadog uses DDSketch-powered distribution metrics and heatmaps to reveal performance patterns that percentile lines can hide. Heatmaps preserve the full shape of latency distributions across hosts and time, making distinct behavioral modes, seasonality, and outliers visible. The visualization is designed to remain scalable and readable even with hundreds of trillions of underlying datapoints. ## Why Unaggregated Distributions Matter - Line graphs reduce billions of events to a single value, such as p50, p99, or max. - Multiple percentile lines provide more context, but the selected percentiles remain arbitrary and can obscure important behavior. - Aggregated percentile changes may suggest that all requests are slowing when only one subset of traffic is changing. - Heatmaps expose separate “modes”—distinct groups of measurements with different behavior. - For example, periodic latency spikes may come from a low-latency benchmarking service rather than from a general degradation in the endpoint. - Filtering out an identified mode can reveal other patterns, such as daily seasonality in the remaining traffic. ## Building Heatmaps with DDSketch - DDSketch sacrifices a small amount of precision to represent extremely large numbers of observations efficiently. - Datadog sends histogram bins and counts to the frontend instead of transmitting every individual datapoint. - Limiting the number of bins keeps the payload size constant as traffic volume grows. - Counts use `float32`, supporting values up to approximately `3 × 10^38` per bin—far beyond practical monitoring volumes. - This allows heatmaps to represent massive datasets, including hundreds of trillions of datapoints. ## Preserving Resolution and Avoiding Aliasing - Heatmap requests contain time buckets, distribution bins, and counts. - Since bucket boundaries are shared across a request, Datadog stores those boundaries only once. - Boundaries must be explicit because distributions may use logarithmic rather than linear scales. - Time buckets need to align with the source data intervals. - Misaligned intervals create aliasing artifacts: for example, grouping 10-second data into 7-second buckets produces repeating count patterns such as `[1, 1, 2, 1, 1, 2, …]`. - Careful discretization preserves the resolution available in the original DDSketch data. ## Designing the Color Scale - The default palette begins with light blue, consistent with other single-series Datadog visualizations. - It transitions toward purple to match Datadog’s visual identity. - The scale avoids lingering on red, which can imply negative alerts, and ends in orange for the hottest values. - Color choices must communicate both the volume and structure of the distribution. ## Maintaining Dynamic Range - A few high-count bins can dominate a linear color scale, leaving most of the heatmap visually indistinguishable. - This is especially problematic for power-law distributions with a dense central mode and a long tail. - A linear scale may clearly show the main mode around 20 ms while hiding a smaller mode near 1 second. - Human brightness perception is nonlinear, approximately following a power law described by Stevens’ law. - Applying nonlinear color interpolation improves the visibility of meaningful differences across both dense regions and long tails. - This helps preserve distribution details that would otherwise be lost when the color range is dominated by outliers or highly concentrated buckets. Datadog’s heatmap approach combines DDSketch compression, aligned high-resolution buckets, and perceptually informed color scaling. For systems where averages or a handful of percentiles conceal important subpopulations, distribution heatmaps provide a more reliable way to investigate performance at scale.

Read original(opens in new tab)
datadog1 min readCurated summary

How we brought Datadog's data visualization to iOS: A focus on performance | Datadog

The provided content does not include the blog post’s actual article text. It contains Datadog’s navigation menu, product links, and a reference to an engineering post about bringing Datadog data visualization to iOS performance, so its technical argument and conclusion cannot be reliably summarized. ## Available Content - Datadog promotes its recognition as a Leader in the Gartner Magic Quadrant for Observability Platforms. - The navigation lists products across: - Infrastructure and application monitoring - Logs, databases, and data observability - Security - Digital experience monitoring - Software delivery - Service management - AI and platform capabilities - The referenced engineering URL suggests a post focused on implementing Datadog data visualization for iOS performance monitoring, but no implementation details are provided. Please provide the article body or a readable extraction of the post for a substantive technical summary.

Read original(opens in new tab)
datadog3 min readCurated summary

How we brought Datadog's data visualization to iOS: A focus on performance

Datadog built DogGraphs, a native SwiftUI graphing library, to support complex data visualizations across its iOS app and widgets. Because existing libraries did not meet its needs and the app supported iOS 14, the team had to optimize SwiftUI rendering without newer APIs such as `Canvas`. By combining careful API design, profiling, and a better understanding of SwiftUI’s update model, DogGraphs became a reusable framework used across multiple Datadog products. ## Building DogGraphs for Complex Visualizations - DogGraphs began with the Service Catalog and was designed to support additional Datadog products. - It needed to provide: - Native Swift and SwiftUI rendering - iOS 14 compatibility - Flexible, easy-to-use APIs - Datadog’s default visual style and behavior - Fast rendering for a responsive user experience - The library now powers visualizations in logs, services, dashboards, Bits AI, and mobile widgets. - It supports increasingly diverse graph types as new products integrate with the mobile application. ## A Declarative, Type-Safe API - DogGraphs uses Swift features such as result builders to describe complex graph configurations declaratively, in a style similar to SwiftUI. - Graph definitions can be generated dynamically from server-provided dashboard or widget configurations. - Compile-time type checking prevents invalid combinations, such as stacking incompatible Bar and Line graphs. - Progressive disclosure provides sensible Datadog defaults while still allowing customization when necessary. ## Profiling SwiftUI Performance Datadog’s visualizations can involve metrics, logs, traces, multiple aggregation strategies, arithmetic operations, axes, labels, scales, and color configuration. Query responses are preprocessed by a shared internal service so that formatting and visual behavior remain consistent across platforms. To optimize rendering, the team focused on two primary measurements: - **SwiftUI view body evaluations** - Excessive body evaluations can degrade performance, especially when many views are involved. - Expensive computation should be moved outside view bodies. - `_printChanges()` can reveal why a view is being reevaluated, though it is a private API unsuitable for production use. - **Time Profiler** - Instruments helps identify slow function calls and locate expensive work in the rendering pipeline. Important profiling scenarios included: - Initial graph rendering - Updates caused by window changes, tooltip selection, or layer visibility changes - Device rotation and light/dark mode changes - Interactions with unrelated views such as scroll views, toggles, and buttons ## Understanding SwiftUI’s Update Model The team used Apple’s “Demystify SwiftUI” session to build a mental model for how SwiftUI determines when views should update. - **Identity:** How SwiftUI determines whether an element is the same as, or different from, a previous element. - **Lifetime:** How SwiftUI tracks a view and its associated data over time. - **Dependencies:** How SwiftUI determines which changes require an interface update. - **Diffing:** SwiftUI compares view values to determine what changed, although the exact diffing mechanism is undocumented. Understanding these concepts helps developers explain unexpected view updates and identify the sources of rendering bottlenecks. ## Practical Recommendation For complex SwiftUI components, measure real interaction scenarios rather than relying on assumptions. Track body evaluations and expensive function calls, keep costly work out of `body`, and design APIs that provide efficient defaults while preserving type safety and flexibility.

Read original(opens in new tab)
datadog2 min readCurated summary

.NET Continuous Profiler: Exception and lock contention | Datadog

Datadog announces that it has been named a Leader in Gartner’s 2026 Magic Quadrant for Observability Platforms. The provided content, however, contains only the announcement link and Datadog’s website navigation; it does not include the underlying technical blog post or its arguments. ## Datadog’s Observability Offering - The site organizes products across: - Infrastructure monitoring, containers, Kubernetes, networks, serverless, and cloud costs - APM, continuous profiling, dynamic instrumentation, and agent observability - Database, data-stream, job, and quality monitoring - Logs, sensitive-data scanning, audit trails, and observability pipelines - Security, cloud security, SIEM, workload protection, and code security - Digital experience monitoring, session replay, synthetic monitoring, and error tracking - CI visibility, test optimization, code coverage, feature flags, and developer tools - Incident response, service catalogs, SLOs, workflow automation, and case management - AI agents, GPU monitoring, AI integrations, and MCP tooling ## Missing Blog Content - The URL path references “.NET Continuous Profiler – Part 3,” but the supplied excerpt does not contain that article’s text. - No profiling techniques, implementation details, performance findings, or conclusions are provided. - A meaningful technical summary would require the full blog post content. The available material supports only the conclusion that Datadog is promoting its recognition as a Gartner observability-platform Leader and positioning its broad product portfolio as part of that platform.

Read original(opens in new tab)
datadog3 min readCurated summary

.NET Continuous Profiler: Exception and lock contention

Datadog’s .NET continuous profiler can diagnose performance problems that CPU and wall-time profiling may miss: excessive exceptions and lock contention. Exceptions consume significant CPU and latency, while locks increase request latency through waiting rather than active computation. By collecting exception details and measuring contention duration with low overhead, the profiler helps developers identify the code and runtime conditions responsible. ## Exception Profiling - The CLR notifies the profiler through `ICorProfilerCallback::ExceptionThrown`, providing the exception’s `ObjectID`. - `ExceptionProvider::OnExceptionThrown` extracts details such as: - Exception type - Thread ID - Source location - The profiler maps the exception object to its `ClassID` using `ICorProfilerInfo::GetClassFromObject`. - Type names are resolved and cached by the `FrameStore`. - Exception messages require reading the private `System.Exception._message` field: - The profiler locates `System.Exception` in `mscorlib` or `System.Private.CoreLib`. - `GetModuleMetaData` provides access to assembly metadata. - `FindTypeDefByName` locates the type definition. - `GetClassFromTokenAndTypeArgs` obtains its `ClassID`. - `GetClassLayout` identifies field offsets. - `FindField` locates `_message`. - `GetStringLayout2` provides the string buffer and length needed to read the message. - Collecting exception counts by type, message, and call site makes it possible to replace expensive exception-driven control flow with cheaper checks such as `TryParse`. ## Lock Contention Monitoring - Standard .NET monitoring exposes contention counts, but generally not how long threads waited or where the contention originated. - The CLR emits: - `ContentionStart` when a thread begins waiting - `ContentionStop` when it acquires the lock - On .NET Framework, contention duration is calculated from timestamps recorded for each thread because `ContentionStop` does not include the duration. - Since .NET 8, `ContentionStart` includes the lock’s `ObjectID` and the ID of the thread holding it, allowing the profiler to identify the blocking thread. - .NET Framework exposes counters such as `Contention Rate / Sec` and `Total # of Contentions`; .NET Core provides `monitor-lock-contention-count` through `dotnet-counters`. - These counters alone do not reveal the duration or cause of waits. ## Consuming CLR Events - Since .NET 5, profilers can synchronously receive CLR events through `ICorProfilerCallback10::EventPipeEventDelivered`. - Datadog’s `ClrEventParser` interprets event payloads based on event IDs and keywords. - The parsed duration is passed to `ContentionProvider::OnContention`. - Runtime differences require version-specific handling because event payloads are not identical across .NET Framework and .NET Core. The practical recommendation is to profile both exception frequency and lock-wait duration, rather than relying only on CPU usage or contention counters. This reveals inefficient exception-based logic and identifies locks—and, on newer runtimes, the threads holding them—that materially affect application latency.

Read original(opens in new tab)
datadog1 min readCurated summary

Engineering spotlight: Marie-Laure Bardonnet | Datadog

The provided content does not include the actual blog post. It contains Datadog’s navigation menu and a promotional banner announcing its recognition as a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms, but no article text to summarize. ## Datadog’s Observability Announcement - Datadog promotes its recognition as a Leader in Gartner’s 2026 Magic Quadrant for Observability Platforms. - The linked announcement appears to be a marketing resource rather than the blog post itself. ## Datadog Product Areas Listed - Infrastructure monitoring, metrics, containers, Kubernetes, networking, serverless, and cloud costs - Application performance monitoring, profiling, dynamic instrumentation, and database monitoring - Log management, observability pipelines, and sensitive data scanning - Security, including cloud security, SIEM, workload protection, and code security - Digital experience tools such as RUM, session replay, synthetic monitoring, and error tracking - Software delivery, CI visibility, testing, feature flags, and code coverage - Service management, incident response, workflows, dashboards, and AI capabilities The article body or source text is needed for a meaningful section-by-section summary.

Read original(opens in new tab)
datadog3 min readCurated summary

Engineering spotlight: Marie-Laure Bardonnet

Marie-Laure Bardonnet’s Datadog career illustrates how engineers can grow through both technical and management paths. After working on Dashboards and Notebooks, she moved into distributed backend systems, eventually leading Datadog’s Logs engineering organization. Her approach emphasizes engineering-informed leadership, deliberate career planning, mentorship, and embracing unfamiliar challenges. ## From Web Engineering to Logs Leadership - Bardonnet joined Datadog full-time in 2017 after interning there. - She began on the Paris-based Dashboards team, where she helped: - Launch the Notebooks product. - Build the backend for a responsive Dashboard layout. - Encouraged by her manager, she transitioned into backend engineering and joined the Logs team. - Logs engineering involved real-time ingestion, processing, enrichment, storage, and querying of millions of log payloads daily. - As Datadog’s products developed shared technical requirements, Logs engineers collaborated closely with a centralized Platform team. - After one year as an individual contributor, Bardonnet became a team lead and later advanced to Engineering Manager II, overseeing both backend and frontend Logs teams. ## Balancing Product Delivery and Technical Health - Her role combines strategic planning, technical decision-making, people development, and recruiting. - At the start of each quarter, teams create OKRs that guide product and technical roadmaps. - Managers balance product priorities with: - Reliability and scalability. - Technical debt reduction. - Cross-team dependencies. - Bardonnet reviews RFCs, incident postmortems, and product documentation to help teams make sound decisions. - She supports both individual contributors and managers by identifying projects that build expertise and leadership skills. - She also participates in weekly hiring committees to recommend candidates and maintain consistent leveling. ## Structuring Teams for Future Growth - As organizations expand, Bardonnet focuses on restructuring teams to improve execution and create better growth opportunities. - Two questions guide this process: - What problems will the organization need to solve about a year from now? - How can everyone progress toward their next career step? - Logs leadership works with Product Management on a three-horizons plan to align future investments with customer needs. - Team design also considers whether each person has appropriately scoped work, meaningful challenges, and sufficient mentorship. ## Building a Self-Directed Career Path - Career planning begins by separating current responsibilities from the work someone ultimately wants to do. - Engineers should reflect on: - What work brings them satisfaction. - What they do well. - What they want to learn. - What legacy they want to leave. - Career goals should be reviewed continuously, organized across different planning horizons, and discussed with leaders. - A strong career path balances personal interests, strengths, learning opportunities, team needs, organizational priorities, and feedback. - Career direction is self-driven and may change over time, but managers and organizational leaders can help identify opportunities and create a suitable path. ## Growth Through Uncertainty - Datadog’s expanding platform and variety of engineering teams mean that career paths differ widely between employees. - Progression may be nonlinear and can require taking risks or accepting unfamiliar challenges. - Growth comes from leaving one’s comfort zone and learning through difficult problems. - Peer feedback helps employees assess whether they are progressing and feel supported. - Regardless of role or trajectory, employees contribute to Datadog’s culture by modeling high standards for quality and delivery. Bardonnet’s experience suggests that career growth is most effective when employees take ownership of their direction while seeking feedback, mentorship, and challenging opportunities from their organization.

Read original(opens in new tab)
datadogOriginal article

How we use Vale to improve our documentation editing process | Datadog (opens in new tab)

To manage a high volume of technical content across dozens of products, Datadog’s documentation team has automated its editorial process using the open-source linting tool Vale. By integrating these checks directly into their CI/CD pipeline via GitHub Actions, the team ensures prose consistency and clarity while significantly reducing the manual burden on technical writers. This "shift-left" approach empowers both internal and external contributors to identify and fix style issues independently before a formal human review begins. ### Scaling Documentation Workflows * The Datadog documentation team operates at a 200:1 developer-to-writer ratio, managing over 1,400 contributors and 35 distinct products. * In 2023 alone, the team merged over 20,000 pull requests covering 650 integrations, 400 security rules, and 65 API endpoints. * On-call writers review an average of 40 pull requests per day, necessitating automation to handle triaging and style enforcement efficiently. ### Automated Prose Review with Vale * Vale is implemented as a command-line tool and a GitHub Action that scans Markdown and HTML files for style violations. * When a contributor opens a pull request, the linter provides automated comments in the "Files Changed" tab, flagging long sentences, wordy phrasing, or legacy formatting habits. * This automation reduces the "mental toll" on writers by filtering out repetitive errors before they reach the human review stage. ### Codifying Style Guides into Rules * The team transitioned from static editorial guidelines stored in Confluence and wikis to a codified repository called `datadog-vale`. * Style rules are defined using Vale’s YAML specification, allowing the team to update global standards in a single location that is immediately active in the CI pipeline. * Custom regular expressions are used to exclude specific content from validation, such as Hugo shortcodes or technical snippets that do not follow standard prose rules. ### Implementation of Specific Linting Rules * **Jargon and Filler Words:** A `words.yml` file flags "cruft" such as "easily" or "simply" to maintain a professional, objective tone. * **Oxford Comma Enforcement:** The `oxfordcomma.yml` rule uses regex to identify lists missing a serial comma and provides a suggestion to the author. * **Latin Abbreviations:** The `abbreviations.yml` rule identifies terms like "e.g." or "i.e." and suggests plain English alternatives like "for example" or "that is." * **Timelessness:** Rules flag words like "currently" or "now" to ensure documentation remains relevant without frequent updates. By open-sourcing their Vale configurations, Datadog provides a framework for other organizations to automate their style guides and foster a more efficient, collaborative documentation culture. Teams looking to improve prose quality should consider adopting a similar "docs-as-code" approach to shift editorial effort toward the beginning of the contribution lifecycle.

datadog3 min readCurated summary

How we use Vale to improve our documentation editing process

Datadog’s Documentation team uses automated style linting to maintain clear, consistent prose across a large, fast-moving documentation repository. By integrating the open-source Vale linter into local authoring workflows and GitHub Actions, the team moves copy editing closer to the moment content is written. This reduces review effort, helps contributors fix issues themselves, and makes the team’s style guide executable rather than scattered across multiple documents. ## Documentation at Scale - The Documentation team grew from 7 to 14 writers while supporting roughly 200 developers per writer. - The repository includes documentation for 35 products and more than 1,400 internal and external contributors. - In 2023, the team merged more than 20,000 pull requests covering: - 30+ products - 65 API endpoints - 95 Marketplace integrations - 400 security compliance rules - 400 workflow actions - 650 integrations - An on-call writer reviews more than 40 pull requests per day, making automated consistency checks especially valuable. ## Why Manual Style Enforcement Falls Short - Writers must catch issues such as: - Jargon and wordy phrasing - Malapropisms - Mismatched tenses - Gendered language - Typewriter-era formatting habits - Organization-specific preferences - Contributors and AI writing tools may not know Datadog’s conventions, such as using serial commas, avoiding “via,” or eliminating time-sensitive words like “currently.” - Previously, style guidance had to be maintained in Confluence, review documentation, contributing guides, and repository wiki pages. ## Vale in Authoring and CI - Datadog adopted Vale, an open-source command-line prose linter, through the `datadog-vale` project. - A GitHub Action runs Vale against Markdown and HTML files in pull requests. - The repository’s `vale.ini` file identifies: - Where style rules are stored - Which rules should run - Which content formats should be checked - Automated comments appear in GitHub’s **Files Changed** view, allowing contributors to correct issues before a writer reviews the pull request. - Vale has reduced editing time and the mental burden on writers while improving contributor self-service. ## Turning the Style Guide into Rules - Existing editorial guidelines were converted into YAML-based Vale rules. - New rules can be added once and enforced everywhere, avoiding duplicated documentation. - Regular expressions exclude content that should not be linted, such as Hugo shortcodes. - Rules can identify both broad writing problems and precise organizational preferences. ## Examples of Vale Rules - A `words.yml` file can flag unnecessary jargon or “cruft” such as “easily” and “simply.” - An `oxfordcomma.yml` rule detects sentences that omit the Oxford comma and provides a correction message and link to the relevant style guidance. - An `abbreviations.yml` rule replaces Latin abbreviations with plain-English alternatives: - `e.g.` → “for example” - `i.e.` → “that is” - `etc.` → “and more” - Vale rules can define severity levels such as `suggestion` or `error`, include explanatory messages, link to documentation, and optionally perform replacements. Datadog’s approach demonstrates that documentation quality can be improved by treating prose standards like code standards: encode them as rules, run them continuously, and give authors immediate, actionable feedback. Teams with large contributor bases can use Vale and CI to make their style guide consistent, discoverable, and easier to maintain.

Read original(opens in new tab)
datadog2 min readCurated summary

.NET Continuous Profiler: CPU and wall time profiling | Datadog

Datadog’s page announces that the company was named a Leader in Gartner’s 2026 Magic Quadrant for Observability Platforms. The provided content mainly consists of Datadog’s product navigation, showing the breadth of its observability, security, digital experience, software delivery, and AI offerings; it does not include the blog article’s substantive text. ## Gartner Recognition - Datadog highlights its position as a Leader in the **Gartner Magic Quadrant for Observability Platforms 2026**. - The page links to a resource describing this recognition. ## Datadog’s Platform Coverage - **Infrastructure:** infrastructure, container, network, serverless, cloud cost, storage, and GPU monitoring. - **Applications:** APM, universal service monitoring, continuous profiling, dynamic instrumentation, and agent observability. - **Data and logs:** database monitoring, data-stream monitoring, log management, sensitive-data scanning, and observability pipelines. - **Security:** code, cloud, workload, application, API, SIEM, vulnerability, compliance, and entitlement management. - **Digital experience:** browser and mobile RUM, session replay, synthetic monitoring, product analytics, experiments, and error tracking. - **Software delivery and service management:** CI visibility, test optimization, feature flags, incident response, SLOs, workflow automation, and case management. - **AI capabilities:** AI agents, investigation tools, GPU monitoring, integrations, MCP services, and AI-assisted development. The supplied excerpt supports the conclusion that Datadog is presenting Gartner’s recognition as validation of its broad, integrated observability platform. A detailed technical summary would require the full blog post, which is not included here.

Read original(opens in new tab)
datadog3 min readCurated summary

.NET Continuous Profiler: CPU and wall time profiling

Datadog’s .NET profiler uses low-overhead thread sampling to collect CPU and wall-time profiles suitable for production. CPU profiling measures time spent running on a processor, while wall-time profiling captures delays caused by I/O, locks, or scheduling. The implementation tracks managed threads, walks their stacks, aggregates samples, and periodically uploads profiles, with platform-specific optimizations for Windows and Linux. ## CPU and Wall-Time Profiling - CPU profiling identifies code consuming processor cycles. - Wall-time profiling finds slow methods regardless of whether threads are running, blocked, or waiting for I/O. - ETW, Linux `perf`, and .NET enter/leave hooks provide profiling data but impose too much overhead or require elevated privileges. - Datadog instead samples threads at intervals, captures their call stacks, and assigns durations to the samples. ## Managed Thread Sampling - The profiler tracks managed threads created through: - The thread pool - `Task` and `async/await` - Explicit `Thread` instances - `ICorProfilerCallback` notifications such as `ThreadCreated` and `ThreadDestroyed` maintain the `ManagedThreadList`. - `StackSamplerLoop` captures stacks and sends raw samples to `CpuTimeProvider` and `WallTimeProvider`. - `SamplesCollector` aggregates provider data, while a shared Rust exporter uploads profiles to Datadog every minute. - An early C# implementation caused native worker threads entering managed code to appear as application threads. Removing that implementation eliminated accidental self-sampling. ## Native Runtime Threads - Server-mode garbage collection uses native threads that can compete with application threads for CPU. - Because the .NET profiling API does not expose these threads directly, the profiler identifies them by their .NET 5 names: - `.NET Server GC` - `.NET BGC` - Their CPU usage is displayed under a Garbage Collector frame in the flame graph. ## CPU Sampling and Performance Optimizations - Every 10 milliseconds, the profiler searches for runnable managed threads, skipping up to 64 non-runnable threads. - `IsRunning` determines whether a thread is executing on a CPU: - Windows uses `NtQueryInformationThread`. - Linux reads `/proc/self/task/<tid>/stat`. - CPU sample duration is calculated from the difference between the thread’s current and previously recorded CPU consumption. - The initial Linux implementation used `std::ifstream` and `std::getline`, allocating an 8 KB buffer for each sample. - Replacing them with lower-level C file-reading code eliminated allocations and reduced CPU usage. The original approach consumed nearly 500 MB of allocations and about 2% of total CPU in testing. ## Wall-Time Profiling and Code Hotspots - Wall-time profiles work with Datadog tracing to explain why requests are slow. - The tracer provides the profiler with a span ID when a thread handles a request. - To avoid repeated expensive P/Invoke calls, the profiler exposes a memory location that the tracer can update directly. - Because short requests may finish before their thread is sampled, the profiler samples an additional group of ten span-associated threads beyond the initial five. - The duration between consecutive samples of a thread is attributed to the later sample, so heavily threaded applications produce longer individual wall-time sample durations.

Read original(opens in new tab)
datadog4 min readCurated summary

.NET Continuous Profiler: Under the hood

Datadog’s .NET profiler is designed for continuous, low-overhead production monitoring rather than occasional diagnostic runs. It collects CPU, wall time, exceptions, lock contention, and allocation data, aggregates it into compact `.pprof` files, and links profiles to traces and services through runtime metadata. The post introduces the architecture and emphasizes preserving application performance as a central design requirement. ## What a Continuous Profiler Does - Profiling analyzes runtime performance and method call stacks. - It complements APM, which focuses on request latency, throughput, and errors. - The profiler also measures: - CPU usage - Wall time and method duration - Exceptions - Lock contention - Memory allocations and potential leaks - Unlike tools such as PerfView, dotTrace, dotMemory, and Visual Studio profilers, Datadog’s profiler is intended to run continuously in production with negligible overhead. - Continuous profiling avoids the need to recreate production traffic, security settings, hardware, and load in a separate environment. ## Datadog’s .NET Profiler Architecture - The profiler is composed of specialized profilers for different resource types. - Each profiler includes: - A sampler that collects raw data - A provider that exposes the collected samples - An aggregator combines samples from all profilers. - An exporter serializes the data into Google’s `.pprof` format and uploads it through the Datadog Agent. - Datadog’s backend processes the profiles for visualization and analysis. ## Sample Aggregation and Storage Each sample contains: - A call stack made up of method frames - Key-value labels, such as thread identifiers - A numeric value vector representing measurements like CPU consumption or wall time Samples with identical call stacks and labels are merged, and their numeric values are added together. This reduces duplication and produces smaller profile files—for example, repeated exceptions from the same code path and thread can be stored as one aggregated sample. The aggregation and `.pprof` serialization code is implemented in Rust and shared across Datadog’s Ruby, PHP, and other runtime profilers. ## Connecting Profiles to Traces and Services - Each uploaded profile includes process ID, host name, and runtime ID metadata. - The runtime ID uniquely identifies a .NET service running within a process. - This is important because a single .NET process can host multiple services, such as separate IIS applications running in different AppDomains. - The tracer communicates the mapping between runtime IDs, AppDomains, and service names. - Service names come from `DD_SERVICE`; if it is unset, the process name is used. - Datadog sends one profile per runtime ID every minute, so multiple profiles from one process may share a timestamp while representing different services. - Runtime IDs allow the backend to associate profiles with the correct traces and spans. ## Making .NET Call Stacks Easier to Read The .NET profiling API can expose compiler- and runtime-generated names that differ from the original source code. Datadog rewrites these frames to make visualized call stacks more understandable. - Constructors named `.ctor` are displayed using the class name. - Compiler-generated anonymous methods are rendered as the enclosing method followed by `_AnonymousMethod`. - Lambdas and local methods use an enclosing-method name with the `_Lambda` suffix. - Nested named methods such as `<DefiningMethodName>g__InnerMethodName|yyy_zzz` are displayed as `DefiningMethodName.InnerMethodName`. - Compiler-generated state-machine methods such as `MoveNext` are mapped back to the original source-level type and method names. ## Native and Managed Implementation Considerations - The team considered using Microsoft’s `TraceEvent` NuGet package to receive and parse CLR events in C#. - That approach would execute managed profiling code on the same CLR as the application being profiled. - Allocations made by the profiler could therefore increase garbage-collector pressure. - The post begins discussing how this performance concern influenced the implementation, but the provided excerpt ends before that design is explained. A production profiler must not only collect useful data but also minimize the memory and CPU costs of collecting it. Datadog’s architecture addresses this through specialized samplers, aggregation, compact serialization, runtime-aware trace association, and source-oriented call-stack cleanup.

Read original(opens in new tab)
datadog2 min readCurated summary

.NET Continuous Profiler: Under the hood | Datadog

Datadog is presented as a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms. The page highlights Datadog’s broad platform, spanning infrastructure, applications, data, logs, security, digital experience, software delivery, service management, and AI. However, the supplied content contains mostly navigation links rather than the blog post’s substantive analysis. ## Gartner Recognition - Datadog’s featured announcement is its designation as a **Leader** in the Gartner® Magic Quadrant™ for Observability Platforms. - The linked resource appears to provide the full Gartner-related announcement and evaluation details. ## Broad Observability Platform The listed Datadog capabilities cover: - **Infrastructure:** infrastructure, container, network, serverless, GPU, storage, and cloud-cost monitoring. - **Applications:** APM, universal service monitoring, continuous profiling, dynamic instrumentation, and agent observability. - **Data and logs:** database monitoring, data-stream monitoring, job and quality monitoring, log management, and observability pipelines. - **Security:** cloud security, SIEM, vulnerability management, code security, workload protection, and application/API protection. - **Digital experience:** browser and mobile RUM, session replay, synthetic monitoring, product analytics, and error tracking. - **Software delivery and service management:** CI visibility, test optimization, feature flags, incident response, SLOs, workflow automation, and case management. - **AI:** GPU monitoring, AI integrations, Bits AI agents, investigation tools, and an MCP server. ## Overall Takeaway The available material positions Datadog as a unified observability and operations platform with capabilities extending well beyond traditional infrastructure monitoring. For the Gartner evaluation criteria, supporting evidence, and detailed rationale behind the Leader designation, the full linked article or report would be required.

Read original(opens in new tab)
datadog1 min readCurated summary

Scaling Self-Serve Analytics: The Tools Empowering 5,000 Employees | Datadog

The provided content does not include the blog post itself. It contains Datadog’s navigation menu and a promotional banner announcing its position as a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms, but no technical discussion from the article. ## Available Content - The page appears to be a Datadog engineering blog post related to a CrunchConf talk on self-serve analytics. - The supplied text primarily lists Datadog products across: - Infrastructure and application monitoring - Data and log management - Security - Digital experience - Software delivery - Service management - AI capabilities - A separate banner promotes Datadog’s recognition by Gartner. ## Missing Article Details - No article title, introduction, body sections, technical examples, architecture, or conclusions are included. - The available text is insufficient to accurately summarize the post’s arguments or implementation details. Please provide the blog post’s main text or a complete extraction of the page for a substantive summary.

Read original(opens in new tab)
datadog3 min readCurated summary

Scaling self-serve analytics: The tools empowering 5,000 employees

Datadog scaled self-serve analytics from 200 to 5,000 employees by building an open-source-based platform around three pillars: trusted data, accessible tools, and organizational knowledge. The goal is to let employees answer routine questions and make informed decisions without relying on a centralized Data & Analytics team. This approach combines a single source of truth, self-service data pipelines and transformations, data discovery, quality monitoring, and training. ## The Purpose of Self-Serve Analytics - Datadog’s mission is to “empower everyone at Datadog to make data-informed decisions on their own.” - Self-service allows Data & Analytics teams to focus on higher-value initiatives instead of handling every request. - The organization identified three primary user profiles: - **Analytics Explorers:** Need discoverable data and ready-made reports. - **Analytics Builders:** Create reports and run advanced queries. - **Analytics Experts:** Expose new data, maintain business logic, and manage quality. ## Data as a Single Source of Truth - Datadog centralizes product, operational, and business data so consumers work from the same version of reality. - Its “Bring Your Own Data” (BYOD) tool lets teams expose their own data for analytics. - The shared data layer supports BI tools, notebooks, data discovery, programmatic access, and machine-learning models. - Trust depends on: - Consistent naming and modeling conventions. - Comprehensive documentation. - Continuous data-quality monitoring. ## Self-Serve Data Intake - Teams can connect internal and third-party data sources through integrations and BYOD. - The platform provides scheduling and a user interface for exposing or requesting datasets. - Pipeline observability covers: - Pipeline execution. - Data quality. - Actionable alerts when failures occur. ## Self-Serve Transformation - Analysts manage their departments’ business logic using SQL and dbt. - The development environment integrates with workflow management, metadata, and pipeline-run systems. - Enforced conventions keep the shared modeling layer consistent and understandable as more analysts contribute. - Analysts can inspect lineage, pipeline runs, quality checks, and alerts. ## Data Discovery and Metadata - Every employee can browse datasets and fields in the central data platform. - Search capabilities help users identify which data can answer a particular question. - Metadata explains: - The dataset’s origin and owner. - Definitions and intended meaning. - Where the data is used. - Sensitivity and reliability. - This context helps employees determine whether data is both relevant and trustworthy. ## Supporting Adoption - Tools alone are insufficient; Datadog also provides data knowledge, support, and training. - The Data & Analytics organization acknowledges that self-service has limits and works to mitigate risks such as misunderstanding data or applying incorrect business logic. - Success is tracked through adoption and the effectiveness of the overall self-service strategy. Datadog’s experience suggests that self-serve analytics scales best when data is treated as a product: centralized, documented, observable, and accessible through tools designed for users with different levels of expertise.

Read original(opens in new tab)