Для явного включения или выключения ведения всех событий используйте элемент log в фильтре:

{
  "filter": { "log": true }
}

Значение log может быть либо true, либо false.

Представленный фильтр включает ведение всех событий. Он эквивалентен:

{
  "filter": { }
}

Поведение ведения зависит от значения log и от того, указаны ли элементы class или event:

Для ведения событий определенного класса используйте элемент class в фильтре, где поле name указывает имя класса для ведения:

{
  "filter": {
    "class": { "name": "connection" }
  }
}

Значение name может быть connection, general или table_access для ведения событий подключения, общих событий или событий доступа к таблицам соответственно.

Представленный фильтр включает ведение событий класса connection. Это эквивалентно следующему фильтру с явными элементами log:

{
  "filter": {
    "log": false,
    "class": { "log": true,
               "name": "connection" }
  }
}

Для включения ведения нескольких классов задайте значение class как элемент массива JSON, содержащий имена классов:

{
  "filter": {
    "class": [
      { "name": "connection" },
      { "name": "general" },
      { "name": "table_access" }
    ]
  }
}

{
  "filter": {
    "class": [
      { "name": [ "connection", "general", "table_access" ] }
    ]
  }
}

Для выбора определенных подклассов событий используйте элемент event, содержащий элемент name с именами подклассов. По умолчанию события, выбранные элементом event, ведётся. Например, этот фильтр включает ведение для указанных подклассов событий:

{
  "filter": {
    "class": [
      {
        "name": "connection",
        "event": [
          { "name": "connect" },
          { "name": "disconnect" }
        ]
      },
      { "name": "general" },
      {
        "name": "table_access",
        "event": [
          { "name": "insert" },
          { "name": "delete" },
          { "name": "update" }
        ]
      }
    ]
  }
}

Элемент event также может содержать явные элементы log, чтобы указать, нужно ли вести события, которые соответствуют условиям. Этот элемент event выбирает несколько событий и явно указывает поведение ведения для них:

"event": [
  { "name": "read", "log": false },
  { "name": "insert", "log": true },
  { "name": "delete", "log": true },
  { "name": "update", "log": true }
]

Начиная с MySQL 5.7.20, элемент event также может указать, следует ли блокировать соответствующие события, если он содержит элемент abort. Подробности см. в разделе Блокирование выполнения определенных событий.

Таблица 6.26, «Комбинации классов и подклассов событий» описывает допустимые значения подклассов для каждого класса событий.

Таблица 6.27, «Характеристики ведения и прерывания по каждой комбинации класса и подкласса события» описывает для каждого подкласса события, можно ли его вести или прервать.

Фильтр может быть определён в режиме включения или исключения:

Для выполнения включительного ведения журнала, отключите ведение журнала глобально и включите ведение журнала для определённых классов. Этот фильтр регистрирует connect и disconnect события в классе connection, и события в классе general:

{
  "filter": {
    "log": false,
    "class": [
      {
        "name": "connection",
        "event": [
          { "name": "connect", "log": true },
          { "name": "disconnect", "log": true }
        ]
      },
      { "name": "general", "log": true }
    ]
  }
}

Для выполнения исключительного ведения журнала, включите ведение журнала глобально и отключите ведение журнала для определённых классов. Этот фильтр регистрирует всё, кроме событий в классе general:

{
  "filter": {
    "log": true,
    "class":
      { "name": "general", "log": false }
  }
}

Этот фильтр регистрирует change_user события в классе connection и table_access события, в силу того, что не регистрирует всё остальное:

{
  "filter": {
    "log": true,
    "class": [
      {
        "name": "connection",
        "event": [
          { "name": "connect", "log": false },
          { "name": "disconnect", "log": false }
        ]
      },
      { "name": "general", "log": false }
    ]
  }
}

Для включения регистрации на основе определённых значений полей событий, укажите элемент field внутри элемента log, который указывает имя поля и его ожидаемое значение:

{
  "filter": {
    "class": {
    "name": "general",
      "event": {
        "name": "status",
        "log": {
          "field": { "name": "general_command.str", "value": "Query" }
        }
      }
    }
  }
}

Каждое событие содержит поля, специфичные для класса события, к которым можно получить доступ в фильтре для выполнения пользовательской фильтрации.

Событие в классе connection указывает, когда во время сессии происходит активность, связанная с подключением, например, когда пользователь подключается к серверу или отключается от него. Таблица 6.28, «Поля событий подключения» указывает разрешённые поля для событий connection.

Значения "::xxx" — это символические псевдоконстанты, которые могут быть указаны вместо буквальных числовых значений. Они должны быть указаны в виде строк и чувствительны к регистру.

Событие в классе general указывает код состояния операции и её детали. Таблица 6.29, «Общие поля событий» указывает разрешённые поля для событий general.

general_command.str указывает имя команды: Query, Execute, Quit или Change user.

Событие general с полем general_command.str, установленным в Query или Execute, содержит general_sql_command.str, установленное на значение, определяющее тип SQL-команды: alter_db, alter_db_upgrade, admin_commands и так далее. Доступные значения general_sql_command.str можно увидеть как последние компоненты инструментов Performance Schema, отображаемых данным запросом:

mysql> SELECT NAME FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'statement/sql/%' ORDER BY NAME;
+---------------------------------------+
| NAME                                  |
+---------------------------------------+
| statement/sql/alter_db                |
| statement/sql/alter_db_upgrade        |
| statement/sql/alter_event             |
| statement/sql/alter_function          |
| statement/sql/alter_instance          |
| statement/sql/alter_procedure         |
| statement/sql/alter_server            |
...

Событие в классе table_access предоставляет информацию о конкретном типе доступа к таблице. Таблица 6.30, «Поля событий доступа к таблице» указывает разрешённые поля для событий table_access.

В следующей таблице показано, какие запросы генерируют события доступа к таблицам:

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

Элемент должен появляться внутри элемента. Например:

"event": {
  "name": qualifying event subclass names
  "abort": condition
}

Для подклассов событий, выбранных элементом, действие равно true или false, в зависимости от оценки. Если условие оценивается как true, событие блокируется. В противном случае событие продолжает выполняться.

Спецификация может быть простой, например, или , или может быть более сложной, так что оценка зависит от характеристик события.

Этот фильтр блокирует запросы INSERT, запросы UPDATE и запросы DELETE:

{
  "filter": {
    "class": {
      "name": "table_access",
      "event": {
        "name": [ "insert", "update", "delete" ],
        "abort": true
      }
    }
  }
}

Этот более сложный фильтр блокирует те же запросы, но только для определённой таблицы ():

{
  "filter": {
    "class": {
      "name": "table_access",
      "event": {
        "name": [ "insert", "update", "delete" ],
        "abort": {
          "and": [
            { "field": { "name": "table_database.str", "value": "finances" } },
            { "field": { "name": "table_name.str", "value": "bank_account" } }
          ]
        }
      }
    }
  }
}

Запросы, соответствующие фильтру и заблокированные им, возвращают ошибку клиенту:

ERROR 1045 (28000): Statement was aborted by an audit log filter

Не все события могут быть заблокированы (см. Таблица 6.27, «Логирование и отмена по комбинациям класса и подкласса события»). Для события, которое нельзя заблокировать, журнал аудита запишет предупреждение в журнал ошибок вместо блокировки.

Для попыток определить фильтр, в котором элемент появляется не внутри элемента, возникает ошибка.

Логические операторы ( , , ) позволяют создавать сложные условия, что позволяет создавать более сложные конфигурации фильтрации. Следующий элемент регистрирует только события с полями, имеющими определенное значение и длину:

{
  "filter": {
    "class": {
      "name": "general",
      "event": {
        "name": "status",
        "log": {
          "or": [
            {
              "and": [
                { "field": { "name": "general_command.str",    "value": "Query" } },
                { "field": { "name": "general_command.length", "value": 5 } }
              ]
            },
            {
              "and": [
                { "field": { "name": "general_command.str",    "value": "Execute" } },
                { "field": { "name": "general_command.length", "value": 7 } }
              ]
            }
          ]
        }
      }
    }
  }
}

Для ссылки на предопределённую переменную в условии используйте элемент, который принимает элементы и элементы и проверяет равенство именованной переменной заданному значению:

"variable": {
  "name": "variable_name",
  "value": comparison_value
}

Это верно, если имеет значение , в противном случае — ложно.

Пример:

{
  "filter": {
    "class": {
      "name": "general",
      "event": {
        "name": "status",
        "log": {
          "variable": {
            "name": "audit_log_connection_policy_value",
            "value": "::none"
          }
        }
      }
    }
  }
}

Каждая предопределённая переменная соответствует системной переменной. Написав фильтр, проверяющий предопределенную переменную, можно изменить работу фильтра, установив соответствующую системную переменную, без переопределения фильтра. Например, написав фильтр, проверяющий значение предопределённой переменной , можно изменить работу фильтра, изменив значение системной переменной .

Системные переменные используются для журнала аудита в режиме обратной совместимости (см. Раздел 6.4.5.10, «Фильтрация журнала аудита в режиме обратной совместимости»). В фильтрации журналов аудита на основе правил эти переменные остаются видимыми (например, с помощью ), но изменения в них не имеют эффекта, если вы не используете конструкции, ссылающиеся на них.

Следующий список описывает разрешённые предопределённые переменные для элементов:

Для ссылки на предопределённую функцию в условии log используйте элемент function, который принимает элементы name и args для указания имени функции и её аргументов соответственно:

"function": {
  "name": "function_name",
  "args": arguments
}

Элемент name должен содержать только имя функции без скобок и списка аргументов.

Элемент args должен удовлетворять следующим условиям:

Если количество аргументов неверно или типы аргументов не соответствуют требованиям функции, возникает ошибка.

Пример:

{
  "filter": {
    "class": {
      "name": "general",
      "event": {
        "name": "status",
        "log": {
          "function": {
            "name": "find_in_include_list",
            "args": [ { "string": [ { "field": "user.str" },
                                    { "string": "@"},
                                    { "field": "host.str" } ] } ]
          }
        }
      }
    }
  }
}

Предыдущий фильтр определяет, нужно ли регистрировать события класса general status в зависимости от того, найден ли текущий пользователь в системной переменной audit_log_include_accounts. Этот пользователь создаётся с помощью полей в событии.

В следующем списке описаны разрешённые предопределённые функции для элементов function:

В некоторых случаях определение фильтра может динамически изменяться. Для этого определите конфигурацию filter внутри существующего элемента filter. Например:

{
  "filter": {
    "id": "main",
    "class": {
      "name": "table_access",
      "event": {
        "name": [ "update", "delete" ],
        "log": false,
        "filter": {
          "class": {
            "name": "general",
            "event" : { "name": "status",
                        "filter": { "ref": "main" } }
          },
          "activate": {
            "or": [
              { "field": { "name": "table_name.str", "value": "temp_1" } },
              { "field": { "name": "table_name.str", "value": "temp_2" } }
            ]
          }
        }
      }
    }
  }
}

Новый фильтр активируется, когда элемент activate внутри подфильтра принимает значение true. Использование элемента activate в верхнем уровне filter не разрешено.

Новый фильтр может быть заменён исходным с помощью элемента ref внутри подфильтра для ссылки на исходный фильтр id.

Работа показанного фильтра выглядит следующим образом:

Фильтр полезен для регистрации заявлений, которые обновляют или удаляют что-либо из таблиц temp_1 или temp_2, например, такой:

UPDATE temp_1, temp_3 SET temp_1.a=21, temp_3.a=23;

Заявление генерирует несколько событий table_access, но в файле аудиторного журнала содержатся только записи general или status.