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