Operations | Monitoring | ITSM | DevOps | Cloud

When your applications raise errors, you need a way to make sense of them so you can set priorities, start troubleshooting, and gauge the success of your efforts. Errors can appear within the thousands of browser sessions and backend hosts running your software, making it difficult to find meaning within the noise. This is especially true of frontend errors, where seemingly endless permutations of browser version, location, and other environmental details can make it hard to spot trends.

As organizations build out their serverless footprint, they might find themselves managing hundreds or thousands of individual components (e.g., Amazon S3 buckets, Amazon DynamoDB tables, AWS SQS queues) for just a single application. At the same time, performance issues can crop up at any of these points, which means that having access to detailed observability data from your serverless functions is crucial for effective troubleshooting.

As cloud providers and infrastructure technologies grow their support for Windows containers, developers who use the Windows ecosystem are more and more able to enjoy the benefits of containerization. It’s quicker and easier than ever to modernize and deploy applications that use Windows-specific frameworks like .NET. Plus, Windows developers can use orchestration services like Kubernetes, Amazon ECS, or Docker Swarm to manage the complexity that containerized environments introduce.

If you are familiar with OpenTracing and OpenCensus, then you have probably already heard of the OpenTelemetry project. OpenTelemetry merges the OpenTracing and OpenCensus projects to provide a standard collection of APIs, libraries, and other tools to capture distributed request traces and metrics from applications and easily export them to third-party monitoring platforms.

When you’re on call and get paged at an inconvenient time, you need to be able to quickly determine the seriousness of the issue and act decisively to reduce system downtime. But pager notifications often don’t give you the information you need to investigate an issue from your mobile device, meaning that access to a laptop at all times is a must.

Amazon Kinesis Data Firehose is a service for ingesting, processing, and loading data from large, distributed sources such as clickstreams into multiple consumers for storage and real-time analytics. AWS recently launched a new Kinesis feature that allows users to ingest AWS service logs from CloudWatch and stream them directly to a third-party service for further analysis.

In Part 1, we looked at some best practices for getting started with creating effective test suites for critical application workflows. In this post, we’ll walk through best practices for making test suites easier to maintain over time, including: We’ll also show how Datadog can help you easily adhere to these best practices to keep test suites maintainable while ensuring a smooth troubleshooting experience for your team.

Client libraries are collections of code that make it easier for developers to write flexible and efficient applications that interface with APIs. Datadog provides client libraries so you can programmatically interact with our API to customize dashboards, search metrics, create alerts, and perform other tasks. We’re pleased to announce that we’ve developed and open-sourced two new client libraries for Java and Go in addition to our existing Ruby and Python libraries.

Reliable systems are vital to meeting customer expectations. Downtime not only hurts a company’s bottom line but can be detrimental to reputation. Our goal at Gremlin is to help enterprises build more reliable systems using Chaos Engineering. Whether your infrastructure is deployed on bare metal in a corporate-owned data center or as Kubernetes-orchestrated microservices in a public cloud, chaos experiments can help you find system weaknesses early, before they affect customers.