From 5d63b3b894e4ee30e0077c4b950f5bdd3a0716b0 Mon Sep 17 00:00:00 2001 From: Markus Stenberg Date: Fri, 14 Jun 2024 13:44:17 +0300 Subject: [PATCH] README: Update --- README.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index e60c562..fbe8818 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ it also does not mean anything (I am not going to use 'dog ate my homework' excuse but instead use the modern excuse - Mistral came up with it). The goal of Lixie is to be single binary, zero external dependency -tool. Currently there are two planned modes: +tool. Currently there are two implemented modes: - configuration generator for tools ( mainly [vector](https://vector.dev) ) @@ -19,9 +19,10 @@ tool. Currently there are two planned modes: # Log filtering - high level idea Most of the modern logs are, to put it bluntly, spam. Typical SIEM -approaches rely on matching specific log rules of interest, and ignoring -the rest. However, this leaves the 'unknown unknown' problem on the table, -as if you don't have rule for it, you are not aware of it happening either. +approaches rely on matching specific log rules of interest, and +ignoring the rest. However, this leaves the 'unknown unknown' problem +on the table, as if you do not have a rule for it, you are not aware +of it happening either (and how often it happens). Lixie's approach is inverse - everything is worth looking at, at least once. Lixie provides a way of cultivating ruleset about which lines are @@ -84,3 +85,7 @@ local Lixie instance which probably does not exist. - style the pages properly (right now just basic Bootstrap and one or two ugly bits remain) + +## Perhaps some day? + +- support victoria logs / opensearch / quickwit as log source