Back to the lexicon

Lexicon · Guide

Azure monitoring built to keep telemetry in your own tenant

What Azure monitoring covers, why Log Analytics costs climb faster than the estate they watch, and what changes when the platform runs in your tenant.

Talk to an architect

Definition

Azure monitoring is the practice of collecting and reading metrics, logs and traces from the Azure services your applications run on, from virtual machines and AKS clusters through to App Service, Functions and managed databases, so you can tell whether the platform and the applications on it are healthy. It overlaps with infrastructure monitoring, and for most teams it starts with Azure Monitor and the Log Analytics workspace underneath it, which is also where the cost question turns up for the first time.

Your Azure monitoring bill grows faster than the estate it is meant to explain, and finance wants to know why. Most platforms collect telemetry inside your subscription, ship it somewhere else to be stored, then charge you again for bytes you already paid to generate and to move. This guide covers why that happens, and what changes when the platform runs inside the tenant instead.

Azure monitoring priced for the subscription it runs in

Azure monitoring costs tend to rise faster than the estate they cover, and teams end up managing the monitoring bill as closely as the systems it is meant to watch. Four patterns show up again and again once a footprint is large enough to matter.

Monitoring agents collect telemetry inside your Azure subscription and then ship it somewhere else to be stored. You pay for storage and compute once inside Azure, then pay again for the same bytes on a second invoice, and egress charges are usually collected on the way out. The gap between the two widens with every service you instrument.

Where Tsuga fits

We built Tsuga for the problems above, so the architecture is the answer rather than a feature list. It runs where your workloads already run, and the consequences follow from that one decision.

Tsuga Engine installs into your Azure environment through infrastructure as code, and runs inside your own virtual network encrypted with keys that stay under your control. Nothing about the deployment requires telemetry to leave the subscription that produced it, and our control plane connects over mutual TLS to serve the dashboard without ingesting your data.

Is Tsuga right for you?

At Tsuga we are honest about fit, because Azure monitoring is not one size fits all. Tsuga earns its place when Azure telemetry has become a budget line of its own, typically six figures or more a year, and when data residency or regulatory obligations mean that telemetry cannot sit in someone else's cloud. It also suits teams running logs, metrics, traces and APM across a large Azure estate, and teams who would rather not let a default sampling rate decide which evidence survives an incident.

The opposite conditions point the other way. A small Azure footprint with modest, predictable volume does not yet have the problem this architecture solves, and neither does a team with no compliance or residency obligations to answer to. If Azure Monitor and Log Analytics already cover what you need at a price you are comfortable with, that is a good outcome and you should keep them, and we would rather say so now than three months into an evaluation.

Frequently asked questions

Azure Monitor stays useful for platform metrics and alerts on Azure services, and Tsuga ingests from it rather than replacing it. What changes is where the long-lived telemetry lives and what it costs to keep, because storage and query run inside your own subscription instead of a vendor's.

Own your observability

Azure monitoring should not cost more than the workloads it watches. Talk to an architect about deploying Tsuga inside your own Azure subscription, and we will model the cost against the telemetry volume you actually produce.

Talk to an architect

Related terms

Back to the lexicon