Destroyed Rule outputs (markdown)

Rule-outputs.md

@@ -1,45 +0,0 @@
-In the current digwatch output, each rule has an optional associated output specifying what output should be printed.
-For example:
-```
-read and fd.name contains .so and not so_dirs | Shared object loaded from unexpected place (%evt.time, %evt.type, %proc.name, %fd.name)
-```
-​
-It is easy to foresee a need for more flexibilty in specifying outputs - not just _what_ is output, but where and how it goes.
-​
-Here are some simple examples: 
-​
-- associating severities with events, like in syslog (@loris).
-- being able to specify which file a given rule's output goes to
-- specifying that a rule (or all rules) should be piped into some other tool or transport. For example send out an alert to some REST API.
-​
-
-Taking things a bit further, we could envision generalized "post-processing" of rule outputs. 
-This is somewhat similar to what chisels do for a single filter today.
-​
-For example, for the rule that "detects .so files loaded outside of a known directory", rather than send an alert at each event, we could pipe these into a script that maintains a list of all the loaded .so's and periodically sends that list out.
-​
-Or, for a simple form of suppression/baselining, we could have a script that maintains some state summarizing previously-seen events, and only outputs new ones.
-​
-​
-Here's a strawman syntax proposal:
-​
-```
-​
-// Handled as currently: output interpreted like sysdig -p argument
-rule ... | Shared object loaded from unexpected place (%evt.time, %evt.type, %proc.name, %fd.name)
-​
-// New: use function call syntax to indicate sending into a Lua function:
-rule ... | syslog(evt, WARN, "%evt.time, %evt.type, %proc.name, %fd.name")
-rule ... | write_to_file(evt, "filename.txt")
-rule ... | send_http(evt, "http://pagerduty.com/rest/alert?id=xyz")
-rule ... | suppress_dupes(evt, "fieldname")
-​
-```
-​
-​
-The API available to these Lua functions is a subset of the existing Lua Chisel API (maybe with some minor additions/changes). For sure, it will need `chisel.request_field()` and `evt.field()`.
-
-Taking things _much_ further out, these Lua functions could be given an API allowing them to modify the ruleset on the fly, adding or inserting rules. This enables a broad range of approaches to baselining, learning, and adaptation.
-
-
-