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.

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

We received lot of error in
Metric Namespace : Event Hub standard metrics
Metric : User Errors. (Preview)

The support Microsoft Azure told me :

There is an ongoing update on the backend server for your namespace, during these updates it is expected that you are going to see User Error and Server Errors on a few requests.
For all these errors the detailed error message should surface into your application code, if you are not seeing any exception on your application probably your client application SDK is retrying the operation successfully so no error is thrown.
These service/OS updates are always going to happen but retrying should have enough resilience in order to have less impact on your application.

Currently it is not possible to receive those alerts through the Azure Portal.
It would be great if we could.