Issue: Historically document our filebeat implementation and revisit alternatives - at least at the discussion level.

When the logging project was uploaded from seed code in July 2017 - Filebeat was the default capture mechanism via the etherial PV emptyDir between containers in a pod - uploading data to the logstash container of the elk pod.

Currently we are running filebeat primarily in REST based containers in since before Amsterdam

https://wiki.onap.org/display/DW/Logging+Reference+Implementation#LoggingReferenceImplementation-ONAPcomponentswithaFilebeatcontainer

AAI(5), APPC(1), POLICY(3), SO(1), Portal(1), SDC(2), SDNC(2), VID(1)

No DCAE filebeat because we are still waiting on DCAE containerization - specifically we are blocked adding filebeat until the cloudify manager software is containerized into a docker image - where we can add it into kubernetes and add filebeat.

examples
We need to be pluggable so we can for example allow for providers using sumologic via fluentd
https://github.com/kubernetes/charts/tree/master/stable/sumologic-fluentd 

We should go back and document alternatives to the current architecture - both to cover off whether our design is sound technically and performant.

We should entertain any other alternative log agents in view of the discussion with multicloud on 20180205:2000 EST (GMT-5)

We especially need performance metrics as one of their MVPs is for performance of their django/python design

TBD email/JIRA under review.

check alternative architecture involving filebeat daemonset reading logs directly from the docker logs on each VM in /var/lib/docker/containers