0

3306 の mysql ポートを監視するために packetbeat を使用していますが、非常にうまく機能しています。ディスカバリータブで任意の単語を簡単に検索できます。例えば

method:SET

これは期待どおりに機能します。しかし、私がそれを変更すると

query:SET

その場合、クエリ フィールドに「SET」という単語が含まれるドキュメントは返されません。クエリ フィールドのインデックスは異なりますか? 「クエリ」フィールドを検索可能にするにはどうすればよいですか?

アップデート：

これは、すべての文字列フィールドに使用されるパラメーター「ignore_above」が原因ですか? このAPIを使用してマッピングを確認しました...

GET /packetbeat-2018.02.01/_mapping/mysql/

この制限を取り除き、今後のすべてのビートをクエリ フィールドのインデックスにするにはどうすればよいですか?

更新 2:

「クエリ」フィールドに基づく検索で文字列全体に言及すると、期待どおりに機能します...

query:"SELECT name, type, comment FROM mysql.proc WHERE name like 'residentDetails_get' and db <=> 'portal' ORDER BY name, type"

これにより、過去 15 分間の 688 レコードすべてが返されます。以下を検索すると、さらに多くの情報が得られると思います...

query:"SELECT"

しかし、私は単一のレコードを取得しません。これは、ドキュメントのインデックス作成方法によるものだと思います。SQL に相当するものを取得することを好みます: query like '%SELECT%'

4

2 に答える 2

1

クエリとフィールドのマッピングを考えると、これは正しい動作です。そして、それは 1024 制限に関するものではありません。一部を省略query:して、Elasticsearch が_allフィールドを使用するようにすることもできますが (これは近い将来削除されます)、ここでは使用するスタックのバージョンによって異なります。

または、より適切でより正しいアプローチは、次のようになるように (次のインデックスが新しいマッピングを使用するように) packetbeat テンプレートでクエリ フィールドを別の方法で構成することです。

    "query": {
      "type": "text",
      "fields": {
        "raw": {
          "type": "keyword",
          "ignore_above": 1024
        }
      }
    }

主なアイデアは、ES がクエリ フィールドの値を分割していないことです (これは であるためkeyword)。これを行う方法が必要です。ワイルドカードを使用することもできますが、ES はそれら (特に主要なワイルドカード) を好まず、そのようなクエリを実行するとパフォーマンスの問題が発生する可能性があります。ES の観点からの「正しい」アプローチは、私がすでに述べたものです。フィールドを分析し、その生のバージョン (並べ替えと集計用) と検索用の単純なバージョンを保持します。

于 2018-02-11T06:05:31.540 に答える