![]() The contents of that string are up to you. A policy to send application/http messagesĪn Event Hub accepts event data as a simple string. This enables supporting many integration scenarios without putting addition delays on the processing of the API request within the API Management service as only one event needs to be generated. This allows events to be processed by different systems. The Event Hub does not care how it is processed, it just cares about making sure the message will be successfully delivered.Įvent Hubs has the ability to stream events to multiple consumer groups. ![]() Once the data has been passed to an Event Hub, it is persisted and will wait for Event Hub consumers to process it. This ensures that your API performance will not suffer due to the logging infrastructure. The Event Hub acts as a kind of sophisticated buffer between your API management service and the infrastructure that stores and processes the messages. The Azure Event Hubs is designed to ingress huge volumes of data, with capacity for dealing with a far higher number of events than the number of HTTP requests most APIs process. However, short spikes in traffic can cause requests to be delayed if requests to logging infrastructure start to slow under load. Gradual increases in load can be handled by increasing available instances of system components or by taking advantage of geo-replication. However, when making logging requests from an API management service, it is necessary to consider how logging messages impact the performance of the API. Why not just send the requests directly to the final destination? That is an option. It is a reasonable to ask, why create a policy that is specific to Azure Event Hubs? There are many different places where I might want to log my requests. It is also scalable, in part due to the geo-replication capabilities of Azure API Management. Using the Azure API Management service to integrate with logging infrastructure provides a centralized and platform-independent solution. Often there are reasons why backend APIs cannot be updated. If there are multiple APIs, then each one must deploy the middleware. The downside to this approach is the HTTP middleware needs to be integrated into the backend API and must match the platform of the API. It is possible to write HTTP middleware that can plug into HTTP API frameworks to capture HTTP requests and responses and feed them into logging and monitoring systems. This article demonstrates how to capture the entire HTTP request and response message, send it to an Event Hub and then relay that message to a third-party service that provides HTTP logging and monitoring services. Some examples include audit trail of updates, usage analytics, exception alerting, and third-party integrations. ![]() There are a variety of reasons why you may want to generate events from HTTP messages being sent to your APIs. The API Management service keeps some important statistics about the APIs for display in the Azure portal dashboard, but beyond that, the details are gone.īy using the log-to-eventhub policy in the API Management service, you can send any details from the request and response to an Azure Event Hub. Your API processes the request and a response flows back through to the API consumer. The request is made and it flows through the API Management service to your backend API. However, the existence of the requests and responses is transient. The API Management service provides many capabilities to enhance the processing of HTTP requests sent to your HTTP API.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |