For consumers of Zeek logs it's handy to have a way to understand the name/goal of the produced logs, what are each log's column names, types, and meaning, etc. Examples of such consumption tasks are

• auto-generating docs / cheatsheets
• understanding differences in generated logs between Zeek versions, installations, or loaded package sets
• data schema definitions required for some log par

Currently the import client and the backend check for .plaso in the filename to verify it is a plaso file. This is not perfect from user perspective as well as error safe.

Instead the import should check on actual content in the file based on the .plaso format.

I was wondering the benefit of using Modular File Management vs Single Config File Management? Why do you consider it easier to use multiple files and then compile? Trying to figure out what the best case is for my use case. Thanks. #

Right now a lot of the logging from the tasks does not get propagated back to the user, so we should make sure that all of the tasks are adding logs and errors to the results so that at minimum the data gets put into the worker-log.txt. Ideally we would store this info in datastore so that the clients could query it later (this part is in #115).