A picture is worth a thousand words, and sometimes, a visual image of your network can save you hours of troubleshooting. Skydive [1] is an open source network analyzer designed to provide a graphical representation of the IT components and how they interact. I'm not talking about wiring but about the data flows between the nodes. Skydive stores this information in a central location. You can interact with Skydive using a web interface, the command line, or an API.

Skydive consists of a central analyzer and many agents (Figure 1). The agents run on Linux hosts and report network configuration and statistics to the analyzer. The analyzer listens to feedback from its agents and stores the input in a database. Gradually, the analyzer gets to know the entire topology and traffic flows between endpoints. The admin can access the new Skydive instance via the analyzer's web interface.

Figure 1: The Linux agents provide states and metrics to the Skydive analyzer.

Agents act as "dumb" data forwarders. The brain of the analyzer is a NoSQL database, either Elasticsearch or OrientDB. Skydive scales horizontally: If an analyzer is at capacity with its agents, additional analyzers can step in and serve additional agents. The analyzers fill the same database with flow information while keeping their configurations in sync using etcd.

Installation

Skydive's Github repository [2] provides a precompiled binary that is ready to use after download. If you don't trust this convenience, grab a build host with a compiler and compile the code yourself (Listing 1).

# yum install go git make protobuf protobuf-c-compiler \
    npm patch libxml2-devel libvirt-devel libpcap-devel \
    protobuf-devel
# mkdir $HOME/go
# export GOPATH=$HOME/go
# export PATH=$GOPATH/bin:$PATH
# mkdir -p $GOPATH/src/github.com/skydive-project
# git clone https://github.com/skydive-project/skydive.git \
    $GOPATH/src/github.com/skydive-project/skydive
# cd $GOPATH/src/github.com/skydive-project/skydive
# make
# make install

The result is an executable file that works as an analyzer or as an agent depending on how it is called. Workable service files for Systemd are provided in the contrib/ directory of the repository. The service retrieves the settings from a configuration file in YAML format, which you will find in etc/ in typical Linux style.

Getting Started

The all-in-one scenario, which runs the agent and analyzer on the same host, is a good choice for getting to know Skydive. After you call skydive allinone, the two components launch immediately and explore the operating system and the network adapters. The analyzer's web interface listens on http://localhost:8082 and lets you browse the new environment without any risks.

The most basic configuration is nothing but a short interlude because the analyzer keeps this data in RAM instead of using persistent storage on the file system. After restarting the software, all the information and settings will be lost. However, Skydive is also capable of storing the explored topology and flow information in an Elasticsearch database. Skydive does not put too much strain on the database server. In simple setups, the database can run on the same host as the analyzer. In either case, Elasticsearch needs to accept the analyzer's connection attempts. No further knowledge of Elasticsearch or NoSQL is needed; Skydive uses the database more like a dumb data silo.

In the sample configuration from Listing 2, the analyzer learns of its new storage facility in a neighboring database system. It is also important to authenticate the web interface because – by default – web access works without a login. The example uses the modest capabilities of Skydive and stores the user accounts in the htpasswd file typical of Apache. For demanding environments, an upstream reverse proxy implements almost arbitrary login scenarios.

analyzer:
  listen: 0.0.0.0:8082
  flow:
    backend: myelasticsearch
  topology:
    backend: myelasticsearch
  auth:
    api:
      backend: mybasic
storage:
  myelasticsearch:
    driver: elasticsearch
    host: 172.31.28.51:9200
    ssl_insecure: true
etcd:
  embedded: true
auth:
  mybasic:
    type: basic
    file: /etc/skydive/skydive.htpasswd

If Firewalld controls network access to the server, the instructions in Listing 3 create an exception for Skydive. With this exception, the analyzer is ready for updates from its agents and the watchful eye of the admin on the web interface.

# firewall-cmd --permanent --add-port=8082/tcp
# firewall-cmd --reload

Agent

The Skydive agent works like an informer that listens as a regular Linux service on a server, on a virtual machine, or in a container. The configuration file tells the agent which protocols and system areas it needs to monitor and which analyzer is responsible for it.

For its discovery tour, the agent can explore a wide variety of topologies: Open vSwitch, Docker, OpenStack, Linux containers, Libvirt, but also the classic neighborhood protocol LLDP. Libvirt support opens the door for exploring major virtualization platforms such as KVM, Qemu, Xen, and VMware ESXi. From the list of topologies, select the ones you want Skydive to explore.

The configuration file in the repository contains all the directives with examples and default values. By default, the agent uses only Netlink and Netns. The configuration file contains only the specification of the analyzer and is rather short:

analyzers:
  - analyzer.example.net:8082

Once the agent has launched, it disappears into the background and communicates with its analyzer. The relationship is a give-and-take affair. The agent receives work orders and provides information such as a host's profile, IPv4/v6 addresses, network adapter utilization, or the ARP and routing table.

Granted: The same values can also be found using the matching Linux commands. The big advantage Skydive offers is that the details from all the agents are available before troubleshooting starts. The transmitted work instructions ultimately come from the operator in front of the screen and are: collect flows and inject packets.