LogBus is a Swiss army knife for log & event processing. https://logbus.tfks.net
Find a file
Erik Stephens fcf3f6c2c5
Some checks failed
/ test (push) Failing after 24s
doc fixes
2025-12-30 05:31:04 -07:00
.forgejo/workflows assume global nodejs installed 2025-11-20 16:09:37 -07:00
.vscode wean off package.json 2025-11-03 23:11:08 -07:00
doc doc fixes 2025-12-30 05:31:04 -07:00
examples lots of changes: 2025-12-26 18:42:57 -07:00
src lots of changes: 2025-12-26 18:42:57 -07:00
test code cleanup 2025-12-03 09:44:32 -07:00
.eslintrc.yml de-lint 2023-01-14 18:30:36 -07:00
.gitignore dynamic import with static analysis 2025-11-29 22:28:55 -07:00
.gitlab-ci.yml disable builds in gitlab for now 2025-11-04 07:40:10 -07:00
.prettierrc dynamic import with static analysis 2025-11-29 22:28:55 -07:00
deno.json lots of changes: 2025-12-26 18:42:57 -07:00
deno.lock lots of changes: 2025-12-26 18:42:57 -07:00
justfile lots of changes: 2025-12-26 18:42:57 -07:00
LICENSE wean off package.json 2025-11-03 23:11:08 -07:00
README.md code cleanup 2025-12-03 09:44:32 -07:00

LogBus

A "Swiss Army" knife for handling events with a focus on processing system & application logs. See the docs for more information.

Hacking

See just help for list of helpful tasks.

Unit Testing

just unit-test will test plugins. Plugins should have their spec files colocated beside them. Plugins should strive to be simple functions, but here are some ways they are not:

  • If a plugin needs to manage state, then that can persist in its closure and managed however the plugin sees fit. For example, the write-opensearch output plugin batches events into an array until it is ready to perform a bulk insert.

  • Some plugins may require special start & stop handling.

End-to-End Testing

just e2e-test will test more real-world like scenarios and exercise the main engine bits, but limited to simpler inputs & outputs (files).

Known Issues, Limitations, Warts

  • There should be an example demonstrating how to "commit" events. For example, when consuming from a kafka topic, should only commit offsets once the final pipeline stage has confirmed that the event was received successfully. Not yet sure if there needs to be 1st class support for such a mechanism or if can achieve by wiring up the latter stage's output to the earlier stage's input.

  • Would be nice if plugins could communicate the type (and maybe shape as well) of the events they process. Then, a user could be warned if a pipeline configuration contains stages wired up erroneously.

  • Some plugins require pipeline-defined functions. For simple functions, inlined in yaml is not cumbersome. For more complicated functions, would be nice to define those in a proper package for a better dev & test story.