- 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.

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.

The two options for batch sending right now are to use the managed client or the REST apis. The managed client lets you just slam in a bytesegment created on a buffer that holds valid json, but then you have to manually set name/value pairs in the Properties collection for any items that you want set in that collection. The REST api lets you just provide the whole UserProperties collection as a single json object, but then requires that you escape all your json to put it in the "Body" field as a string.

If I've already got the ability to produce json bytes, let me use that capability directly for both UserProperties and Body. Don't make me choose one or the other.

I don't care if the field has to actually have a different name for back compat purposes, I just don't want to have to take my existing json blobs and escape them to put them in the body, or have to take other json objects and deserialize them, then iterate over them to put them in UserProperties (which I would need to do if I used the managed EH client).

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.

Currently, a listener of an EventHub has access to all the messages within that EventHub. In the case of untrusted consumers (e.g. in a multi-tenant system), it's sometimes useful to restrict this permission to only read some of the messages in the EventHub.

A sample scenario is for using a shared Event Hub as a multi-tenant distributed log for a service. As it stands, each customer can already have their own publisher key to the shared Event Hub. It would also be nice if each customer can get a SAS key that only allows them to listen to messages from that publisher. This is currently not possible and so makes the idea of a multi-tenant Event Hub impossible.