David Rio

Seeing the network

I had access to realtime wifi data coming from Cisco controllers. These wifi controllers connect to the different access points and get different metrics from them. It is a lot of data and you can release even more by configuring other yang models.

I setup a telegraf instance to send the data to a kafka topic. I wrote then a little web app to visualize the data in realtime.

In this post I want to talk about the frontend visualization I wrote to visualize the data for my customers. But, before doing that, I'd like to talk about how I wrote the whole application.

The backend is written in Golang and its main task is to connect to the kafka topic, process the messages and send them to the clients via server-sent events. I did not know this technology (SSE) existed but it is very useful for scenarios like this were you want to send data from the server only and it is less complex than websockets. Take a look if you haven't heard about it and keep it in your toolbox.

The backend also serves the frontend which is a vanilla javascript app bundled with Vitejs. In production, I embed the bundle in the Golang binary and serve it from within the http server code. This feature (embeding) has been in Golang for a long time but it is worth mention it as it is a feature I find very useful to help with operation complexity for deployments.

All the different components in the backend (http server, consumer, etc...) run concurrently in go routines and I use mutexes to allow the different go routines to access concurrently the different data structures. Nothing fancy.

The viz

The visualization uses heavily d3js. What you are seeing are wifi devices connected to access points. The color of the device encodes the Rssi value which tells us how good the client signal is against the AP. Red colors indicate very poor Rssi values. A bunch of devices on the same AP with red values may indicate the that AP is not properly located.

I use d3-force to compute the 2d locations of the particles: wifi clients and access points. I define forces in the simulation that push wifi clients towards the AP that gives them networking access. I also apply a force that pushes the particles to the center of the viewport to give this circular shape to the visualization.

The simulation runs in a webworker. This is necessary since the simulation requires a substantial amount of cpu cycles. We want to keep the event loop. When the webworker finishes the computations, sends the nodes and links to the main thread. Each of those have the new 2d locations computed and I then apply d3 transitions to help the user see how the network transitions as we get new data. This is currently not very effective. On each iteration the new 2d locations are typically all over the place so the animations are too busy.

There are some other components in the app: the current number of APs/clients connected and the list of APs with the number of clients connected to them. I also display the color scale I use for the Rssi values in the clients.

I think this is an effective visualization. Yes, the animation does not quite work unless the data is not very different between updates. It is effective because consumers can quickly identify APs that may not be be optimally placed.

Drio out.