TeleMate Collector Pro

Managing Data with TeleMate Collector Pro

TeleMate Collector Pro is a very flexible tool for collecting and managing data. It was designed primarily to collect any kind of logged information, but it can also be used to track changes over time of primarily static data, such as directory information stored in an LDAP server. It can be used with our TeleMate Unified Call Management product, our TeleMate Managed Access service, our NetAuditor firewall reporting product, or for any other application that requires you to manage log files.

Figure 1: TeleMate Collector Pro

System Requirements

• Supports all versions of Windows starting with XP with SP2.
• The memory requirement is insignificant over what the OS needs to run smoothly by itself.
• The disk space requirement is insignificant over what the OS needs unless you plan to store the logs on the local hard drive for an extended period of time. In that case, it depends on the size of the logs you want to collect and how long you want to keep them.

Local Features

• Support for the most popular industry‐standard collection methods.
• Support for a powerful scripting language to make it easy to create custom collection methods.
• Stores data in daily log files in compressed folders that are easy to access.
• Cleans up old log files automatically after a specified number of days, on low disk space, or both.
• Allows you to securely relay collected data to another Collector Pro or to a managed server.
• Supports as many “instances” of each collection method as you need. (For server methods like syslog, this means it can listen on several ports at the same time.)
• For each server instance, allows you to decide whether to merge data sent from multiple devices into one log file or to split them up into separate folders.
• For each instance of any kind, allows you to specify periods of time to watch for inactivity. You will be notified by email (SMTP) if no new data is collected during the specified time period.
• Email notifications will also be sent when logs are deleted due to low disk space.
• The engine runs as a single Windows service. Each instance runs in its own thread.
• Performance been finely tuned to support very heavy traffic loads. Customers have informed us that they replaced their Unix syslog servers with our collector because their Unix collectors dropped half the data under heavy load where our collector didn’t drop a single record.
• For troubleshooting purposes, the engine can be told to log everything it does in great detail, and to keep those logs for as long as you want.
• The configuration of each collection method is stored in text files that are easy to read and back up. If the PC a collector is running on dies, it is easy to move its configuration to another PC.
• The collector may be run on a virtual machine, but that is not recommended for collectors handling heavy traffic loads because network, disk, and serial I/O are much slower on a virtual machine.
• The user interface makes it easy to see:
  • How much data has been collected for each method type or instance
  • The distribution of data over time
  • The filenames and contents of individual log files
  • Recent entries in the engine log (all together or filtered by collection method type)

Relay Features

• All relay connections are made using OpenSSL 0.9.8h on port 443. To any proxy server the traffic passes through (or anyone who tries to monitor the data), it looks like any other encrypted SSL tunnel, and the data sent inside that tunnel is impossible to decrypt.
• Each Collector Pro installation can be configured as a stand‐alone collector, a relay client, or a relay server. A client will only talk to the one server you point it to. A server will accept relayed data from as many clients as you want to point to it.
• A relay server behaves like a traditional server. It does not maintain state information on clients, and it does not let clients see what is on the server. Clients connect to the server and tell it to append record X to file Y in folder Z.
• By default, each client keeps a relay connection open 24/7 and transmits all newly collected log records once per minute. Each client also converts its configuration files into log files once per day and relays them to the server (to serve as a backup in case the client dies and a new one needs to be built quickly). Last but not least, if the client generates an alert email due to low disk space or inactivity, it is relayed to the server.
• The relay can be enabled or disabled easily at any time from a client or a server. When a relay connection is re‐established, it picks up where it left off.
• Due to timing issues with network communications, a lost connection during a relay may cause log files to get out of sync between client and server. The relay server detects this and notifies the client that the file is out of sync, which prompts the client to resent the file in question.