 |
Consumption Analytics Documentation |
|
Consumption Analytics Documentation |
All configuration options supported by the Network Traffic Collector are defined in a configuration file. By default, the collector will look for a file called ccnetcollect.conf located in the same directory as the collector itself. You must edit this file to suit the environment. Any changes made to the file become active when the collector is restarted.
You can force the collector to use an alternative configuration file by using the -f option as follows:
ccnetcollect -f myconfig.conf
To generate a sample configuration file, which will contain information about all the available configuration options, use the command line option -sampleconfig. This will output the sample configuration to the terminal, so to capture it as a file use redirection as follows:
ccnetcollect -sampleconfig > myconfig.conf
A configuration file consists of configuration items of the form item = value. All whitespace is ignored, and any text on a line after a # character is also ignored. The item specified on each line can be in upper case, lower case, or a mixture of the two.
The collector will perform a number of sanity checks on the values specified in the configuration file, as well as establish that no required items are missing. In the event of missing or invalid data, diagnostic information will be written to the logfile specified in the configuration file, or to syslog if no logfile is specified.
If any required options are missing, the collector will inform you how many are missing and refer you to the log file for the specific list of missing options.
| Item | Description | Required |
|---|---|---|
logfile | The location and name of the file to log activity into. If not present then the collector will send all logging output to the system log (syslog). | N |
daemon_mode | If enabled using Y, y or 1 then the collector runs as a Unix daemon. If this item is disabled, or absent then the collector runs as a normal application. | N |
daemon_dir | If daemon_mode is enabled, then this option is required in order to set the current working directory of the daemon. | See description |
listen_addr | IP address to listen for NetFlow V9 traffic on | Y |
listen_port | Port number to listen for NetFlow V9 traffic on | Y |
accept_from | IP addresses of authorised NetFlow sources. Up to 32 can be defined using a separate accept_from line for each one. If any accept_from line has a value of * or any then filtering will be disabled and NetFlow will be accepted from any sender. | Y |
cc_server | IP address of the Cloud Cruiser server | Required if ccr_push_flag is enabled (the default) |
cc_port | Port number for API access on the Cloud Cruiser server | |
cc_username | Username for Cloud Cruiser API login. No spaces allowed. | |
cc_password | Password for Cloud Cruiser API login. No spaces allowed. | |
internal_net | A network range, in CIDR notation. The collector determines the direction of traffic by comparing the source IP address against the configured ranges. Multiple ranges can be defined with multiple internal_net lines. Up to 64 internal network ranges are supported. CIDR notation follows an IP address with the number of bits in the network mask, thus 192.168.0.1/24 has a network mask of 255.255.255.0. The IP address must contain all four octets. | Y |
ccr_push_flag | If disabled using N, n or 0, then do not attempt to push files to Cloud Cruiser API. The default is 1 (enabled). | N |
| ccr_push_dir | If present, specifies the directory on the Cloud Cruiser server into which CCR files will be pushed. If absent, the default value is is ccnetcollect | N |
empty_push | If enabled using Y, y or 1, then in the event that the collector exports an empty CCR file, this file will be pushed to Cloud Cruiser via the API. If disabled, no push attempt will be made for empty CCR files. The default is 0 (disabled). | N |
debug | If enabled using Y, y or 1, then the collector will emit a large amount of detailed internal information as it runs. This will also cause a huge performance drop, and as such is intended for developer-level troubleshooting. Default is 0 (disabled). This option is best combined with a packet_limit setting as described below. Note that this option does nothing when the collector is running in daemon mode. | N |
packet_limit | If 0, then the collector runs indefinitely. If set to a number greater than 0, then it will automatically exit after the specified number of NetFlow packets have been processed. This option can be useful to auto-exit after a few packets when the debug setting is enabled. The default is 0. | N |
packet_sizelimit | The maximum amount of data in bytes that the collector will read from a UDP packet. Unless support for jumbo frames is required, it is recommended to leave this option undefined. The default is 2000. | N |
ccr_export_dir | The directory into which CCR files will be exported (the trailing slash is optional). If it does not exist, then the collector will attempt to create it. If there is more than one directory in the path, then the collector will only attempt to create the last directory in the path. Default is ccr/ (in daemon mode this is relative to the directory specified by daemon_dir. | N |
ccr_export_interval | The interval in minutes at which CCR files will be exported. Valid values are 1, 2, 5, 10, 15, 30 and 60. The default is 60. The first export is performed at the first multiple of ccr_export_interval minutes past minute 0 of the hour. | N |
parser_threads | The number of NetFlow parser threads to spawn (1 - 32). If this option is not specified then suitable defaults will be used based on the number of logical CPU cores on the system. | N |
The parser_threads setting should only be used if you have good reason. By default, the collector will automatically detect the number of CPU cores and an appropriate default number of parser threads will be spawned. These defaults are shown in the table below.
| Cores | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Parsers | 0 | 2 | 4 | 6 | 6 | 8 | 8 | 16 | 16 | 16 | 16 | 16 | 16 | 16 | 16 | 16 |
Single core processors are not viable for running the Network Traffic Collector, and the program exits with a message if only a single core is detected.
A maximum of 32 parser threads are supported. The defaults shown above should be appropriate for the majority of installations, but in the event that you have reason to believe that more CPU power is required, then adding a few threads is a good starting point.
This setting should be used with caution, as running too many threads on a server with a low core count can actually decrease performance if there are not enough cores to support them. As a general rule of thumb, 2-6 threads per core is a good range to apply.
(c) Copyright 2017-2020 Hewlett Packard Enterprise Development LP