supernomad / protond Goto Github PK

There are a lot of docs to write.

• godoc needs a lot of work
• readme needs to be written
• wiki needs to be written

Right now the tcp output plugin can hemorrhage events if the remote side is unreachable or terminates a connection and becomes unreachable. The plugin properly handles reconnecting, however there is a period of 10s at minimum where events will be lost.

The idea would be to re-queue the event until the plugin becomes operable again, however in the event that there are multiple outputs this could cause duplication to some if not all of the other configured output plugins. This should be handled gracefully.

This is directly related to #4, and should be implemented at the same time. The idea would be to allow some nominal amount of look back on previous events, so that users can configure differential based alerting.

The biggest issues here are:

• where to store the data for look back
• how much data is available for look back
• how to expose that data to the user for consumption

Currently the idea would be either an in memory LRU or some sort or something like Redis. Then exposing this data to the filter subsystem.

This goes with #3 but is different in that this would be a specific output only triggered by specific conditions that are entirely based on user defined configuration. The easiest way would be to use the outcome of #3, but this again means a very rigid system that means direct development for adding new alerting sinks.

The idea here would be to allow triggering an alert from the filter subsystem. This would allow users to configure arbitrary alerts based on event data.

So right now only protond is only capable of outputing the entire event structure as json encoded data. This is fine for testing and certain output sinks, however not all of them can support this data structure. The idea would be to allow for designating the final data and structure to send to the different outputs, and potentially allowing different outputs have different data encoding.

This could mean just having different output plugins for each of the different supported output sinks, but that means that any new sink will require direct development of protond. The idea would be to allow defining this structure during the filter process.