事前フィルタリングは、パフォーマンススキーマによって行われ、すべてのユーザーに適用されるグローバルな効果を持ちます。 事前フィルタリングは、イベント処理のプロデューサまたはコンシューマステージに適用できます。
-
プロデューサステージで事前フィルタリングを構成するには、いくつかのテーブルを使用できます。
setup_instrumentsは使用可能なインストゥルメントを示します。 このテーブルで無効にされているインストゥルメントは、ほかの生成関連セットアップテーブルの内容に関係なく、イベントを生成しません。 このテーブルで有効にされているインストゥルメントは、イベントの生成が許可され、ほかのテーブルの内容に依存します。setup_objectsは、パフォーマンススキーマが特定のテーブルおよびストアドプログラムオブジェクトをモニターするかどうかを制御します。threadsスレッドは各サーバースレッドでモニタリングが有効にされているかどうかを示します。setup_actorsは、新しいフォアグラウンドスレッドの初期モニタリング状態を決定します。
コンシューマステージで事前フィルタリングを構成するには、
setup_consumersテーブルを変更します。 これによって、イベントの送信先が決まります。setup_consumersはイベント生成にも暗黙的に影響します。 指定されたイベントがどの宛先にも送信されない (つまり、消費されない) 場合、パフォーマンススキーマはそれを生成しません。
これらのテーブルのいずれかを変更すると、すぐに監視に影響しますが、setup_actors テーブルを変更すると、変更後に作成されたフォアグラウンドスレッドにのみ影響し、既存のスレッドには影響しません。
モニタリング構成を変更すると、パフォーマンススキーマは履歴テーブルをフラッシュしません。 すでに収集されたイベントは、新しいイベントによって置き換えられるまで、現在のイベントと履歴テーブルに残ります。 インストゥルメントを無効にする場合、それらのイベントが関心のある新しいイベントによって置き換えられるまで、しばらく待つ必要がある場合があります。 または、TRUNCATE TABLE を使用して、履歴テーブルを空にします。
インストゥルメンテーションの変更後、サマリーテーブルを切り捨てることが必要になる場合があります。 一般に、サマリーカラムは行を削除するのではなく、0 または NULL にリセットされます。 これにより、収集された値をクリアし、アグリゲーションを再開できます。 それは、実行時構成の変更を行なったあとなどに便利な場合があります。 この切捨て動作の例外は、個々のサマリーテーブルのセクションに記載されています。
次のセクションでは、特定のテーブルを使用して、パフォーマンススキーマの事前フィルタリングを制御する方法について説明します。