Operations | Monitoring | ITSM | DevOps | Cloud

The public cloud has revolutionized IT by making infrastructure on-demand, scalable, and self-service. However, this convenience comes at a price. In the cloud, engineers can instantly spin up resources and spend company money with the click of a button or a line of code, bypassing traditional procurement and finance approval processes.

As teams scale, managing synthetic monitoring checks manually in the UI becomes difficult and error-prone. When you're dealing with dozens of checks across multiple environments, teams experience inconsistent configurations, lack of version control, and difficulty tracking changes.

The Kubernetes Monitoring Helm chart is the easiest way to send metrics, logs, traces, and profiles from your Kubernetes clusters to Grafana Cloud (or a self-hosted Grafana stack). And version 4.0 is the biggest update the chart has ever received. Representing nearly six months of planning and development, it's designed to solve real pain points that users have hit as their monitoring setups have grown.

When you identify CPU or memory spikes in your services, it’s critical to understand why they’re happening. But switching between tools or crafting complex queries can slow you down when trying to pinpoint a root cause. This is why we’re excited to share that Profiles Drilldown, an application that lets you easily explore profiling data through an intuitive, point-and-click interface (no queries required), is now integrated with Grafana Cloud Knowledge Graph.

TL;DR: Most Kubernetes clusters waste GPU compute through over-provisioned pod requests and suboptimal node selection. This guide covers 10 tools that fix this across four layers: resource lifecycle (Kubex, ScaleOps, Cast.ai), hardware partitioning (GPU Operator, MIG, time-slicing), inference serving (Triton, KServe), and observability (DCGM Exporter, NFD). For most teams, the biggest gains are at the resource lifecycle layer: no model changes required.

The early era for AI was defined by experimentation, standing up isolated environments, and finding the first practical use cases. Today, the conversation is different. Enterprises are no longer asking whether AI matters. They are asking how to scale it sustainably, securely, and economically. That shift is giving rise to the AI factory: a repeatable, governed, production-ready environment where data scientists, platform teams, and application teams can build, train, deploy, and operate AI at scale.

You know the drill. An error fires, you get the stack trace, and then you spend the next 45 minutes tracing it backward through four services, two config files, and a deploy that happened three hours ago. You eventually find the root cause, but the path to get there was manual, slow, and entirely dependent on how well you already knew the codebase. We built AI-powered root cause analysis (RCA) for that kind of slog.

Kosli gives your organization a complete picture of software delivery - every build, scan, deployment, and compliance event tracked. Until now that picture was most useful to the people managing governance. However, developers shipping code had to ask someone else what versions of their code were running, how long it was taking to get to production, or what their deployment frequency was. Repositories change that.

In preparation for launching CertKit last week, I browsed the websites of a lot of related cybersecurity services. I don’t really understand what any of them do, but apparently, “trust” is a thing that can be sold now.

One of the first decisions teams face when adopting Konstruct is whether to run the control plane themselves or have it managed for them. While this can look like a simple deployment choice, it is really a question of operational responsibility, control, and how your platform needs to evolve over time. Both models exist to solve the same underlying problem: providing a consistent, GitOps-driven platform across teams and environments.