[Metricbeat] Add Oracle module

[sayden]

This is the seed of the Oracle module with a single metricset called tablespace. We are aiming to release it as beta until we get some time to change our CI to deal with the implications of this module. However, the module has many unit tests.

The steps to do the integration tests manually are the following:

• Launch the Oracle docker image available on their Docker Hub: docker run -d --name oracle -p 1521:1521 -p 5500:5500 store/oracle/database-enterprise:12.2.0.1
• Download and install the Instant Client library as described in the docs file in this same PR.
• Also written in the docs, setup LD_LIBRARY_PATH to the proper destination so it can find Instant Client library.
• Run integration tests normally with go test -tags=integration -data ./... from the tablespace folder, ensuring that you have setup the environment variable mentioned above.

The tablespace Metricset has mainly storage information about the data file and temp files that compose the tablespaces. It also contains summaries of the tablespaces, free space and allocated space to mention a few.

[sayden]

Tablespace metricset is mostly done and it looks like this:

{
    "@timestamp": "2017-10-12T08:05:34.853Z",
    "event": {
        "dataset": "oracle.tablespace",
        "duration": 115000,
        "module": "oracle"
    },
    "metricset": {
        "name": "tablespace"
    },
    "oracle": {
        "tablespace": {
            "data_file": {
                "id": 18,
                "name": "/u02/app/oracle/oradata/ORCLCDB/orclpdb1/sysaux01.dbf",
                "online_status": "ONLINE",
                "size": {
                    "bytes": 629145600,
                    "max": {
                        "bytes": 34359721984
                    }
                },
                "status": "AVAILABLE",
                "user": {
                    "bytes": 628097024
                }
            },
            "free_space": {
                "bytes": 39387136
            },
            "name": "SYSAUX"
        }
    },
    "service": {
        "address": "localhost:1521",
        "type": "oracle"
    }
}

And this is the overall look for the dashboard:

It took me a while to understand how and why Oracle expose its metrics and then compact them in a curated, user-friendly JSON that can be also friendly to be consumed in a dashboard in Kibana.

I'm pretty satisfied with the code too, achieving an 80% of statements coverage properly using interfaces and composition.

Gonna refactor some namings and open for review

[odbaeu]

@sayden, could you please allow connection strings instead of hosts?
This would allow simple connection strings like host:port/service_name but also support more complex connections such as:

(DESCRIPTION_LIST=
  (LOAD_BALANCE=off)
  (FAILOVER=on)
  (DESCRIPTION=
    (ADDRESS_LIST=
      (ADDRESS=(PROTOCOL=TCP)(HOST=primary-server)(PORT=1521))
    )
    (CONNECT_DATA=
      (SERVICE_NAME=orcl)
    )
  )
  (DESCRIPTION=
    (ADDRESS_LIST=
      (ADDRESS=(PROTOCOL=TCP)(HOST=standby-server)(PORT=1521))
    )
    (CONNECT_DATA=
      (SERVICE_NAME=orcl)
    )
  )
)

This connection string is for a Data Guard environment and supports failover when the primary role switched to the standby server.

[sayden]

Hey @odbaeu ! Thank you for all your comments! It's amazing to have contributors like you! A couple of questions about the connection strings:

• What are the security implications of allowing full path connection strings? Let me ask with different words: If I'm a Systems Engineer and I monitor many systems but I'm not expert in any of them (for whatever reason) Should I be worried that by just changing the connection string someone may, potentially, get privileges over a database? At the beginning I allowed the addition of full connection strings until I saw that it might be incredibly complex (and powerful) the things you can do there so I prefer to play safe and leave a simple host:port.
• I can see some of the power you can achieve with connection strings. I'm not expert at Oracle but the way that Metricbeat works is by being light and simple so, the second question is: How Metricbeat is going to collect "better" metrics from Oracle by allowing full/complex SID? Following your example, we don't want that Oracle acts as a load balancer of Metricbeat, it will completely break the purpose of monitoring the resources of each Oracle node.

As I mentioned in the issue, we aim to have a very lightweight module with a very curated scope, starting with baby steps, listening the community to get feedback about improvements and moving towards a more full solution so, to clarify, this points will be very useful in any case 🙂

[sayden]

For reviewers: Still a couple of things for the CI must be done but everything else can be considered ready for review.

[jsoriano]

🚀

[jsoriano]

😄

[sayden]

Thanks all for the help ;)