Реализация “механизма правил” на Python

StackOverflow https://stackoverflow.com/questions/467738

  •  19-08-2019
  •  | 
  •  

Вопрос

Я пишу приложение для сбора / анализа журналов на Python, и мне нужно написать "механизм правил" для сопоставления сообщений журнала и их обработки.

Это должно включать:

  • Соответствие регулярному выражению для самого сообщения
  • Арифметические сравнения серьезности / приоритета сообщения
  • Логические операторы

Я предполагаю, что примерное правило, вероятно, было бы чем-то вроде:

(message ~ "program\\[\d+\\]: message" and severity >= high) or (severity >= critical)

Я подумываю об использовании ПиПарсинг или аналогично, чтобы фактически проанализировать правила и построить дерево синтаксического анализа.

Текущий (еще не реализованный) проект, который я имею в виду, заключается в том, чтобы иметь классы для каждого типа правила и создавать и объединять их в цепочку в соответствии с деревом синтаксического анализа.Тогда у каждого правила был бы метод "matches", который мог бы принимать объект message, возвращаемый независимо от того, соответствует он правилу или нет.

Очень быстро, что-то вроде:

class RegexRule(Rule):
    def __init__(self, regex):
         self.regex = regex

    def match(self, message):
         return self.regex.match(message.contents)

class SeverityRule(Rule):
    def __init__(self, operator, severity):
         self.operator = operator

    def match(self, message):
         if operator == ">=":
             return message.severity >= severity
         # more conditions here...

class BooleanAndRule(Rule):
    def __init__(self, rule1, rule2):
         self.rule1 = rule1
         self.rule2 = rule2

    def match(self, message):
          return self.rule1.match(message) and self.rule2.match(message)

Затем эти классы правил были бы объединены в цепочку в соответствии с деревом синтаксического анализа сообщения и методом match(), вызываемым для верхнего правила, которое каскадировалось бы вниз до тех пор, пока все правила не были бы оценены.

Мне просто интересно, разумный ли это подход, или мой дизайн и идеи совершенно не соответствуют действительности?К сожалению, у меня никогда не было возможности пройти курс по дизайну компилятора или что-то в этом роде в Unviersity, поэтому я в значительной степени придумываю этот материал по собственному желанию.

Не мог бы кто-нибудь, имеющий некоторый опыт в подобных вещах, пожалуйста, присоединиться и оценить идею?

Редактировать: Пока есть несколько хороших ответов, вот небольшое уточнение.

Целью программы является сбор сообщений журнала с серверов в сети и сохранение их в базе данных.Помимо сбора сообщений журнала, сборщик определит набор правил, которые будут либо сопоставлять сообщения, либо игнорировать их в зависимости от условий, и при необходимости отметит предупреждение.

Я не вижу, чтобы правила были более чем умеренной сложности, и они будут применяться в цепочке (списке) до тех пор, пока не будет получено соответствующее предупреждение или правило игнорирования.Однако эта часть не совсем так актуальна для данного вопроса.

Что касается синтаксиса, близкого к синтаксису Python, да, это верно, однако я думаю, что было бы трудно отфильтровать Python до такой степени, чтобы пользователь не мог непреднамеренно делать какие-то сумасшедшие вещи с правилами, которые не были предназначены.

Это было полезно?

Решение

Не изобретайте еще один язык правил.

Либо используйте Python, либо используйте какой-нибудь другой существующий, уже отлаженный и рабочий язык, такой как BPEL.

Просто напишите свои правила на Python, импортируйте их и выполняйте.Жизнь проще, ее гораздо легче отлаживать, и вы фактически решили проблему с чтением журнала, не создавая еще одной проблемы.

Представьте себе этот сценарий.Ваша программа ломается.Теперь это либо синтаксический анализ правила, либо выполнение правила, либо само правило.Вы должны отладить все три.Если бы вы написали правило на Python, это было бы правилом, и все было бы так.

"Я думаю, было бы трудно отфильтровать Python до такой степени, чтобы пользователь не мог непреднамеренно наделать с правилами каких-нибудь безумных вещей, которые не были предназначены".

В значительной степени это аргумент типа "Я хочу написать компилятор".

1) Вы являетесь основным пользователем.Вы будете писать, отлаживать и поддерживать правила.Действительно ли существуют армии сумасшедших программистов, которые будут делать безумные вещи?Неужели?Если есть какой-либо потенциальный сумасшедший пользователь, поговорите с ними.Научи Их.Не боритесь с ними, изобретая новый язык (который вам затем придется поддерживать и отлаживать вечно).

2) Это просто обработка журнала.Нет никакой реальной стоимости для сумасшествие.Никто не собирается подрывать мировую экономическую систему неправильным обращением с журналами.Не создавайте небольшую задачу с несколькими десятками строк Python для 1000-строчного интерпретатора, чтобы интерпретировать несколько десятков строк какого-то языка правил.Просто напишите несколько десятков строк на Python.

Просто напишите это на Python как можно быстрее и понятнее и переходите к следующему проекту.

Другие советы

Возможно, вы также захотите взглянуть на ПаЙК.

Рассматривали ли вы НебриОС?Мы только что выпустили этот инструмент после того, как создали его для наших собственных целей.Это чистый движок правил Python / Django.На самом деле мы используем его для задач рабочего процесса, но он достаточно общий, чтобы помочь вам в вашей ситуации.Вам нужно будет подключиться к удаленной базе данных и выполнить для нее правила.

Написанный вами Python в конечном итоге будет содержать более одного правила в системе.Вот один из них для примера:

class SeverityRule(NebriOS):
    # add listener or timer here

check(self):
    if operator == ">="
    return message.severity >= severity
    # any number of checks here


action(self):
    csv.append(message.severity, datetime.now)
    send_email(kamil@example.com, """Severity level alert: {{message.severity}}""")

Проверьте это на http://nebrios.com.Я не понимал, как много значит создание приложения на движке правил, подобного Nebri, пока моя команда не приступила к работе.Это была ОГРОМНАЯ задача, которая гораздо глубже, чем кажется.ACL, очереди, формы, KVP, эффективные проверки, полезные ошибки, синтаксический анализ электронной почты, динамические формы и этот список можно продолжить.

Немного сложно ответить на этот вопрос, не зная, какова сфера применения приложения.

  • О чем ты пытаешься рассуждать?
  • О каком уровне анализа вы говорите?
  • Насколько сложными, по вашему мнению, становятся правила?
  • Насколько сложно взаимодействие между различными правилами?

На одном конце спектра находится простой одноразовый подход, подобный тому, который вы предложили.Это нормально, если правил немного, они относительно просты, и вы не делаете ничего более сложного, чем агрегирование сообщений журнала, соответствующих указанным правилам.

На другой стороне спектра находится тяжеловесная система рассуждений, что-то вроде ЗАЖИМЫ это имеет Интерфейс Python.Это настоящий движок правил с выводом, который предлагает возможность выполнять сложные рассуждения.Если вы создаете что-то вроде диагностического движка, который работает на основе журнала программы, это может быть более подходящим.

Редактировать:

Я бы сказал, что текущая идея реализации подходит для того, что вы делаете.Что-нибудь гораздо большее, и я думаю, вы, вероятно, рискуете перепроектировать решение.Кажется, он фиксирует то, что вы хотите, сопоставляя сообщения журнала только на основе нескольких различных критериев.

Единственное место, которое отличается от самого синтаксиса Python, - это message ~ "program\\[\d+\\]: message" часть, поэтому мне интересно, действительно ли вам нужен новый синтаксис.

Обновить: Хорошо, у вас есть либо проблемы с удобством использования, либо с безопасностью - это разумно.Пара предложений:

  • Воспользуйтесь подсказкой из Awk и оптимизируйте синтаксис сопоставления с шаблоном, например /program\[\d+\]: message/ вместо того , чтобы message ~ "program\\[\d+\\]: message".

  • Я бы реализовал это, переведя в выражение Python по мере анализа входных данных, вместо построения дерева объектов для оценки, если только вы не ожидаете, что будете выполнять больше операций над этими вещами, чем вычисление.Для этого должно потребоваться меньше кода и выполняться быстрее.Верхний уровень может выглядеть примерно так:

    def compile(input):
    return eval('lambda message, severity: %s' % parse(input))

Еще одна идея, более отдаленная:напишите свое приложение на Lua.Он предназначен для непрограммистов, позволяющих достаточно безопасно расширять программы без необходимости многому учиться.(Мне сказали, что он успешно использовался таким образом, и вы можете выполнять оценку в изолированной среде, чтобы пользовательский код не мог получить доступ к каким-либо возможностям, которые вы не передаете ему явно.)

Теперь я заткнусь.:-) Удачи!

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top