Pim van Pelt 589030cb00 doc-fix: clarify UDP listener handles multi-source peers
No runtime change — the listener already uses net.ListenUDP +
ReadFromUDP, which is the unconnected-socket pattern that accepts
datagrams from any source. nginx reloads (new workers with fresh
ephemeral source ports) are handled transparently.

- udp.go: expanded comment on Run() explaining the design choice and
  contrasting with the `nc -k -u -l` latching quirk (which is an nc
  bug, not a kernel behaviour).
- udp_test.go: new TestUDPListenerMultipleSources regresses against
  the multi-worker scenario by sending from three independent
  ListenPacket sockets (three different ephemeral source ports).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-17 10:39:34 +02:00
2026-03-24 04:50:24 +01:00
2026-03-14 20:07:32 +01:00
2026-03-14 20:07:32 +01:00
2026-03-23 22:21:30 +01:00

PREAMBLE

Although this computer program has a permissive license (AP2.0), if you came here looking to ask questions, you're better off just moving on :) This program is shared AS-IS and really without any intent for anybody but IPng Networks to use it. Also, in case the structure of the repo and the style of this README wasn't already clear, this program is 100% written and maintained by Claude Code.

You have been warned :)

nginx-logtail frontend

What is this?

This project consists of four components:

  1. A log collector that tails NGINX (or Apache) logs and/or receives logs over UDP from nginx-ipng-stats-plugin, aggregating counts per website, client address, URI, status, ASN, and source tag. It buckets these into windows of 1m, 5m, 15m, 60m, 6h, and 24h and exposes them over gRPC.
  2. An aggregator that subscribes to any number of collectors and serves a merged view on the same gRPC surface.
  3. An HTTP frontend that renders a drilldown dashboard (zero JavaScript, server-side SVG sparklines) against any collector or the aggregator.
  4. A CLI for shell queries, returning tables or JSON.

Written in Go, released under [APACHE]. Runs as systemd units, in Docker, or any combination.

Quick Start

Three deployment flavors. Pick whichever suits the host.

Debian package. Build once, install the .deb on every nginx host (for the collector) and on one central host (for the aggregator + frontend):

make install-deps          # one-time: apt deps, Go toolchain, go tools
make pkg-deb               # produces nginx-logtail_<ver>_{amd64,arm64}.deb

# on each nginx host:
sudo dpkg -i nginx-logtail_*_amd64.deb
sudo $EDITOR /etc/default/nginx-logtail   # defaults to UDP-only on :9514; set COLLECTOR_LOGS=... to also tail files
sudo systemctl enable --now nginx-logtail-collector.service

# on the central host:
sudo dpkg -i nginx-logtail_*_amd64.deb
sudo systemctl enable --now nginx-logtail-aggregator.service nginx-logtail-frontend.service
# dashboard now at http://<central>:8080

Binaries land at /usr/sbin/nginx-logtail-{collector,aggregator,frontend} and the CLI at /usr/bin/nginx-logtail. All three services run as the _logtail system user (collector uses Group=www-data for log access). None are auto-enabled, so installing the package is safe on any host.

Docker Compose. Runs the aggregator and frontend in one stack; point collectors (on each nginx host) at the aggregator:

AGGREGATOR_COLLECTORS=nginx1:9090,nginx2:9090 docker compose up -d
# frontend on :8080, aggregator gRPC on :9091

From source (make).

make build                 # build/<arch>/{collector,aggregator,frontend,cli}
make test
./build/*/nginx-logtail -version

make help lists every target.

See [User Guide] for operator-facing documentation, or [Design] for the normative requirements and architectural rationale.

Description
No description provided
Readme Apache-2.0 1,002 KiB
Languages
Go 92.3%
Makefile 4%
HTML 2.5%
Dockerfile 1.2%