Operations | Monitoring | ITSM | DevOps | Cloud

Identifying bottlenecks during times of high load is critical to building a scalable software platform. Stress testing is one way to simulate high load on a system and allows you to proactively capture potential bottlenecks before they impact customers. Once a solution is implemented to address the bottleneck, you need a way to measure success and find a new limit. See how HashiCorp Cloud Platform (HCP) has developed a stress testing framework which heavily relies on Datadog’s custom metric capabilities in combination with some out of the box integrations to give HCP engineers a comprehensive view of their platform and how they used these insights to scale their concurrent data-plane provisioning by 300%.

When customer-impacting downtime happens, it’s crucial that responders are prepared and can resolve these issues as quickly as possible. Knowing the right tools to use, from wherever you are working from, will help to have a well-defined strategy in place to come together as a team, work the problem, and get to a solution quickly. In this roundtable discussion, PagerDuty and Datadog engineers chat about incident responses and how we use all the tools at our disposal to respond quickly and effectively.

Often when completing a migration project, you’re having your organisation straddle between two systems. You’re fighting habits and changing attitudes while also attempting to complete a high-risk operation. Every software team at one stage in their career will have to complete a migration. Whether it’s to improve scalability and performance, or transition between an on-prem to cloud solution, you’ll need a deep understanding of your current environment to create a strategy that minimises downtime for your team.

In April 2021, HashiCorp completed the Consul Global Scale Benchmark where Consul updated 172,000+ services running on 10,000 nodes on AWS in under 1 second. Over the course of the experiment, we logged over 1.8 Billion log events in Datadog.

At Vacasa, AWS accounts represent the unit of isolation for distinct applications & services in our software ecosystem, providing security benefits and operational autonomy for our teams as we scale. Managing accounts at this scale requires strong DevOps practices to maintain security, operational sanity, and uniform observability across the system. In this talk, we’ll cover the benefits of such an approach, the practices that make it possible, and the important role Datadog plays.

When application delivery performance issues happen, observability is critical to diagnosing the problem at hand. The adage “it’s always DNS” means that observability must extend to the foundational layers of the application delivery and access networking stacks. Yet granting administrative access to core network services like DNS and DHCP may run contrary to an organization’s least-privileged access policies. In this session, attendees will learn how global internet companies and enterprises use NS1 and Datadog to provide democratized DNS observability and reach optimal application performance.

Observability is trending. Organizations that rely on cloud infrastructure and cloud applications prioritize observability initiatives to get control over their business’s applications. At the same time, we see the “gap” between the on-premises infrastructure and “non-cloud” infrastructure is becoming bigger. Examples are End User Computing (EUC) and Global networks (SD-WAN).

Using managed services is all very well, but how do you get the data you need from the different services into Datadog so you can see it all in one place? This session will walk through the configuration for bringing your Aiven-managed Apache Kafka service metrics into your Datadog explorer. You’ll see how to filter the metrics to focus on specific topics or consumer groups, and how to use the Aiven client to create a repeatable, scriptable setup. This session is recommended for anyone living in the as-a-Service world who cares about data and is interested in using metrics to optimize their Kafka clusters.