Monitoring and maintaining Azure Cognitive Search
Use this reference to better optimize your Azure Cognitive Search service.
Microsoft Azure Cognitive Search is the default search engine for Sitecore, and is where Sitecore stores the content and analytics indexes.
Azure Cognitive Search costs depend on the number and size of the documents that are ingested into search. If you are using xDB, you can keep your document count low by disabling indexing of anonymous contact data in the Contact Segmentation index.
You must look at the SKU size for your Azure Cognitive Search solution. Each SKU size has several metric limitations but the main ones you must pay attention to are storage, index count, and document count. When designing your solution, you must keep these metrics in mind and monitor them, otherwise your search costs can grow faster than you might expect. The minimum SKU size you can use with Sitecore Azure Cognitive Search is S1, this is because the sizes lower than S1 are limiting (for example, Basic only allows 100 fields in an index and Free is limited to three indexes).
Note
There is no way to upgrade your existing Azure Cognitive Search service to a different tier on the fly, so it is important you plan the right service capacity upfront. When you upgrade or downgrade, you must create a new service and rebuild all of the search indexes in Sitecore.
Sitecore communicates with Azure Cognitive Search through its REST API; all calls to the API use an API key as the sole mechanism for authentication. When you deploy Sitecore with the ARM templates, a key is generated automatically for you and added to the cloud.search
connection string. You can always change the key if you need to and then update the cloud.search
connection string with the new value.
Azure Cognitive Search can scale in two dimensions: Partitions and Replicas. You can increase the number of documents you can store with Partitions, whereas with Replicas, you can achieve high availability and increase queries per second by copying your index to a new instance of the search service. You can use one or both scaling types, depending on your scaling requirements, but keep in mind that if you add an additional scaling type, then you increase your monthly costs. You can read about service administration for Azure Cognitive Search in the Microsoft Azure portal and about how to scale resource levels for query and indexing workloads in Azure Cognitive Search.
Azure Cognitive Search does not provide any form of traditional logging. However, you can obtain information about your service in the Azure portal on the service dashboard, through notifications, properties, and status messages.
![]() |
On the dashboard, resource monitoring is limited to the information shown on the service dashboard and the metrics that you can obtain by querying the service. On the service dashboard, in the Usage section, you can quickly determine whether partition resource levels are adequate for your application.
You can use the Azure Cognitive Search metrics: Search Latency, Search queries per sec., and Throttled queries percentage, to create alerts on the Azure Search and Monitor tabs. You can also create charts on the Monitor tab.
![]() |
Search traffic analytics is another monitoring tool in Azure Cognitive Search that gives you visibility of your search service and unlocks insights about your users and their behavior. When you enable this feature, you can copy your search service data to a storage account of your choice. You can process and manipulate this data from your search service logs and aggregated operational metrics, for further analysis.
Refer to the Microsoft Azure documentation website for more information about monitoring, usage, and query metrics in an Azure Cognitive Search service; enabling and using Search Traffic Analytics; scaling resource levels for query and indexing workloads in Azure Cognitive Search, and considerations about Azure Cognitive Search performance and optimization.