Defining the Incident Generated by a Rule

Defining an incident involves setting attributes for the incident based on the subpatterns you created as conditions for the rule, and then setting attributes for the incident that will be used in analytics and reports.

1. In the rule you want to define an incident for, click Edit next to Actions: Generate Incident.
2. Enter an Incident Name, Display Name, and Description.
3. Under Incident Attributes, you will define attributes for the incident based on the Group By and Aggregate Conditions attributes you set for your sub patterns. Typically you will set the Incident attributes to be the same as the Group by attributes in the subpattern. a. Select the Event Attribute you want to add to Incident.
   1. Select a Subpattern.
   2. This will populate values from the Group By attributes in the subpattern to the Filter Attribute
   3. In the Filter menu, select the attribute you want to set as equivalent to the Event Attribute.
4. Under Triggered Event Attributes, select the attributes from the triggering events that you want to include in dashboards and analytics for this event.

This is pre-populated with typical attributes you would want included in an incident report.

5. Click OK.

Defining Rule Exceptions

Once you activate a rule, it continuously monitors your IT infrastructure for conditions that would trigger an event. However, you may also want to define exceptions to those conditions. For example, you may know that a server will be going down for maintenance during a specific time period and you don’t want your Server Down – No Ping Response rule to trigger an incident for it.

1. In Analytics > Rules, select the rule you want to add the exception to, and click Edit.
2. Next to Exceptions, click Edit.
3. Select an Attribute and Operator, and enter a Value, for the conditions that will prevent an incident from being generated.

The values in the Attribute menu are from the Event Attributes associated with the incident definition.

4. Click the + icon to set an effective time period for the exception.

You can set effective time periods for single and recurring events, and for durations of time from hours to days.

5. Enter any Notes about the exception.

Defining Clear Conditions

Clear conditions specify conditions in which incidents will have their status changed from Active to Cleared. You can set the time period that must elapse for the clear condition to occur, and then set the conditions based on the triggering of the original rule, or on a sub pattern based on t he Incident Attributes.

1. In Analytics > Rules, select the rule you want to add the clear condition to, and click Edit.
2. Next to Clear Condition, click Edit.
3. Set the Time Period that should elapse for the clear condition to go into effect.
4. If you want the clear condition to go into effect based on the firing of the original rule, select the Original Rule Does Not Trigger. For example, if you wanted the clear condition to change the status of Active incidents to Cleared after the original rule had not been triggered for ten minutes, you would set Cleared Within to 10 Minutes and select this option.
5. If you want to base the clear condition on a sub-pattern of the incident attributes, select the following conditions are met.

The incident attributes from your rule will load and the clear condition attributes will be set to match.

6. Define the pattern to use by clicking the Edit icon next to the clear sub pattern.
7. Click Save.

Testing a Rule

After you’ve created or a edited a rule, you should test it to see if behave as expected before you activate it. This topic describes how to test a rule using synthetic events.

Procedure

Test Results

Test Example

Troubleshooting for Rule Testing

Rule Syntax Error

Rule Semantics Error

Event Parsing Error

Procedure

1. Go to Analytics > Rules, and deactivate the rule you want to test.
2. Select the rule, and then click Test Rule.

This will open the Rule Debugger.

3. Enter a Reporting IP where the synthetic event should originate from.
4. Under Raw Event, enter the raw event log text that contains the triggering conditions for the rule.
5. Under Pause, enter the number of seconds before the next test event will be sent, and then click + under Action to enter additional test events.

You will need to create as many events as are necessary to trigger the rule conditions.

6. Click Run Test.

If the test succeeds you are now ready to activate the rule.

Test Results

The test will run through a four stage process, which you can observe in the Test Results tab of the rule. A yellow icon will also appear in the Stat us column for the rule to indicate that the test is running.

1. Rules are checked for syntax errors.
2. Events are parsed and sent to Rule Workers.

If there are errors in the rule syntax or event parsing errors, see the examples under Troubleshooting for Rule Testing for suggestions on how to correct them. As events are being parsed, you can view their Event Details by clicking on the Raw Event Log icon next to the event.

3. Rule Worker nodes evaluate the events against the rule conditions, and if they match, they are sent to the Rule Master.
4. The Rule Master creates incidents, which then appear in the Incidents dashboards.

When the test successfully completes, a green icon will appear in the Status column next to the rule name.

Test Example

This screenshot shows the example of a test for the rule Multiple Admin Login Failures: Net Devices. The conditions for this rule are that the the Reporting IP must belong to a network device, and there must be 3 login failure events from the same IP and user.

Troubleshooting for Rule Testing

If the test fails, a red icon will appear under the Status column next to the rule name, and you will see the error message in the Test Results tab for the rule.

Rule Syntax Error

Rule Semantics Error

This means that the conditions of the rule were not met by the event. For example, if five events were required to meet the condition, but only one was sent.

Event Parsing Error

This means that some text in the raw event log did not pass the event parser. For example, if “denied” is the term expected by the parser in the test example, but the raw event log contains the term “deny,” then the event will not pass the parser.

Activating and Deactivating Rules

When you create a new rule, you must activate it before it will start to monitor events. You may also want to deactivate a rule, for example to test it, instead of deleting it from the system.

1. Log in to your Supervisor node.
2. Go to Analytics > Rules.
3. Browse or search to find the rule that you want to activate or deactivate.
4. Select Active for the rule you want to activate, or clear the Active option if you want to deactivate a rule.

Adding a Watch List to a Rule

1. Go to Analytics > Rules.
2. Select the rule you want to add the watch list to, and then click Edit.
3. Next to Watch Lists, click Edit.
4. Select the watch list you want to add, and use the Add >> button to add it to the rule.
5. For Incident Attribute, select the incident information you want to add to the watch list.

Watch List Attribute Type Must Match Incident Attribute

The Type that you set for the watch list must match the Incident Attribute Types for the rule. For example, if your watch list Type is IP, and the Incident Attribute Type for the rule is string, you will not be able to associate the watch list to the rule.

6. Click OK.

Next to Watch Lists, you will see Watch List has been defined.

Cloning a Rule

You can clone a rule to use it as the basis for creating another rule, or to use in testing.

1. Log in to your Supervisor node.
2. Go to Analytics > Rules.
3. Search or browse to select the rule you want to clone.
4. Click Clone.
5. Enter a new name for the cloned rule and click OK.

The cloned rule will be added to the same group as the original rule but will be inactive.

Running Historical Searches to Test Rule Sub Patterns

If you are trying to analyze why a rule is triggering an excessive number of incidents, or why it isn’t triggering any, you can run an historical search with the rule sub patterns to see how the sub pattern behaves in relation to past events. If the search has interesting results, you can then generate a report for further investigation. This is a way that you can test rules without having to deactivate them.

1. Go to Analytics > Rules.
2. Select a rule and then click Edit.
3. Click Edit next to the sub pattern you want to use in the search.
4. Click Run as Query.
5. Enter information for the time period you want to search.
6. Click OK.

An historical search will run based on the sub pattern filters, aggregate conditions, and group by conditions.

Using a Sub Pattern in a Report

If the search includes results that you want to share or investigate further, you can save the rule as a report.

1. In the sub pattern you want to save, click Save as Report.

The report will be saved in Analytics > Reports, and will have the phrase From Rule in the report name.

2. Select the report and click Run Now to generate a report from the sub pattern.

Setting Rules for Event Dropping

Some devices and applications generate a significant number of logs, which may be very verbose, contain little valuable information, and consume storage resources. You can configure Event Dropping rules that will drop events just after they have been received by AccelOps, preventing these event logs from being collected and processed. Implementing these rules may require some thought to accurately set the event type, reporting device type, and event regular expression match, for example. However, dropped events do not count towards licensed Events per Second (EPS), and are not stored in the Event database. Dropped event also do not appear in reports, and do not trigger rules. You can also specify that events should be dropped but stored, so event information will be available for searches and reports, but will not trigger rules. And example of an event type that you might want to store but not have trigger any rules would be an IPS event that is a false positive.

Procedure

1. Log in to your Supervisor node.

For multi-tenant deployments you should log in to the Super/Global account if you want to set a system-wide event dropping rule. If you want to set an event-dropping rule for a specific organization, either log in as an administrator for that organization, or or log in using the Super/Global Account and then select the organization to which the rule should apply when you are creating it.

2. Go to Admin > General Settings > Event Handling.
3. Under Event Dropping Rule, click Add.
4. Next to Reporting Device, click Edit, and use the CMDB Browser to find device group or individual device that you want to create the rule for.
5. Next to Event Type, click Edit, and use the Event Type Browser to find the group of event types, or a specific event type, that you want to create the rule for.
6. If the event type you select has an Source IP or Destination IP attribute, you can enter specific IP addresses to which the rule should apply.
7. For Regex Filter, enter any regular expressions you want to use to filter the log files.

If any matches are made against your regular expression, then the event will be dropped.

8. For multi-tenant deployments, select the Organization to which the rule should apply.
9. Select the Action that should be taken when the event dropping rule is triggered.
10. Enter any Description for the rule.
11. Click Save.

Notes

1. All matching rules are implemented by AccelOps, and inter-rule order is not important. If you create a duplicate of an event dropping rule, the first rule is in effect.
2. If you leave a rule definition field blank, then that field is not evaluated. For example, leaving Event Type left blank is the same as selecting All Event Types.
3. AccelOps drops the event at the first entry point. If your deployment uses Collectors, events are dropped by the Collectors. If your deployment doesn’t use Collectors, then the event will be droppedby the Worker or Supervisor where the event is received.
4. You can use the report System Event Processing Statistics to view the statistics for dropped events. When you run the report, select AVG(Policy Dropped Event Rate(/sec) as one of the dimensions for Chart For to see events that have been dropped to this policy.

Setting Rules for Event Forwarding

In systems management, many servers may need access to forward logs, traps and Netflows from network devices and servers, but it is often resource intensive for network devices and servers to forward logs, traps and netflows to multiple destinations. For example, most Cisco routers can forward Netflow to two locations at most. However, AccelOps can forward/relay specific logs, traps and Netflows to one or more destinations. If you want to send a log to multiple destinations, you can send it to AccelOps, which will use an event forwarding rule to send it to the desired locations.

1. Log in to your Supervisor node.
2. Go to Admin > General Settings > Event Handling.
3. Under Event Forwarding Rule, for multi-tenant deployments, select the organization for which the rule will apply.
4. Click Add.
5. For Sender IP, enter the IP address of the device that will be sending the logs.
6. For Severity, select an operator and enter a severity level that must match for the log to be forwarded.
7. Select the Traffic Type to which the rule should apply.

The Forward To > Port field will be populated based on your selection here.

8. For Forward to > IP, enter the IP address to which the event should be forwarded.
9. Click OK.

Setting Global and Per-Device Threshold Properties

Overview

Defining a Global Threshold Property

Defining Per-Device Threshold Properties

Using the DeviceToCMDBAttr Function in a Rule

Overview

In many cases when you create a rule, you set values for device thresholds that should trigger an incident. The example of a rule with a single sub-pattern, for example, contains a condition where if the average CPU utilization of a server exceeds 95% over 3 samples, an incident should be triggered. This is an example of setting an absolute value for the threshold in the rule itself.

Instead of setting an absolute value for the threshold, you can define global threshold properties that you can use as functions within a rule, and also define these threshold properties on a per-device basis. The advantage of this approach is that if you want to change the threshold values in a rule, you can edit the threshold property, rather than having to edit the rule. This is accomplished by using the DeviceToCMDBAttr function to return the value set for that device in the rule.

This table illustrates the difference between using an absolute value, shown in the first column, and threshold property, shown in the second column, in the aggregation conditions for a rule. For the threshold property, the function takes the form of DeviceToCMDBAttr(Host IP,

Threshold Property), while it takes the form of DeviceToCMDBAttr(Host IP, Component, Threshold) for devices with components as shown in the second example.

In the first example, when the rule evaluates the function, the Server CPU Critical rule will return the value of Server CPU Util Critical

Threshold for the host IP if that has been defined for the reporting device, otherwise the global threshold value will return. In the second example, if the Disk Space Util Critical Threshold is defined for a (Host IP,Disk Name) tuple, then the function returns that value, otherwise the global threshold value returns. This is an example of a Map threshold, in which there is one threshold value for each component, and which apply only to disk and interface components.

Defining a Global Threshold Property

AccelOps includes over 30+ pre-defined global threshold properties that you can edit and use in rules, but you can also create custom threshold properties.

1. Go to Admin > Device Support.
2. Click the Custom Properties
3. Click Add.
4. Enter a Name and Display Name for the new threshold property.
5. Enter the Default Value for the threshold.
6. Select the Type of threshold value.

For most global threshold values you will select Double. For Map thresholds, which apply to disks and interfaces, select the Item Type fo r the threshold value, and then select the Component Type to which it applies.

7. Click Save.

Defining Per-Device Threshold Properties

1. Go to CDMB > Devices.
2. Select a device.
3. In the Device Details pane, click Edit.
4. Click the Properties
5. For any of the threshold properties, enter a value.

If you want to edit a Map property, click Edit next to the property name, and then enter the value. If that device does not have any components to which that property could apply, you will see an error message.

6. Click OK.

Using the DeviceToCMDBAttr Function in a Rule

Using the example of the Server CPU Critical rule, you would use the DeviceToCMDB function to set a threshold for the aggregation conditions of the rule in this way:

1. In the sub pattern of the rule, under Aggregation Conditions, click the expression builder icon next to the Attribute
2. In the expression builder, under Add Function, select AVG.
3. In the Add Event Attribute field, select CPU Utilization.
4. Click OK.

The expression builder will close, and you will see the function and event attribute you selected listed as the Attribute for the Aggregate Conditions.

5. For Operator, select =.
6. Click the expression builder icon next to the Value
7. In the Add Function menu, select DeviceToCMDBAttr.
8. In the Select Function Pattern dialog, select DeviceToCMDBAttr(EventAttr,CMDBAttr).
9. Under Add Event Attribute, select Host IP.
10. Under Add CMDB Attribute, select Server CPU Util Critical Threshold.
11. Click OK.
12. Click Save.

Using Geolocation Attributes in Rules

In the same way that you can use geolocation attributes in searches and search results, you can also use them in creating rules. AccelOps includes four system-level rules based on geolocation attributes:

Failed VPN Logon from Outside My Country

Successful VPN Logon from Outside My Country

Large Inbound Transfer From Outside My Country

Large Outbound Transfer To Outside My Country

This screenshot shows the sub pattern for Failed VPN Logon from Outside My Country as an illustration of the way you can use geolocation attributes in a rule.

Using Watch Lists as Conditions in Rules and Reports

You may want to create a rule that refers to the attributes in a watch list, for example if you want to create a condition in which a Source IP listed in your DNS Violators watch list will trigger an incident.

1. Go to the rule or report where you want to use the watch list.
2. Under Conditions for the report, or under Filters in your rule subpattern, enter the watch list attribute you want to filter for in the Attribut e

For example, Source IP.

3. For Operator, select IN.
4. Click … next to Value, and use the CMDB Browser to find and select the watch list you want to use.

For example, DNS Violators.

5. Click Folder >> to select the watch list, and then click OK.
6. Continue with creating your search criteria or rule sub pattern as you normally would.

Viewing Rules

AccelOps includes a large set of rules for Availability, Performance, Change, and Security incidents in addition to the rules that you can define for your system.

1. To view all system and user-defined rules, go to Analytics > Rules.
2. For multi-tenant deployments, use the Organizations menu in the upper-right corner of the Rules List pane to filter rules by organization.
3. Select any rule in the Rules List to view information about it.

All rules have three information tabs:

Reports

You can think of reports as saved or pre-defined versions of searches that you can load and run at any time. AccelOps includes over 2000 pre-defined reports that you can access in Analytics > Reports. Topics in this section describe how to access and view information about reports, how to create baseline reports, and how to use specialized reports like the Identity and Location report. You can refine the results of your reports in the same way that you would refine the results of an historical search or a real time search.

Baseline Reports

System-Defined Baseline Reports

Creating a Report or Baseline Report

Identity and Location Report

Report Bundles

Creating a Report Bundle

Running a Report Bundle

Running System and User-Defined Reports and Baseline Reports

Scheduling Reports

Viewing Available Reports

Baseline Reports

How AccelOps Sets Baselines

Evaluating Rules and Detecting Deviations

When you are setting up AccelOps to monitor your IT infrastructure, you may want to define what is “normal” activity within your systems, and have incidents triggered when a a deviation from that normal activity occurs. For example, you can always assume that there will be some logon failures to a server on a daily basis. Rather than creating a rule that will trigger an incident when a certain hard-coded number of failures occurs, you can set up baseline reports that will trigger an incident when the total number of logon failures over a time period is twice the average over the same time period, or when the deviation from the average is threee times the standard deviation over a specific time period.

By creating a baseline report, you can set mean and standard deviations for any metric and use them in rule, and AccelOps will evaluate the current monitored values against the mean and standard deviation for that time period.

How AccelOps Sets Baselines

Establishing a baseline means recognizing that data center resource usage is time dependent:

Usage is different during weekdays and weekends, and may also be different depending on the day of the week or month Usage is dramatically higher during business hours, typically 8am-5pm

AccelOps maintains distinct baselines for weekdays, weekends and for each hour of day – a total of 24*2 = 48 buckets. Baselines for days of the week or month are not maintained to save memory usage, as this would require 31*24 = 1764 buckets, a 15 fold-increase of memory.

A baseline report is a set of Keys that represent the baselined metrics, and a collection of Values. You can see examples of these Keys and Values in the System-Defined Baseline Reports. These are then used in this process to build the report:

1. During the current hour, the Supervisor and any Worker nodes operate in parallel to save a baseline report in memory by analyzing the report events as a stream.
2. When the hour finishes:
   1. The report is written to disk (on NFS for AccelOps cluster).
   2. The Supervisor module summarizes individual baseline reports from all nodes and forms the baseline for the current hour. c. The baselines are stored in a SQLite database on a local Supervisor.
   3. The Supervisor module reads the previous baseline for the current time interval from the SQLite database. Then it combines the previous values with the current values to create a new baseline.
   4. The new baseline is then stored in SQLite database.
3. For the new hour, a new baseline is created following this process

As this process illustrates, baselining is continuous in AccelOps, and new baseline values are learned adaptively.

Evaluating Rules and Detecting Deviations

A baseline rule contains expressions that involve using the functions STAT_AVG() and STAT_STDDEV() to set dynamic thresholds.

These examples show how STAT_AVG() and STAT_STDDEV() would be used to evaluate the conditions for the example of logon failures in the introduction to this topic.

When AccelOps processes these rules:

1. Rule engine computes the current values in memory.
2. Every 5 minutes:
   1. It looks for STAT_AVG(X:ID) and STAT_STDDEV(X:ID) in memory
   2. If it fails, it retrieves them from the SQLite database and caches them for future use during the hour. c. Evaluates the rule conditions

A sample rule condition involving statistical functions is shown below with (X = AVG(fwConnCount); ID = 112).

System-Defined Baseline Reports

The following system provided baseline reports are continuously running in the system.

Network Traffic Analysis

Performance / Availability Monitoring

Logon Activity

Network Traffic Analysis

Performance / Availability Monitoring

Logon Activity

Creating a Report or Baseline Report

Creating a report or baseline report is like creating a structured historical search, because you set the Conditions and Group By attributes that will be used to process the report data, and specify Display Fields to use in the report summary.

1. Log in to your Supervisor node.
2. Go to Analytics > Reports, and select the category for your new report.

Select Baseline for baseline reports.

3. Click New.
4. Enter a report Name and Description.
5. For baseline reports, select Anomaly Detection Baseline.
6. Enter the Conditions to use in your report.

See Selecting Attributes for Structured Searches, Display Fields, and Rules and Using Expressions in Structured Searches and Rules for more information on setting conditions. For creating baseline reports, see Baseline Reports for information on how to use the STAT_AVG and STAT_STDDEV functions in creating expressions for baseline reports.

7. Select the Group By attribute to use in processing the search results.

The topic Example of How a Structured Historical Search is Processed explains how the Group By attribute is used in search results.

8. Set the Display Fields to use in your search results.

See Selecting Attributes for Structured Searches, Display Fields, and Rules for more information on using event attributes in display fields.

9. Click Save.

Your report will be saved into the selected category, and you can now run it or schedule it to run later.

Related Links

Creating a Structured Historical Search

Selecting Attributes for Structured Searches, Display Fields, and Rules

Example of How a Structured Historical Search is Processed

Using Expressions in Structured Searches and Rules Baseline Reports

Identity and Location Report

Overview

The Identity and Location Report Display Fields

Report Information and Event Types

Creating New Identity Events

Overview

The Identity and Location report is constructed by associating a network identity like an IP address, or MAC address, to a user identity like a user name, computer name, or domain, and tying that to a location, like a wired switch port, a wireless LAN controller, or VPN gateway. When any element of these associations changes, a new entry is created in the report.

The associations between IP addresses, users, and locations are obtained by combining Windows Active Directory events, DHCP events, and WLAN and VPN logon events, with discovery results to produce a report combining all of this information into a comprehensive listing of users and machines by their identity and location.

The Identity and Location Report Display Fields

The Identity and Location Report contains these display fields:

Report Information and Event Types

This table lists the events and event types that contribute to information in the Identity and Location Report, as well as what information is collected for each type of event.

Creating New Identity Events

There may be a situation in which a new event type is added to AccelOps, and you want to use the parsed attributes of that event in the Identity and Location report. Once you have made sure that the event will parse correctly, you will need to edit the identityDef.xml file for your Supervisor and any Worker nodes in your deployment.

1. Log in to your Supervisor host machine as admin.
2. Change the directory to /opt/phoenix/config/xml.
3. Logon to AccelOps Super as admin
4. Edit the xml file:
   1. Create a new <identityEvent>.
   2. For <eventType>, enter the ID of the event containing the identity attribute.
   3. For <eventAttributes>, enter the name of the event attribute and its corresponding identity attribute. For reqd, enter yes if t he event must have this event attribute for use in the identity and location report. Possible location attributes include: ipAddr macAddr computerName domain domainUser aaaUser vpnUser geoCountry geoState geoCity geoLatitude vlanId netEntryPt netEntryPort
5. Restart identityMaster and identityWorker
6. Repeat for any Worker nodes.

This code sample is an example of a new <identityEvent> entry in the identityDef.xml file

Report Bundles

Report bundles are groups of reports for common IT infrastructure analytics, such as Windows Server Health. Be defining a bundle and placing reports into it, you can run all the reports at the same time, and apply the same filter conditions to all reports. You can view system and user-defined report bundles under Analytics > Report Bundles.

Creating a Report Bundle Running a Report Bundle

Creating a Report Bundle

Creating a report bundle involves naming and describing the bundle, adding reports to the bundle, and then setting what you want to include in the report results.

1. Log in to your Supervisor node.
2. Go to Analytics > Reports > Report Bundles.
3. Click the + icon at the top of the Analytics navigation pane.
4. For Group, enter the name of the bundle, and then enter a Description.
5. Under Select Group Members, select the report category that contains the report you want to add to the bundle.

When you select a category, all the reports in that category will be added to the selection window.

6. Select a report and use the >> button to add it to the bundle.
7. Select Show Table if you want all reports to include tables by default.

You can set individual reports to show tables by selecting the report under Show Reports, clicking Edit, and then selecting Show Table.

8. Enter the number of Rows per Table.
9. Click OK.

Running a Report Bundle

1. Log in to your Supervisor node.
2. Go to Analytics > Reports > Report Bundles.
3. Select a report bundle to run.
4. At the top of the Analytics navigation pane, click the blue Arrow
5. For multi-tenant deployments, select the Organization for which the reports should apply.
6. Select the Time Range for the results.
7. Set any Data Conditions to use in filtering the results.

The most common use cases for setting data conditions involves imposing additional restrictions on the reporting devices, for example reporting devices IN a particular device group. These conditions are AND-ed to the filter conditions in every report of the bundle.

8. Click Export.

The reports will run in the background, and when ready, you will see a dialog to save or download the PDF files.

Running System and User-Defined Reports and Baseline Reports

AccelOps includes a number of baseline reports for common data center analytics, as well as over 300 reports relating to IT infrastructure. You can also create your own reports. This topic describes how to run a system-generated or user-defined baseline report.

1. Log in to your Supervisor node.
2. Go to Analytics > Reports and select the subcategory containing the report you want to run.

For baseline reports, select Baseline.

3. Select the report to run.
4. Click Run Now to run the report immediately, or Run Later to schedule the report.
5. If you chose Run Now and have a multi-tenant deployment, select the Organization for which you want to run the baseline report, and then click OK.

The report will run and the results will be displayed.

For baseline results, the values in the Profile Date Type column indicate whether the baseline date type is a Weekend (Saturday and Sunday) – 0 or Workday – 1. The values in Hour of Day, 1 – 24, column indicate the time on which the baseline is based.

You can further refine the results of reports and baseline reports as described in Using Search Results to Refine Historical Searches.

For baseline reports, you can create scatter plots of the report results, use the Quick Info menu to get more information about items in the report results, and also view geolocation information about the results. For other types of reports you can use all the charts and other methods of refining results that are related to historical search.

Related Links

Scheduling Reports

Using Search Results to Refine Historical Searches

System-Defined Baseline Reports

Overview of Historical Search Results and Charts

Using the Analysis Menu

Using Geolocation Attributes in Rules

Refining the Results from Historical Search