Statseeker Version 3.x Documentation
- Release Notes
- Hardware Requirements
- Operating System
- Supported Web Browsers
- New Installation Procedure
- Upgrade Statseeker Software
- Upgrade Statseeker Operating System
- Upgrade Statseeker Operating System using the old method
- Getting Started with the Network Infrastructure Monitor
- Report List
- Group Filter
- Device Filter
- Time Filter
- General Filters
- Administration Tool
- Change User
- Edit User
- User Accounts
- Statseeker System User Accounts
- How to Add / Edit a User
- Entity / Group Assignments (EGA)
- Entity / Group Concepts
- What is a Group ?
- What is an Entity ?
- Parent Child Relationships
- Understanding Intersects
- How to Add a Group
- How to Assign Entities to a Group
- How to Assign Groups to an Entity
- A Practical Example
- Renaming and Deleting Devices
- Time Filter
- General Filters
- General Filters - Network Infrastructure Monitor Advanced Console
- General Filters - Traffic Analyzer
- Administration Tools
- ssadmin - Command Line Server Utilities
- Administration Tool - Web Based Product Configuration
- How to Configure and Run Network Discovery
- Network Discovery Advanced Options
- How to Perform a Back Up / Restore
- How to Migrate to a New Server
- Remote Network Appliance (RNA)
- What is a Remote Network Appliance ?
- RNA Hardware Requirements
- How to Deploy an RNA
- Creating an RNA Flash Drive
- Configure an RNA
- Add an RNA to the Statseeker Server Configuration
- Duplicating the RNA Flash Drive
- Traffic Analyzer
- What is the Traffic Analyzer ?
- What is a Traffic Collector ?
- Where to Connect Traffic Collectors
- How to Deploy Traffic Collectors
- How to Configure Traffic Collectors
- Getting Started with the Traffic Analyzer
- Realtime LAN Traffic Analyzer
- Undefined Protocols
- Syslog
- SNMP Traps
- Filters and Actions for NIM Events, SNMP Traps and Syslog Messages
- Concepts
- Filters
- Actions
- Statseeker Provided Scripts
- Thresholds
- General
- Steps to Configure Threshold alerting
- Threshold Configuration
- Threshold Alerting Example 1.
- Threshold Alerting Example 2.
- Frequently Asked Questions
- How to delete / rename a device
- How to change interface details
- How to change device details
- Can Version 2.8.x be upgraded to Version 3 ?
- Can Version 2.8.x data be migrated to Version 3 ?
- Can Version 3 run on VMware ?
- What are Server ID, Hardware ID and Customer Numbers ?
- What are appropriate alphanumeric characters in my Host File ?
- How does the NIM discovery differentiate from a server and a PC ?
- Can I exclude servers and PCs from my configuration ?
- What characters can I use for my User passwords ?
- I've forgotten my root password, how do I retrieve it?
- How does Statseeker determine a device is "Down" ?
- How do I add a ping only device ?
- Should I connect my Statseeker Server to a UPS ?
- Why does Statseeker use different port numbers for each NetFlow ?
- What are allowable characters in Device or Interface name ?
- How do I add new MIBS to Statseeker ?
- How is the MAC/IP Switch Port Report generated ?
- Why can't I see the port number in MAC/IP Switch Port Report ?
- Can I customise the format of email alerts ?
- I've added a Device to a Group but only want to see specific interfaces ?
- What is IP SLA ?
- Detailed Upgrade Instructions
- Security
- Development Tools
1. Release Notes
Release Notes
2. Hardware Requirements
Unsupported Hardware/Configurations:
- VMware
- SAN (Storage Area Networks)
Server hardware requirements depend entirely on the size of the network being
monitored and the type and volume of data being collected, stored and processed.
Monitoring a small number of SNMP objects (e.g. a 10,000 interface network) and a
couple of low volume NetFlow collectors will only require a current model
commodity PC.
For best performance we recommend the following:
Up to 20,000 network interfaces and minimal NetFlow collection requirements:
- 64 bit Dual Core CPU, with 2MB of L2 cache for each core
- 2GB RAM
- 500GB Hard Drive
- Gigabit capable NIC
Up to 50,000 network interfaces and average NetFlow collection requirements:
- 64 bit Quad Core CPU, with 2MB of L2 cache for each core
- 8GB RAM
- 1TB Hard Drive
- Gigabit capable NIC
For more than 50,000 network interfaces or large NetFlow deployments, please contact
Statseeker Technical Support for assistance.
For a detailed list of supported chipsets go to:
FreeBSD Supported Hardware.
Statseeker does NOT recommend RAID 5 or 6 due to their relatively slow access speeds.
Statseeker RECOMMENDS the use of a single large disk or disks configured as RAID 0 or RAID 1.
Click here for more examples of Hardware Configurations.
A detailed discussion on hardware requirements follows:
- CPU Type
-
Number of CPU cores
There are many different CPU types, clock speeds and cache configurations available today. Statseeker's
pollers, packet capture and analysis modules, NetFlow collectors and databases use concurrent
real time processing which can make use of multi core CPUs.
Multiple CPU cores allow user initiated reports to be generated without effecting the real time
data collection and processing.
Virtual CPUs were available in many older Intel CPUs via the hyperthreading feature.
Hyperthreading is not a real CPU core and provides no benefit to Statseeker. Make sure hyperthreading
is turned OFF in the BIOS. Note: Your BIOS may use the term "Logical Processor" when referring
to hyperthreading.
-
64bit vs 32bit
Statseeker is designed, coded, profiled and tested on 64bit architecture. We do release a 32bit
version but place a heavier focus on our 64bit stream.
One of the major problems with the 32bit architecture is that it has a maximum physical memory
addressable limit of 4GB. In practice, a 32bit PC is limited to 2 to 3GB of
addressable RAM because peripheral devices such as video cards and disk controllers use chunks
of the address space below 4GB and the RAM is remapped by the BIOS to above 4GB, which is out of
the reach of a 32bit operating system. 64bit architectures do not have this severe limitation.
Note: Many of the internal data types and structures in Statseeker are 64bit, and therefore the
software will run faster when loaded on a 64bit operating system.
-
CPU speed, cache size and memory speed
The fastest CPU is not necessarily the highest clocked chip, but more a combination of CPU clock,
cache size and main memory speed. L1 cache is small, but a lot faster than L2 cache, which in turn
is a lot faster than accessing main memory. Code written to run mostly in L1/L2 cache can be orders
of magnitude faster than code accessing main memory. Much of Statseeker's code is tuned to utilize
CPU cache efficiently.
- Memory Size
Statseeker requires an ample amount of free memory to operate efficiently. Many of the modules
allocate large amounts of memory.
For example:
- database processes map large files directly into active memory
- the ping/SNMP pollers allocate ICMP/UDP socket buffers so bursts of incoming responses are not dropped
- the pollers build all requests once at start up and leave them in memory
- SNMP processes load the entire set of compiled MIBs into memory
- processes which communicate via pipes allocate large read/write buffers
- user requests load all the necessary data into memory before producing the relevant reports/graphs
- the timeseries database performs its own background preemptive file read-aheads, which fill inactive
memory with useful content before it is needed
- netflow collectors allocate large UDP socket buffers so bursts of incoming packets are not dropped
- each LAN Analyzer allocates large kernel and user process buffers
If Statseeker runs short of free memory it will swap memory contents out to disk which will have
a drastic effect on performance.
- Disk Space
Statseeker requires an ample amount of free disk space to operate efficiently. The various databases
are made up of extremely large files and it is important that these files are written to the file
system in a sequential order. When these files become fragmented, disk seek times and database
performance both drop will off dramatically.
It is important to note that the Statseeker time series database will utilize three times its
maximum daily disk allocation size as part of its daily validate, compact, and backup processes.
It is also important to note that the main consumer of disk space is NetFlow. Monitoring NetFlow
on a busy core router that has many unique IP conversations/protocol combinations can consume
an enormous amount of disk space quickly. Be sure to have a large amount of free disk space if
you wish to deploy NetFlow.
- Disk Speed
For optimum performance, Statseeker prefers a disk with fast seek speed and a large on disk
cache (16-32MB) to assist with large sequential reads and writes. The raw sequential read/write
speed is determined by how fast the disk spins and the bit density on the platters. A larger
disk (ie higher bit density) can read/write more data per revolution than a smaller disk (which
needs to spin a lot faster to make up for the performance loss). There may be no performance
improvement by selecting a smaller, often more expensive disk with faster transfer speeds.
The two modern interface types are SATA (serial ATA) and SAS (serial SCSI). Statseeker runs
and performs extremely well on a SATA disk so there is no need to buy expensive SAS disks.
Note: A SAS controller is backwards compatible with SATA, so you should be able to plug a SATA II
disk into a SAS controller without a problem. Vendors rarely mention this as they prefer to sell
you the more expensive SAS disks.
In practice, a SATA disk is as reliable as a SAS disk. Refer to the following Google disk
reliability study: http://storagemojo.com/2007/02/19/googles-disk-failure-experience/
- RAID
Statseeker has done extensive research into various file system and RAID configuration combinations
to determine optimum performance criteria and therefore recommend the following:
- Do NOT use any of the parity RAID configurations (such as RAID 5 or 6) as their performance can be
ten to fifteen times slower. Statseeker will not operate correctly while a RAID
5/6 system is rebuilding itself due to its dismal disk performance.
- For pure performance, a striped (RAID 0) configuration with a 128KB stripe size will give a
fairly optimal performance. Note: Many controllers appear to default to a 64KB stripe size.
- For redundancy, a mirrored (RAID 1) configuration will perform well. Depending on the controller,
read performance maybe be better than a single disk as the controller can read different parts
of a file from each disk.
- For both performance and redundancy, a striped/mirrored combination (RAID 1+0 or 0+1) with a
128K stripe size is best.
Statseeker developers have performed a great deal of RAID testing using a single core 500Mhz LSI
MegaRAID controller (Dell Perc 6 equivalent) and a dual core 1.2GHZ Adaptec controller, with batteries
installed and write caching enabled. Both controllers performed well, but the cheaper LSI
controller was a performance bottle neck in large six disk RAID configurations. All testing
was performed using commodity 7200RPM 500GB SATA II disks.
- Ethernet Controllers
Use a Gigabit capable NIC. Do NOT use a 10/100Mb NIC. Our testing has shown that the
performance of the pollers deteriorates when running on 10/100Mb NICs.
The ping pollers maximum rate is reduced from more than 60,000 per second to 3,000 per second,
a 20 times drop in performance.
- Hardware Configuration Examples
(Large Networks)
This specification should scale to 50,000 interfaces and a moderate amount of NetFlow collection.
- Motherboard
- Intel DQ35JO Desktop motherboard with onboard Intel Gigabit NIC
- CPU
- Intel Core2 Quad Processor Q6600 with 2MB L2 cache per core
- RAM
- 8GB
- 4 * 2GB 667Mhz DDR2 modules
- Installed in pairs for 1066Mhz memory bandwidth
- Disk
- 750GB Seagate 7200RPM SATA II
- 32MB on disk cache
- raw sequential read performance of ~105MB per sec
3. Operating System
Statseeker software runs "ONLY" on the FreeBSD operating system which is derived
from BSD UNIX®. Statseeker chose FreeBSD as a platform due to its long history
of high performance networking functionality, its stability under extreme loads
and its rigorous development/release model.
Statseeker's unique installation process automatically installs the
FreeBSD operating system in minutes and ensures that NO KNOWLEDGE OF UNIX
is required to successfully install and maintain the product.
4. Supported Web Browsers
- IE 7
- Firefox
- Flock
- Safari v3
- Konqueror
- Opera
Notes:
- IE6 is NOT supported
- Disable popup blockers for the Statseeker server
- Ensure that Javascript is enabled
- Disable Tabs and allow pages to open in a new window
- For IE 7 - Add the server URL as a "Trusted Site" on your local Intranet.
Internet Options -> Security -> Local Intranet -> Sites -> Advanced
5. New Installation Procedure
Important Notes
- All data on the hard disk will be deleted
- The following configurations are NOT supported.
- VMware
- Raid 5/6
- SAN drives
Before you begin, you will need the following:
- A Server ID Number. The Server ID number is supplied by Statseeker. You can request a Server ID Number
by emailing keys@statseeker.com or by directly contacting your Statseeker Representative.
- The Statseeker Installation CDROM (Download and burn the appropriate CD image). The download is
available from: Release Notes
- If you can not download the product or if you require a product CD kit, please email keys@statseeker.com
You will also need to provide several additional items for the Installation
- Mandatory Items
- A root password for the server (you will need to make this up).
- A hostname for the server (Example: Statseeker)
- Static IP, Netmask and Default Gateway addresses for the server
- The IP address of your DNS
- The SNMP read access community string to your devices (routers, switches, etc...)
- Non Mandatory Items
- SMTP Gateway IP address
- HTTP Proxy IP address, Port Number, Username and Password
- NTP Server IP address
New Installation Procedure
- Set the server BIOS
- To your local time
- First boot device to CDROM
- Second boot device to the hard disk
- Connect the server to a centrally located LAN segment with only ONE router connected to it.
- Boot the server from the Statseeker Installation CDROM.
- Press [Enter] to confirm the following hardware warning message.
- Press [Enter] to confirm the following warning and proceed with the installation. All data on the hard disk will be deleted.
- If the server has multiple logical disks, you will be asked which disk to use for the installation.
- If the disk is more than 1 TB in size, you will be asked if you want to use the new method for partitioning filesystems.
The new method for partitioning the filesystems supports filesystem sizes greater than 1 TB. You should try using the new method first.
Some hardware will not support the new method and you will need to reinstall using the old method.
The old method for partitioning filesystem will only use 1 TB of the disk
- At this stage, the disk will be formatted and the operating system installed. You will see some progress messages
appear and these can be ignored.
- When prompted "Is this machine's CMOS clock set to UTC ?", select "No", then follow the on-screen instructions
to set the time zone.
- Enter a root password twice. You will need to create this password. This will also be the WEB admin password.
It is recommended you remember this password.
- The Network interface information required" screen will appear.
Select the Ethernet card and [OK] to continue.
- The "Network Configuration" screen will appear.
Fill in the following fields and then select [OK] to continue.
- Host Name of the server (Example: Statseeker)
- Domain Name (Example: yourdomain.com)
- IPv4 Gateway IP address
- Name Server IP address
- IPv4 Address of the server
- Netmask
- Leave the extra options empty and press [Enter].
- Press [Enter] to bring the interface up.
- The installation will now install the final packages and perform a disk performance check.
- Remove the CDROM when the installation is complete. The server will reboot to the login prompt.
- Login on the console as the "root" user and try and ping an address on your network to test network
connectivity (Press CTL + c to end the ping).
- If required you can run the ssadmin command to set the following items:
- SMTP Gateway IP address and Masquerade as domain name
- HTTP proxy IP address, port number, username and password
- NTP server IP address
(Note: Enter "q" to exit ssadmin , and then "exit" to logout.)
- Point your browser at the server and login as admin (Use the password you provided in step 9).
- Click on the "Administration Tool" button to start the configuration process.
- Select the "License Key" link - Enter your Server ID Number and press "Download" to retrieve a License Key.
- Accept the License Agreement by checking the "Accept License" box and then press "Save".
- If you do not have Internet access, email your Server and Hardware ID Numbers to keys@statseeker.com.
- You can not proceed until you have a valid License Key.
- Configure Statseeker to run on your network. Generally this requires the below steps be followed.
It is recommended that you review Section 13.3 How to Configure and Run Network Discovery
for more details on these steps.
- Select the "SNMP Communities" link - Enter the SNMP community names and press "Save".
- Select the "Hosts File" link - Enter a list of your devices in hosts file format as described
and press "Save". This is not mandatory however all detected devices will be displayed as IP addresses
that can be renamed later.
- Select the "Discover Ranges" link - Enter a list of network addresses to be discovered and press "Save".
- Select the "Discover My Network" link - Start the Network Discovery and watch the log. Be patient as it takes a
few minutes for the discover process to scan the network, test the devices for SNMP, walk the necessary
MIB trees and build its configuration files. When finished the log will display "Completed".
- Close the Administration Tool and click on the "Reset" button. The device list will be populated with the
discovered devices. It will take approximately five minutes for initial data values to populate the reports.
6. Upgrade Statseeker Software
- Either download and burn the appropriate upgrade CD image to CDROM and insert into the server
or download and copy the appropriate upgrade CD image to "/home/statseeker/cdrom".
Download available from: Release Notes
- Log into the Statseeker server and run ssadmin.
- Select Option 5 -> Software Upgrade.
- When complete, remove the CDROM.
NOTE: For a detailed overview of the upgrade procedure, FTP instructions and the use of ssadmin go to:
Detailed Upgrade Instructions
7. Upgrade Statseeker Operating System without removing Statseeker data
Should I use this process:
Thing I Need before starting:
- Mandatory Items
- A VALID BACKUP of the Statseeker server.
- A root password for the server
- A hostname for the server (Example: Statseeker)
- Static IP, Netmask and Default Gateway addresses for the server
- The IP address of your DNS
- The Statseeker Installation CDROM (Download and burn the appropriate CD image). The download is
available from: Release Notes
- If you can not download the product or if you require a product CD kit, please email keys@statseeker.com
- Non Mandatory Items
- SMTP Gateway IP address
- HTTP Proxy IP address, Port Number, Username and Password
- NTP Server IP address
Upgrade Procedure (without replacing /home/statseeker)
- Ensure you have a valid backup
- Set the server BIOS
- To your local time
- First boot device to CDROM
- Second boot device to the hard disk
- Boot the server from the Statseeker Installation CDROM.
- Press [Enter] to confirm the following hardware warning message.
- Press [Enter] to confirm the following warning and proceed with the installation. All data on the hard disk will be deleted.
- If the server has multiple logical disks, you will be asked which disk to use for the installation.
- If the disk is more than 1 TB in size, you will be asked if you want to use the new method for partitioning filesystems.
Ensure you choose the method for partitiong that you previously used. If you change this method, you will lose
all data on the Statseeker server.
- The installation procedure will detect the /home/statseeker filesystem and display the following screen.
Select "Yes" to upgrade the operating system without replacing /home/statseeker.
- At this stage, all filesystems (except /home/statseeker) will be recreated and the operating system installed. You will see some progress messages
appear and these can be ignored.
- When prompted "Is this machine's CMOS clock set to UTC ?", select "No", then follow the on-screen instructions
to set the time zone.
- Enter a root password twice. You will need to create this password. This will also be the WEB admin password.
It is recommended you remember this password.
- The Network interface information required" screen will appear.
Select the Ethernet card and [OK] to continue.
- The "Network Configuration" screen will appear.
Fill in the following fields and then select [OK] to continue.
- Host Name of the server (Example: Statseeker)
- Domain Name (Example: yourdomain.com)
- IPv4 Gateway IP address
- Name Server IP address
- IPv4 Address of the server
- Netmask
- Leave the extra options empty and press [Enter].
- Press [Enter] to bring the interface up.
- The installation will now install the final packages and perform a disk performance check.
- Remove the CDROM when the installation is complete. The server will reboot to the login prompt.
- Login on the console as the "root" user and try and ping an address on your network to test network
connectivity (Press CTL + c to end the ping).
- Run the ssadmin command to reconfigure the following items:
- SMTP Gateway IP address and Masquerade as domain name
- HTTP proxy IP address, port number, username and password
- NTP server IP address
- Date, Time and NTP
- Email
- Network Configuration
- Backup
- Passwords
- Operating System
- Web Server
8. Upgrade Statseeker Operating System using the old method
If you can not use the "Upgrade Statseeker Operating System without removing Statseeker data" method,
to upgrade the operating system:
- Download and burn the appropriate "os" CD image.
Download available from: Release Notes
- Use the Backup/Restore utility in ssadmin to perform a
backup of the server.
- Perform a clean installation using the latest Statseeker Installation
CDROM.
- Use the Backup/Restore utility in ssadmin to perform a
restore of the server. The server will reboot after a successful restore.
9. Getting Started with the Network Infrastructure Monitor
The NIM is the nerve center of the Statseeker product set. The NIM consists of two user consoles -
the Standard console and the Advanced console for administrators and power users. Administrator
logins will automatically be taken to the advanced console whilst all other users will be taken
to the standard console upon login.
Notes and Tips:
- To run a report from the Report List simply click on the report.
- Some reports may require a Time Filter or General Filter to be selected before the report is run.
- It is recommended that users select either a Device OR Group Filter prior to running a report to
reduce the amount of data to be viewed. Users cannot select a Device AND Group Filter.
- To create a new Group Filter see Entity / Group Assignments (EGA)
- Users can select multiple Devices OR multiple Groups.
- Click on the Clear Filters button at the bottom right corner of the NIM Console to reset / clear
filters.
- Click on "Sort Arrows" under each column heading to sort the report by that column type.
- For your convenience most reports include a "Last N" drop down time filter which is centrally
located above the report column headings.
- Most reports have drill down features. Mouse over the rows, columns, and images of each report
to familiarise yourself with the drill down fields of each report.
- The standard NIM console is the default console for all non-admin users. This console allows users
access to the most commonly used reports and time filters within Statseeker. To toggle to the
advanced console select the Advanced console button.
- The Advanced Console is the default console at login for the Statseeker admin user. This console
allows users access to all reports they have been given access to, including the advanced reporting
tools. The advanced console also provides expanded time filter and general reporting options.
Administrators can access the Administration toll from the advanced console.
The NIM console consists of seven easy to use sections:
8.1 Report List
The report list in Statseeker has been grouped logically into infrastructure types, technology types
and vendor specific reports.
Statseeker currently reports on the following infrastructure and technology types:
- Ping (Network Devices)
- Network Interfaces
- Frame Relay
- Servers
- Events (Syslog, SNMP Traps)
- Cisco specfic reports
- UPS
- APC
- General (Traffic Analyzer, NetFlow, sFlow, Printers etc)
Statseeker currently produces the following report types:
- Top N Graphs - (including Top Delay Graphs, Top Utilization Graphs, Top CPU Load Graphs etc)
- Availability Reports - (including Device SLA Availability; port usage reports etc)
- Statistics Reports - (including Interface Statistics Report, SNMP Poller Statistics etc)
- Event Reports - (including Syslog, SNMP Traps, Interface Events etc)
- List views - (including MAC/IP/Switch Port report and Printer statistics)
- Configuration Reports - (Interface Details and Device Details reports)
- Vendor or Technology Specific reports - (including Cisco CPU Load, IP SLA, NBAR, UPS etc)
- Reporting Tool - (applicable to each report group and directly available from Advanced console only.
Reporting tool options are available in some reports as drill downs)
Top N Graphs:
- Top N graphs rank all data in the filter selection showing the top 50 values in the Advanced console
and Top 20 values in the Standard console - both over the last 6 hours.
- The graph is read left to right and top to bottom.
- Scaling is set to either 100% or will autoscale to the highest value on any of the top 50 entries.
This scaling is then applied to all other entities in the report to allow comparison against the
first / 'busiest' entity.
- For additional detail click on the graph to drill down to the detailed performance across
additional timezones and time filter selections.
- To adjust the number of entries displayed in the Top N graphs change the Top N filter option from
50 to the desired number in the General options of the Advanced NIM Console. Rg. Changing this
value to 100 and running a top N graph will now display the top 100 entries.
Availability Reports:
- Report on the SLA availability of a device, multiple devices, a group of devices or multiple
groups of devices.
Statistics Reports:
- Statistics reports provide additional information against preset time periods.
Statistics reports differ from the Top graphs in that they show more than just one data type.
For example:
The Top Utilization Graph shows utilization over time, and the Interface Statistics report
shows Rx and Tx Utilization, bytes, bps, errors, discards, packets, % packets in error,
% packets discarded etc.
- The default setting for the Statistics Reports is the top 50 results in the Advanced NIM Console
and top 20 results on the Standard Console. For the advanced console this length is controlled by
the Top N Filter on the Advanced NIM Console.
- The reports are pre-calculated for the last 5 minutes, 1 hour, 24 hours and on some reports the
last 90 days.
- The links column of the statistics report will open the Advanced reporting tool. See Advanced
Reporting Tool.
Event Reports:
- Event reports record entries as they occur.
- Since Events are not time series data they are stored with both the event and the time it occurred.
- Events can have notes added to them by selecting the Function column. Examples of NIM Events
include ping_state down, ping_state up.
- SNMP Traps and syslog are also considered events and have their own reports.
- Event reports require that the Time Filter options on the NIM Console be set before running the
report.
Reporting Tool:
- The reporting tool is used for advanced analysis (refer to The Reporting tool and Advanced Report
Building for more information).
- Each report group has a reporting tool option.
- The reporting tool consists of an entity filter, a time filter and general output options.
- Selections must be made in each of these for the reports to generate successfully.
- Users can change the look and feel of a generated graph by changing the General or Graphing
Options.
- The reporting tool is available directly from the Advanced NIM console or by drill down from the
Statistics reports using the Advanced Reporting Tool link.
List Views:
- List views present data in a list format. Examples of this include the MAC/IP/Switch Port
report, Syslog, and printer statistics.
- Users can reduce the viewed syslog messages by using the Text Filter on the NIM Console to
search for specific syslog messages, OR use the Time Filter on the NIM Console to search
through time ranges for messages.
Configuration Reports:
- The Interface Details and Device Details reports provide the ability to edit the configuration
on the following fields:
- Interface Details Report - Interface Title, Tx and Rx Speeds, Oper Status and Polling
Status.
- Device Details Report - Device Name, IP Address, Ping Status, SNMP Polling Status,
Community String.
- Users can lock configuration changes so subsequent rewalks do not override settings.
- Available from the Advanced NIM console only.
Vendor/Technology Specific reports:
- There are a number of vendor specific or technology specific reports.
For example - Reports List - Cisco Reports - IP SLA, Process Table and NBAR reports are all
specific to Cisco devices.
- Vendor devices will continue to be added to the product.
8.2 Group Filter
Go to: Entity / Group Assignments (EGA)
8.3 Device Filter
Every time a device is added to Statseeker it is displayed in the Device Filter list. Devices that
appear as IP addresses can either have an entry added to the Hosts File (via the Administration Tool)
or be edited via the Device Details report (but only by users with Administration rights) to display
a device name. The Device Filter displays the list of devices that your User profile gives you access
to view. Reports can be filtered down to single or multiple devices through this Filter.
8.4 Time Filter
Go to: Time Filter
8.5 General Filters
Go to: General Filters - Network Infrastructure Monitor Advanced Console
8.6 Administration Tool
Go to: Administration Tool
8.7 Change User
Click on the Change User button to log out as the current user and log in as a different user.
See: User Accounts
8.8 Edit User
Enables user to change their Email address, Password and default Time Zone.
10. User Accounts
10.1 Statseeker System User Accounts
There are three main Statseeker System User Accounts:
- admin - The "admin" web administrator account is the only account that can perform
configuration changes. All other web users run as non-privileged users. The admin user has
access to all groups and entities. There can only be one admin web administrator account.
- statseeker - The "statseeker" user is a UNIX account used by the Statseeker application.
- root - The "root" superuser is a UNIX account used to run start / stop scripts and processes
which need access to privileged files / network ports
10.2 How to Add / Edit a User
To add a new User or edit the details of an existing User:
Administration Tool -> Group Assignments -> Add / Edit User (Add)
- Type the User name into the text box and select "Add"
- Enter an email address and password and select "Save User"
- The web server will automatically restart to make the User available.
Administration Tool -> Group Assignments -> Add / Edit User (Edit)
- Select a User and select "Edit"
- Change relevant details and press "Save user"
- The web server will automatically restart to make the User's details.
11. Entity / Group Assignments (EGA)
11.1 Entity / Group concepts
Entity / Group Assignments (EGA) is used to:
- group entities into useful groups for reporting
- control who gets to see what within the product
- create user profiles based on role, geographical location, department
etc or combinations of all
For example, by using the EGA it is possible to create one user group for the helpdesk team
that only sees a specific list of reports, on certain devices, and with specific
time filters. It is also possible to create another EGA for the server team that
limited only to servers, with server specific reports etc ...
11.2 What is a Group ?
A "group" is simply a list of names. It is best to use descriptive group names.
For example:
- Report: Helpdesk
- Report: Network Guys
- ...
- Device: Core Routers
- Device: Core Switches
- Device: UPS
- ...
- Interface: 10G Ethernet
- Interface: Frame Relay
- Interface: Serial
- ...
- Vendor: 3Com
- Vendor: Cisco
- Vendor: Nortel
- ...
- Country: Australia
- Country: United Kingdom
- ...
General:
- Each group name is assigned an internal unique identifier. This identifier never changes.
- You can rename the group without effecting the assigned EGA permissions.
- There is a special group called "All Groups". If a user belongs to the "All Groups" group,
then they have unrestricted access to that entity.
Interface Groups are automatically created for every interface speed discovered on the network and
every interface type found. This option is able to be toggled on/off from the administration tool -
network discovery - advanced options section. Automatic Interface groups are created/updated when a
discovery occurs or on a software restart.
11.3 What is an Entity ?
An entity is a:
- report
- time filter
- device
- port
General:
- An entity can belong to zero, one or multiple groups.
- For convenience, the EGA configuration GUIs allow the administrator to assign
"an entity to list of groups" or "a group to a list of entities".
- A user only has access to an entity if they belong to the same group as that entity.
11.4 Parent / Child Relationships
Some EGA types have a parent/child relationship. Having access to a parent
automatically allows access to all its children. But, having access to a child
does NOT allow access to its parent. Currently, only device and port EGA types
are setup this way. For example, if you have access to a device, all port/interface
statistics can be accessed. But if you have access to a port and not the device,
then you can see the statistics for that particular interface, but not for the
device or any other interface on that device. This allows an administrator to specify
precisely what reports, devices and interfaces a user can access.
11.5 Understanding Intersects
EGA is implemented as "intersects", as per the diagram below. In this
example, 'Fred' has access to 'Core-router' because they both belong to
'Group D'.
11.6 How to Add a Group
Administration Tool -> Group Assignments -> Add / Edit Groups
- Type the Group name into the text box and select Add
11.7 How to Assign Entities to a Group
- Administration Tool -> Group Assignments -> Users to a Group
- Select a Group name and a list of Users will appear in the right window
- Select the Users you wish to assign to the Group
- Click on arrows to move the Users into the "Include" area
- Administration Tool -> Group Assignments -> Reports to a Group
- Select a Group name and a list of Reports will appear in the right window
- Select the Reports you wish to assign to the Group
- Click on arrows to move the Reports into the "Include" area
- Administration Tool -> Group Assignments -> Devices to a Group
- Select a Group name and a list of Devices will appear in the right window
- Select the Devices you wish to assign to the Group
- Click on arrows to move the Devices the "Include" area
- Administration Tool -> Group Assignments -> Interfaces to a Group
This is a non-mandatory selection.
- Select a Group name and a list of Interfaces will appear in the right window
- From the drop box in the right selection window choose the device to
select interfaces from. If interfaces are to be selected from multiple
devices select each device in turn from the drop down list and choose the appropriate interfaces which are to be included.
- Select the Interfaces you wish to assign to the Group
- Click on arrows to move the Interfaces into the "Include" area
- Administration Tool -> Group Assignments -> Time Filters to a Group
This is a non-mandatory selection.
- Select a Group name and a list of Time Filters will appear in the right window
- Select the Time Filters you wish to assign to the Group
- Click on arrows to move the Time Filters into the "Include" area
11.8 How to Assign Groups to an Entity
- Administration Tool -> Group Assignments -> Groups to a User
- Select a User name and a list of Groups will appear in the right window
- Select the Groups you wish to assign to the User
- Click on arrows to move the Groups into the "Include" area
- Administration Tool -> Group Assignments -> Groups to a Report
- Select a Report name and a list of Groups will appear in the right window
- Select the Groups you wish to assign to the Report
- Click on arrows to move the Groups into the "Include" area
- Administration Tool -> Group Assignments -> Groups to a Device
- Select a Device name and a list of Groups will appear in the right window
- Select the Groups you wish to assign to the Device
- Click on arrows to move the Groups into the "Include" area
- Administration Tool -> Group Assignments -> Groups to an Interface
This is a non-mandatory selection.
- Select the device to add the groups to
- Select a Interface name and a list of Groups will appear in the right window
- Select the Groups you wish to assign to the Interface
- Click on arrows to move the Groups into the "Include" area
- Administration Tool -> Group Assignments -> Groups to a Time Filter
This is a non-mandatory selection.
- Select a Time Filter name and a list of Groups will appear in the right window
- Select the Groups you wish to assign to the Time Filter
- Click on arrows to move into the Groups the "Include" area
11.9 A Practical Example
As a practical example let's say that management has determined that the Help Desk Team
should only view interface utilization charts, PING response time performance and current
device outages information. A single user/login called "helpdesk" is to be created and
given access to this setup.
To set up an EGA to meet these criteria first open the Administration Tool to add a new
user if they don't already exist.
Administration Tool -> Group Assignments -> Add / Edit Users
- Type the User name into the text box and select Add (in this example "Helpdesk" is to be the user)
- Enter an email address and password
- Press "Add User"
The next step is to add a group called "Helpdesk".
Administration Tool -> Group Assignments -> Add / Edit Groups
- Type the group name "Helpdesk" into the text box and select Add
Now assign the EGA relationships to the new group.
Administration Tool -> Group Assignments -> Users to a Group
It is possible to assign an Entity to the Group or a Group to an entity.
Either method is correct.
After selecting the Users to a Group link, we can now add the "Helpdesk" user to the
"Helpdesk" group. The "Helpdesk" user is the user that can login into Statseeker. The
"Helpdesk" Group will have entities assigned to it. Users which have been associated to this group will
have access to all entities that have been assigned to this group within Statseeker.
- Select the Group name "Helpdesk" and a list of Users will appear in the right window
- Select the user "Helpdesk"
- Click on arrows to move the user "Helpdesk" into the "Include" area
NOTE: If you create a User with "All Groups" access then they will be added
automatically to any new groups added at a later time.
Administration Tool -> Group Assignments -> Devices to a Group
Repeat the process to add Devices to the Group.
Administration Tool -> Group Assignments ->> Reports to a Group
Repeat the process to add Reports to the Group. It is at this step that
the TopN Interface report, Ping outages Report and Top N Ping reports are
selected.
NOTE: Selecting multiple entries makes the job easier!
Log in as the new user "Helpdesk" by returning to the Network Infrastructure
Monitor console and changing the user to "Helpdesk".
11.10 Renaming and Deleting Groups
12. Time Filter
Statseeker databases and Reporting Tools utilize a single time/date filter mechanism for
narrowing data searches. Time filters can be applied by making one or a number of selections from
the time filter options. The resultant time filter can then be applied to a report or even saved
as a favorite for future use. The advanced time filter is available from the Advanced NIM console
and in the advanced reporting tools. The Standard NIM console includes the time filter favorites
and timezone selections only.
Examples of applying a time filter range from relatively simple selections using Statseeker provided
favorites through to complex user created filter selections. There are seven options available when
creating a Time Filter for a report.
12.1 Favorites
- The most basic method of selecting a time filter is to use the Statseeker provided
favorites - which is a list of pre-configured time filters.
- Using these favorites will automatically create a range for a report.
- The range can be seen in the Custom Filter text box.
- Some examples of the Favorites and the range they create include:
"Last 21 days" creates a "range = start_of_today - 21d to now;"
"Last 15 minutes" creates a "range = now - 15m to now;"
"Yesterday" creates a "range = start_of_today - 1d to start_of_today;"
"This month" creates a "range = start_of_this_month to now;"
- Favorites can be modified and then saved as a new favorite by clicking the Modify button.
- Statseeker Administrators can also add or delete custom Time Filters as Favorites in the
Administration Tool. Administration Tool -> Group Assignments -> Add / Edit Time Filters.
12.2 Range
- Allows users to make selections using the drop down boxes for different time periods
(year, month, days hours minute); the duration of the range; the workdays and specific
hours.
- It is also possible to select the Timezone that the report will be generated in.
- Note that year, month, day, hour and minute selections are the starting points for the
time filters. A duration also needs to be applied to complete the range.
- Three examples of the different levels of time filters built from the range drop downs
include:
- Creating a time filter for March and April 2008, can be achieved by selecting:
year = 2008;
Month = March;
Duration = 2 months
This will create the range:
"range = 2008-03-01 to 2008-05-01;"
- Creating a time filter for the 15 days from June 20, 2008 for Monday to Friday only:
year = 2008;
Month = June;
Day= 20
Duration = 15 days
Weekday = Mon to Fri
this will create the range:
"range = 2008-06-20 to 2008-07-05; wday = Mon to Fri;"
- Creating a time filter for the 15 days from June 20, 2008 for Monday to Friday,
from 8am to 5pm only:
year = 2008;
Month = June;
Day= 20
Duration = 15 days
Weekday = Mon to Fri
Time: 8:00am to 5:00pm
this will create the range:
"range = 2008-06-20 to 2008-07-05; wday = Mon to Fri; time = 08:00 to 17:00;"
12.3 Duration
- Adjusts the end time of the query. Granularity of Duration is determined by the finest
granularity selected in the drop down lists of the Range filter. For instance - if the
finest level of range selected is months, then the duration available will be N months;
if the finest range selection is hours then the duration selection will be N hours
12.4 Weekday
- Inserts start day only OR start and end day into the query.
12.5 Time
- Inserts start time only OR start and end time into the query.
12.6 Time Zone
- Many organizations span multiple time zones making it necessary to view data in the
time zones of those distributed locations.
- Statseeker stores all historical data in GMT/UTC and can report the data in any time
zone by using the Time Zone selector.
- Administrators can select what time zones appear in the Time Filter via
Administration Tool -> General -> Time Zone Selection
12.7 Custom Filter Text Box
- An alternative to using the Favorites and Range drop down boxes is to use the
custom filter text box.
- The custom filter allows users to create their own detailed time filters using regex.
- The following query options are available for use:
Note:
- The = operator includes the specified option
- The != operator excludes the specified option
time
At least one range value must be defined to specify the start/end times of the query.
The range can be specified in multiple query formats and may contain basic arithmetic.
The following range keywords are available for use:
now
forever
start_of_today
start_of_this_year
start_of_this_month
start_of_this_week
start_of_last_year
start_of_last_month
start_of_last_week
end_of_today
end_of_this_year
end_of_this_month
end_of_this_week
end_of_last_year
end_of_last_month
end_of_last_week
Each of the following result in the same query:
range = 2008
range = 2008-01-01 to 2009-01-01
range = start_of_this_year to end_of_this_year (Assuming the year is 2008 of course!)
time
Each of the following result in the same query:
time = 8am to 6pm
time = 08:00 to 18:00
time = 08:00:00 to 18:00:00
wday (weekday)
Each of the following result in the same query:
wday = mon,tue,wed,thu,fri
wday = mon to fri
wday != sat,sun
wday != sat to sun
wday = 1,2,3,4,5
wday = 1 to 5
wday != 6,7
wday != 6 to 7
mday (day of the month)
Each of the following result in the same query:
mday = 5,6,7,8,9,10
mday = 5 to 10
mday != 1 to 4 mday != 11 to 31
month
Each of the following result in the same query:
month = jun,jul,aug,sep
month = jun to sep
month != jan to jun month != oct to dec
month = 6,7,8,9
month = 6 to 9
month != 1 to 6 month != 10 to 12
year
Each of the following result in the same query:
year = 2006 to 2008
year = 2006,2007,2008
Custom Filter Examples:
Each of the following result in the same query:
range = 2008 wday = mon to fri time = 8am to 5pm
range = 2007-08 wday != sat,sun time != 01:00 to 03:00
- An example of a complex time filter may be:
"range = start_of_today - 21d to now; wday = Mon to Fri; time = 06:00 to 20:00; time != 11:00 to 13:00;"
This filter limits the report to Monday to Friday from 6am to 8pm for the last 21 days but excludes
11am to 1pm.
- Note: a range must always be specified for a time filter to be applied.
12.8 Examples of Filter Combinations
- Filter combinations allow users to create reports using one or a number of the methods above.
- For instance, the complex filter created above can be simply created by using a combination of
the available options. For instance, to create this filter without needing to type in the entire
regex directly:
- select "Last 21 Days" from the Favorites. The custom Filter Box now updates as:
"range = start_of_today - 21d to now;"
- select Monday to Friday from the weekday drop downs:
"range = start_of_today - 21d to now; wday = Mon to Fri;"
- Select 6am to 8pm from the Time option:
"range = start_of_today - 21d to now; wday = Mon to Fri; time = 06:00 to 20:00;"
- To add in the not including 11am to 1pm copy the time portion of the above range
(time = 06:00 to 20:00) and paste at the end of the current expression. Edit the times.
The new range now becomes:
"range = start_of_today - 21d to now; wday = Mon to Fri; time = 06:00 to 20:00; time != 11:00 to 13:00;"
12.9 Saving Filters
- Custom time filters can be saved for use again as needed.
- These filters can be saved from the time filter selection box on any reporting tool using
the Modify button, from the NIM advance Console Time Filter section using the Modify button
or from the Administration Tool from the Add/Edit time filters option (Administrators only)
- Any time filters that have been created can then be assigned to groups by the administrator
using the Time filters to groups option.
- This is useful in assigning a group of users the same time filters that may be relevant to them.
To create a favorite from the NIM console after making the selections:
- click the modify button
- provide a title for the filter
- ensure the range box has the desired filter
- adjust as necessary
- save
To create a favorite from the Administration Tool
- Go to Administration tool -> Group Assignments -> Add/Edit Time Filters
- Select Add (or edit if editing an existing filter)
- Create the filter
- Provide a title
- Save
13. General Filters
13.1 General Filters - Network Infrastructure Monitor Advanced Console
Notes and Tips:
- Use the Reset button to clear all Filters
- Top N
Top N sets the number of records that Statseeker will show in its reports.
The default setting of 50 determines the report length of 50 entries. Changing this
number will change the number of records shown in reports that this filter applies to.
Selecting the Interface Statistics report will display the Top 50 interfaces.
Changing the Top N General Filter to 250 will display the Top 250 entries.
- Text Filter
Adding text into this box limits the results of certain reports. This is useful in those
reports containing many text entries (such as syslog and SNMP traps reports).
- Grouping Option
The grouping options allows users to determine how the selection of multiple groups
will be executed for reports. The AND option is the intersect of multiple groups - this
option is used when the criteria of each group must be met to return a result. The OR
option is the UNION of multiple groups - this option is used when the criteria is to
report on entities in either group. For example:
- Selecting the High Priority Devices group and the Router Group with the AND grouping
option will only return devices that have been assigned as both a high priority
device AND and a Router.
- Selecting the High Priority Devices group and the Router Group with the OR grouping
option will return devices that have been assigned as Either a high priority device
OR a Router.
13.2 General Filters - Traffic Analyzer
Notes and Tips:
- Use the Reset button to clear all Filters
- Need to use "inc" to signify inclusions
- Examples of Address and Protocol filters are available by mouse-over of the "?" within
the Traffic Analyser Reporting console
- Address
Filter by IP Address
<inc|exc> <src|dst|both|either> [and|or] ...
Some examples:
inc src 10.2.1.23 - traffic from this IP
inc src 10.2.1.0/24 - traffic from this subnet
inc dst 10.2.1.0/24 - traffic coming to this subnet
inc both 10.2.1.0/24 - traffic only on this subnet
inc src 10.2.1.0/24 and inc dst 10.3.1.0/24 - traffic from one subnet to another subnet
- Protocol
Filter by protocol and sub protocol type.
<inc|exc> {protocol}.{subprotocol} ....
e.g. inc TCP.telnet
inc TCP.telnet inc TCP.ssh
inc udp.dns inc arp.Request
inc ICMP.*
inc TCP.*
Wildcards can only be used for subprotocols.
- Top N
Specifies the number of entries in a report. (Default of 0 "zero" turns off the TOP N filter and
shows all entries.
- Sort
Sort by Bytes, Protocol, Conversations, Destination, Source or Packets.
- Interval
Used to quickly break a query down into day, hour or minute intervals. Format: (Nd, Nm, Ns)
e.g. 5d = 5 days, 5h = 5 hours, 5m = 5 minutes.
- Format
Specify number formats: (Short format:- 98M / Long format:- 99,999,999 / Raw format:- 99999999).
- Display
Allows reports to be displayed in a tabular format, graphically or a combination of both.
14. Administrator Tools
Statseeker provides two administration tools for the administration and configuration of the Statseeker
server and product. ssadmin is a command line tool used to configure the Statseeker server, while
the Administration Tool is a web based tool accessed from within the product, used to configure the
Statseeker software.
14.1 ssadmin
ssadmin is a command line tool is used to configure the Statseeker server.
Use ssadmin to:
- Set system time/date
- Configure NTP servers for time synchronization
- Configure SMTP email
- Configure HTTP proxy settings
- Configure network interface settings
- Turn on/off network services (telnet, ftp, DNS lookups)
- Perform software upgrades
- Configure backup and restores
- Change Statseeker system passwords
- Configure various operating system parameters / reboot server
- Create an RNA USB flash drive
To run ssadmin :
- Login to the server as the "statseeker" user via the console,
telnet, or ssh.
- Run ssadmin. ssadmin requires superuser access so you
will need to know the 'root' password.
- Follow the menus.
14.2 Administration Tool
The Administration Tool is accessed via the Network Infrastructure Monitor Console and is
used to configure the Statseeker software.
Use the Administration Tool to:
General:
- Set the Server ID Number and add a License Key
- Set Time Zones available for reports
- Configure, finetune and run the Network Discovery Program
- Create and Manage Users
- Create and manage Groups
- Control User profiles (who can see what)
- Configure NIM Filters, Actions and Events for Alerting
- Configure Thresholds, Filters and Actions for Alerting
- Use the SNMP Walk Tool
- Configure the Traffic Analyzer (NetFlow, sFlow, LAN Traffic Analyzer)
- Create an internal diagnostics report to aid in technical support
- View Statseeker log files
14.3 How to Configure and Run Network Discovery
Populating Statseeker with all your network devices is easily done via Network Discovery. The discovery
process simply checks a user provided list of IP addresses (Hosts File) or IP ranges to find those
devices on your network. If you already have an up to date list of IP addresses then discovering
via a Hosts file is the best option. Use the "IP Address Scan Ranges" option if there is no pre-existing
list of devices available.
When using the "IP Address Scan Ranges" option, only add ranges where devices are expected to be found. For
example if your network has has hosts on 192.168.1.0/24 through to 192.168.10.0/24, then entering
192.168.0.0/16 to discover this area would result in the discover process taking much longer than
necessary.
To configure the Network Discovery go to Administration Tool -> Network Discovery and add
the following information:
- SNMP Community Strings
Administration Tool -> Network Discovery -> SNMP Communities
Each discovery method first requires SNMP community strings to be configured.
Network devices typically have a read-only community, and a read-write community.
Statseeker should be configured to use the read-only SNMP community string as it does not
perform device configuration.
Enter new community strings in the text window, one string per line and click Save.
To minimize discovery time, the list of community strings should be kept as short as possible.
When discovery is running, it will try each configured community string on each device, therefore
each configured community string significantly increases the discovery time. Using a single
community string for all network devices assists in an efficient discovery.
For example:
public
mycommunityname
NOTE: Do not use the following types of characters in community names as they may be stripped
by the Statseeker SNMP applications:
- Spaces
- Single quote
- Double quote
- Back quote
- Forward slash
- Backslash
- Hash
- Star
- Ampersand
- Configuring via a IP Address Scan Ranges
Administration Tool -> Network Discovery -> IP Address Scan Ranges
Using plain text in the format below, add the IP Address ranges that will be used by the Ping and
SNMP discover programs to discover your network.
Scan Ranges Format = {include or exclude} {NetworkAddress} / {Netmask}
Example A:
include 10.1.1.0/255.255.255.0 (or)
include 10.1.1.0/24 (or)
include 10.1.1.* (or)
include 10.1.1.[0-255]
Will include all IP addresses from 10.1.1.0 to 10.1.1.255
Example B:
include 10.1.4.128/26 (or) (NOTE: /26 = 26 bit mask)
include 10.1.4.128/255.255.255.192 (or)
include 0.1.4.[128-191]
Will include all IP addresses from 10.1.1.128 through to 10.1.1.191
Example C:
include 10.10.*.[1-10]
Will include all subnets within 10.10.0.0 through to 10.10.255.255,
but only the first 10 addresses of each
Example D:
include 10.1.20.[1,5,10,11,12]
Will include specific IP's within a subnet
Example E:
include 10.2.0.0/16
exclude 10.2.4.0/24
include 10.13.0.0/16
include 10.80.0.0/24
This will result in the following address ranges to be probed by the discovery:
10.2.0.0 to 10.2.3.255
10.2.5.0 to 10.2.255.255
10.13.0.0 to 10.13.255.255
10.80.0.0 to 10.80.0.255
Notes
- Multiple network ranges can be defined
- IP network ranges must fall on a natural subnet boundary
- Blank lines and lines starting with a hash character are ignored
Warnings
- Do not include massively large network ranges (e.g. 0.0.0.0/0)
- Only include ranges relevant to your site's address ranges
- Configuring via a Hosts File
Administration Tool -> Network Discovery -> Hosts File
The Hosts file is simply a list of IP addresses of the devices that you want to to Statseeker.
Each address must have a corresponding hostname that will be used as the device name in Statseeker.
Host File Format = {ip address} {host name}
When the hosts file is saved, you will see one of the following messages:
- Valid Hosts file
Synchronize Hosts
Done
- Invalid Hosts file
If there are any IP addresses without a hostname configured, an error message will be
displayed like:
Synchronize Hosts
Error: no hostname for 10.100.11.234
Invalid hosts file, aborting
- Invalid IP address
If invalid IP addresses are entered, they will be removed from the configuration,
leaving only valid hosts file entries.
- Discover My Network
Administration Tool -> Network Discovery -> Discover My Network
After Network Discovery is configured either using a hosts file or IP ranges,
the network discovery can be started from "Administration Tool -> Network Discovery -> Discover My Network"
Click either "Discover Using Ranges" or "Discover Using Hosts".
- Network Discovery - Log File Help
Administration Tool -> Network Discovery -> Discover My Network
When a Network Discovery is launched, a detailed log is produced that shows what is happening
during the discover process. This log can be very useful for finding out why certain devices
or interfaces have not appeared in Statseeker or what steps have failed during the discover
process.
The following example shows what happens during a typical discovery process.
Important log sections are explained.
Running Ping Discover
All devices responding to a ping are displayed. If a device is not listed then it is most
likely that either the device is turned off or there may be a firewall blocking ping access to
the device. Firewalls could be either local on the switch or server, or they could be
network based.
Running Ping Discover - Sun Feb 1 23:07:02 2009
Found 10.100.21.212
Found 10.100.21.213
Found 10.100.21.214
Found 10.100.21.215
Found 10.100.21.216
Testing devices for SNMP
The SNMP tests involve sending SNMP requests to all the devices that responded to the ping.
Requests are sent using both SNMPv1 and SNMPv2, and also using all configured community names.
Testing devices for SNMP - Sun Feb 1 23:07:25 2009
nim-snmpget Resending(1) to 10.100.21.212 v1 mycommunity1 SNMPv2-MIB.sysDescr.0
nim-snmpget Resending(1) to 10.100.21.212 v2 mycommunity1 SNMPv2-MIB.sysDescr.0
nim-snmpget Resending(1) to 10.100.21.213 v1 mycommunity1 SNMPv2-MIB.sysDescr.0
nim-snmpget Resending(1) to 10.100.21.213 v2 mycommunity1 SNMPv2-MIB.sysDescr.0
nim-snmpget Resending(1) to 10.100.21.214 v1 mycommunity1 SNMPv2-MIB.sysDescr.0
nim-snmpget Resending(1) to 10.100.21.214 v2 mycommunity1 SNMPv2-MIB.sysDescr.0
nim-snmpget Resending(1) to 10.100.21.215 v1 mycommunity1 SNMPv2-MIB.sysDescr.0
nim-snmpget Resending(1) to 10.100.21.215 v2 mycommunity1 SNMPv2-MIB.sysDescr.0
nim-snmpget Resending(1) to 10.100.21.216 v1 mycommunity1 SNMPv2-MIB.sysDescr.0
nim-snmpget Resending(1) to 10.100.21.216 v2 mycommunity1 SNMPv2-MIB.sysDescr.0
This output shows all the devices that are scanned for SNMP response, and the communities
and version that are tested.
Selecting SNMP Version and Community
The SNMP version and the community that will be used to configure the device are shown.
If a device is not shown here, it typically has not had its community configured in Statseeker,
or Statseeker is being blocked from accessing the device via SNMP. In this case you need to
check the for firewalls and access controls that would block SNMP requests from the Statseeker
server.
Selecting SNMP Version and Community
10.100.21.216 2 public
10.100.21.215 2 public
10.100.21.214 2 public
10.100.21.213 2 public
10.100.21.212 2 public
Including/Excluding devices
This section of the log shows which of the "SysDescr Rules" definitions matched
against each device.
Including/Excluding devices
+ (includes Windows) 10.100.21.216 2 public Windows NT
+ (includes Windows) 10.100.21.215 2 public Windows NT
+ (includes Windows) 10.100.21.214 2 public Windows NT
+ (includes Windows) 10.100.21.213 2 public Windows NT
+ (includes ConnectUPS) 10.100.21.212 2 public ConnectUPS Web/SNMP Card V3.10
The above example shows that 4 Windows servers and a UPS are included.
If 3COM devices were configured to be excluded, they would appear as follows:
- (excludes 3COM) 10.100.21.233 2 public 3COM switch
Retrieving SNMP Engine IDs
The SNMP Engine ID is a unique number used to help determine duplicate devices. For example,
routers with many addresses could be discovered several times on different IP addresses.
The Engine ID is used to find these duplicates and remove them.
The Engine ID appears as follows:
10.100.21.11 80:00:00:09:03:00:00:16:af:1b:56:20
Processing Walks
For each device, the MIB sections that have been found to respond, are listed.
For example:
10.100.1.2
maxoid 40
System
Interfaces
Ignoring plip0 3 para
Ignoring lo0 4 softwareLoopback
Host Resources
This is sample output means:
- Server IP 10.100.1.2 was discovered.
- maxoid 40 - up to 40 SNMP objects will be retrieved with each SNMP request to the server.
- System - The system part of the SNMP tree will be used for configuration.
- Interfaces - Interfaces will be configured, however a few are ignored as they don't match
the "Interface Types" configuration.
- Host Resources - the Host Resources MIB will be polled, this provides information such as disk
and memory statistics for a server.
14.4 Advanced Network Discovery Options
- Discover sysDescr Rules
Administration Tool -> Network Discovery - Advanced Options -> SysDescr Rules
Statseeker by default SysDescr Rules to determine devices to be discovered from the discover process.
Use SysDescr Rules to include or exclude additional or specific devices in the discover
process.
All network devices that respond to an SNMP request will have a system description. This is known
as the sysDescr SNMP object. Statseeker looks for a match on this sysDescr object when adding
new devices. If a device is found that does not contain a known sysDescr, then it is not added
to the Statseeker configuration. The default included and excluded devices can be seen in
"Administration Tool -> Network Discovery - Advanced Options -> SysDescr Rules". These defaults cover most popular
network manufacturers, server operating systems, printers and UPS's.
To add a new device type to the include list, you need to find its sysDescr field.
The sysDescr field can be found by using the SNMP Walk facility in the Administration tool.
Administration Tool -> Export Tools -> SNMP Walk
To perform an SNMP walk of a device:
- IP - enter the IP address of the device
- Community - enter the SNMP community name of the device
- OID - enter "sysDescr"
- Click SNMPWalk
Administration Tool -> Network Discovery - Advanced Options -> SysDescr Rules
The resulting sysDescr of this example is "ConnectUPS Web/SNMP Card V3.10".
ConnectUPS is one of the default Includes, so this device would be discovered by Statseeker.
For a device that is not already included, select part of the sysDescr string that represents
the vendor and add an "include" line to the "SysDescr Rules" list.
SysDescr Format = {include/exclude} {sysDescr string}
Adding these include strings simply makes the discovery process examine the device. It won't
automatically find and monitor all possible SNMP variables from the devices. The discover process
will try various predefined SNMP objects and poll any of these that respond.
Excludes are used if there is a device that should not be added to Statseeker. Simply add part of
the sysDescr string as an "exclude" line.
- Interface Types
Administration Tool -> Network Discovery - Advanced Options -> Interface Types
Use this tool to configure the interface types to be added to Statseeker. There are numerous types
of interfaces associated with many different vendors. Many of these interface types have no
monitoring requirements or value so they are not added by default.
Statseeker's default interface list includes those interface types produced by the most established
vendors and interfaces that provide the most useful information.
You can add to this list if there are certain interface types that you wish to monitor, however
only add to this list if your specific interface types are missing. Typically changes are not
required here as most network equipment is included by default.
To determine what text to submit for the interface types, use the "Administration Tool -> Expert Tools -> SNMP Walk"
function described above in the previous section (Discover sysDescr Includes and Excludes).
- IP - enter the IP address of the device
- Community - enter the SNMP community name of the device
- OID - enter "ifType"
- Click SNMPWalk
The output will produce a list of all the interfaces types such as:
IF-MIB.ifType.1 ethernetCsmacd
IF-MIB.ifType.2 adsl
IF-MIB.ifType.3 ethernetCsmacd
IF-MIB.ifType.4 adsl
IF-MIB.ifType.5 ethernetCsmacd
IF-MIB.ifType.6 adsl
IF-MIB.ifType.8 other
IF-MIB.ifType.9 ds1
The output above produced a mix of ethernet and adsl interfaces. Adsl interfaces are not part of the
default Statseeker configuration, so this can be added by entering the string "adsl" to the
interface type list.
- add the new interface type "adsl" to the text list.
- Click "Save".
Examples of interface types:
ethernetCsmacd
fastEther
fibreChannel
frameRelay
14.5 How to Perform a Backup / Restore (FTP)
This utility has been specifically designed to backup and restore Statseeker
data only. Non-Statseeker data, the operating system and Statseeker
applications programs are NOT backed up. If you create additional Unix user
accounts/directories/scripts, or install other software packages, they will
NOT be included in the backup. The utility assumes the server is used for
the Statseeker application only and that no modifications have been
performed. Local changes must be reapplied after a machine restore.
Users can only restore data to the same version of Statseeker. If you need
to rebuild your existing server and are using an older version, install the
old version, restore your data THEN upgrade to the latest version.
Never stop a restore while in progress as the server will be left in an
unknown/incomplete state. A full reinstallation will need to be performed
if a restore does not complete fully.
When using a MS Windows based machine as the FTP server, make sure
you are not trying to use anonymous FTP as the user login as this
will stop the backup cycle feature from operating. Also make sure
that Unix directory listing format is selected, otherwise the utility
will not retrieve a list of backup files and a failure will
occur on both a backup and restore.
On your FTP server:
- Create the username and password.
- Create the directory, making sure that the user has read/write.
permissions to the directory.
On the Statseeker server, use ssadmin to set:
- IP Address of the FTP server.
- Username and Password for logging into the FTP server.
- The full path to the directory where the data is to be stored.
You can determine this by manually ftp'ing to the server, changing
to the relevant directory, and typing 'pwd' to print the entire
directory path.
- Set the Cycle count (i.e. the number of backups to keep on the remote host).
- Use the "Backup Test" option in ssadmin to verify that the Statseeker
server can login, create a file, and then delete the file.
14.6 How to Migrate to a New Server
As part of the migration process you will need a valid key to activate the
new server. To obtain an updated key email keys@statseeker.com and inform us
that you wish to migrate your server. Please make sure to include your
current Server ID number which can be obtained from Administration Tool ->
General -> License Key option. A confirmation email will be sent to confirm
that a new License Key is ready to be downloaded on the new server.
When restoring to a new server please ensure you have the latest Statseeker
version.
A migration to a new server involves the following steps:
- Backup the existing data from the current server. If you do not have a
current backup use the Backup/Restore utility in ssadmin to perform a backup
of the original server.
How to Perform a Back Up / Restore
- Perform a clean installation of the software onto a new machine.
- Download a new License Key via Administration Tool -> General -> License Key.
- Use the Backup/Restore utility in ssadmin to perform a restore to the new
server. To do this use the ssadmin utility on the new server to configure a
backup. This step will show the restore process the location of the backup
files that can be chosen for the restore.
On the new server run ssadmin and select option 6 Backup / Restore and
then option 7 Start Restore.
For any assistance on migrating servers please contact Statseeker technical
support.
15. Remote Network Appliance (RNA)
15.1 What is a Remote Network Appliance ?
The Remote Network Appliance (RNA) is a platform on which "Remote" Statseeker
applications (NetFlow collectors, sFlow collectors and LAN Traffic collectors) are deployed.
The architecture is based around a bootable USB flash drive which turns any PC connected to the
network into a remote platform within minutes. The RNA operates entirely in RAM, therefore
any PC can be turned into an RNA without effecting its local operating system.
Your Statseeker license permits you to install and deploy an Unlimited Number of RNAs and
RNA applications across your network infrastructure.
When RNAs are deployed the Statseeker server:
- Communicates with the RNAs via HTTP and can operate through proxies
- Regularly polls all enabled RNAs
- Synchronizes the system time of each RNA to within one second
- Automatically updates older RNA flash versions
- Downloads all applications and configuration files to each RNA
- Monitors the health and logfiles of each RNA
15.2 RNA Hardware Requirements
Minimum hardware requirements:
- CPU: 1GHz
- RAM: 128M
- NIC: PCI Ethernet card (Maximum of 8).
- USB flash drive
Note: The PC BIOS must be configured to boot from a USB Device as its first boot device.
15.3 How to Deploy an RNA
To deploy an RNA:
- Create a RNA flash drive
- Configure the RNA
- Add the RNA to the Statseeker server configuration
15.4 Creating an RNA Flash Drive
Notes and Tips:
- The "Create RNA USB Flash" utility works by scanning the bus twice and
installing on the new device found on the second scan. Make sure the USB flash drive is
unplugged when starting the utility and only plug it in when prompted
- All data on the USB flash drive will be lost
- Ignore all messages except for the "WARNING: ABOUT TO ERASE ALL DATA ON DEVICE" message
To create an RNA USB Flash Drive run ssadmin :
- Login to the server's console as "root".
- Run ssadmin (Make sure the USB flash drive is NOT inserted).
- Select menu Option 9 in ssadmin to "Create RNA USB Flash".
- When prompted, insert USB flash drive
- After the USB flash drive has been detected press Enter
- Continue to erase data and create flash drive
15.5 Configure an RNA
Note: The PC BIOS must be configured to boot from a USB Device as its first boot device.
- Boot a PC with the RNA flash drive.
- Switch to the configuration menu (Alt-F2).
- Select menu Option 3 Edit Config.
- You will be prompted for:
- IP Address
- Subnet mask
- Default gateway
- Select menu Option 1 Reboot the PC with the RNA flash drive for the new IP configuration
to take effect.
15.6 Add an RNA to the Statseeker Server Configuration
- Go to: Administration Tool -> Traffic Analyzer ->
Remote Network Appliance -> Add
- Fill in the required fields and click the Save button.
- RNA Name (allowable characters are a-z, A-Z, 0-9, and underscore)
- Title (allowable characters are a-z, A-Z, 0-9, underscore and space)
- Details (allowable characters are a-z, A-Z, 0-9, underscore and space)
- IP Address
- Mode (enabled or disabled)
- Via Proxy (enable if deploying an RNA on the outside of a
firewall and all communications are only possible via your HTTP
proxy)
- Rate Limit (Allows you to limit the data transfer rate of
all RNA client/server communications)
- Interface descriptions 0 to 7 (allowable characters are a-z, A-Z, 0-9,
underscore and space). A short description of what network
the interface is connected
- The newly added RNA will appear in the list. It may take a few minutes for the RNA
to change status
15.7 Duplicating the RNA Flash Drive
To duplicate the RNA flash drive:
- Boot a PC with an RNA flash drive.
- Switch to the configuration menu (Alt-F2).
- Select menu Option 5 Copy drive and follow the prompts. This will read the current
drive image into memory, then ask you to insert a target flash drive. The diskcopy program
will write the drive image and then verify it.
- Once a drive has been successfully copied, you will be asked to enter a new IP configuration.
- When you are finished copying flash drives, re-insert the original flash drive into the PC.
16. Traffic Analyzer
16.1 What is the Traffic Analyzer
The Traffic Analyzer is a consolidated tool for reporting on:
- NetFlow (V5, V7, V9)
- sFlow
- LAN Traffic on LAN segments locally connected to the server
- LAN Traffic on LAN segments that are connected to Statseeker Remote Network Appliances
(RNAs)
The Traffic Analyzer reports on data gathered by Statseeker Traffic Collectors.
16.2 What is a Traffic Collector ?
A Traffic Collector is a Statseeker application that resides on the Statseeker server and/or
on a Statseeker Remote Network Appliance (RNA).
Traffic Collectors build conversation matrix tables and dump these tables to a highly compressed
file every five minutes. The tables are then downloaded by the Statseeker server and processed
into a central historical database.
A Traffic Collector is automatically started for every:
- Network interface on the Statseeker server
- Network interface of every deployed Statseeker RNA
- Configured NetFlow and sFlow
Traffic Collectors can decode 802.1q VLAN packets.
No historical data is stored on the remote devices and the server regularly prunes historical
data after a user defined period of time (default of 90 days).
To deploy "Remote" Traffic Collectors, you must first deploy an RNA. The Traffic
Collectors will be automatically downloaded to each RNA at boot time.
16.3 How to Deploy Traffic Collectors
- Determine where to connect Traffic Collectors
- Configure Traffic Collectors
16.4 Where to Connect Traffic Collectors
- Traffic Collectors for NetFlow and sFlow will use the first interface on the RNA and
should be connected to a non-mirrored switch port.
- Traffic Collectors for LAN Traffic should be deployed as follows:
Port mirroring
VLAN mirroring
Note: Many of the newer switches do not allow packets to be transmitted on the
mirrored interface, therefore the RNA will need to be fitted with at least two
network interfaces (i.e. one to monitor and the other to talk to the network).
16.5 How to Configure Traffic Collectors
- To configure a Traffic Collector for NetFlow or sFlow:
- Go to: Administration Tool -> Traffic Analyzer -> Flows
- Select the appropriate RNA
- Specify a Port number
- Specify a Label
- Press "Save"
- Configure the device to send NetFlow or sFlow to the specified port number
on the Traffic Collector
- Traffic Collectors for LAN Traffic do not require configuration
16.6 Getting Started With the Traffic Analyzer
Network Infrastructure Monitor report list -> General -> Traffic Analyzer
The Traffic Analyzer is one consolidated reporting tool used for accessing and
reporting on Netflow, sFlow and LAN Traffic data.
Notes and Tips:
- To run a report from the Report List, select a Time Filter, a Traffic Collector and then
click on the report
- Use the Reset button in the bottom right corner of the Traffic Analyzer console to reset
/ clear the filters
- Use meaningful names for each Traffic Collector e.g. Netflow_New_York_Router_1
- Go to: Administration Tool -> Traffic Analyzer -> General to set:
- Keep History For: Number of days (Default is 90 days)
- Password: For Real Time LAN Traffic Analyzer
- Data is collected and reported in five minute intervals
The Traffic Analyzer consists of four easy to use sections:
Report List
The Report List consists of the following reports:
- Nodes: (IP source, Protocol, Packets, Bytes)
- Node Totals: (IP source, Total packets, Total bytes)
- Node Conversations: (IP source, conversation Count, Packets, Bytes)
- Node Protocol Conversations: (IP Source, Protocol, Conversation Count, Packets, Bytes)
- Conversations: (IP source, Destination, Protocol, Packets, Bytes)
- Conversation Totals: (IP source, Destination, Total packets, Total bytes)
- Protocols: (Protocol totals)
- Totals Only: (Total packets, Total bytes)
Traffic Collector
A list of every deployed Traffic Collector: (NetFlow, sFlow and LAN Traffic)
Time Filter
Go to: Time Filter
General Filters
Go to: General Filters - Traffic Analyzer
16.7 Realtime LAN Traffic Analyzer
The realtime LAN Traffic Analyzer uses a terminal user interface to display realtime
LAN statistics. All commands are listed on the initial help screen.
The LAN Traffic Analyzer supports a limited number of terminal emulators including:
Note: Before using the realtime LAN Traffic Analyzer you must set the password via
Administration Tool -> Traffic Analyzer -> General
To utilize the realtime LAN Traffic Analyzer, telnet to the RNA with the following command:
telnet ipaddress portnumber
ipaddress is the IP address of the RNA or Statseeker Server
portnumber is 30000 for the first interface, 30001 for the second interface ...
The Display Modes consists of the following options:
- IP nodes: (Source IP, Source MAC, Total packets, Total bytes, Packets / sec, Bytes / sec)
- IP conversations: (Source IP, Destination IP, Total packets, Total bytes, Packets / sec, Bytes / sec)
- MAC nodes: (Source MAC, Source IP, Total packets, Total bytes, Packets / sec, Bytes / sec)
- Total protocol counts: (Protocols, Total packets, Total bytes, Packets / sec, Bytes / sec)
- Undefined TCP/UDP ports: (Port number, TCP/UDP, IP Address)
- Alerts: (Duplicate IP Addresses, Possible Routers)
16.8 Undefined Protocols
To define a previously undefined protocol:
- Go to: Administration Tool -> Traffic Analyzer -> Protocols
- Tick the Enabled box
- Select the protocol Type
- Specify a Port number
- Specify an IP Address
- Specify a Label
- Press "Save"
- Press "Apply"
Once a protocol is added it will take a few moments to migrate to the remote device/s.
All subsequent traffic collected will be tagged as the new protocol. Old data will not be renamed.
To establish which port number a device is using, connect to the Traffic Analyzer by telneting to
it on port 30000 or 30001 (second interface).
Use the "?" menu selection to display the undefined TCP/UDP ports in use.
17. Syslog
Statseeker can store and report syslog messages from any monitored device.
Before Statseeker can store and report on syslog messages, the device must be configured to
send syslog messages to the Statseeker server, otherwise we won't collect any messages. Applying
Filters and Actions to the syslog data will make the data more useful.
Users can search for specific Syslog messages or groups of messages using the Text Filter
on the Network Infrastructure Monitor Console.
Refer to Section 19 for more information on sending alerts or running scripts when the
Statseeker server receives syslog messages.
18. SNMP Traps
Statseeker can store and report SNMP trap messages from any monitored device.
Before Statseeker can store and report on SNMP Traps, the device must be configured to send
SNMP trap messages to the Statseeker server. Applying Filters and Actions to the trap data
will make the data more useful.
19. Filters and Actions for NIM Events, SNMP Traps and Syslog Messages
19.1 Concepts
- Filters and Actions within Statseeker perform functions around Events whether they are PING/SNMP Events, syslog Events or SNMP Trap Events.
- Many 'things' can be constituted as being events, ranging from temperature warnings, devices failing, UPS batteries needing replacement
through to interface state changes or a received syslog message.
- Statseeker may see these faults on the network, but in order to make use of this it is necessary to configure the Actions that have to be
taken when events happen. Actions are the tasks that are performed when an event occurs; whilst filters are where users define what it
is that triggers an Action.
- When an event is triggered, it passes through any defined filters that have been configured. If the event matches any of these filters,
it will then be passed to the Action that is configured within that filter.
- Generally speaking the action then performs a task, like sending an email, or a syslog message. As the actions are simple scripts, almost
anything could be performed by an action. Statseeker provides a default Action to discard the event from being recorded.
- To create an event alert users must first create an Action and a Filter.
Notes:
- NIM Events are entries stored in the Statseeker Event Database. Examples of NIM Events include ping_state down,
ping_state up. To view NIM Events go to:
Network Infrastructure Monitor -> Report List -> Events -> Ping / SNMP
- To view SNMP Traps go to: Network Infrastructure Monitor -> Report List -> Events -> SNMP Traps
- To view syslog messages go to: Network Infrastructure Monitor -> Report List -> Events -> Syslog
- You must use ssadmin to configure and test email connectivity for email alerting to work correctly.
19.2 Filters
Filters are used to determine when an associated Action will run.
Each new NIM Event, syslog and SNMP Trap is checked against a set of "user defined"
Filters to determine if it should be saved or discarded. The Filters use "regex"
(regular expressions), allowing for simple or complex filter expressions.
To apply a Filter:
- Administration Tool -> Ping/SNMP Events -> Actions/Filters; click on Filters button
- Administration Tool -> SNMP Traps -> Actions/Filters; click on Filters button
- Administration Tool -> Syslog -> Actions/Filters; click on Filters button
The Filter Configuration section is identical for NIM Events, SNMP Traps, and syslog messages. Examples are available in the
configuration screen to help users make selections. Configuration consists of providing a Filter Name, a Regular Expression
to filter on, selecting the Status, Action, Group, Entity and Time Filters where:
- The actions drop down will contain the default "discard" action plus a list of all user configured actions. The "discard"
action will result in the event NOT being saved to the event database.
- The regex option is a regular expression match of the string that will appear in the event database when the particular event
occurs. It is often best practice to enter a regex that closely matches the criteria you want to filter and therefore alert
on.
For example: A regex of "ping_state" would return both ping_state up and ping_state down A regex of "ping_state down"
would only return events that are ping_state down. To see examples of the expressions that can be used to enter into the
regex field go to the main NIM console, select a time filter and then run the Ping/SNMP Events report. The Events column shows
the event text strings of which any part could be used in these filters. SNMP Trap and syslog regex examples can be taken from
the main NIM Console Syslog and SNMP Trap reports.
Example 1 - PING Filter - Device down state change email alert
Requirement
Configure a filter for when a device changes to ping_state down during business hours.
Procedure
- Enter the Name for this filter: Device State Change Alert Business Hours
- Specify the Regex that will be used for this filter: ping_state down
- Select the Status for this filter. Only filters set to ON will be active.
- Select an Action from the list of available actions previously created. For example:
- Specify the Group or Entity that this filter is to apply to. Since this filter is to apply to the entire network, select:
- Configure options for when the filter will be applied.
- Leave Range and Duration unchanged.
- From Weekday, select: Monday to Friday
- From Time, select: 9:00am to 5:00pm
- Specify the Time Zone for the action to be executed in.
- Select Save Filter.
Example 2 - SNMP Filter - Interface operStatus change alerting
Requirement
Configure a filter for operstatus changes on all interfaces 24 x 7.
Procedure
- Enter the Name for this filter: Interface Email Alerts
- Specify the Regex that will be used for this filter: OperStatus.* down
Note: operStatus polling will need to be turned on for this filter to work.
- Select the Status for this filter. Only filters set to ON will be active.
- Select an Action from the list of available actions previously created. For example:
- Specify the Group or Entity that this filter is to apply to. Since this filter is to apply to the entire network, select:
- Leave the remaining options unchanged. This filter will run 24 x 7, therefore the time filter options do not apply.
- Select Save Filter.
Example 3 - SNMP Trap Filter - Power supply fan failure
Requirement
Configure a filter for when a power supply fan fails during business hours.
Procedure
- Enter the Name for this filter: Power Supply Fan Failure Business Hours
- Specify the Regex that will be used for this filter: POWERSUPPLYFANBAD
- Select the Status for this filter. Only filters set to ON will be active.
- Select an Action from the list of available actions previously created. For example:
- Specify the Group or Entity that this filter is to apply to. Since this filter is to apply to the entire network, select:
- Configure options for when the filter will be applied.
- Leave Range and Duration unchanged.
- From Weekday, select Monday to Friday
- From Time, select 9:00am to 5:00pm
- Specify the Time Zone for the action to be executed in.
- Select Save Filter.
Example 4 - Syslog Filter - Cisco switch in a stack failure
Requirement
Configure a filter for when a Cisco switch in a stack fails during business hours.
Procedure
- Enter the Name for this filter: Cisco Stack Switch Failure Business Hours
- Specify the Regex that will be used for this filter. Some regex examples are provided below:
- Select the Status for this filter. Only filters set to ON will be active.
- Select an Action from the list of available actions previously created. For example:
- Specify the Group or Entity that this filter is to apply to. Since this filter is to apply to the entire network, select:
- Configure options for when the filter will be applied.
- Leave Range and Duration unchanged.
- From Weekday, select Monday to Friday
- From Time, select 9:00am to 5:00pm
- Specify the Time Zone for the action to be executed in.
- Select Save Filter.
19.3 Actions
An Action runs a command that executes a user created script written in shell, C, PERL,
etc... These scripts can be as simple as piping a NIM Event, SNMP Trap or syslog message
to an email or as complex as raising a trouble ticket.
To apply an Action:
- Administration Tool -> PING / SNMP Events -> Actions/Filters
- Administration Tool -> SNMP Traps -> Actions/Filters
- Administration Tool -> Syslog -> Actions/Filters
The Action Configuration section is identical for PING/SNMP Events, SNMP Traps, and syslog messages.
To configure an action simply provide an Action Name, a Command, and select the Status. The Name option is a text string of
your choosing to make this action easily identifiable. The Command is the command line for the action to execute and the
Status can be set to on or off (only actions that are set to on will be executed).
To assist users Statseeker provides a number of command scripts. Go to: Statseeker Provided Email Scripts for more detail.
Example
Requirement
Configure an action to send a single bundled email for all events after 2 minutes to the training@example.com email address.
Procedure
- Enter the Name for this action: Email Alert
- Enter the Command that will execute the script to send the email. We will select the nim-alert-email-generic scripts. The command is:
nim-alert-email-generic -b 2 -e training@example.com
- Select the Status for this action. Only actions set to ON will be active.
- Select Save Action.
19.4 Statseeker Provided Scripts
Statseeker has provided a number of scripts that can be used for actions
within the NIM. It is possible for users to write their own scripts for
use as actions as needed. The scripts provided by Statseeker are:
- nim-alert-email-generic is used to send a generic email
message on any event.
- nim-alert-email-ifOperStatus is for use specifically with
ifOperStatus events. It sends an email message with details of the
device name and interface.
- nim-alert-syslog-generic is used to send a generic message to
a syslog server.
- nim-alert-syslog-ifOperStatus is for use specifically with
ifOperStatus events. It sends a message to a syslog server with
details of the device name and interface.
There are a number of parameters that must be passed to each Statseeker
alert script. The available parameters are detailed below.
nim-alert-email parameters
nim-alert-email-generic [ -b {minutes} ] { -e {email} | -u {user} | -g {group} }
nim-alert-email-ifOperStatus [ -b {minutes} ] { -e {email} | -u {user} | -g {group} }
At least one of -e, -u or -g must be specified. -b is optional.
| Parameter |
Comment |
| -b |
An integer describing the number of minutes to bundle the alerts
before sending the email.
|
| -e |
Send the alert to the specified email address.
|
| -g |
Send the alert to any users associated to the specified Statseeker
group.
|
| -u |
Send the alert to the email address associated with the specified
Statseeker user.
|
nim-alert-syslog parameters
nim-alert-syslog-generic -h {host}
nim-alert-syslog-ifOperStatus -h {host}
-h must be specified.
| Parameter |
Comment |
| -h |
Send syslog messages to the specified syslog host.
|
20. Thresholds
20.1 General
- The Statseeker NIM allows users to configure Threshold monitoring on a number of important data types that are collected.
- By using the Filter/Action feature in combination with the Threshold configuration options it is possible to proactively
alert users on threshold exceed events via email.
- Thresholds are configured from the Administration tool -> Thresholds section
- Thresholds are available for:
- Tx Utilization
- Rx Utilization
- Tx Errors (as a percentage of Total Tx Packets)
- Rx Errors (as a percentage of Total Rx Packets)
- Tx Discards (as a percentage of Total Tx Packets)
- Rx Discards (as a percentage of Total Rx Packets)
- Memory
- CPU
- File System
- PING Delay times (in milliseconds)
- Thresholds should only be applied to critical devices/interfaces where the baselined data has been reviewed to determine the
most appropriate parameters for the threshold configuration. Applying inappropriate thresholds across large numbers of
devices/interfaces could result in large numbers of threshold events being created and possibly an enormous number of alerts.
20.2 Steps to Configure Threshold alerting:
- First create an Action to send the alert as desired. Statseeker provides several scripts to assist with this as
needed (see Statseeker Provided Scripts). This process is the same as that for Syslog, SNMP Trap and PING/SNMP Actions
- Secondly create a Filter specifying when the Action will be triggered and relating it to the Threshold. Configuring
the Threshold Filter requires the same steps be followed as for the SNMP Trap, syslog and PING/SNMP Filters. However
in the 'Regex' text field enter a regular expression that matches the threshold that will be generated.
- Lastly create a Threshold that is the subject of the alert. In some cases it may be beneficial to create the Threshold
using the Threshold Config option first as the Filter will be required to reference the threshold name.
20.3 Threshold Configuration
- Go to Administration Tool -> Thresholds -> Threshold Config.
- Select Add
- Enter a unique threshold name in the 'Name' field.
- Select the Threshold type that is to be configured. Note that subsequent options will change as a result of this selection.
- Choose whether to initiate the threshold if it is above or below the Threshold value.
- Enter the threshold value noting that:
- The configuration items will vary depending on Threshold type selected.
- The interval is in minutes and must be a multiple of the polling interval. (Errors and Discards are polled every 5min,
whilst the remaining data types are polled every 1 minute).
- Select the time filters for when the thresholds are to be checked. Entering no values will mean 24 x 7 threshold checking
- Select the entities/groups to be monitored noting that:
- Only groups OR entities can be used as filters, not both together.
- Entities will be either 'ports' or 'devices' depending on threshold type.
- Press 'save'.
20.4 Threshold Alerting Example 1.
Email Alerting on Primary WAN Link Utilization % Threshold Exceeds.
A. Configure an action to send a single bundled email for all events after 2 minutes. Send this email to the
training@example.com email address.
B. Configure a filter for when a "Primary WAN Link" threshold event has occurred during office hours and send an email alert.
C. Create a high utilization threshold event on a primary WAN link during office hours.
A single event will be added to your threshold event database every time the above threshold condition occurs.
20.5. Threshold Alerting Example 2.
Email alerting when a server file system reaches 75% capacity.
A. Configure an action to send a single bundled email for all events after 2 minutes to the training@example.com email address.
B. Configure a filter for when a file system has reached 75% capacity on all servers 24x7.
- Go To Administration Tool -> Thresholds -> Actions/Filters -> Click on Filters -> Add
- Enter the Name for this filter.
File System 75% Utilized
- Specify the Regex that will be used for this filter.
File System
(Please note: This regex matches part of or all of the name of the threshold configured in the Threshold Config
section of the Administration Tool. See Below)
- Select the Status for this filter. Only filters set to ON will be active.
- Select an Action from the list of available actions previously created. For example:
Email Alert
- Specify the Group or Entity that this filter is to apply to. Since this filter is to apply to the entire network, select:
- Leave the remaining options unchanged. This filter will run 24 x 7, therefore the time filter options do not apply.
- Select Save Filter.
C. Create a threshold event for when a server file system reaches 75% capacity.
A single event will be added to your threshold event database every time the above threshold condition occurs.
21. Frequently Asked Questions
21.1 How to delete / rename a device
At the Network Infrastructure Monitor Advanced Console go to the Reports List and select the
Device Details report in the General Section. Click on the Device Name (far left column) that
you wish to delete. A pop up window will allow you to rename or delete the device.
21.2 How to change interface details
At the Network Infrastructure Monitor Advanced Console go to the Reports List and select
the Details report in the Interfaces section or for Frame Relay select the Details Report
in the Frame Relay section and run the report.
The following options can be changed by clicking on the link and opening the NIM Config Editor:
- Title – the interface title you wish to see appear in reports
- Tx (speed) – the Tx speed for calculations and reporting
- Rx (speed) – the Rx speed for calculations and reporting
- Oper (poll) – polling oper status on interfaces
- Poll (on/off) – sets polling on or off (off will stop Statseeker polling interface)
NOTE:
The "lock" flag will lock this field so that future SNMP walks do not change these fields.
The "nolock" will enable the change only until the next SNMP walk updates this field again.
21.3 How to change device details
At the Network Infrastructure Monitor Advanced Console go to the Reports List and select
the Device Details report in the General section
The following options can be changed by clicking on the link and opening the NIM Config Editor:
- Device – (Change name)
- IP Address - (Change name, lock / nolock)
- Ping - (poll on / off)
- SNMP (poll on / off)
- Community (Change name, lock / nolock)
NOTE:
The "lock" flag will lock this field so that future SNMP walks do not change these fields.
The "nolock" will enable the change only until the next SNMP walk updates this field again.
21.4 Can Version 2.8.x be upgraded to Version 3 ?
Version 3 is a complete replacement for the current product and is NOT an incremental upgrade
to Version 2.8.x. The entire code base has been re-written from the ground up to accommodate
expanding network sizes, new technologies and many new data types.
You will need to install Version 3 onto another piece of hardware and we strongly recommend
that you run both systems in parallel until you are ready to turn off your Version 2.8.x
server.
Every customer will get a new set of unlimited license keys for Version 3.
21.5 Can Version 2.8.x data be migrated to Version 3 ?
The simple answer here is No.
Version 3 collects a far greater number of data types, from many different technologies,
at far greater granularity than Version 2.8.x. This unfortunately means Version 2.8.x data
becomes incompatible with Version 3.
You will need to install Version 3 onto another piece of hardware and we strongly recommend
that you run both systems in parallel until you are ready to turn off your Version 2.8.x
server. If you wish to continue viewing your historical 2.8.x data, and are ready to rely on
Version 3 for your day to day monitoring requirements, Statseeker will provide you with a script
that will turn off the poller on your Version 2.8.x server. You can leave your Version 2.8.x
server running for as long as you wish.
For script instructions: Please log a Technical Support call via the Statseeker website.
21.6 Can Version 3 run on VMware ?
No.
21.7 What are Server ID, Hardware ID and Customer Numbers ?
A Server ID Number is required to activate every Statseeker server. The Server ID Number is
generated by Statseeker and can be obtained by emailing keys@statseeker.com. Once this number
is applied to the Server via the Administration Tool -> General -> License Key
section, the system will generate a Hardware ID Number based on the hardware footprint of the
server. The Hardware ID Number and Server ID number are then used to create a License Key.
The License Key is downloaded directly from Statseeker's backend systems to the server. If
the server does not have a connection to the Internet then email a License Key request
containing the Server and Hardware ID Numbers to keys@statseeker.com.
A License Key will be manually produced and sent back via email.
Your Customer Number is a unique number used to identify your organization. You will need this
number to log Technical Support Requests via www.statseeker.com/Support.html. Your Customer
Number can be found at the bottom of the main Network Infrastructure Monitor console.
21.8 What are appropriate alphanumeric characters in my Host File?
In version 3, the host names are compliant with RFC 952.
RFC 952 states
A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters
drawn from the alphabet(A-Z), digits (0-9), minus sign (-), and period (.) Note that periods
are only allowed when they serve to delimit components of "domain style names".
21.9 How does the NIM discovery differentiate from a server and a PC?
The short answer is "it doesn't". There is no "server" list.
Statseeker will add SNMP objects to be polled into the configuration
for any devices that respond with HOST-RESOURCES-MIB objects when they are discovered.
For example, if the device responds with details about the processor load SNMP object
hrProcessorLoad during the discover, it will be added to the configuration, and it will be polled.
When the CPU Load report is run, then it will report on any SNMP object in the configuration for hrProcessorLoad.
Any device that responded with hrProcessorLoad during the discover would appear in the list of the CPU Load report.
Any device that responded with hrStorageUsed, hrStorageAllocationUnits, hrStorageDescr; hrStorageSize SNMP object
and hrStorageType of hrStorageFixedDisk during the discover would appear in the File System Usage Report.
Any device that responded with hrStorageUsed, hrStorageAllocationUnits, hrStorageDescr; hrStorageSize
SNMP object and hrStorageType of hrStorageVirtualMemory during the discover would appear in the Memory
Usage (Virtual) Report.
Any device that responded with hrStorageUsed, hrStorageAllocationUnits, hrStorageDescr; hrStorageSize
SNMP object and hrStorageType of hrStorageRam during the discover would appear in the Memory Usage
(Physical) Report.
So in this instance PCs and Servers may be responding with HOST-RESOURCES-MIB objects and therefore
are appearing in the reports under the Server sections. Any device with HOST-RESOURCES-MIB implemented
would be considered a server including UNIX servers, FreeBSD Servers, Windows Servers and Windows PCs.
21.10 Can I exclude servers and PCs from my configuration?
During the discovery, all of the IP Addresses in the Discover Range (for Discovery Using Ranges) or in the Host File
(for Discovery Using Hosts) are pinged.
Any device that responds to the ping is a candidate to be added for SNMP polling.
The candidates are then polled for the sysDescr object. If the response contains any string in the Sysdescr Rules section
of the Administration Tool (Administration Tool -> Network Discovery -> SysDescr Rules) with an include prefix/rule
and does not include any string with an exclude prefix/rule, they are then walked and added to the configuration.
So to excluded a device from being added, add any part of the sysDescr for the device to the
SysDescr Rules with an exclude prefix.
To determine the sysDescr for a particular device, you can use the SNMP Walk in the
Administration Tool to query for sysDescr.
A Microsoft PC would return a string for sysDescr similar to
x86 Family 15 Model 3 Stepping 4 AT/AT COMPATIBLE - Software:
Windows 2000 Version 5.0 (Build 2195 Multiprocessor Free)
So you could add any part of this to the SysDescr Rules to exclude the device.
For example, if you want to exclude all windows devices, you could add
exclude Windows
to the SysDescr Rules section.
21.11 What characters can I use for my User passwords?
Special characters are not supported (@, $, !, # etc). Please use alphanumeric characters only.
21.12 I've forgotten my root password, how do I retrieve it?
Statseeker support can provide a procedure to retrieve your root password.
Please log a call to our Help Desk (http://www.statseeker.com/Support)
21.13 How does Statseeker determine a device is "Down"?
Statseeker pings devices every 15 seconds. The outage time is 45 seconds (i.e. three missed pings in a row).
The v3 SNMP poller does one timeout/retry for each request, but records every instance of a lost response.
Typically email alerts would be configured to be sent as soon as an outage occurs.
However, Users can manipulate the amount of time between an outage and an alert by
implementing the bundling option in their email alert setup. Please log a call
with Statseeker Technical Support to find out more information on this option.
http://www.statseeker.com/Support.
21.14 How do I Add a ping only device?
To add a new ping only device into Version 3.x follow the procedure below:
- Add entries for the ping only devices into the hosts file section of the Administration Tool and save the hosts file.
- From the Discover My Network section of the Administration Tool run a Discovery. The Network Discovery will add entries to
the NIM configuration for every host in the hosts file.
21.15 Should I connect my Statseeker Server to a UPS ?
Yes. When the Statseeker Server experiences a power failure the timeseries database can become corrupt.
If so users will see messages similar to the following:
2008-12-21 21:32:58 35635 base-timeseries rle.c 472 ERROR: Invalid magic number 00
2008-12-21 21:32:58 35635 base-timeseries timeseries.c 2214 INFO:
Corrupt block id 2352 block 473
2008-12-21 21:32:58 35635 base-timeseries timeseries.c 4460 ERROR: Loading block for id 2352:
internal uncompression error
To reduce the probability of this occurring please ensure your server is connected to UPS. If you experience
this problem you will need to rebuild your server from the last available back-up.
21.16 Why does Statseeker use different port numbers for each NetFlow ?
The netflow collector is a modification to the 2.x ltm-client program where it reads netflow packets from
a router instead of packets directly off the LAN. We didn't anticipate having to integrate with other
vendor's netflow forwarders which can bundle multiple sets of collected flows into a single stream
(i.e. single destination UDP port). Each ltm-client is only expecting the flow records for a single router
netflow exporter.
We will be addressing this issue in future releases. At the current time users need to use a different
destination port and set up a different flow in Statseeker for each export.
21.17 What are allowable characters in Device or Interface names ?
Many characters are not very friendly to shell/perl/etc. For example, backquotes, brackets, braces, dollar,
hash, commas (for csv files), etc. Escaping all possible nasty characters would make the entire code base
much larger and more complex. Therefore, the following ifName characters are allowed, and the rest
are stripped:
a-z
A-Z
0-9
space
dot
underscore
forward slash
colon
21.18 How do I add new MIBS to Statseeker ?
Out of the box, Statseeker Version 3 monitors a vast range of devices. However, Version 3 also supports
the ability to add new MIBS to enable non-standard and different equipment to be monitored. Basically, any device
that is SNMP readable, and has a useable MIB can be monitored. Unfortunately many MIBS do not comply with the
accepted RFC on MIB development. Therefore, if a user requires a new MIB to be added they need to email the MIB,
an SNMP walk of the device and an overview of the type of information needed from the device to
csm@statseeker.com. If the MIB is useable the device will be added to a future Statseeker release.
21.19 How is the MAC/IP Switch Port Report generated ?
The MAC/IP/Switch Port table provides a match of the MAC Address to IP Address to Switch Port for easy searching.
The table is created by:
- Collecting the ARP table from all monitored devices. In practice routers will have the biggest ARP table, while
switches will only contain entries for devices talking to its management interface. The device's ARP table will
only contain entries for locally attached addresses.
The objects collected are:
IP-MIB.ipNetToMediaPhysAddress
IP-MIB.ipNetToMediaNetAddress
- Collect the bridging table for each switch. For switch ports with a single device connected,
the bridging table for that port will only contain a single entry. Switch ports which connect to other switches
will contain a table of all the downstream MACs.
The SNMP objects collected are:
BRIDGE-MIB.dot1dTpFdbAddress
BRIDGE-MIB.dot1dTpFdbPort
- Build a combined ARP table from the data collected in 1.
- Build a MAC / switch port table from the data collected in 2.
Switch ports which contain more than one MAC are discarded.
- Combine both tables together into a single MAC / IP / Switch Port table.
Note: The table will grow over time. The collection is done once an hour, but the default timeout on the ARP
and Bridging tables will probably be 5 minutes. Therefore, if a device has not sent a packet within 5 minutes
of the data collection, then it will have already aged from the router/switch tables.
The port number is retrieved from the BRIDGE-MIB.dot1dTpFdbPort
For further details about this object, please click on the following link:
Go to Cisco Website
21.20 Why can't I see the port number in MAC/IP Switch Port Report ?
The most likely reason is that the server was unable to retrieve the bridging table including
BRIDGE-MIB.dot1dTpFdbAddress and BRIDGE-MIB.dot1dTpFdbPort from this device.
21.21 Can I customise the format of email alerts ?
Statseeker has provided a number of scripts to enable basic email alerting. Users can use these scripts as a
template to customise scripts for email alerts as required. The scripts are located in the
/usr/local/statseeker/ss/bin directory, and are written in PERL.
Do not modify the scripts in this directory. Scripts should be copied and stored in the
/home/statseeker/bin directory.
The NIM event, syslog and SNMP traps will pass an event message to the scripts specified in the action.
The event message format is 5 comma delimited fields:
time,event_id,ega_id,ega_name,event_text
For further details, please refer the nim-alert scripts in the /usr/local/statseeker/ss/bin directory.
21.22 I've added a Device to a Group but only want to see specific interfaces.
When a device is added to a group, all of the interfaces that belong to the device automatically inherit that group's
membership.
By selecting the Interface to Group section on the Administration Tool, and then selecting a device that is a member
of the group, the interfaces will appear greyed out in the include section. This is because all the interfaces have
inherited the group membership and an interface on the device in a group can not be removed from the group.
Similarly, in the Group to Interface section on the Administration Tool, when selecting an interface on a device
that is a member of the group, the group will appear in the Include section. It will be greyed out and can not be
removed from the interface. This inheritance is expected behaviour and is not a bug.
If users do not want all of the interfaces on a device in a group, the device must firstly be removed from the
group.
To include individual interfaces on devices that do not belong to a group, use the Interface to Group option
in the Administration Tool and include them to a group. Users can also elect to add ALL interfaces to
a group. Any changes are automatically applied.
21.23 What is IP SLA ?
Cisco IOS IP Service Level Agreements (SLAs) enable customers to assure new business-critical
IP applications, as well as IP services that utilize data, voice, and video, in an IP network.
Cisco has augmented traditional service level monitoring and advanced the IP infrastructure
to become IP application-aware by measuring both end-to-end and at the IP layer.
With Cisco IOS IP SLAs, users can verify service guarantees, increase network reliability by
validating network performance, proactively identify network issues, and increase Return on
Investment (ROI) by easing the deployment of new IP services. Cisco IOS IP SLAs use active
monitoring to generate traffic in a continuous, reliable, and predictable manner, thus enabling
the measurement of network performance and health.
Basically, IP SLA is a method of utilizing switches and routers to perform network tests in order
to gain a better picture of how a network is performing. Many Cisco devices can perform a
variety of tests. The results of these tests are available via SNMP, which can then be reported
and graphed by Statseeker.
On first impressions, IP SLA appears a little complex, however it is actually quite simple to generate
some very useful reports when the tests are configured. When these tests are configured on a switch
or router, they are automatically graphed by Statseeker.
The report below shows an example of IP SLA results:
From each entry in the IP SLA report, you can drill down to obtain more details.
Clicking the probe "tag" graphs the results for that test. Clicking the device name,
will launches the Cisco IP SLA Reporting Tool where you can do detailed reporting in many different
graph formats and time periods.
The output below shows an example graph produced by clicking on a tag name:
The tests that can be performed via IP SLA are:
dhcp DHCP Operation
dns DNS Query Operation
ftp FTP Operation
http HTTP Operation
icmp-echo ICMP Echo Operation
path-echo Path Discovered ICMP Echo Operation
path-jitter Path Discovered ICMP Jitter Operation
tcp-connect TCP Connect Operation
udp-echo UDP Echo Operation
udp-jitter UDP Jitter Operation
For a detailed description of IP SLA and its configuration, please refer to the Cisco documentation at
Cisco IOS IP Service Level Agreements User Guide
Basic Examples:
Here are some examples of typical IP SLA configuration. Configuration syntax may vary slightly on different
Cisco devices, please refer to specific manuals for your device.
Each IP SLA test configuration is in two parts, the probe definition, and the schedule.
The probe definition sets the type of test, the test destination, the time parameters, and a name.
The schedule defines how frequently the test will run and when to start it.
- HTTP connection to a web server
ip sla 1
http get http://www.Statseeker.com
timeout 1000
threshold 1000
owner Server Team
tag HTTP www.Statseeker.com
ip sla schedule 1 life forever start-time now
In the above example, a web request is sent to http://www.Statseeker.com with a timeout of 1 second (1000 milliseconds).
The default frequency of 60 seconds is used.
- TCP connection to test SSH response
ip sla 2
tcp-connect 192.168.1.1 22 source-ip 192.168.10.10 control disable
timeout 1000
threshold 1000
owner SSH
tag SSH server1
frequency 20
ip sla schedule 2 life forever start-time now
In the above example, a TCP connection is made to a server to test its SSH (port 22) operation.
The setting "control disable" is needed for a standard server TCP connection. A dedicated Cisco responder
can provide some extra information via return control data which is not required in this case.
- DNS Lookup
ip sla 4
dns www.google.com name-server 192.168.1.2
timeout 1000
threshold 1000
tag DNS google
frequency 600
ip sla schedule 4 life forever start-time now
The above example performs a DNS lookup every 10 minutes using the name server 192.168.1.2.
- Ping Response
ip sla 5
icmp-echo 10.1.2.3
verify-data
owner Networks
tag ICMP site2-site3
ip sla schedule 1 life forever start-time now
The above example performs a ping test to 10.1.2.3. Although Statseeker can perform ping tests to
any device, an IP SLA ping test could be used to test connectivity along specific parts of your network
by configuring the tests on specific devices. For example, the Statseeker server could be located in a data
centre in Chicago, however you may wish to know the response time between sites London and Melbourne. An
IP SLA probe could be configured to perform a ping from London to Melbourne, and Statseeker can then report
on the results of these tests by retrieving the results from the switch in London.
- VOIP Jitter
ip sla monitor 3
type jitter dest-ipaddr 10.4.3.2 dest-port 11111 codec g729a
threshold 120
tag g729a
frequency 300
ip sla monitor schedule 3 life forever start-time now
The test above performs a jitter test for VOIP. When configuring VOIP tests you must configure the correct codec to
correctly simulate the type of VOIP traffic on your network, as not all VOIP installations use the same codec.
Once an IP SLA probe is configured on a switch or router, it will be picked up by Statseeker the next time the
device is walked, or immediately if you discover the device.
- IP SLA Traps
Any IP SLA probes can be set to send a trap if the item they are polling fails. This trap can then be filtered by
Statseeker and used to send an email alert.
ip sla reaction-configuration 2 react timeout threshold-type immediate action-type trapOnly
For example, if the reaction was triggered by failing the SSH request above, it would generate a trap such as:
2009/02/23 22:24:53 Atlanta-SW1
SNMPv2-MIB.sysUpTime.0 82489720 9d13h08m17s
SNMPv2-MIB.snmpTrapOID.0
CISCO-RTTMON-MIB.rttMonTimeoutNotification
CISCO-RTTMON-MIB.rttMonCtrlAdminTag.2 NULL
CISCO-RTTMON-MIB.rttMonHistoryCollectionAddress.2 73:ed:02:01
CISCO-RTTMON-MIB.rttMonCtrlOperTimeoutOccurred.2 true
This trap is for a failed TCP Connect poll.
By using the SNMP Traps Actions and Filters, this trap can then send an email alert. See the "Events" section of this
document for details on configuring Actions and Filters.
21.24 Detailed Upgrade Instructions
Prerequisites: You must be running Statseeker version 3.XXX before upgrading.
-
Step 1. Download the appropriate CD image file.
Download the lastest update version from : Release Notes
-
Step 2. Copy the file to your Statseeker server.
Many customers will copy the file using FTP, although some customers may prefer to use SSH.
FTP Instructions for Windows:
Once the file is downloaded, copy or move the file to the c:\ directory on your PC.
Open a command prompt:
Start -> Run
Enter "cmd" into the Open box
Click OK
A black "Command prompt" window will open.
Enter the command: cd \
Now FTP the file to the Statseeker server.
ftp ip_address (ip_address is the IP address of your Statseeker server)
Enter the username: statseeker
Enter your statseeker password: (This password will be the same as your "admin" password when using Statseeker)
Change to the "cdrom" directory by entering the command: cd cdrom
Now enter the command: bin
This will ensure the file is copied in binary mode.
Now use the "put" command to place the upgrade image into the Statseeker server.
put statseeker_3.3.3_upgrade_64bit.iso
Exit FTP by entering the quit command: quit
-
Step 3. Login to your Statseeker server and perform the upgrade.
Telnet to the Statseeker server by either using a telnet application, or telnet from the command prompt used previously.
Enter the command: telnet ip_address (ip_address is the IP address of your Statseeker server)
You will then see a login prompt:
At the login prompt, enter the username: statseeker
Enter your password.
Enter the command: ssadmin
Enter the Statseeker admin password.
You should now see the following menu:
Choose option 5. Software Upgrade.
Note: if you are upgrading from a version before 3.3.0 the
upgrade process will now shutdown the Statseeker software, perform the
upgrade and then reboot the server with the new version.
If you are upgrading from 3.3.X or above, a reboot is not performed
You can confirm that the server is running the new version by checking the Statseeker Version Number
in the following location:
22. System Security
22.1 Server
Open Ports
- TCP port 23: telnet
- TCP port 20/21: ftp
- TCP port 22: ssh
- TCP port 80: http
- TCP port 443: https
- TCP port 30000-30007: Realtime LAN Analyzer
- UDP port 123: NTP
- UDP port 162: snmptrap
- UDP port 514: syslog
- Ports that are configured for NetFlow/sFlow collectors
Notes on Open Ports
- TCP port 443: https and UDP port 123: NTP are not opened by default
- UDP port 123: NTP will be opened if NTP is configured in the Date, Time and NTP menu of ssadmin
- TCP port 23: telnet and TCP port 20/21: ftp can be disabled in the Network Configuration menu of ssadmin
- TCP port 80: http and TCP port 443: https can be enabled or disabled in the Web Server menu of ssadmin
- Ports for NetFlow/sFlow can be configured in the Administration Tool
Protocols Used
- ICMP
- UDP SNMP
- UDP snmptrap
- TCP http
Server Processes
- Sendmail is configured to only process local mail. It will NOT accept remote SMTP connections,
runs as a non-privileged user, and will make outgoing connections to the configured SMTP gateway
- You can not login as root via a network connection. You must login as a normal user and
then 'su' to root
- The Realtime LAN Analyzer telnet daemon runs on tcp ports 30000-30007. All Realtime LAN Analyzer
telnet data is sent across the network in plain text
22.2 Remote Network Appliance
The RNA is a custom designed platform based on FreeBSD.
- There is no command line shell (e.g. /bin/sh)
- The RNA will only execute Statseeker certified programs
- The client/server protocol runs over HTTP. The data is not encrypted, however it is obscure
and would require a lot of effort to reverse engineer it
- The Realtime LAN Analyzer telnet daemon runs on tcp ports 30000-30007. All Realtime LAN Analyzer
telnet data is sent across the network in plain text
Open Ports
- TCP port 80: http
- TCP port 30000-30007: LAN Analyzer telnet
- Ports that are configured for NetFlow/sFlow collectors
Notes on Open Ports
- Ports for NetFlow/sFlow can be configured in the Administration Tool
23. Development Tools
***************************************************************
WARNING!
***************************************************************
Please ensure that you have a current backup before
you run any commands or scripts that modify Statseeker.
Any commands run from the command line or scripts
implemented by the user are done so entirely at
the users risk.
Statseeker is not liable or responsible for any damages
or consequences caused by these actions.
***************************************************************
Tools for building reports
Most Statseeker reports are generated with short perl scripts (wrappers around various
command line tools).
These tools perform functions such as:
- Decode CGI/Cookie queries
- Decode TFC queries
- Interact with the EGA
- Interact with the time series database
- Interact with the event database
- Interact with the message databases
- Interact with the Traffic Analyzer database (i.e. NetFlow, sFlow)
- Interact with the NIM configuration
- Build graphs (line, strip, filled, bar, stacked bar, pie, calendar, etc...)
- Build HTML table reports
- Perform SNMP get/walk/poll requests
base-cgi
base-cgi decodes Statseeker HTTP GET and POST requests. The output is presented
as a key/value pair.
base-tfc
base-tfc [-ir] [-z tz] query
-i: Display filter info
-r: Display results in raw format
tz: Time zone string, e.g. 'Australia/Sydney'
query: The time filter query
base-ega
base-ega [command ...]
EGA Types: device port report time user
access { add|set } group { <name|id> } { {ega} { <name|id> } }
access clear { {ega} { <name|id> } } group { <name|id> }
add { group|{ega} } { <name> }
check { group|{ega} } { <name|id> } { group|{ega} } { <name|id> }
delete { group|{ega} } { <name|id> }
get group [ {ega} { <name|id> } ] ...
get {ega} [ { group|{ega}|parent } { <name|id> } ] ...
get {ega} info { <name|id> } [ { <name|id> } ... ]
rename { group|{ega} } { <name|id> } { <name> }
flush
base-event
base-event dbname [...]
add action { -a <action name> } { -c <action command> } [ -t <tfc> -z <timezone> ]
add filter [ -e <entity id|name> | -g <group id|name> ] [ -f <filter name> ]
{ -r <filter regex> } [ -t <tfc> -z <timezone> ] [ -a <action id|name> ]
add event { { -e <entity id|name> & -m <event text> } [ -T <time> ]
add note { -i <event id> } { -T <time> } { -m <note text> }
modify event { -i <event id> } { [ -x <event flag> ] [ -a <action id|name> ] }
modify record { -i <event id> } { -t <time> } { -x <record flag> }
modify action { -a <action id|name> } { [ -x on|off ] [ -t <tfc> -z <timezone> ]
[ -c <action command> ] }
modify filter [ -e <entity id|name> | -g <group id|name> ]
{ -f <filter id|name> } { [ -x on|off ] [ -t <tfc> -z <timezone> ]
[ -r <filter regex> ] [ -a <action id|name> ] }
delete action { -a <action id|name> }
delete filter { -f <filter id|name> }
delete event { -i <event id> }
delete record { -i <event id> } { -T <time> }
delete note { -i <event id> } { -T <time> }
get action [ -a <action id|name> ]
get filter { -f <filter id|name> }
get event [ -e <entity id|name> [ -m <event text> ] |
-g <group id|name> | -i <event id> ] [ -r <regex> ]
get record [ -e <entity id|name> [ -m <event text> ] |
-g <group id|name> | -i <event id> ] [ -r <regex> ]
[ -T <time> | -t <tfc> -z <timezone> ]
[ -s <sort by +|- time|id|entity|group|text> ]
get note { -i <event id> } { -T <time> }
expire records { -T <time> }
base-message
base-message dbname [...]
expire message time
add message { -e <entity id|name> } { -m <message text> }
add action { -a <action name> } { -c <command> }
add filter { -f <filter name> } { -r <regex> }
modify filter { -f <filter id|name> } { -r <regex> }
modify action { -a <action id|name> } { -c <command> }
get filter [ -f <filter id|name> ]
get action [ -a <action id|name> ]
get message { -e <entity id|name> -e ... | -g <group id|name> -g ... }
[ -s <sort by +|- time|id|entity|group|text> ]
{ -t <time filter> } [ -z <timezone> ]
[ -r <regex> ]
base-timeseries
base-timeseries [-w] <dbname> ...
new { <type> <width> <interval> [ <cachesize> <cachemin> <zblocksize> ]
save { <id> <time|seqnum> <value> }
delete { <id> }
timezone <zonename>
stat clear [ all|interval|scale|results ]
stat set { range|interval|seqnum|varcnt|scale <values> }
stat set range "<tfc>"
stat set interval <value>
stat set seqnum <value>
stat set varcnt <value>
stat set scale <time> <multiplier> <divisor>
stat add <id ... >
stat get [ min|max|avg|tot|cnt|data|stats ... ]
output format:
min,<seqnum>,<interval>,<num_results>,<min ...>
max,<seqnum>,<interval>,<num_results>,<max ...>
avg,<seqnum>,<interval>,<num_results>,<avg ...>
tot,<seqnum>,<interval>,<num_results>,<tot ...>
cnt,<seqnum>,<interval>,<num_results>,<cnt ...>
data,<id>,<time>,<year>,<month>,<mday>,<hour>,<minute>,<second>,<interval>,
<nonzero>,<min>,<max>,<avg>,<tot>,<num_results>,<data ...>
stats,<id>,<cnt>,<nonzero>,<min>,<max>,<avg>,<tot>
validate
ltm-db
ltm-db { -t <time filter> } [ -a <address filter> ] [ -p <protocol filter> ]
[ -i <interval> ] [ -s <sort filter> ] [ -l <limit to N records> ]
[ -z <timezone> ] <probe name> <interface number> <report type>
where:
-t {TFC query}
-a <inc|exc> <src|dst|both|either> [ <and|or> <inc|exc> <src|dst|both|either> ]
-p <protocol.subprotocol> (e.g. TCP.telnet or TCP.*)
-i <Nh|Nm|Nh>
-s <src|dst|proto|packets|bytes>
-l <limit> (e.g. limit to top N)
-z <timezone> (e.g. Australia/Brisbane)
type <conv|node|proto|total>
nim-cfg
build
delete entity:mib:oid:index
get entity:mib:oid:index
getflag entity:mib:oid:index
getvalue entity:mib:oid:index
list entity:mib:oid:index
rename entity:mib:oid:index entity:mib:oid:index
set entity:mib:oid:index flags value
setflag entity:mib:oid:index flags
setvalue entity:mib:oid:index value
status
base-graph
base-graph
config options:
background <colour_hex>
calendar { 0|1 }
colour <index> <colour_hex>
font-axis-title <font>
font-axis-label <font>
font-legend <font>
font-title <font>
interval <value>
legend <index> "<string>"
margin <top> <right> <bottom> <left>
margin-col <value>
margin-row <value>
margin-title <value>
radius <value>
start-time <value>
title "<string>"
type { line|filled|bar|stacked|strip }
x-gridlines { 0|1 }
x-step <value>
x-title "<string>"
y-gridlines <number>
y-height <value>
y-labels "<string>" ...
y-max <value>
y-title "<string>"
commands:
data <value>,<value>,...
save </path/to/file>
clear
status
base-report
All tabular reports are created by the base-report program.
base-tfc-gui
base-tfc-gui produces the HTML of the Time Filter. If you are building
a new control panel which requires the Time Filter control, simply call
base-tfc-gui from within your perl script to create the HTML.
nim-snmp
nim-snmpget [-f config file] ipaddr version community varbinds
nim-snmpgetnext [-f config file] ipaddr version community varbinds
nim-snmpwalk [-f config file] ipaddr version community varbinds
nim-snmppoll [-f config file]
|