> > > This SEC admin, as I see it, is still also from user perspective, tightly > bound with SEC technology and user needs to know, how SEC rules and their > compositions work internally. I am imagining something, that is > technology-agnostic, just describing logic of correlations, and from that > "formal description" generating SEC (or something other, > technology-agnostic means, that it may not to be dependent on SEC or other > specific technology, user needs just "what", but not "how"). Therefore > configuration DB should not operate with SEC-specific entities, but rather > something more general. Maybe something, which could be described with > something like EMML (Event Management Markup Language - never used that, I > don't know it, I just found that it exists). > > Levels of formal description of correlation types: > > - *user (admin) level* (higher-level, less detailed) - containing enough > information to configure and use described correlation type > > - *developer level* (lower-level, more detailed) - containing enough > information, to generate lower-level code (SEC configurations) from formal > description (from configuration DB, maybe with support of something like > EMML) > > Hope this helps to undertand what I wanted to say :). >
Developing another event correlation language and tools for supporting it sounds like a separate major software development project to me. Before embarking on that, have you considered using configuration management frameworks (e.g., Salt or Ansible)? Among other things, they allow you to create configuration files in automated fashion after the user has set some generic parameters. It might not be exactly what you have envisioned, but it is definitely cheaper workaround than rolling out an entirely new solution. kind regards, risto > Richard > >> >> hope this helps, >> risto >> >
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
