こんにちは。Elevateセッションへようこそ。「メトリクスとログがチョコレートとピーナッツバターよりも優れている理由」についてご説明します。世界のどこにお住まいかによって、チョコレートとピーナッツバターを一度食べたら、もう手放せなくなるようなブランドをご存知かもしれません。ロンドンでは、これを「メトリクスとログがフィッシュアンドチップスよりも優れている理由」と呼んでいると思います。ですから、皆さんがどんな組み合わせであれ、このセッションを通して、メトリクスだけでは不十分で、メトリクスとログが皆さんを満足させる理由を理解していただければ幸いです。本日ご一緒するのは、ログ担当プロダクトマーケティングマネージャーのTom Chavezです。そして、ログ担当プロダクトアーキテクトのPatrickも同席しています。ログについて少し触れ、素晴らしいデモもお見せします。

ログを使用していない理由はたくさんあります。理由の一つは、社内のログにアクセスできない可能性があることです。ログはセキュリティ関連のユースケースで使用されている可能性があります。ログは使用しているマシン上に保存されていないかもしれません。デバイス上に保存されている可能性もあります。

そして、ログにアクセスでき、鍵を持っている人を見つけることは、時々非常に困難です。

ログの量が多すぎるのかもしれません。プラットフォーム上でログを出力するデバイスをすべて把握していると、膨大な量になります。あらゆるデバイスからサーバー、ソフトウェアに至るまで、あらゆるログが大量に蓄積され、それらを保存できる場所がなくなると、管理が大変になります。

企業によっては、ログツールが多すぎて、全てのログを管理できず、そのツールのキーを持つ人を見つけるのに苦労しています。それはセキュリティ担当者かもしれませんし、別のITチームかもしれませんし、リモートチームかもしれません。そして、必要な人、ログ、そして必要な期間にアクセスするのは非常に困難です。

すべてのログにアクセスできるようになったとしても、あまりにも膨大なログに気づくかもしれません。情報ログ、警告ログ、エラーログ、セキュリティログなど、膨大なログデータがあり、社内で使用しているログツールのクエリ言語がわからないとしたら、膨大な作業になってしまいます。そんな時、どうすればいいのでしょうか？

Logic Monitor、LMログ、そしてLM Inspectorプラットフォームのログの優れた点は、運用チーム向けにログを統合していることです。セキュリティログや他の種類のログを参照するのではなく、インフラ内で何が起こっているかを把握するのに役立つログを統合しています。

すべてのログがプラットフォームに統合されているため、トラブルシューティングの時間が 80% 短縮され、成功までの時間が短縮されます。

これらは顧客統計です。これは私たちの推測ではなく、お客様からいただいた数字です。

これらを単一のプラットフォームで提供することで、ログを持っている人を探し、Jiraチケットを発行し、適切な期間を尋ね、ログが手元にない状態で再度問い合わせるといった、これまでの10～40%の時間を節約できます。これは非常に時間の無駄です。他の人、場合によっては別のタイムゾーンの人を待つことになり、結局は何の価値も提供できません。だからこそ、私たちはその時間をお客様に還元できるのです。

ログの量を絞り込むことで、ログ全体に含まれるノイズを削減できます。すべてのログを表示するわけではありません。全体の時間も、デバイス数も表示しませんが、AIエンジンを使用して、現在取り組んでいる問題に関連するログだけに絞り込みます。

LMログ製品は、特に運用チーム向けにログへのアクセスを効率化します。セキュリティは考慮していません。そのため、指標が赤になった場合、その指標に関連するログにすぐにアクセスできます。CPU、サーバー、データベースのダウンなど、インシデントに関連するログの洞察のみが表示され、迅速に根本原因分析に進めます。

当社のAIエンジンは異常検知機能を備えており、ログが正常な動作やデータから、どこで変化したかを探します。誰かが設定を変更したのかもしれませんし、何らかのメトリックが変更されたのかもしれませんし、ログに何か変化が記録されているのかもしれません。当社のAIエンジンは常にログを分析して変化を探し、変化があった際にアラートを発します。これにより、良い変化なのか、悪い変化なのか、それとも通知が必要な変化なのかを判別できます。

そして、これらすべてを、メトリック、アラート、ロジック モニター プラットフォーム内のすべての情報とともに単一のプラットフォームにまとめているため、L 1、L 2、L 3 のエンジニアにとって使い慣れた単一のインターフェイスにまとめることで使いやすさが向上します。また、ログの検索とフィルタリングも L 1 のエンジニアが確認できる場所に既に設定されているため、クエリ バーを使用する必要がありません。クエリ バーは、クエリが必要な場合に使用します。ただし、インシデントが発生した時刻とインシデント発生前の時刻にプリセットされているため、L 1 のエンジニアは、クエリを最初から作成する必要がなく、迅速に問題を解決できます。クエリを最初から作成するのは時間のかかる作業の 1 つです。

私たちはITチームの効率性向上を目指しています。そのため、すべてのログを確認するセキュリティ担当者ではなく、ITユースケースに合わせて価格設定しました。ITチームにとって適切なログのみに焦点を当てています。つまり、高価なログソリューションではありません。Logic Monitorで既に取得しているメトリクスを補完するものです。

保存期間はユースケースに合わせて設定されています。例えば、アプリケーションであれば7日間のログで十分かもしれません。しかし、監査のために保存する必要がある可能性のあるログであれば、最大1年間保存できます。これは、そこまで遡って確認する必要があるチームのニーズを満たすものです。根本原因分析を行う場合は、毎月、あるいは四半期ごとに行うかもしれません。保存期間は1か月と3か月から選択できます。

すべてのログはホットストレージに保存されているため、ディスクにアーカイブされることはありません。テープやGlacierなどにもアーカイブされません。30日単位のログセット全体を参照し、非常に高速に結果を得ることができます。

さらに、当社の自動化システムは、ログの差分や変更を探すクエリを記述することなく、ログ全体にわたって自動的に異常検出を実行します。

当社のプラットフォーム「lm」と「vision」は、様々な方法と場所からログを収集します。既に導入されているコレクターは、Windowsサーバー、Linuxサーバー、デバイスなどからメトリクスを収集しています。

ただし、API を通じてクラウドからログを収集することもできます。AWS、GCP、Azure を使用している場合や、コンテナ内で実行している場合は、API に接続できる可能性があります。

また、システム全体のディスク上にあるログ ファイルも対象になる可能性があり、それらは、fluidd および liquidbit または OTEL コレクターを通じて当社に配信される可能性があります。

ログを作成している SaaS アプリがいくつかある場合、それらを取り込むことができます。

同様に、デバイスをクラウドから管理することもできます。デバイスを直接接続することも、Cisco Meraki、Juniper、そしてVMwareテクノロジーをすべて備えたBroadcomを介して接続することもできます。

最後に、別のログ製品をお持ちの場合、たとえば、セキュリティのために Splunk を使用している場合や、ログの管理などに Cribl を使用している場合は、既存のツールの 1 つから直接、API を介して LogicMonitor にログを送信できます。

それでは、これを LogicMonitor でライブで素晴らしいデモを見せてくれる Patrick にバトンタッチします。

パトリック、持って行ってください。

ここでアラートが発生しました。特定のCiscoファイアウォールから、IPsec集約トンネルのようなビューが表示されています。ログについて最初にデモを行いたいのは、クエリバーに移動してログページをクリックし、クエリをいくつか書いて絞り込むのではなく、メトリクスやアラートデータと照らし合わせてログをどのように活用するかです。トラブルシューティングワークフローに従って、ログデータをメトリクスやアラートデータと照らし合わせて活用し、なぜアラート状態になっているのかを解明したいと考えています。まずは、詳細を掘り下げて確認したいので、ここで「警告」をクリックします。

さて、この情報を開いて、グラフタブに移動しました。概要画面では、基本的に何が起こっているのか、基本的な情報が表示されています。しかし、視覚化されたデータを見て、ここで何が起こっているのか理解したいのです。以前は順調に機能していたのに、その後調子が悪くなって、失敗していることがわかります。

以前は、そういうことはほとんどできませんでした。ロジックモニターは、問題を正確に特定し、検出するのに非常に優れています。つまり、検出に時間がかかるということです。そして、データスループットが正常だったのに今は正常ではない、といったことを教えてくれる、きれいな画像が得られるのです。以前は成功していたのに今は失敗している、といった具合です。

パケットはありましたが、今はなくなりました。素晴らしいデータが大量に得られました。しかし、次にやるべきことは、その理由を理解することです。そして、管理者として、どのようにトラブルシューティングを行うかを決めるポイントがここにあります。
できることはたくさんあります。サーバー自体やリソース自体（この場合はファイアウォール）にアクセスすることもできます。

ログインして、設定を少し調べてみるかもしれません。リソースをバウンスしてみるかもしれません。わかりません。関連するログデータを確認する必要があるかもしれませんが、セキュリティチームやSIM、SOCによってログがロックされているような適切なログツールがありません。

これは、先ほどお話ししたログデータの力と異常検知、そしてノイズ低減を活用できる方法です。ここで示しているのは、紫色の部分は、問題が発生する直前に発生した異常なログイベントがいくつかあることを示しています。これは通常、ログがリアルタイムで記録されるのに対し、メトリクスやプルは一定間隔で記録されるという、非常に良い指標となります。

ここに何が書いてあるか分かります。人間として、5つか6つくらいは読み取れますよね？そんなに多いわけではありません。しかし、これはAIと機械学習によって、発生した異常な事象を絞り込んで提供されたサブセットです。

デモでタブを移動するとわかるように、ログイベントは何千件もあります。しかし、ここでは発生した小さなイベントをいくつかに絞り込んでいます。ざっと目を通すと、いくつかは警告レベルであることが分かります。トンネルが正常に確立されたことは分かります。

しかし、そのトンネルにはトランスフォームセットがありませんでした。わかりましたか？おそらく問題でしょう。そして、ああ、どうなったと思いますか？

交渉は頓挫してしまいました。これが私のミスです。ここで少し説明させてください。ここでの異常性の強みは、問題になりがちな奇妙な点、いわば針山の中の針に焦点を絞ったことです。AIを使って、この情報を変換し、素晴らしい写真やビジュアルではなく、私自身を回転させて理解させています。

これは、興味深い情報や私の根本的な原因になりそうな情報を、エンジンを使って次々と生成し、表示してくれるタイプのデータです。今回のケースでは、まさにその通りでした。
デモの次の部分では、画面が空白で、異常なログアクティビティがないという仮定を立てます。あるいは、異常なログアクティビティは私の問題とは実際には関係がなく、解決策が見つからなかったのかもしれません。そのため、より詳細なトリアージと調査が必要です。

このページでは、これがログデータであることは特に気にしていません。これは私が関心のあるテレメトリ情報なので、これは素晴らしいと思います。しかし、ログデータについて見ていきましょう。ログタブに移動すると、すべてのログ情報を確認できます。そして、ここに表示されているのがそれです。

これをスクロールしていくと、WindowsとWindowsで無限に続くのが分かります。これは、この時間枠で発生した数千のログです。ログの量がかなり安定して流れているのが分かります。繰り返し発生するような情報が多数あるのも分かります。

必要に応じて、ここでフィルタリングして検索を開始できます。これは非常に限定された検索ウィンドウです。

UIの別の部分には完全なクエリ機能があります。しかし、ここでは検索をあまり深く掘り下げる必要はありません。AI駆動型ツールと機械学習機能をいくつか提供し、より使いやすい形式にしていきます。まず最初に、ノイズを絞り込み、最もノイズの多いものを特定したいと考えています。そこで、重複している可能性のあるものがたくさん見つかりました。

これを実行しながら、少し処理を進めていき、その後、Patternsが何をしているのかについてお話しします。これは、これらの様々なトークン化を調べています。これは異常検出で使用されているのと同じアルゴリズムです。ここでは別の目的で使用しています。

ここでの目的は、これがメッセージで、アスタリスクは変更された値を表しています。そうですか？つまり、このログメッセージは同じです。過去30分間で1169回発生しています。

これらの値は変化していますが、メッセージは同じです。ざっと見て、「これはノイズだ。これは私の問題ではない」と判断しました。そこで、カウント数が多いものは無視することにします。

正直に言うと、おそらく私の問題がまさにそこにあるとは思えません。確かに便利ですね。確かに理解できます。将来的には、ログフィルタリングやノイズ除去など、この種のデータを活用できるかもしれません。

しかし、あまり発生していない可能性のあるものについても調べてみたいと思います。ここで、アクセスリスト制御のようなものも見え始めています。誰かが何らかの変更を試みているようです。出口の特定に失敗したようです。つまり、他にもエラーや状況が発生しているということです。これらは症状的なもので、過去に発生したものかもしれませんし、今回の問題と関連している可能性もあります。しかし、今回のことで、あまり目にしない、あまり重要でない項目が明らかになりました。

ログインも確認できました。これは私の会社のものかもしれません。変更した人かもしれませんし、私の設定の問題かもしれません。この人はおそらく頻繁にログインしているので、異常ではありません。

このサービスアカウントは、おそらく複数回、あるいは少なくとも何らかのスケジュールに基づいてログインしているでしょう。つまり、厳密には異常を原因として特定されているわけではありませんが、1件、2件、3件といった頻度の低い事象を表示する方が、数千件単位の事象よりもはるかに興味深く、見やすいのです。ですから、これと無限スクロールホイールを比較してみると、かなり大きな違いが分かります。これは機械学習のもう一つの例であり、それをどのように適用し、異常検出エンジンの逆位相で利用しているかを示しています。

そして最後に、私が「ログ分析」と呼んでいる楽しい機能があります。LogiMarkでは、ロジックログ分析は少し異なる意味を持っています。

これをクリックして、ログ分析セッションを起動します。

そして、これは私にとって素敵な絵を描くことになるでしょう。

これは、ログに表示される否定的な言葉、あるいはいわゆる「不適切な言葉」のライブラリを構築したものです。例えば、「closed」「disconnect」「fail」「terminate」「kill」「die」といった言葉です。約90個の言葉のライブラリを構築し、クエリバーに入力させる代わりに、それらの言葉を確実にキャプチャし、現在対処しようとしている問題のコンテキストに合わせて視覚的に表示します。

この件で一番気に入っているのは、この「感情」にスコアを適用していることです。これは、見つかった否定的な単語の数に基づいています。また、ログレベル自体が重大度1またはクリティカルの場合、それらを合計してこのスコアを計算します。これを最悪のスコアで並べ替えます。最初の例では、これは実際には警告レベルのイベントに過ぎませんでした。

しかし、IPsecの問題が発生し始めた頃、どこで障害が発生し始めたのかは明確に特定できました。ネゴシエーションが失敗した場所はここで確認できます。また、周辺のログも確認しましたが、最もひどいログから始めました。これが最もひどいログです。では、その直前に何が起こったのでしょうか？

その時間帯はどうだったでしょうか？IPsecの問題の根本原因も、適切な設定がされていないことに絞り込みました。つまり、3つの異なるツールセット、異常値、パターンといった3つの異なる方法で問題を絞り込んだのです。そして、これらのキーワードをネガティブに表現し、どのように対処できるかを示しています。

このウィンドウから、見せたいことをいくつか実行したり、プロットして「これは頻繁に発生しているだろうか？」と確認したりすることもできます。そして、一度だけ発生したことが分かります。そして、それは私の障害が発生した時間帯と、数千回も発生しているノイズの多い障害の時間帯の周辺だと分かります。これは、見て、実際に操作できる便利な機能です。また、これらのグラフを操作することもできます。

ですから、断絶は私にとっては興味がないと言えるかもしれません。ですから、断絶を除外して再提出するかもしれません。そして、これで不合格に絞り込んだことになります。そして、ここにある影響やその他の事柄について、別の角度から見ていきます。

これらを操作できるだけでなく、ユーザーディメンションや除外フレーズを使って独自のライブラリを作成することもできます。このライブラリに追加することも可能です。

最後に、もし他の方法がすべて失敗し、追加のコンテキスト情報が必要になった場合、最後に行うべきことは、先ほどまで表示していたアラートからログタブに移動することです。ログタブでは、より詳細なトリアージ、完全なクエリ分析、分析、正規表現、パース、アラートの作成など、様々な操作を実行できます。ここで注目すべき重要な点は、リソース名です。これは以前から表示していたものです。既に入力済みです。また、時間枠が以前の状態まで絞り込まれているため、コンテキストを切り替えて、同じビューと同じような外観を確認しました。

問題が発生するたびにログタブを開いても何も表示されず、コンテキストが全くわからない状態だったのに対し、これは本当に便利な方法です。そして、そこから何か有益な情報を得るためには、ログタブにあらゆる情報を入力しなければなりません。

もう一度、これがワークフローの概要です。

皆様にご理解いただけたようで、私たちもこの件について学ぶことができました。ありがとうございます。

パトリックさん、素晴らしいデモをありがとうございました。ログとメトリクスがプラットフォーム内でどのように連携し、異常検知やパターン検出を実現し、プラットフォーム内のログ全体にわたってパターンを認識できる様子を見ることができて、とても良かったです。

皆さんが出発する前に、皆さんの旅をさらに進めるのに役立つリソースをいくつかご紹介します。
LM Logsの使い方を教育し、学習することに注力しています。毎月「Logs for Lunch」というログウェビナーを開催しているほか、毎月「プロダクトパワーアワー」も開催しており、定期的にログに焦点を当てています。録画版へのリンクはこちらです。「Logs have level up」です。ログと、AIエンジンによるログ分析、クエリトラッキングへの活用方法について最近公開したブログ記事も含め、優れたブログを多数ご用意しています。

ソリューション概要をご用意しました。ご質問がありましたら、Logic Monitorコミュニティでコミュニティにご参加ください。また、お使いの環境でログをまだ有効化していない場合は、営業担当またはカスタマーサクセス担当者にご連絡ください。デモをご覧いただき、環境に最適なログ容量の選定をお手伝いいたします。本日は素晴らしいセッションにご参加いただき、誠にありがとうございました。

ご質問がございましたら、先ほども申し上げたように、お気軽にお問い合わせください。ログやメトリクスについて、そしてそれらがチョコレートとピーナッツバター、フィッシュアンドチップス、あるいはお好きな2品よりも優れている点などについて、ぜひお話しさせていただければ幸いです。