API Gateways, by their very nature, see a lot of traffic - all the service requests from your apps, from your Fiori tiles, from your users. And so, as APIs are used, they generate a lot of log file through both business-as-usual, policy exception and system exception operations. This can be monitored: the log file of an API gateway can be a very rich source of insight, as it typically contains:
- Customer Information - orders, notifications
- Application Information - security, access
- Device Information - type, connection, location
- Subscriber Information - tariffs, contract
- Product Information - information, transaction
- Service Information - performance, errors, trending
This information is generated in real-time (of the order of GBs a day), and can also be used to create a historical (and hence analytical) view of behaviour. It is ripe for predictive analytics. These five data sets can be combined in a number of ways to provide very detailed insight. You can answer questions such as:
What products are most often viewed, and on what devices? Is there a correlation between products and devices - are some devices better at showing off certain products? Filter the log file for the service “getProductInfo” and filter by device or endpoint.
What affects (web-store) browsing on a given device? Construct customer journeys by aggregating all service calls from a given device. Map and track that journey. What about it is predictive or predictable?
Which of your services are used the most? Are any of your services getting increasingly slower? What do you consider to be healthy round-trip-times? How long does fail-over take? Again, take the log file and sort by service name (e.g. “getLocation” or “submitOrder”) then aggregate by role or situation. Simple analysis can show up a lot of things. I’ve seen people detect a service running the wrong version of Java from this.
Who uses your services, when? Who generates the most errors and exceptions? Who exceeds their SLA every month? Which applications generate the most traffic, and the most revenue? Sort the log by ApplicationID (you do keep track of your developer community, right?), then generate totals for number of all service calls, and number (and amount) of “submitOrder” calls.
This is also a neat way of identifying up-and-coming applications and developers (previous generations called these “killer apps”). When a new application is launched, it’s usual to give that application a small amount of the Service Level Agreement. That’s to say, if this new app creates a lot of requests, it will flagged as such by the gateway. For security and risk reasons, it’s usual to ‘throttle’ the app, so as to not cause any operational impact to the services (and internal systems) supporting the app. This highlights an exciting “must-have” application. The business can then decide if the additional traffic this app represents is a good thing (more revenue) or a bad thing (more load) and update the throttling policy appropriately.
