Can it run in parallel in a distributed real-time computing system？

[logpai]

Can it run in parallel in a distributed real-time computing system？

[davidohana]

Drain3 is currently not designed for multiprocessing or even multithreading. For that to be supported, the parse tree that is created while ingesting data shall be saved on shared storage (multiprocessing) or have synchronized memory access (multithreading) - the later should be easier to achieve.

Drain3 can usually reach a processing rate of thousands of messages / second on modern hardware (single CPU). This date should be enough for log producing rates in many real-world use cases.

However, sometimes this is not enough, or you want to process historic data fast.

What can still be done:

1. You may separate the input logs by independent sources (e.g. process each data-center independently in a dedicated Drain3 instance).

2. You may shard your input logs by any other fashion you want and still process each shard with a Drain3 instance. However, keep in mind that each Drain3 instance will maintain its own list of mined templates and parse-tree, and the sequential numbers of mined templates will not match between instances. You may ignore the template ID and identify templates by the actual content e.g. Request processed: <*> or a hash of it, merging templates from all Drain3 instances together. The mining results will not be the same vs running a single instance Drain3, but should still be acceptable for many purposes.

3. You may have multiple3 Drain3 instances that only process already-known templates, and a single instance that will process logs that do not match any known template. Whenever you encounter such a template, you will have to send it to the single instance, and then have other instances synchronize with the new state.

[soulripple]

Thank you very much！！(∩_∩)