Time Zones and data collection

Contents

Time Zones and data collection

Overview

The Portal collects data from the Engine once every day to compute the widgets and build up its history. Because collecting data from the Engine is a costly operation, the Portal is programmed to get the data during the night, when the activity of the Engine is supposed to be low. At one o'clock in the morning, the Portal starts collecting information about the events that occurred during the last day, that is, the 24 hours that went by from past midnight to midnight one hour ago. The whole computation process can take up to several hours, depending on the quantity of data collected and the number and complexity of the widgets to compute.

Special care has to be taken when the Portal and the Engine are placed in different time zones, in particular when the Portal is connected to multiple Engines. A setup with Engines placed in distant locations may lead to surprising results in the Portal if the data collection process is not well understood. One o'clock in the morning in one time zone may be two in the afternoon in another. Thus, data collection may not be triggered during the night for all Engines.

This document explains how the Portal determines when to start collecting data from the connected Engines and other issues that arise when the Portal and the Engines are placed in different time zones.

The time zone of the Portal account

The Portal connects to the Engine by means of a dedicated account. This account is unique to each Engine and is similar to the accounts of the users of the Finder. The time zone specified for the Portal account is key to understand when data collection is triggered. Depending on how the Portal account is configured, we can find one of the three situations explained below.

Default behavior

By default, the Portal account is configured in every Engine to have the time zone of Europe/Zurich, which corresponds to Central European Time (CET, UTC +1 hour) during the winter and Central European Summer Time (CEST, UTC +2 hours) during the summer. Therefore, from the point of view of the Portal, all Engines share the same time zone (Europe/Zurich), even when this is actually not the case.

To schedule the collection of data, the Portal computes the local time that is equivalent to 01:00 Zurich time. When the scheduled time is reached, the Portal begins to collect data from all Engines.

Centralized admin account

If you want to change the default value of the time zone of the Portal account, you can do so by centralizing the admin account. When the admin account is centrally managed by the Portal, one of the consequences is that all the Engines automatically set the time zone of their Portal accounts to be the same as the time zone of the admin account. This situation is similar to the default in the sense that the Portal considers that all the Engines share the same time zone.

As a result the Portal starts collecting data from all Engines at 01:00 according to the time zone of the admin account. As explained in the previous default case, the Portal computes the equivalent local time for scheduling the data collection.

Beware that if the admin account is later decentralized, the time zone of the Portal account does not automatically go back to the default value of Europe/Zurich.

Multiple time zones (advanced)

Usually, you cannot modify the time zone of the Portal account in the Engines separately. Centralizing the admin account, as seen above, only lets you set the same time zone in all Engines at once. However, advanced users can replace the time zone of the Portal account in each Engine individually through the command-line interface (CLI) of the Appliance. The result is that the Portal account may have a different time zone in each one of the Engines.

When you have multiple time zones defined for the Portal account, the Portal takes as reference the time zone that is located the most to the west. In this way, the Portal makes sure that all the Engines have crossed the day boundary when the data collection is launched. Thus, the Portal launches the collection of data at 01:00 according to the time zone of the Portal account that is the most to the west.

By its very nature, defining multiple time zones is incompatible with a centralized admin account. If the admin account is centralized and you use the Appliance CLI to manually reset the time zone of a Portal account, the automatic synchronization of the Portal and the Engine quickly changes its time zone back to the centralized value. Consequently, define multiple time zones only when the admin account is decentralized.

Example

Let us illustrate the possible situations with an example involving one Portal connected to two Engines. Imagine that we have a Portal installed in London, one Engine in New York and another Engine in Paris. For the sake of simplicity, we are not going to deal with daylight savings. Therefore, we assume that the Portal in London has UTC time, that the Engine in New York has UTC -5 hours and that the Engine in Paris has UTC +1 hour as their respective time zones.

We can reduce the three situations explained above to two, without loss of generality:

The Portal account shares the same time zone in all Engines (default case and centralized admin account). The Portal account has a different time zone in each Engine (multiple time zones). Let us consider both cases with the help of our example.

The Portal account shares the same time zone in all Engines

Imagine that most of the machines with the Collector installed are located in Paris. It makes sense then to centralize the admin account with the time zone of Paris. As explained above, if the admin account is centralized, the Portal account shares the time zone of the admin account. Therefore, both the Engine in New York and the Engine in Paris have the time zone of the Portal account set to Paris time.

Portal tz centralized.png

The Portal in London triggers the computation at 01:00 Paris time, that is 00:00 London time. The Engine in Paris has its data collected as usual, from midnight one day ago to midnight one hour ago. However, for the Engine in New York the situation is different. Since its time zone has been centralized to Paris, data collection is performed from 18h last day to 18h today, coinciding in real-time with the collection of data in Paris.

Data collect centralized.png

The Portal account has a different time zone in each Engine

Let us suppose now that you configure each Engine to have the Portal account set to its own time zone. Remember that this is an advanced configuration that you can only do with the help of the Appliance CLI.

Portal tz multiple.png

In this setup, the Portal starts the data collection according to the Engine that is located the most to the west, that is, the Engine in New York. To launch the data collection at 01:00 New York time, the Portal in London starts the process at 06:00 London time. As mentioned before, this technique ensures that the day is also over for the Engines situated more to the east - in our example, the Engine in Paris.

In this case, both Engines collect data from midnight one day ago to midnight one hour ago, accordingly to their respective time zones. Because the time zones are different, this implies that the two periods of data collection do not coincide in real-time.

Data collect multiple.png

Impact on users

As we said at the beginning, data collection is a costly operation. It increases sensibly the load of the Portal and the Engines while it is going on. To impact the fewer users possible, the Portal collects data during the night. However, in scenarios with multiple time zones involved, the night is not simultaneous for everyone. More users may be impacted as a result of the Portal performing data collection during local working hours.

For instance, In the previous example, where the Portal adapts to the time zone of New York, users of the Portal in London may experience poor response time if they try to connect to the Portal early in the morning, because data collection was started at 06:00 London time and it can still be going on.

Similarly, users of the Finder may experience a decrease in the performance of their connection to an Engine, if the Engine is being solicited by the Portal because of the data collection process.

If you centralize the admin account, it is recommended to use the time zone of the Engine where most of the users of both the Portal and the Finder are located. In this way, you reduce the impact of data collection on the majority of your users.

Interpreting the results

Be careful with widgets that compute values for particular intervals of time in a day. For instance, let us consider the widget Number of desktops with nightly activity. The widget is supposed to return the number of desktops which had any kind of activity during the night. But we have seen that the night is not simultaneous for everybody in setups with multiple time zones.

In the first example of the centralized admin account, for instance, the Engine in New York is computing from 18:00 yesterday to 18:00 today, but the Portal makes the computation with respect to the centralized time zone, which is Paris time. Therefore, the widget reports the desktops with nightly activity according to Paris time and not to New York time, even for desktops placed in New York.

On the other hand, in the example with multiple time zones, the widget actually reports the number of desktops which were active during the night, both for the night in Paris and the night in New York. You just have to realize that the night hours are not simultaneous in Paris and in New York, so do not assume that all the desktops reported were active concurrently.

Remember that the widgets in the Portal display their results with respect to the time zone used to launch the computation:

  • By default, the time zone of Europe/Zurich.
  • If the admin account is centralized, the time zone of the admin account.
  • If multiple time zones are configured for the Portal account, the time zone that is most to the west.

The users of the Portal see time information in their web browser according to one of these possible time zones and it is the same time zone for all users. You should therefore not confuse the time zone of the widget results in the Portal with the time zone configured in the profile of the user. The time zone in the profile of the user exclusively serves to present information in the Finder, if the user of the Portal is allowed access to the Finder.