aboutsummaryrefslogtreecommitdiffstats
path: root/vnfs/VESreporting_vFW5.0_DANOS/evel/evel-library/code/evel_library/readme.md
diff options
context:
space:
mode:
authorroot <root@danos-build.zbl31w4ywk4ulg0far32rd2huc.cx.internal.cloudapp.net>2020-04-27 21:53:00 +0000
committerMarco Platania <platania@research.att.com>2020-04-28 14:52:48 +0000
commit08eddb8df44beacbb7b4047e313a771292030ccc (patch)
treeede637e3c6725bfd999d115b6ad330f1caa2602f /vnfs/VESreporting_vFW5.0_DANOS/evel/evel-library/code/evel_library/readme.md
parent6610dc1180d0dfbe30a737306d0f059b463aeb26 (diff)
Initial VES for DANOS vRouter
1. Create vpp_measurement_reporter that use DANOS configd query to retrieve statistics and libevel to transmit 2. Copy VES evel library to build a debian package under vpp_measurement_report 3. Add debian files to create a vpp_measurement_reporter + libevel debian package 4. Add debian install and systemctl start files 5. Add instruction to build VES reporter debian package (that will include libevel.so) 6. Add instructions to build DANOS ISO with VES reporter debian package and creating glance image Issue-ID: INT-1566 Change-Id: If18f16525f07f1b6bae0fc105e0452263b4bf661 Signed-off-by: Brian Freeman <bf1936@att.com>
Diffstat (limited to 'vnfs/VESreporting_vFW5.0_DANOS/evel/evel-library/code/evel_library/readme.md')
-rw-r--r--vnfs/VESreporting_vFW5.0_DANOS/evel/evel-library/code/evel_library/readme.md249
1 files changed, 249 insertions, 0 deletions
diff --git a/vnfs/VESreporting_vFW5.0_DANOS/evel/evel-library/code/evel_library/readme.md b/vnfs/VESreporting_vFW5.0_DANOS/evel/evel-library/code/evel_library/readme.md
new file mode 100644
index 00000000..2033cfc9
--- /dev/null
+++ b/vnfs/VESreporting_vFW5.0_DANOS/evel/evel-library/code/evel_library/readme.md
@@ -0,0 +1,249 @@
+# EVEL Library Overview {#mainpage}
+
+# Introduction
+
+The ECOMP Vendor Event Listener ("EVEL") library encapsulates the use of
+AT&T's JSON API to the collector function within the ECOMP infrastructure.
+
+As such, it provides a reference implementation of the EVEL JSON API which
+can either be directly as part of a project or can be used to inform the
+independent implementation of an equivalent binding to the API in another
+development environment.
+
+This section provides an overview of the library and how it is integrated
+into the target application. If all you want is a set of instructions to
+get you started, the @ref quickstart "Quick Start" section is for you. If
+you want a more in-depth understanding of the _EVEL Library_ then this section
+provides an overview and then you can read the detailed API documentation for
+each function. The documentation for evel.h is a good starting point, since
+that defines the public API of the _EVEL Library_.
+
+# Library Structure
+
+The API is designed to be used on multi-process platforms where each process
+may be multi-threaded. Each process using this library will create an
+independent HTTP client (using libcURL). Each process will have a single
+thread running the HTTP client but that thread receives work on a
+ring-buffer from however may threads are required to implement the function.
+
+**Note**: libcurl imposes a constraint that it is initialized before
+the process starts multi-threaded operation.
+
+# Typical Usage
+
+The library is designed to be very straightforward to use and lightweight to
+integrate into projects. The only serious external dependency is on libcURL.
+
+The supplied Makefile produces a single library **libevel.so** or
+**libevel.a** which your application needs to be linked against.
+
+Each process within the application which wants to generate events needs to
+call ::evel_initialize at the start of day (observing the above warning
+about not being MT safe at this stage.) The initialization specifies the
+details of where the API is located. Management of configuration is the
+responsibility of the client.
+
+Once initialized, and now MT-safe, there are factory functions to produce
+new events:
+- Faults - ::evel_new_fault
+- Measurements - ::evel_new_measurement
+- Report - ::evel_new_report
+- State Change - ::evel_new_state_change
+- Syslog - ::evel_new_syslog
+- Other - ::evel_new_other
+- Mobile Flow - ::evel_new_mobile_flow
+
+There is also a factory function ::evel_new_mobile_gtp_flow_metrics to create
+the parameter gtp_per_flow_metrics, which is then configured and passed to the
+::evel_new_mobile_flow factory function.
+
+The event structures are initialized with mandatory fields at the point of
+creation and optional fields may be added thereafter. Once set, values in
+the structures are immutable.
+
+Once the event is prepared, it may be posted, using ::evel_post_event, at
+which point the calling thread relinquishes all responsibility for the
+event. It will be freed once successfully or unsuccessfully posted to the
+API. If, for any reason, you change your mind and don't want to post a
+created event, it must be destroyed with ::evel_free_event.
+
+Finally, at the end of day, the library can be terminated cleanly by calling
+::evel_terminate.
+
+## Example Code
+
+The following fragment illustrates the above usage:
+
+```C
+
+EVEL_ERR_CODES evel_initialize(const char * const fqdn,
+ int port,
+ const char * const bakup_fqdn,
+ int bakup_port,
+ const char * const path,
+ const char * const topic,
+ int ring_buf_size,
+ int secure,
+ const char * const cert_file_path,
+ const char * const key_file_path,
+ const char * const ca_info,
+ const char * const ca_file_path,
+ long verify_peer,
+ long verify_host,
+ const char * const username,
+ const char * const password,
+ const char * const bakup_username,
+ const char * const bakup_password,
+ const char * const source_ip,
+ const char * const bakup_source_ip,
+ EVEL_SOURCE_TYPES source_type,
+ const char * const role,
+ int verbosity
+ ) {
+ fprintf(stderr, "Failed to initialize the EVEL library!!!");
+ exit(-1);
+ }
+
+ ...
+
+ fault = evel_new_fault("My alarm condition",
+ "It broke very badly",
+ EVEL_PRIORITY_NORMAL,
+ EVEL_SEVERITY_MAJOR);
+ if (fault != NULL)
+ {
+ evel_fault_type_set(fault, "Bad things happen...");
+ evel_fault_interface_set(fault, "My Interface Card");
+ evel_fault_addl_info_add(fault, "name1", "value1");
+ evel_fault_addl_info_add(fault, "name2", "value2");
+ evel_rc = evel_post_event((EVENT_HEADER *)fault);
+ if (evel_rc != EVEL_SUCCESS)
+ {
+ EVEL_ERROR("Post failed %d (%s)", evel_rc, evel_error_string());
+ }
+ }
+
+```
+
+The public API to the library is defined in evel.h. The internal APIs
+within library are defined in separate headers (<em>e.g.</em>
+evel_internal.h), but these should not need to be included by the code
+using the library.
+
+# Example Application
+
+A simple command-line application to generate events is provided as part of
+the source package (the above code fragment is taken from that application).
+
+The following illustrates its operation to a co-located "test-collector":
+```
+$ ./evel_demo --fqdn 127.0.0.1 --port 30000 --path vendor_event_listener --topic example_vnf --verbose
+./evel_demo built Feb 26 2016 18:14:48
+* About to connect() to 169.254.169.254 port 80 (#0)
+* Trying 169.254.169.254... * Timeout
+* connect() timed out!
+* Closing connection #0
+* About to connect() to 127.0.0.1 port 30000 (#0)
+* Trying 127.0.0.1... * connected
+* Connected to 127.0.0.1 (127.0.0.1) port 30000 (#0)
+* Server auth using Basic with user 'Alice'
+> POST /vendor_event_listener/eventListener/v1/example_vnf HTTP/1.1
+Authorization: Basic QWxpY2U6VGhpcyBpc24ndCB2ZXJ5IHNlY3VyZSE=
+User-Agent: libcurl-agent/1.0
+Host: 127.0.0.1:30000
+Accept: */*
+Content-type: application/json
+Content-Length: 510
+
+* HTTP 1.0, assume close after body
+< HTTP/1.0 204 No Content
+< Date: Fri, 04 Mar 2016 15:37:22 GMT
+< Server: WSGIServer/0.1 Python/2.6.6
+<
+* Closing connection #0
+* About to connect() to 127.0.0.1 port 30000 (#0)
+* Trying 127.0.0.1... * connected
+* Connected to 127.0.0.1 (127.0.0.1) port 30000 (#0)
+* Server auth using Basic with user 'Alice'
+> POST /vendor_event_listener/eventListener/v1/example_vnf HTTP/1.1
+Authorization: Basic QWxpY2U6VGhpcyBpc24ndCB2ZXJ5IHNlY3VyZSE=
+User-Agent: libcurl-agent/1.0
+Host: 127.0.0.1:30000
+Accept: */*
+Content-type: application/json
+Content-Length: 865
+
+* HTTP 1.0, assume close after body
+< HTTP/1.0 204 No Content
+< Date: Fri, 04 Mar 2016 15:37:22 GMT
+< Server: WSGIServer/0.1 Python/2.6.6
+<
+* Closing connection #0
+* About to connect() to 127.0.0.1 port 30000 (#0)
+* Trying 127.0.0.1... * connected
+* Connected to 127.0.0.1 (127.0.0.1) port 30000 (#0)
+* Server auth using Basic with user 'Alice'
+> POST /vendor_event_listener/eventListener/v1/example_vnf HTTP/1.1
+Authorization: Basic QWxpY2U6VGhpcyBpc24ndCB2ZXJ5IHNlY3VyZSE=
+User-Agent: libcurl-agent/1.0
+Host: 127.0.0.1:30000
+Accept: */*
+Content-type: application/json
+Content-Length: 2325
+
+* HTTP 1.0, assume close after body
+< HTTP/1.0 204 No Content
+< Date: Fri, 04 Mar 2016 15:37:22 GMT
+< Server: WSGIServer/0.1 Python/2.6.6
+<
+* Closing connection #0
+^C
+
+Interrupted - quitting!
+$
+```
+
+# Restrictions and Limitations
+
+## Constraint Validation
+
+The _EVEL Library_ has been designed to be production-safe code with the
+emphasis at this stage being in correctness of operation rather than
+raw performance.
+
+The API tries to check as much information as possible to avoid misuse and
+will **assert()** if constraints are not satisfied. This is likely to lead
+to the rapid discovery of coding errors by programmers, but does mean that
+the application can fail abruptly if the library is misused in any way.
+
+## Performance
+
+The default Makefile avoids aggressive optimizations so that any core-files
+are easy to interpret. Production code should use greater optimization
+levels.
+
+As described above, the HTTP client is single threaded and will run all
+transactions synchronously. As transactions are serialized, a client that
+generates a lot of events will be paced by the round-trip time.
+
+It would be a straightforward enhancement to use the multi-thread API into
+libcurl and use a pool of client threads to run transactions in parallel if
+this ever became a bottleneck.
+
+## Logging
+
+The initialization of the library includes the log verbosity. The verbose
+operation makes the library very chatty so syslog may get rather clogged
+with detailed diagnostics. It is possible to configure syslog to put these
+events into a separate file. A trivial syslog.conf file would be:
+
+```
+
+# Log all user messages so debug information is captured.
+
+user.* /var/log/debug
+```
+
+If verbose logging is enabled, the cURL library will generate information
+about the HTTP operations on **stdout**.
+