事前フィルタリングは、パフォーマンススキーマによって行われ、すべてのユーザーに適用されるグローバルな効果を持ちます。 事前フィルタリングは、イベント処理のプロデューサまたはコンシューマステージに適用できます。

これらのテーブルのいずれかを変更すると、すぐに監視に影響しますが、setup_actors テーブルを変更すると、変更後に作成されたフォアグラウンドスレッドにのみ影響し、既存のスレッドには影響しません。

モニタリング構成を変更すると、パフォーマンススキーマは履歴テーブルをフラッシュしません。 すでに収集されたイベントは、新しいイベントによって置き換えられるまで、現在のイベントと履歴テーブルに残ります。 インストゥルメントを無効にする場合、それらのイベントが関心のある新しいイベントによって置き換えられるまで、しばらく待つ必要がある場合があります。 または、TRUNCATE TABLE を使用して、履歴テーブルを空にします。

インストゥルメンテーションの変更後、サマリーテーブルを切り捨てることが必要になる場合があります。 一般に、サマリーカラムは行を削除するのではなく、0 または NULL にリセットされます。 これにより、収集された値をクリアし、アグリゲーションを再開できます。 それは、実行時構成の変更を行なったあとなどに便利な場合があります。 この切捨て動作の例外は、個々のサマリーテーブルのセクションに記載されています。

次のセクションでは、特定のテーブルを使用して、パフォーマンススキーマの事前フィルタリングを制御する方法について説明します。