- 5 minutes to read

Monitoring Cosmos DB in Azure

Monitor your Azure Cosmos DB estate from Nodinite with the same operational visibility you already use for the rest of your integration landscape. This page explains how the Nodinite Azure Agent discovers SQL (Core) API databases and containers, evaluates their availability, and surfaces changes in a regular Monitor View.

New 7.9.x This feature adds native monitoring for Azure Cosmos DB databases and containers in Nodinite, including automatic discovery, availability monitoring, and configuration visibility.

  • ✅ Discover databases and containers automatically without manual lists
  • ✅ Surface reachability problems as visible resources instead of silently skipping them
  • ✅ Keep inventory current as databases or containers are added or removed in Azure
  • ✅ Show configuration facts such as RU/s, autoscale maxima, partition keys, and TTL
  • ✅ Monitor the data itself with your own read-only queries (Monitoring Scripts)
  • ✅ Act on databases and containers with Remote Actions (Managing Cosmos DB)

Nodinite monitors each Azure Cosmos DB account through the connection details in the agent Configuration. Once the account is known, the agent discovers all databases and all containers beneath them and presents them as monitored Resources. Cosmos DB availability and drift then show up in the same workflow as other Azure services, such as Azure Storage and Event Hubs, and next to the Azure SQL Database monitoring of the Database agent.

How Cosmos DB Monitoring Works

The agent reads each database and container, reports the result to the Nodinite Monitoring Service, and state changes reach your team through Alarm Plugins.

graph LR subgraph "Azure" A["fa:fa-database Cosmos DB Account"] B["fa:fa-database Database"] C["fa:fa-boxes Container"] end subgraph "Nodinite" D["fa:fa-monitor-waveform Azure Agent"] E["fa:fa-check OK
Read succeeds"] F["fa:fa-ban Unavailable
Read fails"] G["fa:fa-bell Alarm Plugins"] end A --> B B --> C D -->|"Read"| A D --> E D --> F F --> G style D fill:#2678BD,color:#fff style E fill:#93d16d style F fill:#c33d34,color:#fff

Diagram: The Azure Agent checks the Cosmos DB account and exposes each database and container as a monitored resource in Nodinite; a successful read is OK (green), a failed read is Unavailable (red) and raises an alert.

Monitoring Features

  • Automatic discovery – New databases and containers appear without manual reconfiguration.
  • Continuous re-discovery – Each polling cycle updates the inventory and removes entities that are genuinely gone.
  • Category-based monitoring – Nodinite groups databases and containers in Categories for clear ownership and filtering.
  • Role-based visibility – Share access with Users through one or more Role-based Monitor Views.
  • Configuration facts – The resource shows RU/s, autoscale max, partition key, and TTL details.

State Evaluation for Cosmos DB

Nodinite creates a Resource for each monitored database and container. The resource state is based on the agent's ability to read it successfully. Override the evaluation for any Resource with the Expected State option.

State Meaning What the user sees Available remote actions
✅ OK The database or container is reachable and readable Green state with no warning text Details
Approved Queries
Throughput
Keys
Create or Delete Containers
Post Document
🚫 Unavailable The account is unreachable, the connection string is invalid, or the container cannot be read A red resource with an explanatory message Details
Keys

The monitoring model is intentionally simple:

  • A read success is OK – healthy resources remain green.
  • ⚠️ A read failure is visible – a broken account or container becomes UNAVAILABLE instead of disappearing silently.
  • Resources are removed only after sustained absence – if a database or container is genuinely deleted in Azure, it disappears after three missed cycles.

When a resource is Unavailable, check the connection string, the Azure rights (the least privileges page lists the role for Cosmos DB accounts), and that the firewall allows HTTPS to *.documents.azure.com.

Databases

Each Cosmos DB database is represented as a resource with details such as:

  • Account name
  • Number of containers
  • Provisioned RU/s
  • Autoscale max RU/s

If the account becomes unreachable or the database cannot be read, Nodinite marks the resource Unavailable, and the user sees the connection or access problem directly in the monitor view.

Containers

Each container resource shows the container's own configuration facts:

  • Partition key path
  • Provisioned RU/s
  • Autoscale max RU/s
  • Default TTL

If a single container cannot be read, only that container becomes Unavailable. Healthy containers remain visible and usable.

Alert History and Operational Awareness

When an incident happens, review the event history for the affected database or container in the same way as other monitored resources. Use the history capabilities of your Monitor View to review whether the issue started with a connection problem, an access issue, or a resource removal. Learn more in the Add or manage Monitor View guide and the Resource State History user guide.

Frequently Asked Questions

Use the Troubleshooting guide for known issues with the Azure Agent.

What is monitored?

Nodinite monitors Azure Cosmos DB SQL (Core) API databases and containers, including reachability, inventory drift, and configuration facts. It does not alert on RU consumption or latency metrics. To monitor the data in a container, such as stuck messages or old documents, add Monitoring Scripts: read-only queries judged against thresholds, a health value, or a return code.

What happens if the account is unreachable?

The monitored account resource becomes Unavailable with a plain-language explanation. Connection-string problems, rotated keys, and access issues therefore show up immediately in Nodinite. Use the Keys Remote Action to check the masked connection details.

Next Steps