When setting up Azure policy for tag inheritance, you cannot exclude secondary namespaces, even though by definition the secondary namespaces cannot be updated under any circumstances. So when you do an automated deployment the policy kicks in and deployment fails wit the error "Cannot update a namespace that is secondary".

The only suggested way to get around this from Microsoft is to break the pairing (10 minutes) delete secondary namespace's event hubs (2-5 minutes) and set up tags enable pairing gain (10 minutes). I am setting this as the baseline, and it turns out it will be at least 25 minutes per namespce pairing. Imagine have multiple namespaces!! Even if you automate the process it still is a downtime of 25 minutes. Which is not acceptable. So please allow tags to be updated on event hub.

How to recreate this situation.

1. Create an ARM template for EventHub with GeoRecovery (with no tags set up)


2. Create a policy to inherit tags from Resource Group/subscription if not set (provided tags are set up for the RG/subscription)


3. Deploy the ARM - This will succeed, as when the primary and secondary namespaces are still different stand alone namespaces, tags will be inherited on resource creation and pairing happens normally.


4. Re-deploy the same template - This will fail, as the primary and secondary are now paired secondary cannot be updated. Even though you are deploying the same event hub definition with no tags, ARM will assume you are trying to update the tags (even on an incremental update).


5. Now break the pairing, delete the event hubs, deploy again - this will succeed, but you have just added a lot of manual work and have gained yourself a downtime of 15-20 minutes.


6. Now imagine a large scale enterprise having at least 50 namespaces.

Possible solution -
1. PoweShell to exclude scope on policy assignment - Defies the point of having an easy template on the portal, but have to be a scripting genius to get this right.
2. Set up policies based on naming convention - Big enterprise, not going to be easy.
3. Multiple policies one to exclude all event hubs the other one to exclude namespaces based on either a PowerShell script or naming convention - Please check cons of point 1 and 2.
4. Allow tags to be updated on secondary namespaces - That could be interesting!

It would be good if some sort of viewer/explore was provided for looking at the events within an Event Hub. This could be done either via the portal or Azure Storage Explorer.

When developing I currently use https://marketplace.visualstudio.com/items?itemName=Summer.azure-event-hub-explorer to view events as they are produced.

However, it would be good if a tool existed that let you browse events within the retention period. With the possibility to query by timestamp & partition key. As well as the event body, it would be good to be able to see the properties and other metadata.

We use Event Hub as the integration point between multiple systems and being able to diagnose issues by querying events would be extremely useful.

In trying to be more efficient with read/writes into CosmosDB my customer is requesting that having a Kafka Stream connect to Event Hub directly will provide some signficant savings. Also Kafka is very commonly used for Streaming across various enterprises and so hopefully supporting this connectivity for Event Hub might mean a good thing.

Some more details with an example below, there are workarounds I am sure but hope this helps:

o We currently have several read services and several write services. With Kafka Streaming the reads are consolidated in a Kafka queue and published to Event Hub as a single read or write to CosmosDB. Without this in place, there will be several reads or several writes with Event Hub to CosmosDB.

 Increased traffic will have a slower throughput
 Resulting traffic will have an increased cost in CosmosDB

Event Hub's support for Kafka Streaming can possibly help.

• TU count


• Event.Ingress: % of actual versus total capacity


• Events.Egress: % of actual versus total capacity


• Throughput.Incoming: % of actual versus total capacity


• Throughput.Outgoing: % of actual versus total capacity

These metrics would help to answer questions:
- Based upon our current usage and current billing structure, how can I forecast future costs as our scale increases? Similar to existing Azure Stream Analytics "SU %": this metric allowed me to roughly guage our current usage (versus capacity) and budget for future growth.
- What was the metric that triggered auto-inflate of TU count: Events? Throughput? Incoming? Outgoing?
- "TU count": especially since auto-inflate TU doesn't auto-deflate TU count after load has dropped. Having this metric allows me to create an alert for when auto-inflate TU count occur, so I can manually lower TU count once load dimishes.