Operations | Monitoring | ITSM | DevOps | Cloud

When we introduced the Low Code Plugin (LCP) framework in February, the premise was simple: if a system has an API, you should be able to build a plugin for it — quickly, with minimal code, and in a way you can share with the community. The "AI-ready" part was deliberate. The framework was designed to work naturally with AI assistants, so the path from idea to working integration would be as short as possible. That design decision is now paying off.

Microsoft Purview is an enterprise-scale platform for managing data governance across your whole cloud estate. It is not just about ensuring the integrity of data stored in SQL databases — it spans the whole spectrum of data storage including blob storage, document databases, email and AI frameworks. It has an extensive list of features for organising and monitoring your enterprise data. This includes.

Once you've published more than a handful of KPIs, you eventually need a way to summarize them. A total cost. An overall health status. An organization-wide SLA. Something that lets you answer the big questions without opening ten different dashboards. Summarizing those into a handful of KPIs usually feels straightforward. You add things together, average them, or collapse several statuses into one. The dashboard becomes easier to read, and nothing looks obviously wrong.

APIs power almost everything we use today, from cloud platforms and monitoring tools to ticketing systems and internal applications. But no matter how useful an API is, the response usually arrives as raw JSON. That's perfectly fine for machines, but much less convenient for people. Whether you're debugging an endpoint, exploring a new service, or building dashboards for your team, you'll probably want a better way to visualize that data. Fortunately, there are several ways to visualize API responses.

AI is set to transform our technology landscape. For many of us working in software, it already has — developers are now writing more code, building more features, and deploying more applications, faster. For the teams supporting IT and software services that means more applications to support, across a greater breadth of technologies, and with more complexity (that is probably less well understood by the developers who created it). Your operational tooling needs to keep pace.

Getting your dashboards in the right hands is vital for many teams. This typically means that someone has to remember to check them, and that rarely happens consistently. Stakeholders miss weekly updates, managers ask for reports that already exist, and your carefully-built dashboards sit unread while people wait for someone to send them a screenshot. Scheduled sharing is the frictionless feature that solves this issue.

At first glance, Power BI and SquaredUp both look like dashboarding tools. In practice, they solve different problems. SquaredUp serves engineering teams and IT teams, including SREs, DevOps engineers, engineering managers, and technology leaders. It connects to monitoring, cloud, DevOps, and ITSM platforms. This gives teams a real-time insights into service health, performance, and key metrics in one place. Power BI is Microsoft's business intelligence platform, designed for analysts and business teams.

If you run Huntress across a fleet of client environments, you already know the console gives you a solid view of agent health, threat detections and incident reports. What it doesn't give you is a way to put that data next to everything else you're tracking, your PSA tickets, your other security tools, the rest of your stack, so you can see the whole client picture in one place.

Microsoft Defender does a great job protecting you and your organization from online threats. It is constantly working to detect and collect security data so you don’t have to worry about falling behind on incidents and vulnerabilities. The Defender portal can also provide great insights into that data, but connecting it to the rest of your stack is difficult.

In our previous article we looked at the basics of: In this article, we are going to take a deeper dive into some of the complexities of configuration as well as some of the nuances of analysing Claude telemetry. Before we dive into the code, let us just remind ourselves that our telemetry pipeline looks like this: That is, we are emitting Claude Code telemetry to an OpenTelemetry Collector. The telemetry is then exported to an Application Insights endpoint and stored in Log Analytics tables.