すべてのイベントのロギングを明示的に有効または無効にするには、フィルタで log 要素を使用します:

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

log の値は、true または false のいずれかです。

前述のフィルタは、すべてのイベントのロギングを有効にします。 これは次と同等です:

{
  "filter": { }
}

ロギングの動作は、log の値、および class アイテムと event アイテムのどちらが指定されているかによって異なります:

特定のクラスのイベントをログに記録するには、ログに記録するクラスの名前を示す name フィールドとともに、フィルタで class 要素を使用します:

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

name の値は、それぞれ connection、general または table_access で、接続、一般またはテーブルアクセスイベントをログに記録できます。

前述のフィルタは、connection クラスでのイベントのロギングを有効にします。 これは、明示的に作成された log アイテムの次のフィルタと同等です:

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

複数のクラスのロギングを有効にするには、クラスを指定する JSON 配列要素として class 値を定義します:

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

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

特定のイベントサブクラスを選択するには、サブクラスを指定する name アイテムを含む event アイテムを使用します。 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 }
]

event 項目に abort 項目が含まれている場合は、該当するイベントをブロックするかどうかも指定できます。 詳細は、特定のイベントの実行のブロックを参照してください。

表6.29「イベントクラスとサブクラスの組合せ」 は、各イベントクラスに許可されるサブクラス値を記述します。

表6.30「イベントクラスとサブクラスの組合せごとのログおよび中断特性」 では、イベントサブクラスごとに、ログに記録できるか中断できるかが記述されます。

フィルタは包含モードまたは排他モードで定義できます:

包括的ロギングを実行するには、ロギングをグローバルに無効にし、特定のクラスのロギングを有効にします。 このフィルタは、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 クラス、message イベントおよび 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" }
        }
      }
    }
  }
}

各イベントには、カスタムフィルタリングを実行するためにフィルタ内からアクセスできるイベントクラス固有のフィールドが含まれます。

接続イベントは、ユーザーがサーバーに接続したり、サーバーから切断したりするなど、セッション中に接続関連のアクティビティが発生したときを示します。表6.31「接続イベントフィールド」 は、接続イベントに許可されているフィールドを示します。

"::xxx"値は、リテラルの数値のかわりに指定できるシンボリック擬似定数です。 これらは文字列として引用符で囲む必要があり、大/小文字が区別されます。

一般イベントは、操作のステータスコードとその詳細を示します。表6.32「一般イベントフィールド」 は、一般イベントに許可されているフィールドを示します。

general_command.str はコマンド名を示します: Query, Execute, Quit または Change user。

general_command.str フィールドが Query または Execute に設定された一般イベントには、SQL コマンドのタイプを指定する値に設定された general_sql_command.str が含まれます: alter_db, alter_db_upgrade, admin_commands など。 これらの値は、次のステートメントによって表示されるパフォーマンススキーマインストゥルメントの最後のコンポーネントとして表示できます:

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            |
...

テーブルアクセスイベントは、特定のテーブルアクセスに関する情報を提供します。表6.33「テーブルアクセスイベントフィールド」 は、テーブルアクセスイベントに許可されているフィールドを示します。

次のリストに、どのステートメントがどのテーブルアクセスイベントを生成するかを示します:

event 品目には、適格イベントが実行されないようにするかどうかを示す abort 品目を含めることができます。 たとえば、abort では、特定の SQL ステートメントの実行をブロックするルールを記述できます。

abort 品目は、event 品目内に表示される必要があります。 例:

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

name アイテムによって選択されたイベントサブクラスの場合、abort アクションは condition 評価に応じて true または false です。 条件が true と評価された場合、イベントはブロックされます。 それ以外の場合、イベントは引き続き実行されます。

condition 仕様は、true または false のように単純にすることも、イベント特性に依存するようにより複雑にすることもできます。

このフィルタは、INSERT、UPDATE および DELETE ステートメントをブロックします:

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

この複雑なフィルタは、特定のテーブル (finances.bank_account) に対してのみ同じステートメントをブロックします:

{
  "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.30「イベントクラスとサブクラスの組合せごとのログおよび中断特性」 を参照)。 できないイベントの場合、監査ログは警告をブロックするのではなく、エラーログに書き込みます。

abort アイテムが event アイテム以外の場所に表示されるフィルタを定義しようとすると、エラーが発生します。

論理演算子 (and, or, not) は、log アイテムで使用できます。 これにより、より高度なフィルタリング構成を構築できます:

{
  "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 } }
              ]
            }
          ]
        }
      }
    }
  }
}

log 条件で事前定義済の変数を参照するには、特定の値と等しいかどうかをテストする variable アイテムを使用します:

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

事前定義された各変数は、システム変数に対応します。 事前定義された変数をテストするフィルタを記述することで、フィルタを再定義しなくても、対応するシステム変数を設定してフィルタ操作を変更できます。 たとえば、audit_log_connection_policy_value の事前定義済変数の値をテストするフィルタを記述することで、audit_log_connection_policy システム変数の値を変更することでフィルタ操作を変更できます。

audit_log_xxx_policy システム変数は、レガシーモードの監査ログに使用されます (セクション6.4.5.9「レガシーモード監査ログのフィルタリング」 を参照)。 ルールベースの監査ログフィルタリングでは、これらの変数は表示されたままになりますが (たとえば、SHOW VARIABLES を使用して)、変数を参照する構成を含むフィルタを記述しないかぎり、変更は効果がありません。

次のリストでは、variable 品目に許可されている事前定義済変数について説明します:

log 条件で事前定義済関数を参照するには、function アイテムを使用します。このアイテムは、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" } ] } ]
          }
        }
      }
    }
  }
}

name 項目に指定されている関数は、カッコや引数リストを含まない関数名のみである必要があります。 args アイテムに引数がある場合は、関数の説明にリストされている順序で引数を指定する必要があります。 引数は、事前定義済の変数、イベントフィールド、文字列定数または数値定数を参照できます。

前述のフィルタは、現在のユーザーが audit_log_include_accounts システム変数で見つかったかどうかに応じて、general クラスの status イベントをログに記録するかどうかを決定します。 そのユーザーは、イベントのフィールドを使用して作成されます。

次のリストでは、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 と評価されると、新しいフィルタがアクティブ化されます。 最上位の filter での activate の使用は許可されていません。

サブフィルタ内の ref アイテムを使用して元のフィルタ id を参照することで、新しいフィルタを元のフィルタに置き換えることができます。

表示されるフィルタは次のように動作します:

このフィルタは、次のような temp_1 または temp_2 テーブルに対して更新または削除を行うステートメントをログに記録する場合に役立ちます:

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

このステートメントでは複数の table_access イベントが生成されますが、監査ログファイルには general / status エントリのみが含まれます。