No description
Find a file
2023-12-14 11:24:59 +01:00
src Add a dockerfile and move files around 2022-10-13 00:10:43 +02:00
.gitignore Update gitignore file 2022-10-14 00:21:28 +02:00
.gitlab-ci.yml Update the gitlab-ci.yml to use CI variables 2023-12-14 11:24:59 +01:00
docker-compose.yml Add a docker-compose file to easily build and deploy the service 2023-03-24 11:38:44 +01:00
Dockerfile Add test gitlab-ci.yml 2023-07-24 17:02:23 +02:00
README.md Add a README document 2022-01-08 18:40:23 +01:00
requirements.txt Initial implementation of server in Python 2021-12-12 00:57:34 +01:00

Test Logger Service

This is a simple Test Logger Service that can be set up anywhere. It has minimal dependencies. I initially wrote this project for testing Ethernet logging from the Real-Time Hypervisor while working from home. In my personal home-office setup, this project is running on a small RaspberryPi Zero lying in some corner.

The main goals for this project were:

  • Be as lightweight as possible. I don't want to run a LAMP Stack on my RPi.
  • Be CLI friendly.

I don't care for the web interface that is provided in the Test Logging Service available in the Ravensburg office. However, it was trivial to add some of that functionality, so I have done so.

Requirements

A simple Linux based system with the following tools:

  1. GNU Bash 4+
  2. Python 3.6+
  3. BSD Netcat

Installing

Installation is simple. On the Logging server clone this repository and run the following commands:

$ python3 -m venv venv
$ source ./venv/bin/activate
$ pip3 install -r requirements.txt

This creates a Python virtual environment and installs the necessary Python packages into it. You may way to simply install the packages globally if you'd like to set this up as a permanent service.

Running

In order to run the service, simply execute the start_server script. See start_server --help for an explanation of the parameters it accepts

API

This Test Logger Service is designed around a CLI use-case and thus is optimized for use with GNU Wget.

It provides the following API endpoints:

GET /status

Returns: An HTML page with a list of all ports the Test Service is currently listening on.

HEAD /

Returns: 200 Ok if the test-logger-service is currently listening on <port-number>.

Error: 404 Not Found if the port is not being listened to.

GET /

Returns: The currently collected log data on <port-number>. This data is returned with a Content-Disposition header. Thus accessing it from a browser will prompt a message to download the file instead of viewing it directly.

Error: 404 Not Found if the port is not being listened to.

NOTE: I might consider changing it to just preview the file in the browser. But, for my current CLI-centric usecase, this is not an issue.

WATCH /

RETURNS: 200 Ok Effectively the equivalent of running tail -f on the logging port. Starting from the time of sending this request, it will keep the connection open indefinitely and return new lines as they are received on the logging port. This can be useful for tracking the debug log messages as they arrive without needing to manually refresh or request the data.

Error: 404 Not Found if the port is not being listened to.

NOTE: This is not a standard HTTP Command. Wget can access it using the --method=watch parameter. See corresponding client tools in the scripts repository for an example.

DELETE /

Returns: 204 No Content and truncates the file that is collecting logs from <port-number>.

Error: 404 Not Found if the port is not being listened to.

NOTE: DELETE here is a misnomer. I would have liked to use TRUNCATE. But DELETE is a known HTTP command, so it felt right to use that.

Limitations

This service only supports a flat hierarchy of ports to listen to. So a simple range of ports is all that is possible. It is currently not possible to have namespaced ports, though implementing that shouldn't be too difficult. I just have no need for them.