Traffic Menu: Traffic Aggregation
The Traffic Aggregation function allows extraction of performance data from the analytics database for use in modeling, simulation and trending. You can extract different types of performance traffic into their relative files using a variety of timeframes and traffic statistics. Figure 1 shows the Traffic Aggregation Window.
Make your selections in the Traffic Aggregation window and click OK. The traffic aggregation process on the server requests the analytics database to aggregate the performance data according to the selections you provided, and the data are stored to the corresponding traffic files (interface, T_trafficload and trafficload). When complete, the window remains open. You can close it by clicking Cancel or via the window actions used by the interface for the operating system (red yellow green in Figure 1).
The information in the following sections should help you define a traffic aggregation that suits your purpose.
Performance Data Indices Used for Aggregated Queries
The analytics database stores performance data in a series of indices. The default index for a measurement contains each measurement to a granularity of 5 minutes. High frequency measurements collected through Telemetry are stored in a special index used mostly for real-time traffic graphs. The high-speed (raw) index is then recorded as an average into the default index. The default index has a configurable retention period which is initially set to 90 days with this setting.
The measurements are then rolled up hourly with average and 90 percentile aggregations, and this rolled-up index is used for more scalable queries on the performance data. In addition to the hourly index, the default index is also rolled up into daily, weekly and monthly indices to support queries over longer time frames. The rollup indices are initially set to 1000 days.
The performance data indices are summarized in Table 1.
Table 1: Performance Data Indices
Same as collection for high frequency measurements such as Telemetry (30 seconds, for example).
Hard set to 1 day
Measurement frequency or five minutes, whichever is less.
In northstar.cfg: es_log_retention_days = 90
Rolled up on an hourly, daily, weekly, and monthly basis.
Produces increased performance and reduced storage needs for traffic reporting and modeling.
In northstar.cfg: es_log_rollups_retention_days = 1000
The generate options are:
Interface CoS Traffic
Demand and trafficloads
Click the check boxes to select as many of these options as you want, except that Interface Traffic and Interface CoS Traffic are mutually exclusive. They use the same interface traffic files for output, so you can only have one or the other. If selected, Demands only returns values if demands have been collected via NorthStar Controller task collection.
Click any one of the radio buttons to select that range. Begin Time and End Time formats are a little different, depending on what you choose for the Series:
If Series = hour of day aggregation, the Begin Time and End Time are specified as just the date because all hours of the specified days are used.
If Series = time series, the Begin Time and End Time are specified as date and time.
Two options are available for Series:
Hour of day aggregation
In this type of series, all measurements are aggregated by hour of day, potentially across multiple days. For example, by specifying “last week”, you would get the average or 90 percentile traffic for 9 – 10 PM. All measurements between 9 and 10 PM from all seven days would be considered in the calculation of the statistics. This is useful for calculating a typical day across a date range. Each parameter would have 24 values in the resultant traffic file, corresponding to each hour in the typical day. The usefulness of this series type diminishes as the time range becomes longer because the impacts of traffic trend over the time range would skew the statistic to represent either the time range mid-point or end-point for average and 90 percentile statistics, respectively.
This is a typical series which will have a data point for each interval between the selected start and end times. There is a maximum of 168 data points that can be utilized in simulation. For example, you could do hourly statistic calculations for seven days (24 x 7 = 168), but if you were interested in a time series for a month of data, you would need to use a courser interval such as daily or weekly. This should be a consideration if the data is to later be trended as a forward projection, to ensure the projected data does not result in exceeding the maximum of 168 data points per parameter. The system does give you an error message if you enter settings that would result in more than 168 data points.
Use the drop-down menu to select from the two traffic statistics options offered. The two options enable different objectives in modeling:
Average: Provides a representation of the typical traffic during a period.
90 percentile: Provides a representation of peak traffic during a period.
For recent time ranges (last day or week), there may not be a large difference in these values for hourly interval time series or hour of day aggregation. For daily or larger intervals, 90 percentile might be a better choice for capacity planning and average might be a better choice for trending.
Use the drop-down menu to select an Interval. Based on the Series type, data points will represent the selected interval as shown in Table 2.
Table 2: Data Points by Series Type and Interval
Series Type: Hour of day aggregation
Series Type: Time series
For example, a one-week interval applies to Time series, but not to Hour of day aggregation. Recall that a maximum of 168 values per parameter can be retrieved in a time series. Hourly data must be used for hour of day aggregation.
Output Directory and Output Runcode
The output directory defaults to the directory where the model is stored on the server. Click Browse to select an alternate directory.
Do not extract traffic aggregations to directories used by the
NorthStar Controller (
The output runcode defaults to the current model’s runcode.
Load New Data
If selected, the extracted performance files are read into the current model.