This is the first part in a set of articles describing Zato ESB and application server's statistics - what they provide, how to use them and how they can be efficiently managed.

The series will include:

  • Trends (this part)
  • Summaries
  • Settings and maintenance
  • Statistics API

Trends answer the one important question asked by developers and operations alike - what is currently going on and what sort of tendencies can be found on my environments?

From that follows - is what happening right now considered typical or should I expect difficulties ahead soon?

Note that trends are not an early-warning system and as such they don't substitute monitoring solutions - they are instead meant to be an aid with an intricate knowledge of Zato.

Trends are concerned with relatively short spans of time - last hour, last 20 minutes or last 10 minutes. Essentially, this is a tool to give you an insight into how your services behave right after you receive a signal that there might be something unwanted hapenning right now.



When displaying trends the screen will be usually divided into 4 parts:

  • Left side - Slowest services + Most commonly used ones
  • Right side - as above but in a different time period, the one we want to compare the left side to

Hovering over any row will highlight matching rows in all the tables - for instance, the most commonly used service doesn't have to be necessarily the slowest one and the one that was slowest yesterday the same time of day doesn't have to be so slow today.

Understanding the difference in usage patterns is literally a hover away.



By default top 10 services in each category are shown but the number can be set to any one required.

3 quick links let one answer the most common questions:

  • How does it all compare to last hour?
  • To yesterday the same hour?
  • Last week the same day and hour?

It's also possible to pick arbitrary start/stop dates to compare to but do note that trends are always generated on fly from Redis and the process is CPU intensive so obtaining information for more than a couple of hours can result in visible CPU spikes.

Slowest services


The 6 columns displayed for each of the slowest services are:

  • M - Mean response time of that service (in ms)
  • AM - Average mean response time of all services, including that one (in ms)
  • U% - The service's usage share - of all invocations of all services, how many fell on that one
  • T% - The service's time share - of the whole time spent in all services, how many percents that service constitutes
  • TU - How many times all the services, including this one, have been invoked
  • Trend - A sparkline chart displaying how the service's mean response time fluctuated in the selected period

Hence the row in the screenshot describes a service whose mean response time was 12.72 ms which is almost 10 times faster than the average mean response time when all services are taken into account (122 ms).

Of out the total 40 invocations of all services (TU) this one took 2.5% of it but in terms of the time spent it was 18.9% of the whole time the 40 invocations took.

From the sparkline, one can also learn that the service was not used at all except for a sudden spike a few minutes ago.

Each service slower than expected is marked with a red dot left to its name (shown here).

Everything can also be exported to CSV.

Most commonly used


The 6 columns describing for each of the most commonly used services are:

  • U - How many times the service has been invoked
  • Rq/s - How many requests a second that service processed - note that 0.1 req/s is the smallest degree shown
  • U% - The service's usage share - of all invocations of all services, how many fell on that one (repeated)
  • T% - The service's time share - of the whole time spent in all services, how many percents that service constitutes (repeated)
  • TU - How many times all the services, including this one, have been invoked (repeated)
  • Trend - A sparkline chart displaying the service's average request rate per second

Thus in the screenshot one can find a service which was invoked 14 times (U) of all the 40 service invocations (TU) which is exactly 35% of them all.

However, despite consituting 35% of all invocations it took only 9.4% (T%) when CPU time is considered - meaning it was pretty fast.

The trend tells us that the service is mostly idle except for a brief period a couple of minutes ago.

Each service whose usage share exceeds what is expected is marked with a red dot left to its name.

And again, statistics can be exported to CSV.

Final words

Trends are a tool used for finding out or confirming whether what an environment does currently conforms to standard usage patterns or not.

Next instalment will cover summaries that let one quickly compare statistics across days, months or years.


但这样解析并没有太多的内在含义。 所以这里尽可能的提供一些更多的信息, 而不是仅仅从企业的角度的说法。

The no-nonsense intro to ESB and SOA has been just translated into Chinese - check it out for information on what ESB and SOA really are and how to design awesome microservices following the principles of IRA:

  • I nteresting
  • R eusable
  • A tomic

Also available in Català, Português and ру́сский.




Head over to the new chapter in the Zato documentation to find out how to integrate Django and Flask applications with Zato services.

The service it uses is a hypothetical yet fully functional one which looks up and caches user data by their IDs.

The integration effort is presented from the point of view of both libraries using self-contained ready-to-use projects living on GitHub.

Simply put - it contains everything you need to integrate Django or Flask with Zato :-)

# -*- coding: utf-8 -*-

from __future__ import absolute_import, division, print_function, unicode_literals

# stdlib
from random import choice

# Zato
from zato.server.service import Service

# A set of first and last names to generate customer names from
first = ('Richard', 'Victoria', 'Sebastian', 'James', 'Hannah')
last = ('Ogden', 'Piper', 'Edmunds', 'Murray', 'Young')

# Redis key we store our cache under
CACHE_KEY = 'example:customer:by-id'

class GetCustomer(Service):
    name = 'customer.get2'

    def get_customer(self, cust_id):

        # Assume in an actual service this would look up the data in a real DB
        return '{} {}'.format(choice(first), choice(last))

    def handle(self):


        # Customer ID received on input
        cust_id = self.request.payload['cust_id']

        # Do we have their name in cache?
        name = self.kvdb.conn.hget(CACHE_KEY, cust_id)

        # If not, we need to ask the backend and cache the response
        if not name:
            name = self.get_customer(cust_id)
            self.kvdb.conn.hset(CACHE_KEY, cust_id, name)

        # Produce the response for the calling application.
        self.response.payload = {'name': name}

Django screenshots below:




The new version of Zato - the open-source middleware platform and backend application server - has just been released.

Release 2.0 brings dozens of interesting features building on and greatly enriching already existing capabilities.

Major features include:

The changelog lists all the updates that are in addition to what Zato has had since the initial release: clustering, scheduling, hot-deployment, GUI, CLI, statistics, Plain HTTP, SOAP, AMQP, FTP(S), JMS WebSphere MQ, ZeroMQ and more.

Check out the no-nonsense introduction to ESB/SOA for an introduction to the philosophy behind the project and just have a look at the following sample screenshots depicting but a small part of the platform in action:

Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot

The upcoming release 2.0 of Zato - ESB and application server in Python for SOA, REST, APIs and cloud integrations - will feature means to connect to Redis High Availability (HA) environments with entinels.

While meant for Zato users mostly, the chapter on configuring a minimal Redis HA environment with sentinels can be interesting for a wider audience as well.


Have fun!