このアプリケーションでは、重要な情報をログに記録して、後でデバッグする目的でテキスト ファイルをログに記録します。Splunk を使用すると、注文番号や「オブジェクト参照が見つかりません」タイプのエラーなどのデータ ポイントが既にある場合に、問題を簡単に特定できます。しかし、splunk を使用して問題の全体像を把握するのは困難です。ソフトウェアの実際の問題を特定するには、複数のログ ファイルまたはログ ファイル全体を読み込んで、問題が発生する前にアプリケーションが何をしていたかを確認する必要があります。人間のやり方でログ ファイル全体を読み取ると、実際の問題が発生する前に、アプリケーションが他のデータ ポイントに対してどのように動作したかを特定するのに役立ちます。つまり、splunk のエラーの「本当の根本原因」を確認するのは難しいのです。ソフトウェア開発の分野でのあなたの経験は何ですか。
4 に答える
splunkの質問をするのに適切な場所は
あなたを助ける人々のコミュニティがあるところ...
@Cninrohはほとんどのアカウントで間違っています。私はSplunkで開発に携わっています。
- splunkを使用すると、アプリやログを変更する必要はありません
- 日付のないイベントは正常に機能します。
必要に応じて、検索を作成して根本原因を見つけることができます。必要に応じて検索を作成する必要があります。あなたのデータはわかりませんが、たとえば、以下の検索では、「ディスクエラー」の直前にrootとしてログインしたユーザーが見つかります...
login root [ search disk-error | head 1 | eval latest = _time - 5*60 ] | head 1
異常な値やその他の予期しないものを探すようにアラートを設定することもできるので、問題を積極的に探す必要はありません。彼らはあなたにプッシュすることができます。
人間的な側面を取り除くことは非常に困難です。そうは言っても、私は最近、splunk ロールアウトの開発側を率いる必要があり、少なくともいくつかのニーズを満たす素晴らしいツールがいくつかあります。splunk のビルトイン アラートを使用するのが、これを行う最も簡単な方法です。残念ながら、多くの splunk 関連のものに対する実際の実用的な回答と例が不足しています (つまり、真剣に言うと、Web サービスまたは残りの API のすべての例でセキュリティ保護されていないフラグを指定して curl を使用しないでください)。インターネット。
いずれにせよ、特定の種類のログまたはログ データを見つけるために私が見つけた最も洗練されたソリューションのいくつかは、検索で「rex」コマンドをパイプすることを多用していました。適切なフィールドから適切な情報を抽出するのに役立つ Perl 正規表現を指定します。 これは、splunk の Web サイトの新しいページです。
もちろん、これは、探しているデータがどのフィールドに含まれているかを知っていることを前提としています。残念ながら、インデクサーで正しく設定されていない場合、Windows ログで問題が発生する可能性があります。
Splunkが(説明から判断して)おそらく希望する方法で機能するためには、データのインデックス作成と保存というSplunkのアプローチに合うように、アプリケーションの一部を変更するように「強制」されます。
Splunkは、イベントのインデックスに依存しています。これらのイベントは、システムのさまざまなログからのエラーまたはステータスメッセージです。Splunkインデックスの主なターゲットは日付であるため、日付がないということはインデックスがないことを意味します。これにより、Splunk検索での検索結果が少なくなります。
また、さまざまな状況に応じてさまざまな検索用語のリストまたはチートシートを保持しておくこともお勧めします。そうすれば、後で成功として見つけた結果を簡単に生成できます。
当社では、監視ツールとしてSplunkを使用することを選択したクライアント専用に、特定のバージョンのソフトウェアを作成しました。基本的にこのカスタムアプリケーションと標準アプリケーションの大きな違いは、ログファイルへのすべての書き込みと、「segemtn --time --root cause --user- group--file--action」を使用した論理イベントへの保存に非常に強く依存していることです。 --result --note "これにより、問題をリアルタイムで、以前よりもはるかに少ないコストで見つけて特定することができます。
ログ ファイルを読み取って評価する方法を学ぶ必要があるのと同じように、Splunk を使用して努力を活用する方法を学ぶ必要があります。
1 台のマシンでコードを実行している開発者の場合、1 つのログ ファイルを簡単に読み取って、いつ何が起こったのかを確認できます。そのコードをリリースし、多層アーキテクチャまたは分散アーキテクチャで実行すると、問題を追跡するために、いつどこで何が起こったのかを簡単に追跡できなくなります。本番システムのログにアクセスすることさえできないかもしれません。
これが例です。簡単なキーワード検索でエラーを見つけてください。興味深いイベントのタイムスタンプをクリックします。これにより、Splunk の時間範囲が 1 秒にスナップされます。キーワード検索をクリアして * を入力すると、その 1 秒間のすべてのイベントが表示されます。イベントを表示しているホストとデバイスを、関心のあるシステム/アプリケーションに制限します。
アプリに関連するすべてのシステムからのイベントが 1 つのビューで表示されるようになりました。ルート イベントをキャッチする必要がある場合は、ズーム アウトしてより多くの時間を表示できます。Splunk のデフォルトの逆の時系列順ではなく、上 (古いもの) から下 (新しいもの) へと時系列で読み取りたい場合は、"| reverse" コマンドを使用します。
問題を見つけたら、その検索を Splunk アラートに変換して、後で通知を受け取ることができます。その問題を修正した後、アラートを有効のままにしておくことができます。これにより、修正がすべての状況で 100% 効果的でなかった場合、または次のメジャー/マイナー リリースにロールバックされなかった場合に通知が届きます。