broadview-collector/README.md
Volodymyr Samotiy 39a635ddd4 Correct the licence text in README.md file
Change-Id: I7c2f3640f83e2985479a76a123d95591641a25b7
2016-03-10 13:09:18 +02:00

435 lines
14 KiB
Markdown

# Overview
`broadview-collector` is a service capable of receiving and publishing
BroadView data received from a network device that is running Broadcom's
BroadView agent. It is built on top of
[broadview-lib](https://github.com/openstack/broadview-lib/tree/master/broadview_lib).
broadview-collector is designed to support multiple metrics-gathering
infrastructures via a plugin architecture.
## Publisher Plugins
broadview-collector is designed to accept plugins that are capable of
publishing BroadView data received by the collector to metric-collecting
services such as OpenStack Monasca. These plugins are in the
form of Python classes. These classes inherit from a base class that
defines the interface the collector will invoke when data is received
from the BroadView agent.
A serializer takes BroadView data and converts it into a playload that
is suitable for a given publisher plugin.
Data coming into the collector from a BroadView agent is passed to a
list of handlers. Each handler is designed to convert the payload
that was received by the agent into an object form (currently, only BST
data is supported, but handlers for additional BroadView components will
be developed). This object form is canonical in the sense that it is
independent of any publisher plugin.
Once the payload is in an object form, a list of publisher plugins is
iterated. Each publisher is given a chance to serialize the data (it
does this by instantiating a serializer object, described below). If
the serialization is successful, then the publisher plugin will write
the data to the service that it directly supports.
## Creating Publisher Plugins
Publisher plugins are simply python source files that exist in the directory
broadview_collector/plugins. A single class inheriting BroadViewPublisherBase
is implemented in this file. This base class defines a single method,
publish(), which accepts a data object from the collector. The plugin
must provide an override to this method.
Addition directories can be configured to hold plugins. These directories,
if configured, will be searched for plugins at startup in addition to
broadview_collector/plugins. See the documentation on the searchpath config
variable in /etc/broadviewcollector.conf, below, for details and an
example.
The name of the class implemented by the plugin must be BroadViewPlublisher.
The set of plugins used at runtime is defined in configuration, and only
configured plugins will be invoked by the collector. Simply placing a
python source file in the plugins directory will not cause it to be
recognized by broadview-collector. Further details on configuration is
provided below.
The job of the publish() method is to (optionally) call a serializer to
convert the data into payload (e.g., JSON) understandable to the service
that the publisher plugin targets, and to publish the data using whatever
API that the target service provides for doing so.
Two example publishers are provided:
* monascapublisher: targets the OpenStack Monasca Python metric publishing API
* logpublisher: appends data to a configured text file
To use a publisher, it must be added to the comma-separated list of publishers
listed in /etc/broadviewcollector.conf, and the collector must be restarted.
## Serializers
Serializers are python source files that are located in the directory
broadview_collector/serializers. The broadview-collector is not directly
aware of these serializers, nor are they required to be configured in order
to be used. They are aggregated in the serializers directory simply to make
them available for whatever plugins wish to use (or not use) them.
A serializer should inherit from BroadViewSerializerBase. The intent is to
promote a uniform API among the serializers. If the target of a
publisher plugin requires a new serializer be written, consider creating a
serializer that inherits BroadViewSerializerBase and locating it in the
serializers directory so that it might be of use to developers of other
publisher plugins.
The monasca and log publishers both use the BSTToMonasca serializer located
in serializers/bst_to_monasca.py to illustrate this concept of reuse. If you
don't like the format of the messages that are written by an existing
publisher, you can write your own serializer (if one of the existing ones
does not fit your needs) and hack the publisher to import and use it instead.
## Handlers
A handler is designed to take traffic incoming to the collector, parse it,
and return an object (of some type) that represents the parsed data. The
returned object (or list of objects perhaps) is then sent to each registered
publisher.
Handlers map to BroadView components. Handlers, like publisher plugins and
serializers, inherit a base class, in this case BroadViewHandlerBase. This
class, and the handlers themselves, are located in
broadview_collector/handlers.
Handlers directly correspond to BroadView components that are supported in
broadview-lib. See https://github.com/openstack/broadview-lib for more
information on the BroadView components supported by broadview-lib.
To use a handler, it must be listed in the comma-separated list of handlers
in /etc/broadviewcollector.conf, and it must be located in the handlers
directory.
The name of the handler class must be BroadViewHandler.
See broadview_collector/handlers/bsthandler.py for an example. Handlers have
a tight coupling to parsers provided in broadview-lib, and normally they will
be added (or updated) as parsers are added (or updated) in the broadview-lib
project.
# Installing BroadView Collector
## Basic Installation and Configuration<a name="basicinstall">
Installation requires the following steps:
1. Install OpenStack, including the services to which you intend to publish
data to. We discuss below Monasca-based publishing in more detail. Steps for
other services are currently not supported, but will be similar in scope.
Your OpenStack vendor/supplier may have installation instructions specific to
products that they support, contact your supplier for more details.
2. Install broadview-lib:
$ git clone https://github.com/openstack/broadview-lib.git
$ cd broadview-lib
$ python setup.py install
3. Install broadview-collector
$ git clone https://github.com/openstack/broadview-collector.git
$ cd broadview-collector
$ python setup.py install
4. Copy the file broadview_collector/config/broadviewcollector.conf to /etc
$ sudo cp broadview_collector/config/broadviewcollector.conf /etc
5. Edit /etc/broadviewcollector.conf as needed
$ sudo vi /etc/broadviewcollector.conf
6. Copy broadview collector application to /usr/local/bin:
$ sudo cp broadview_collector/bin/bvcollect.py /usr/local/bin
$ sudo chmod 755 /usr/local/bin/bvcollect.py
7. Start the collector (assuming /usr/local/bin is in your PATH):
$ bvcollect.py &
In addition, you must configure the broadview agent. This involves two
steps: editing the device configuration so that the agent knows the IP
address and port where the collector is listening, and configuring the
agent to publish desired statistics.
To configure the agent, refer to instructions provided by your vendor.
The IP address and port of the collector is in the [network] section of
/etc/broadviewcollector.conf, for example:
[network]
ip_address: 10.14.244.143
port: 8082
Once the agent is up and running on the networking device, you can use
bv-bstclt (included in broadview-lib) to configure BST.
## Detailed Installation: Monasca API
This section details how to set up and configure a devstack-based install
of broadview-collector that publishes to Monasca API.
The following assumes you are on a host running Ubuntu 14.04. Later versions
of Ubuntu may work, but as of this writing, are not tested or supported.
1. Follow the directions for bringing up Monasca with devstack which are
located here:
https://github.com/openstack/monasca-api/blob/master/devstack/README.txt
If you already have OpenStack and Monasca working, then you probably can
skip the above step.
2. Follow the instructions above in [Basic Installation and
Configuration](#basicinstall)
3. Add monascapublisher to the list of publishers in
/etc/broadviewcollector.conf
4. Add a section, [monasca], to /etc/broadviewcollector.conf, as in the
following:
[monasca]
username: mini-mon
password: password
project_name: mini-mon
auth_url: http://10.14.245.57:35357/v3
endpoint: http://10.14.245.57:8070/v2.0
api_version: 2_0
A /etc/broadviewcollector.conf known to work with monasca-api devstack looks
like the following (you'll need to change the IP addresses to match the one
of your host system):
[plugins]
# comma separated list of plugin modules
publishers: monascapublisher, logpublisher
# handlers map to broadview components, e.g., bst, packet trace
handlers: bsthandler
[logging]
# this section sets prefs for the logging handler.
file: /tmp/broadview-bstlogging.log
[network]
ip_address: 10.14.245.57
port: 8082
[monasca]
username: mini-mon
password: password
project_name: mini-mon
auth_url: http://10.14.245.57:35357/v3
endpoint: http://10.14.245.57:8070/v2.0
api_version: 2_0
# Configuration File Syntax
This section describes the syntax of the configuration file
/etc/broadviewcollector.conf.
## [DEFAULT]
The [DEFAULT] section defines logging parameters. Refer to the example
in config/broadviewcollector.conf for details. Logs in the default
configuration are written to the file
/var/log/broadview-collector/broadview-collector.log
## [plugins]
The [plugins] section supports the following settings related to publisher
plugins:
### publishers
publishers is a list of comma-separated python modules that are located in
the plugins directory, or the plugins searchpath (see searchpath, below).
Example:
publishers: monascapublisher, logpublisher, syslogpublisher
### searchpath
searchpath is a comma-separated list of prefixes that are preprended to the
publisher names when the collector attempts to load plugins.
A search order is defined by the order of items in this comma-separated list.
The "plugins" directory associated with broadview-collector is searched
last. Each plugin is searched for in each directory, in order. If the plugin
is successfully loaded using an entry in the search path, the search ceases.
Otherwise, the search will continue in the next directory defined in the
search path.
Note: the python searchpath (e.g., PYTHONPATH) is not modified by the value
of this variable.
Items in the searchpath must be for the form a.b.c
Example:
searchpath: tmp, home.broadview.plugins
## [misc]
### handlers
The handlers setting is a list of handlers of broadview payload sent by an
agent. This setting generally is defined to reflect the capabilities of
broadview-lib. If you are only interested in a subset of the functions that
BroadView supports, reducing the list of handlers to contain only those
BroadView components you are interested in can increase the performance of
the collector, and reduce the burden on your metric collection/analytics
pipeline. Items in this setting are comma-separated.
Example:
handlers: bsthandler
## [logging]
This section supports the logpublisher publisher plugin.
### file
This setting is the absolute path of the logfile written by the publisher
plugin
Example:
file: /tmp/broadview-bstlogging.log
## [network]
This section contains the networking configuration of the collector
### ip_address
The IP address (IPV4) that the collector will listen for connections on
Example:
ip_address: 10.14.245.57
### port
The port that the collector will listen for connections on
Example:
port: 8082
## [monasca]
This section supports the monascapublisher publisher plugin. These settings
are passed by the monasca publisher as arguments to the monasca python client
constructor. An example of how a python app creates a client object:
from monascaclient import client
import monascaclient.exc as exc
api_version = '2_0'
endpoint = 'http://192.168.10.4:8080/v2.0'
auth_kwargs = {'username': 'mini-mon',
'password': 'password',
'project_name': 'mini-mon',
'auth_url': 'http://192.168.10.5:35357/v3/'}
monasca_client = client.Client(api_version, endpoint, **auth_kwargs)
The settings in this section directory correspond (in name and purpose) with
the arguments pass to the Client constructor above.
### username
The username to authenticate
Example:
username: mini-mon
### password
The password associated with the user being authenticated
Example:
password: password
### project_name
The project name for which the above user is authenticated
Example:
project_name: mini-mon
### auth_url
The URL of the authentication service (keystone)
example:
auth_url: http://10.14.245.57:35357/v3
### endpoint
The URL that defines where monasca API is running
Example:
endpoint: http://10.14.245.57:8070/v2.0
### api_version
The version of the Monasca API
Example:
api_version: 2_0
## DevStack Support
Devstack support is provided by the files located in the directory
broadview_controller/devstack. Devstack is probably the easiest way
to experiment with BroadView Collector.
Refer to the README.txt file in broadview_controller/devstack for
details on how to setup a devstack-based environment for executing
BroadView Collector.
# License
(C) Copyright Broadcom Corporation 2016
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.