2016-03-24 51 views
2

私は必要な情報をすべて得るために一緒に参加する必要がある2つのログを持っています。 summary.logには、このイベントが私に当てはまるかどうかの指標とともに、私が必要とするフィールドの大半があります。 location.logには、ログをまとめるために一意の識別子とともに必要なフィールドが1つだけあります。フィールドを失うことなくSplunkマップ

最初は、名前が示すようにjoinコマンドを使用すると考えましたが、最初の検索の結果のフィールドはサブサーチ(結合を使用する)で使用できません。それから、私はマップコマンドを発見しました。しかし、マップは今すぐマップから来なかったすべてのフィールドを削除するという副作用があります。後で私はcollectやoutputlookupを使ってフィールドを一時的に保存することができると考えました。しかし、競合条件なしでこのクエリを実行できるようにするには複数の人が必要なので、参照が問題になりません。 collect testmode = true(またはそうではないかもしれませんが)既存のインデックスだけを使用することができます。空のインデックスを作成して、それが空のままであることを確認しません。ちょっとしたオンライン検索の後、私はサブサーチを使わなかった他のコマンドを見つけることができませんでした(したがって、セットはジョインと同じ問題があります)。

オプション1:だから私は、唯一の3つのオプションを考え出すことができ

source=summary.log | xmlkv | search transactionFailed=true 
| join transactionId max=0 [search 
source=summary.log | xmlkv | search transactionFailed=true 
| map search="search source=location.log \"[$transactionId$]\" | eval transactionId=\"$transactionId$\"" 
| rex "(?<locationId>\w+)$" | fields transactionId locationId] 
| table * 

オプション2:

source=summary.log | xmlkv | search transactionFailed=true 
| map search="search source=location.log \"[$transactionId$]\" | eval transactionId=\"$transactionId$\" 
| eval every=\"$every$\" | eval single=\"$single$\" | eval field=\"$field$\" | eval I=\"$I$\" | eval need=\"$need$\"" 
| rex "(?<locationId>\w+)$" | table * 

オプション3:1が正確に同じことを

source=location.log | rex "\[(?<transactionId>.+?)\]" | rex "(?<locationId>\w+)$" 
| map search="source=summary.log \"$transactionId$\" | eval locationId=\"$locationId$\"" 
maxsearches=2147483647 
| xmlkv | search transactionFailed=true | table * 

オプション2回の検索(これがcollectまたはoutputlookupで結果を保存する方法を調べた理由ですが)、これはちょうど問題です簡略化された模擬クエリでは、実際のクエリは複雑で繰り返しが大量のものはDRYではなく、おそらくパフォーマンスが悪いものです。

オプション2は、動作するすべての単一フィールドのリストを必要としますが、面倒です(私は約10フィールドだと思います)。柔軟性はありませんが、フィールドはすぐには変更されないため、要件ではありません。

オプション3は決して終わらないでしょう。大部分のトランザクションは失敗ではなく、マップコマンドは非常に遅いです。いいえ、私は数千を超える必要はありません。上記のmaxsearchesは、文法的にクリーンなアプローチの問題を強調するためのものでした。

すべてが不良です。オプション3はオプションではありません。オプション1はゆっくりで乱雑です。オプション2は面倒ですが、そうでなければ最高です。私はSplunkのドキュメントを検索するのに時間を費やしましたが、私が見逃した関連コマンドがあるかもしれません。私は他の人の質問が自分の問題と同じであるとは思っていませんでした。

mapコマンドのかなり普通の使用例のようですが、内部以外のすべてのフィールドを保持するにはno optionがあります。

結論:このような検索をきれいで妥当な方法で実行する方法はありますか?

私は現在仕事に慣れていませんが、Splunkのバージョンは6.1.8です(これはSplunk Mintではありません)。

+1

実際に(代わりに任意の引数の)それは、「フィールド - *」の使用を必要とする、デフォルトですべてのフィールドを維持するためにマップするためにはるかに多くの意味を作ると思いますそれらを削除します。しかし、これはどういうものではなく、それを行うためにそれを変更することは、下位互換性がない(すなわち、以前に動作していたクエリを中断する)ことはありません。 – SkySpiral7

+0

ちょっとこれまでの解決策を見つけましたか?私は同じ問題にぶつかっています。 – dobbs

+0

@dobbs実際にはありません。私はSplunkのウェブサイトに尋ねたことがないので、試してみる価値があります。しかし、Splunkはうまく設計されていないように見えます。オーバーラップする検索コマンドが多数あり、オーバーラップのない小さめの小さなコマンドでうまくいくでしょう。さらにポイント:私の答えを見てください。 – SkySpiral7

答えて

0

SplunkはSQLのようなものを一緒にパイプすることしかサポートしていませんが、私たちはPL/SQLに似たものを求めています。 Splunkを大幅に変更することなく、これを行うには良い方法ではないということを意味します。

現在のところ、最適な解決策は、アプリに関心のあるすべてを計算させて記録させることです。私の例では夏。ログにlocationIdを含める必要があります。プロダクトになった後は、重要なフィールドをすべて知り、該当する各ログにそれらを入れることは難しくありません(プレプロッドは、QAに基づいて推測する必要があります)。理想的には、それぞれの目的のためにログが必要です:(「?ニューヨークでの一日あたりどのように多くの成功」など)performance.log、security.log、errors.log、businessMetrics.logを素敵なキーに必要なすべてのフィールドを持つそれぞれを値ペア形式。同じフィールドが複数のログにあり、単一のイベントが1つ以上のログをトリガーすることはOKです。すべてうまくいけば、SplunkをElasticsearchのように安くて良いものにすることができます(古いログをJSONに変換するスクリプトを実行する必要があるかもしれません)。

だから、これのSplunk問題の「解決策」は、Splunkの使用しないことです...うん、それはSplunkのための悪い兆候です。 Splunkが本当に輝くためには、ログにアクセスするための事前定義された関数を持つ任意のJavaScript(または別の言語)をサポートする必要があります。しかし、それでも:なぜ非常に複雑な検索が必要ですか?これらのフィールドがすべてログに存在する場合は、それらのフィールドを簡単な場所に配置することもできます。だから、Splunkでさえ、非標準フィールドに関するビジネス上の質問に答えたり、既存のフィールドでは解決できない問題をデバッグするのに役立つだけです(rex、xmlkv、またはspathを使って解析する例の両方)。