Last updated
Was this helpful?
Version 6.30
Last updated
Was this helpful?
The Portal collects data from the Engine once every day to compute the metrics for its dashboards and build up its history. Because collecting data from the Engine is a costly operation, the Portal is programmed by default to get the data during the night, when the activity of the Engine is supposed to be low.
, the Portal starts collecting information about the events that occurred during the past day, which usually are 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 metrics to compute.
The Portal determines the past day individually for each Engine in the following way:
The Portal gets the time of the last event stored in the Engine.
The past day is the whole day before the date of the last event in the Engine (always computed in the time zone of the Portal).
For Engines with low activity, this way of determining the past day might mean that the past day is two (or more) days ago. For instance, if an Engine has no event during the current day yet (when the Portal starts the nightly computation) but the last event happened the day before, the Portal considers the past day to be two days ago for that Engine.
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 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 of the Portal account matches the time zone of the admin user in every Engine.
By default, the time zone of the admin user (and, therefore, that of 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 that is equivalent to 01:00 Zurich time. When the scheduled time is reached, the Portal begins to collect data from all Engines.
If you change the time zone of the admin account, a similiar scenario occurs. All the Engines automatically set the time zone of their Portal accounts to be the same as the time zone of the admin account. 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.
Let us illustrate the influence of time zones in the data collection 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.
Suppose that most of the devices with the Collector installed are located in Paris. It makes sense thus to have the time zone of the admin account set to Paris. This ensures that the computation occurs during the night in Paris, when most of the devices are inactive. Since the Portal account shares the same time zone of the admin account, both the Engine in New York and the Engine in Paris have the time zone of the Portal account set to Paris time.
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.
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 Paris, users of the Portal in New York may experience poor response time if they try to connect to the Portal late in the evening, because data collection was started at 19:00 New York time and it can go on for a few hours.
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.
Therefore, 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.
Be careful with metrics that compute values for particular intervals of time in a day. For instance, let us consider a metric Number of desktops with nightly activity that is based on a between hours condition. The metric 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 example, 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.
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.
The time zone of the admin account, if you change it from Europe/Zurich to any other value.
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 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.
RELATED TASKS
