5

ログ ファイルの解析が必要なプロジェクトに取り組んでいます。次のようなグループメッセージを受け取る高速なアルゴリズムを探しています:

P1 の温度は華氏 35 度です。

P1 の温度は 40F です。

P3 の温度は華氏 35 度です。

ロガーが停止しました。

ロガーを開始しました。

P1 の温度は 40F です。

printf() の形式で何かを出力します。

"The temperature at P%d is %dF.", Int1, Int2" 
{(1,35), (1, 40), (3, 35), (1,40)}

アルゴリズムは、メッセージ グループ内のほぼすべてのデータ ロードを認識できるように十分に汎用的である必要があります。

この種のテクノロジーを検索してみましたが、検索する正しい用語もわかりません。

4

10 に答える 10

12

fscanf() と sscanf() を見落としている可能性があると思います。fprintf() と sprintf() の反対です。

于 2008-08-13T14:28:26.397 に答える
6

概要：

ナイーブ!! アルゴリズムは、単語の頻度を列ごとに追跡します。この場合、各行は区切り記号で列に分割できると想定できます。

入力例:

犬が月を
飛び越えた 猫が月を
飛び越えた 月が月を飛び越えた
車が 月を飛び越えた

周波数:

Column 1: {The: 4}
Column 2: {car: 1, cat: 1, dog: 1, moon: 1}
Column 3: {jumped: 4}
Column 4: {over: 4}
Column 5: {the: 4}
Column 6: {moon: 4}

フィールドの総数に基づいてグループ化することで、これらの頻度リストをさらに分割することもできますが、この単純で便利な例では、一定数のフィールド (6) のみを使用しています。

次のステップは、これらの頻度リストを生成した行を反復処理することです。最初の例を見てみましょう。

  1. : はいくつかの手動の基準を満たし、アルゴリズムはそれが静的でなければならないと判断します。
  2. dog : 残りの頻度リストに基づいて静的ではないように見えるため、静的テキストではなく動的でなければなりません。いくつかの事前定義された正規表現をループして、/[a-z]+/i.
  3. オーバー: #1 と同じ取引。静的なので、そのままにしておきます。
  4. the : #1 と同じ取引。静的なので、そのままにしておきます。
  5. moon : #1 と同じ。静的なので、そのままにしておきます。

したがって、最初の行を確認するだけで、次の正規表現をまとめることができます。

/The ([a-z]+?) jumps over the moon/

考慮事項:

  • 明らかに、頻度リストがデータ全体の十分なサンプリングになると確信している限り、最初のパスでドキュメントの一部または全体をスキャンすることを選択できます。

  • 偽陽性が結果に忍び寄る可能性があり、静的フィールドと動的フィールドの間の最適なしきい値を提供するのはフィルタリング アルゴリズム (手を振っている)、または人間による後処理に依存します。

  • 全体的なアイデアはおそらく良いものですが、実際の実装は、このアルゴリズムの速度と効率に大きく影響します。

于 2008-08-15T16:45:12.813 に答える
3

すべての素晴らしい提案をありがとう。クリス そうです。あらゆる種類のテキストを正規化するための一般的なソリューションを探しています。問題の解決策は、2 つ以上の類似した文字列のパターンを動的に見つけることです。前の 2 つの要素に基づいて、セット内の次の要素を予測するのとほとんど同じです。

1: エベレストの高さは 30000 フィート

2: K2 の高さは 28000 フィート

=> パターンは何ですか? => 答え:

[name] は [number] フィートの高さです

テキスト ファイルには、数百万の行と数千のパターンを含めることができます。ファイルを非常に高速に解析し、パターンを見つけて、各パターンに関連付けられているデータ セットを収集したいと考えています。

メッセージ文字列のパターンを表現するために、いくつかの高レベルのセマンティック ハッシュを作成することを考えました。トークナイザーを使用して、各トークン タイプに特定の「重み」を与えます。次に、ハッシュをグループ化し、それらの類似性を評価します。グループ化が完了したら、データセットを収集します。

私は車輪を再発明する必要がなく、すでにそこにあるものを再利用できることを望んでいました.

クラウス

于 2008-08-15T15:00:43.553 に答える
2

目的が sprintf() 入力をすばやく生成することである場合、これは機能します。データを解析しようとしている場合は、おそらく正規表現も使用できます..

于 2008-08-13T15:52:09.300 に答える
1

単純に任意の入力を受け取り、そこから必要なデータを推測し、必要な出力を生成できるツールを見つけることはできません。それは私には強いAIのように聞こえます。

このようなものを作成することは、数字を認識するためだけでも、非常に厄介になります。たとえば、「123.456」は1つまたは2つですか？この「123,456」はどうですか？「35F」は10進数と「F」ですか、それとも16進値0x35Fですか。必要な方法で解析できるものを作成する必要があります。これは正規表現を使用してsscanf行うことも、、を使用して行うことも、他の方法で行うこともできますが、カスタムで何かを作成する必要があります。

ただし、基本的な正規表現を使用すると、これを自分で行うことができます。魔法ではありませんが、それほど手間はかかりません。このようなものは、あなたが興味を持っている行を解析し、それらを統合します（Perl）：

my @vals = ();
while (defined(my $line = <>))
{
    if ($line =~ /The temperature at P(\d*) is (\d*)F./)
    {
        push(@vals, "($1,$2)");
    }
}
print "The temperature at P%d is %dF. {";
for (my $i = 0; $i < @vals; $i++)
{
    print $vals[$i];
    if ($i < @vals - 1)
    {
        print ",";
    }
}
print "}\n";

このisLからの出力

The temperature at P%d is %dF. {(1,35),(1,40),(3,35),(1,40)}

解析する必要のある行のタイプごとに、同様のことを行うことができます。それぞれをカスタムコーディングする代わりに、ファイルからこれらの正規表現を読み取ることもできます。

于 2008-08-14T02:25:16.637 に答える
1

それを行うための特定のツールについては知りません。同様の問題を解決する必要があるときに私がしたことは、正規表現を推測して行に一致させようとすることでした。

次に、ファイルを処理し、一致しない行のみを表示しました。行が一致しない場合は、パターンが間違っているため、微調整するか、別のパターンを追加する必要があることを意味します。

約 1 時間の作業の後、10000 行以上に一致する ~20 のパターンを見つけることに成功しました。

あなたの場合、最初に 1 つのパターンが"The temperature at P[1-3] is [0-9]{2}F.". 一致する行を削除してファイルを再処理すると、「のみ」が残ります。

ロガーが停止しました。

ロガーを開始しました。

と一致させることができます"Logger (.+)."。

その後、パターンを改良し、ログ全体に一致する新しいパターンを見つけることができます。

于 2008-08-15T15:32:17.873 に答える
0

@John：質問は、ログファイルのパターンを実際に認識し、適切な形式の文字列とデータを自動的に「推測」するアルゴリズムに関連していると思います。*scanf家族はそれを自分で行うことはできません。パターンが最初に認識されて初めて助けになります。

于 2008-08-14T02:01:34.000 に答える
0

@Derek Park：ええと、強力なAIでさえ、正しい答えがあるかどうか確信が持てませんでした。

おそらく、圧縮のようなメカニズムを使用できます。

  1. 大きくて頻繁な部分文字列を見つける
  2. 大きくて頻繁な部分文字列パターンを見つけます。（つまり、[パターン：1][ジャンク][パターン：2]）

考慮すべきもう1つの項目は、edit-distanceで行をグループ化することです。同様の行をグループ化すると、問題がグループごとに1つのパターンのチャンクに分割されます。

実は、これをなんとか書けたら、全世界に知らせてください。私たちの多くがこのツールを望んでいると思います！

于 2008-08-15T18:01:45.187 に答える
0

@アンダース

まあ、強力なAIでさえ、それが正しい答えを持っているかどうかを確信することはできませんでした。

私は、十分に強力なAIは、通常、コンテキストから正しい答えを見つけることができると考えていました。たとえば、強力なAIは、このコンテキストでの「35F」は温度であり、16進数ではないことを認識できます。確かに強いAIでも答えられない場合があります。ただし、これらは人間が答えることができない場合と同じです（非常に強力なAIを想定しています）。

もちろん、私たちは強力なAIを持っていないので、それは実際には問題ではありません。:)

于 2008-08-15T18:11:42.263 に答える
0

http://www.logparser.comは、かなり活発な IIS フォーラムに転送されます。これは、Gabriele Giuseppini の「ログ パーサー ツールキット」の公式サイトです。私はこのツールを実際に使用したことはありませんが、Amazon マーケットプレイスから安い本を手に入れました。ページをめくるだけの枯れ木インターフェースに勝るものはありません。

このフォーラムをざっと見ただけで、 http://www.lizardl.com/ にある「MS Log Parser の新しい GUI ツール、Log Parser Lizard」について聞いたことがありませんでした。

もちろん、重要な問題は GRAMMAR の複雑さです。用語が一般的に使用されているように、任意の種類のログパーサーを使用するには、スキャン対象を正確に知る必要があります。そのための BNF を作成できます。何年も前に、私は Aho-and-Ullman の "Dragon Book" に基づいたコースを受講しました。完全に理解された LALR テクノロジーは、もちろんその CFG を持っていれば、最適な速度を提供できます。

一方で、まったく別の複雑さの順序である AI のようなものに到達している可能性があるようです。

于 2008-09-23T04:33:19.750 に答える