Logging
Goal: Know what your workspace logs, change what it sends, and read whether it is still on.
Every Azure resource OpenX builds in your subscription sends its logs to your landing zone's Log
Analytics workspace. OpenX turns this on as part of building: the same Deploy that makes a
resource also gives it a diagnostic setting named openx, pointing at that workspace. You do not set
anything up by hand, and nothing is sent anywhere outside your own subscription.
Before you start
- A provisioned landing zone. See Manage Private CALZ. Its Log Analytics workspace is where every log goes.
The three switches
Logs come in three classes. Each class is one switch.
| Switch | What it sends | Default |
|---|---|---|
| Audit | Who changed what, and when. | On |
| Errors | What failed, and why. | On |
| Traffic | Every request and read. | Off |
Traffic is off by default because it is the largest share of log volume, and Azure bills Log Analytics by the volume it takes in.
The landing zone also turns on your subscription's activity log - who created, changed or deleted what in the subscription - and sends it to the same workspace. It is on by default.
Change the defaults
Open Environment > Manage Private CALZ. Once the landing zone is provisioned, the window has a Logs section with the three switches and Subscription activity log.
- Flip the switches you want.
- Press Save log settings.
Saving applies at once to the landing zone's own resources: its Key Vault, its storage and its Log Analytics workspace. Every other node picks the new defaults up on its next Deploy. See Deploy.
Each node starts from the landing zone
The landing zone's switches are the defaults for the whole workspace. A node that sends logs uses them until someone saves its own value for a switch:
- The node's own value, when one is saved.
- Otherwise, the landing zone's.
- Otherwise, the built-in default: Audit on, Errors on, Traffic off.
A Workbench or a Simulator runs in a Container Apps environment that the whole group shares, so it always follows the landing zone's switches.
What each kind of node sends
| Node | Azure resource | Audit and Errors (on) | Traffic adds |
|---|---|---|---|
| Landing zone | Key Vault | AuditEvent | AzurePolicyEvaluationDetails |
| Landing zone | Storage (blob and queue services) | StorageWrite, StorageDelete | StorageRead |
| Landing zone | Log Analytics workspace | nothing | Audit |
| Data & IoT Fabric | IoT hub | Connections, DeviceIdentityOperations, Routes and the other operations | DeviceTelemetry, twin reads and queries |
| Data & IoT Fabric | Data Explorer cluster | FailedIngestion, Command, Journal, TableUsageStatistics | successful ingestion, queries, data operations |
| Data Stores (an account) | Cosmos DB account | ControlPlaneRequests, PartitionKeyStatistics, DataPlaneRequests5M | every data-plane request, query statistics |
| Provenance | Its immutable storage | StorageWrite, StorageDelete, StorageRead | nothing more |
| Workbench, Simulator | Container Apps environment | ContainerAppSystemLogs, ContainerAppConsoleLogs | ContainerAppHTTPLogs |
| API source | Function App | FunctionAppLogs, AppServiceAuditLogs | IP and sign-in logs |
Who read your Provenance evidence counts as audit for Provenance, so its reads are on with Audit. A database or table has no logs of its own; it follows its data store. Application Insights needs no setting: its tables already live in the same workspace.
Is it still on?
Each node's health says whether its logging matches the switches:
| Logging | Means |
|---|---|
| on | Every resource sends what the switches say |
| off | The openx setting is gone from a resource that should send logs |
| differs | A setting exists but sends something else; the health names what differs |
| unknown | OpenX could not read the setting. This does not mean it is off |
Reading the health never changes anything in Azure. The next Deploy puts back a setting that was deleted or changed by hand, and writes nothing where the setting is already right.
A workspace made before this existed catches up on its next Deploy: every resource gets its
openx setting then. Save log settings on the landing zone updates the landing zone's own
resources straight away.
Cost
Log Analytics bills by the data it takes in, to your Azure subscription. Audit and errors are small. Traffic is the largest share, which is why it is off until you turn it on. The activity log is free to take in.
Thinky and agents
Thinky, or an agent connected over MCP, can propose the landing zone's log switches. A proposal shows over the Logs form, which it fills in; Accept proposal and Save accepts it and saves what the form holds. Only that save changes anything in Azure.
| Code | When |
|---|---|
CALZ_LOGGING_NOT_PROPOSABLE | The proposal carries anything other than Defaults (Audit, Errors and Traffic, each true or false) and ActivityLog (true or false) |
CALZ_LOGGING_UNREADABLE | A save carries a switch that is not true or false |
When the stored settings cannot be read, the window shows the built-in defaults and says so; saving replaces them.
Next steps
- Your landing zone -> Manage Private CALZ
- Building what you saved -> Deploy