An Azure search service with built-in artificial intelligence capabilities that enrich information to help identify and explore relevant content at scale.
hi maapinho,
you want your ops team to monitor the indexers without handing them the master keys to the kingdom. the reader role should be enough, but it often fails for deep operational data.
the issue is that the indexer execution history and detailed status are considered administrative information by the azure ai search service. the built in reader role is often too broad at the resource level but too narrow for these specific operational details.
you can create a custom azure role. this lets you define very specific permissions. you can create a role that only has the Microsoft.Search/searchServices/indexers/read action and the Microsoft.Search/searchServices/indexers/status/action permission. this would allow users to list indexers and check their status without being able to see the api keys.
another approach is to use azure monitor. you can enable diagnostic settings for your search service to send logs, including indexer execution logs, to a log analytics workspace. you can then give your operations team reader access to just that log analytics workspace. they can run kusto queries to see the indexer history and status without ever needing access to the search service itself.
this pattern of using a dedicated monitoring workspace is a very secure and scalable way to grant access to operational data.
to summarize. your two best options are to create a custom role with just the indexer status permission, or to use azure monitor and grant access to the logs in a log analytics workspace.
regards,
Alex
and "yes" if you would follow me at Q&A - personaly thx.
P.S. If my answer help to you, please Accept my answer