マシンデータとロギング全般の進化は、過去XNUMX年間で何度も変化しています。 ログはUnixで始まり、tailやgrepなどのコマンドラインアクションに基づいていました。 システムベースのログからアプリケーションベースのログに進化し、最終的にはUIに適した読みやすいものになりました。 ログ自体が進化しただけでなく、ログの目的とログの対象者も時間の経過とともに変化しました。 最初のユーザーは開発者でしたが、問題を切り分けて診断する手段として、最終的には運用チームに移行しました。 最終的に、サイバー脅威とハッキングにより、ログはセキュリティセンターの真ん中に着陸し、過去XNUMX年間でログの状況を支配し、XNUMX億ドル規模の業界とセキュリティ情報およびイベント管理（SIEM）の概念を生み出しました。 勢いを増している新しい移行が進行中であり、日々のオペレーションセンターのワークフローでログが再び出現することで、移行し続けるログが完全に一巡します。
ログの歴史
Splunkの前の世界では、「再起動するとすべてが修正される」という古い格言が、最前線のトラブルシューティング作業の中で王様でした。 もうXNUMXつの実証済みの方法は、サービスを停止/開始し、指を交差させてリソースをバウンスすることです。これにより、ファイアファイト中の問題が解決されます。 問題が再発するか、再起動が解決しない場合にのみ、管理者はログに飛び込みました。
当時、丸太は気弱な人向けではありませんでした。 それらは冗長ではなく、内容が無視されることが多く、開発ライフサイクルの重要な部分とは見なされていませんでした。 ほとんどのログのトラブルシューティングでは、実際の開発者がログを解釈する必要がありました。これにより、運用チームがログにアクセスするのが複雑になり、意欲が高まりました。
ログの強化
次のシフトは、マシンデータの認識が高まり、停止を調査し、開発チーム以外の根本原因を見つけるための重要な要素であることが判明したときに発生しました。 開発者は、ログの形式の標準化を開始しました。 RFC準拠も出現し、受け入れられたタイムスタンプと基本情報、セッションID、およびホスト情報がすべてのタイプのログに含まれるようになりました。
これは、ログレベルの概念が登場したのと同じ時間枠でもあります。 ログ自体は、デバッグレベル、情報、警告、エラー、またはクリティカルとして分類されるようになりました。これは、トラブルシューティング担当者が焦点を絞るのに役立ちます。 開発者がロギングにさらに焦点を合わせ始めると、このプロセスは最終的に開発ライフサイクルの重要なチェックボックスとなり、DevOps方法論の重要な要素になりました。 これらすべてのログの強化により、業界ではデータ量が爆発的に増加しました。 ログを実際に理解して使用するために、物事はすぐに人間の消費を超えてしまいました。 ロギングフレームワークに対するこれらの機能強化により、運用チームは開発者を常に関与させることなく、根本原因を自分で探すことができるようになりましたが、これらのログの取り込みおよび分析ツール、検索機能、解析、および集中ストレージの必要性も高まりました。 。
運用からセキュリティへの移行
サイバーセキュリティ、データ侵害、攻撃が標準になると、ログの次のピボットはNOCから移動し、SOCとSIEMSの出現を後押ししました。 企業は、業界とその顧客ベースの間で自分たちをカバーし、調査し、うまくいけば良い恵みを維持する手段として、ロギングツールに数十億ドルを費やすために競争しました。
企業は、万が一のシナリオに備えて、これらのログの収集、分析、および保存に数十億ドルを投じて、万が一のシナリオに備え、脅威の捜索を支援しています。 このデータとそれらが存在するツールの制御は、運用からセキュリティに移行しました。 これらすべてにおいて、NOCオペレーターとシステム管理者は取り残され、停止や問題を解決するために最初にログインする理由全体が失われました。
現在、セキュリティチームはこれらのツールを所有しています。 それらはそれらをロックし、アクセスは制限され、管理者にアクセス権が与えられたとしても、クエリ言語を十分に理解して10万イベントから10イベントに移行するための学習曲線は耐え難いものです。 最前線のチームは、ログを避けて、開始した場所に戻っています。 代わりに、問題が解決することを期待して、指を交差させてサービスを再起動またはバウンスしようとしています。解決しない場合は、再発しないことを期待しています。
さらに悪いことに、それは再び起こり、今あなたはしぶしぶログに強制されます。 次のステップは、多くの場合面倒で、通常は手動です。 手動モードでは、RDP、termserv、またはボックスへのリモート接続が必要であり、資格情報が不可欠になります。 次に、タイムスタンプが異なる数十のログファイルのうち、調査に必要なものを決定します。 次は、ログファイルをダウンロードし、圧縮または解凍することです。そうすれば、本当の楽しみが始まります。 ファイル自体を開き、ctrl + f、grep、またはtailコマンドを実行して、ログの背後にある技術の専門知識がない人にはあまり意味のない不可解なエラーコードを見つけます。 その場合は、Tier 2、3、またはそれ以降にエスカレーションし、コピーして貼り付けてから、さらに分析するためにアプリまたは開発チームに発送します。 針のスタックでいわゆる針を見つけたとしても、コンテキストがなく、トリガーされたメトリックやモニターのしきい値、またはアップストリームまたはダウンストリームの接続、デバイス、またはコンテナーとの関係がありません。 この概念全体は、付加価値のないエンジニアリング時間として知られており、どのようにスライスしてもコストがかかります。 その間、MTTRはすべり落ちています。
運用の焦点をログに戻す
LogicMonitorの LMログ また、その異常検出機能により、運用上の焦点がログに戻ります。 インターフェースのアラートおよび通知ペインでは、停止をリアルタイムでトラブルシューティングするときに、相関するログとメトリックを80つのガラスペインにまとめて表示でき、最大XNUMX％を促進します。 MTTRの改善.
LMログでは、高度なクエリは必要ありません。 ログはシンプルで簡単に取り込むことができ、LogicMonitorにすでに存在する監視対象デバイスにマッピングされます。 AIと異常検出が最初の作業を行うため、使いやすさが重要であり、クエリ言語の学習曲線は必要ありません。 さらに、ログに手動でアクセスするために、付加価値のないエンジニアリング時間を必要としません。
基本的なログのユースケースを超えて、アーリーアダプターは、問題が再発した場合にリアルタイムの通知を受け取るために、パイプラインアラートにすばやく頼ってログ条件に基づいて通知をトリガーしました。 チームはまた、異常ビューをすばやく活用しています。 チームとの毎週のレビューでこの情報を使用して、これらの異常をパイプラインアラートに変換して、再び発生するイベントをリアルタイムで可視化する必要があるかどうかを話し合うことができます。
ほんの短い時間で、SIEMまたはセキュリティベースのツールをすでに持っているにもかかわらず、大小の顧客がLMログを運用固有のログツールとして活用しているのを目にしました。 Opsのログ。
SIEMは今後も存続し、セキュリティにおけるログの重要性は依然として重要ですが、ログの進化は完全にオペレーションセンターに戻ってきています。 LogicMonitorとLMLogsは、そのシフトの真っ只中にあります。
