File: PLUGINS

package info (click to toggle)
pmacct 1.7.6-2
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, sid
  • size: 11,548 kB
  • sloc: ansic: 106,538; sh: 4,876; cpp: 4,340; python: 3,631; makefile: 502
file content (57 lines) | stat: -rw-r--r-- 3,144 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
PMACCT PLUGIN WRITING HOW-TO

SHORT OVERVIEW
pmacct plugin architecture is thought to allow to implement own
backends without knowing much of core collectors functionalities
and independently by other plugins. Below are listed a few steps
to hook a new plugin in pmacct; pmacct is also extremely open to
new ideas, so if you wish to contribute your work, you will be the
most welcome. 

- minor hacks to configure.in script following the example of what
  has been done there for mysql plugin; same goes for requirements
  like paths to headers or libraries. By making use of the PLUGINS
  variable, it will not be required to touch the "src/Makefile.am"
  script. Definitions in configure.in (ie. AC_DEFINE(WITH_MYSQL, 1))
  whose existence can be checked via compiler preprocessor is an
  easy way to propagate user configuration choices at compilation
  time.

- [OPTIONAL] If the plugin needs to take configurable values, this
  can be achieved by defining configuration handlers (pmacct-data.h,
  cfg_handlers.h, cfg_handlers.c) and declaring config variables to
  deliver configured values to the plugin (cfg.h, struct configuration).
  If command-line parameters are also required, some getopt() related
  code needs to be dealt with (pmacct-defines.h and ie. pmacctd.c,
  nfacctd.c, sfacctd.c and uacctd.c). 
  
- Define the new plugin in pmacct; this can be done by adding an
  entry to the plugin_types_list[] array (pmacct-data.h). An entry
  consists of two fields: an id string and a pointer to a function
  to be called. The first is the string which will be used to call
  the plugin from within the configuration or command-line. The
  second is effectively the entry point to the plugin.

- [OPTIONAL] If the plugin needs any checks that require visibility
  in the global configuration for example for compatibility against
  other plugins instantiated (ie. tee plugin not compatible with any
  plugins) or the daemon itself (ie. nfprobe plugin only supported
  in pmacctd and uacctd daemons), such checks can be performed in
  the daemon code itself (ie. pmacctd.c, nfacctd.c, etc. - look in
  these files for the "PLUGIN_ID" string for examples). 

- Develop the plugin code. One of the existing plugins can be used
  as reference - of course, as long as the purpose of the plugin
  under development is same or similar in function (ie. data is
  extracted from the circular buffer, then aggregated and cached in
  memory for a configurable amount of time, ie. print_refresh_time, 
  and finally purged to the backend. Structures for parsing data
  coming out of the circular buffer are defined in the network.h
  file; structures for data caching are in print_common.h (at least
  three generations of caches were conceived over time: first the
  one used in the memory plugin; second the one used in SQL plugins,
  rich in features but challenging to control in size; third, and
  current, the one used in print, MongoDB and AMQP plugins which is
  defined, as said, in print_common.h). The basic layout for the
  main plugin loop can be grasped in the print_plugin.c file by
  looking at content of the "for (;;)" loop.