July 2024 Summaries

Checkly has secured $20 million in Series B funding led by Balderton, alongside existing investors Accel and CRV, to accelerate its development of code-first synthetic monitoring for modern DevOps, connecting OpenTelemetry to synthetics to help resolve issues 10x faster. The company aims to provide proactive monitoring that alerts engineers before users recognize performance and functional issues, using Monitoring as Code (MaC) to enable developers to configure, understand, and own the monitoring of their production services. With the introduction of Checkly Traces, the company is introducing OpenTelemetry traces to help engineers find issues, get alerted, and fix them 10x faster, reducing MTTR significantly. The funding will also be used to expand the team and enhance synthetics to proactively detect issues faster.

### Summary Playwright uses JavaScript promises under the hood, but it doesn't enforce TypeScript type checking or linting, leaving users vulnerable to runtime exceptions and hard-to-spot bugs. By adding TypeScript type checking and linting with `typescript-eslint`, developers can catch common Playwright mistakes before running tests, ensuring safer and more reliable end-to-end testing. The setup involves installing TypeScript, creating a `tsconfig.json` file, and configuring `typescript-eslint` for linting. With this approach, users can avoid unnecessary CI/CD minutes wasted on discovering typos and improve the overall developer experience.

Observability as Code (OaC) is a crucial aspect of modern software development, ensuring consistency, reliability, and scalability in monitoring practices. By automating and standardizing observability configurations, OaC enhances efficiency, supports collaboration, and accommodates infrastructure growth. Tools like Checkly make implementing Monitoring as Code (MaC) straightforward, offering comprehensive monitoring solutions while reducing costs and manual effort.

Checkly has announced the general availability of its new feature, Checkly Traces, which combines synthetic monitoring with distributed tracing to provide developers with a more comprehensive view of their application's performance. With this addition, development teams can detect, diagnose, and resolve issues faster than ever before, reducing Mean Time to Resolution (MTTR) and improving system reliability and user experience. The feature provides instant correlation between failing monitors and their underlying traces, clear visibility into each step of a request's journey, focused insights without data noise, and immediate full-stack visibility into every error. Checkly Traces is built on OpenTelemetry, the industry standard for instrumentation, and offers native support, optimized performance, complete performance overview without noise, and end-to-end visibility, ultimately simplifying observability for development teams.

This guide provides an overview of using OpenTelemetry (OTel) for monitoring Next.js applications, including its fundamentals, practical applications, and tips & tricks. OTel is an open-source observability framework that helps developers understand their apps' and infrastructure's performance and behavior by collecting telemetry data such as metrics, logs, and traces. Key features of OpenTelemetry include language-agnostic implementation, support for distributed tracing, and automatic instrumentation for popular frameworks and libraries like Next.js. To install the OTel SDK in a Next app, use the @vercel/otel wrapper package, which handles specific configurations related to Vercel's Edge environment. Enable the instrumentation hook in your next.config.js|ts file and install the relevant packages. The configuration auto-instruments basic HTTP handlers for page routes and API routes, emitting traces with Next.js and/or Vercel-specific tags. You can test OTel instrumentation locally by setting the OTEL_LOG_LEVEL environment variable to debug and using a local Docker container with some OTel tools like Jaeger for debugging. To add more automatic instrumentation, use the @opentelemetry/auto-instrumentations-node package and configure it accordingly. To remove noise from your instrumentation, exclude certain packages or features by setting their enabled property to false in the getNodeAutoInstrumentations() function. For custom instrumentation, create a custom trace and test it locally using the global trace object and startActiveSpan() function. When deploying OTel to production, keep costs down by head sampling on prod with either an AlwaysOnSampler or TraceIdRatioBasedSampler depending on your environment. Additionally, configure an API key in some header for sending data to a 3rd party backend compatible with OTel.

The authors of this text were optimizing the startup time of ephemeral pods in a Kubernetes cluster, which represented compute time and platform cost. They started by looking at the chunky AWS SDK, which added 70 megabytes to the package size, but switching to the V3 AWS SDK didn't improve start times as much as expected. The authors then drilled into finding the exact source of CPU time by adding a log line to track the time it took for each pod to be ready. They found that the startup time was around 3 seconds, which seemed high, and were concerned about the experience for new users of Checkly. To fix this issue, they shifted their order of operations to optimize performance, but still had excess time to prepare the pod. The authors then monkey-patched the `require` function to find the cause of slow starts, discovered that different versions of the AWS SDK were causing delays, and changed all versions to be the same version, which reduced startup times by 300 milliseconds, resulting in significant cost savings.

The text discusses the importance of stability and speed in end-to-end tests for websites, focusing on Playwright synthetic monitoring with Checkly. It highlights that the `page.goto()` action can cause delays due to waiting for all resources to be loaded, which is not necessary for testing UI actions and state changes. The author suggests using `waitUntil: "commit"` or `domcontentloaded` instead of `load` to reduce test execution times without compromising on test coverage. However, it also emphasizes the importance of monitoring network dependencies when adopting end-to-end testing with Playwright, as it can provide valuable insights into site performance and infrastructure issues. The text concludes that there is no one-size-fits-all solution, and the best approach depends on individual project requirements and priorities.