Working with Time Zones and Time Intervals

The platform provides metric information to help you monitor function and performance, such as your app's usage of an API or your API's overall traffic volume and message processing speed.

This topic includes:

Overview

There are several key factors to consider when determining what metric information you want to track and how you will do it, including:

  • Time zones you want to support
  • Data volume
  • Data storage facilities
  • Reporting requirements
  • Budget

Supported Time Zones

By default, the platform can support all time zones defined in the tz database, also called the IANA Time Zone Database. These time zones follow a basic continent/area format; for example, America/Los_Angeles, Europe/Paris, or Pacific/Fiji. The standard also includes a category, Etc, to support the GMT offset format; GMT+6, GMT-4, and so forth. For example, Etc/GMT-5 represents US Eastern Standard Time. For more information, refer to the Wikipedia article on the tz database.

Although this standard identifies a very large number of time zones, each installation of the Akana API Platform can be configured based on requirements, resources, and efficiency, and might therefore support only a subset. For example, a specific installation might have users in only one time zone, and might therefore be configured to support one time zone, which would increase efficiency.

Time Zone Offsets

Most time zones are offset from Coordinated Universal Time (UTC) by some increment of whole hours. For example, when it's 9am in Los Angeles it's 12 noon in New York, 5pm in London, 6pm in Paris, and 2am the following morning in Tokyo.

However, there are some time zones that vary by smaller increments—a half-hour and even in some cases a quarter-hour. The time in Bangalore, India is UTC+5:30 hours. The time in Eucla, in Western Australia, is UTC+8:45.

Available Metrics and Increments

By default, the platform supports tracking of metrics in the increments shown below.

This designation... Indicates this unit of measure... And is available in these increments...
s Seconds Five-second increments (5s)
m Minutes Fifteen-minute increments (15m)
h Hours Hourly increments (1h, 2h, etc.) up to 24h
d Days Daily increments (1d, 2d etc.)
w Weeks Weekly increments (1w, 2w, etc.)
M Months Monthly increments (1M, 2M, etc.)

Note that there is a limitation with regard to the increments for seconds and minutes. For example, you cannot track metrics in 12-second increments or 10-minute increments. Seconds must be in multiples of 5s, and minutes in multiples of 15m.

Preset Limitations on Your Platform

Your specific installation might be preconfigured in such a way as to limit your reporting possibilities. You can get this information from your system administrator.

For example, you might decide that you want to support hourly metrics for Bangalore, but you might find that your deployment only supports hourly reporting in GMT plus or minus 1-hour increments, which would mean that Bangalore time could not be supported.

Alternatively, you might want to track metrics for your API in five-second increments, but your installation might be configured with a minimum increment of 15s.

Make sure you are aware of any limitations that might be imposed by your implementation. Check with your system administrator for details.

Flexibility of Data Points

Smaller data points have greater flexibility; larger data points have less flexibility. For example, 5s or 15m data points are applicable to any time zone; 1h data points can't be used for the half-hour and quarter-hour time zones; daily data points can't be used for any time zone other than the one to which they apply. Choosing the appropriate data points for your scenario is a matter of judgment based on requirements and resources.

Accuracy Versus Efficiency

If you set up the metrics on your API so that information is measured at 5-second intervals (5s), and there are a large number of transactions being processed, this will soon accumulate an enormous amount of data. This leads to storage and maintenance costs. It's a matter of judgment to determine not only the metric intervals, but also how long to store the data.

One approach is to store information of a very fine level of granularity only for short periods of time. If you create a 5-second data point, there will soon be many of these data points, and this can overload the system. Instead, you could delete the 5-second data points after two days, keep 15-minute data points for two weeks, keep hourly data points for a month, and store daily data points for a year. This gives a balance between detail and efficiency.

Here is another scenario: You want to provide hourly data metrics to all your users. Most of the team members are in New York but some are in Bangalore. Your hourly data metrics will not work for Bangalore because it has a time zone offset that isn't in whole hours (see Time Zone Offsets above). In this scenario, you might decide to track your data at intervals of 30 minutes (30m) so that you can match those data points to the times in both locations. Alternatively, you might decide to keep only the hourly metric information, which would require only half as much data storage, and tell the Bangalore users that they must use the New York metrics (or vice versa).

Note that in the above scenario, a configuration setting would also need to be changed, in the underlying infrastructure, to set the configuration rollup offset to 30 minutes. This is an Administrator task, in the Akana Administration Console for the container: Configuration > com.soa.rollup.configuration > monitoring.rollup.configuration.hourRollupMinutesOffsets. The default value is 0, which means that rollups are per hour, on the hour. When this value is set to 0,30, rollups are also created for each hour, on the half-hour.

Adding a value, rather than changing the default, will result in two sets of rollup data. If you only have one group of users, in the offset time zone, you can replace the default. If you have users in different time zones, add the value.

Summary

Generally, the important factors are to make sure you choose data points that are compatible with any limitations preset by your implementation, and that satisfy any reporting requirements you might have.

Satisfying user requirements while maintaining performance and efficiency of your implementation are also important considerations.

You can modify data points later if needed.

API Operations for Managing Metrics Information

There are several operations that you can use for managing metrics information. Most of these offer various parameters that you can use to adjust your selection criteria as explained above.

Metrics-related API operationas are in two main services, APIs Service and Apps Service, and include:

Note: The above is a selection of metric-related operations, not a full list.