「はい。皆さん、こんにちは。」

LM InVision入門セッションへようこそ。LogicMonitorでプロダクトマネジメント担当副社長を務めているサラ・テリーです。

本日は、エール大学のお客様であるDevin氏をお迎えし、Logic Monitorの活用方法と、それがこれまでの道のりでどのように役立ったかについてお話しいただきます。それでは、Devinさん、簡単に自己紹介をお願いできますか？

もちろんです、サラ。私の名前はデビン・ビアンカレッリです。イェール大学のネットワークエンジニアです。ここに来て3年ちょっとになりますが、ここ2年間はLogic Monitorを使ってイェールITSのコアインフラを監視しています。

素晴らしいですね。イェール大学のインフラについて、そのレイアウトやどのような種類のデバイスが使われているのか、もう少し詳しく教えていただけますか？

はい、もちろんです。Cisco DNA Center、Cisco ICE、Blue Catといった複数のソフトウェアを活用し、IPAMにも活用しています。Logic Monitorを使って監視を一元化することで、全部門がインフラやネットワークの状況を把握できる一元的な拠点を確保しています。Logic Monitorでは、REST APやSNMP MIB、すぐに使えるデータソース、ダッシュボードなどを活用し、他部門とのコミュニケーションやネットワークの状況を可視化しています。

素晴らしいですね。とても参考になりました。まずは、Logic Monitor を使う前はどのような感じだったのか、そして皆さんが感じていた問題点について少し教えていただけますか？

ロジックモニターを使用する前は、非常に時代遅れのネットワーク監視システムを使用しており、ほとんどの場合、pingしか実行できませんでした。ロジックモニターに切り替えたことで、トラブルシューティングの効率が大幅に向上しました。

ネットワーク インフラストラクチャとそのパフォーマンスをより深く理解できるようになります。

当社では、ダッシュボードとユーザーの役割ベースのアクセスに大きく依存しています。これにより、ユーザーは表示が許可されているものだけを表示でき、ネットワークの各部門で何が起こっているかをわかりやすく透明化できます。

素晴らしいですね。分かりました。ロジックモニターではどのような種類のデータを使用していますか？メトリクス、ログ、構成データ、トポロジなどでしょうか？それぞれ詳しく説明していただけますか？

私たちは主にメトリクスに依存しており、構成データも少し使用しています。特にCPUネットワークインターフェースなどのSNMP MIBに大きく依存しています。

DNA CenterやCisco ICEなどのCisco製品にはREST APIを使用しています。また、ServiceNowとCisco Thousand ICEについても少し詳しく調べ、これらの機能についてより深く理解しています。

また、設定を監視するために設定ソースを頻繁に使用しています。24時間ごとに監視するように設定しています。

ロジック モニターは、構成、開始構成、実行構成、場合によってはインベントリを収集し、構成が変更されたかどうかを毎日比較できます。

素晴らしいですね。トラブルシューティングを迅速化するのに役立つデータがたくさんあるようですね。

皆さんはLogic Monitorを日常的にどのように使っているのか、少し詳しく教えていただけますか？普段はトラブルシューティングに使っているのでしょうか？それとも、プロアクティブな視点で使っているのでしょうか？

これは主にプロアクティブな視点です。ロジックモニターを購入して以来、複数の部署から問い合わせがありました。

各部門には独自のダッシュボード ビューがあります。たとえば、データ センターのデータ センター運用チームには、ネットワークの現在の状況を監視できるシンプルな NUC ダッシュボードがありますが、ネットワーク エンジニアリングには、エール大学のコア インフラストラクチャのより詳細なビューがあり、それがリアルタイムでどのようになっているかを把握できます。ネットワーク エンジニアリングは、エール大学の AWS および Azure 環境に関する情報を収集するためにロジック モニターを使用するクラウド チームなどの他のチームと連携して作業しています。

なるほど。真のハイブリッド環境ですね。オンプレミスの機器だけでなく、クラウド上の機器も多数お持ちで、Logic Monitor で監視されているようですね。これは典型的なユースケースですね。

他にどのようなツールをお使いですか？ServiceNowをご利用いただいていると伺いましたが、Logic Monitorのどのような連携機能や機能をお使いですか？

はい。ServiceNowとの連携により、REST APIを利用して変更チケット、リクエストチケット、インシデントチケットのメトリクスを収集しています。1日に作成されたチケットの数と、それらがどのグループに振り分けられたかを追跡することが可能です。

例えば、ヘルプデスクには大量のインシデントチケットが送られてきますが、REST APIとロジックモニターを使って、ヘルプデスクが処理するインシデントチケットの増加状況を時系列で把握しています。日々の定期的なパターンを把握できるだけでなく、動的なアラート機能も活用して、インシデントの急増を検知し、アラートを受け取ることができます。

一日を通してヘルプデスクに届くインシデントチケットの急増が見られた場合、ネットワークに何らかの問題がある可能性があると確認することができます。ServiceNowに問い合わせ、他のソフトウェアソリューションも活用し、ネットワークのボトルネックが発生していないか、そしてそれらのインシデントチケットの原因は何かを調べます。

素晴らしい。とても役に立ちました。

イェール大学のハイブリッド環境にロジック モニターを導入されて、どのようなメリットが得られているのか、もう一度説明していただけますか?

したがって、ロジック モニターは、イェール大学の ITS ネットワーク環境で何が起こっているかを詳細に調査できるという点で、大きなメリットとなっています。

先ほども申し上げたように、当時はデバイスにpingを送信するだけの、非常に時代遅れのNMS製品を使用していました。Logic Monitorを導入したことで、SNMP MIBをより深く活用できるようになり、より幅広いメトリクスを活用できるようになりました。また、カスタムデータソースとカスタムGroovyスクリプトを活用して他のソリューションのREST APIを利用できるようになり、SNMPをREST APIとして使用する代わりに、SSHでデバイスに接続してデータを収集することも可能になりました。

素晴らしいですね。Logic Monitorを使えば、環境全体を1か所でより包括的に把握できるようになり、トラブルシューティングが格段に速くなるようですね。それは素晴らしいですね。

わかりました。では、デビンさん、スライドを開いて、ロジックモニタープラットフォームと、そのどの部分を使っているのかを、エレメントビジョンの市場構造という観点から見ていきましょう。

わかりました。ここではElement Visionプラットフォームを見ています。これについては数分後にもう少し詳しく説明しますが、まずはDevonがYaleで使用しているプラ​​ットフォームのどのような側面なのかを確認したいと思います。まずはこの図の左側から見ていきましょう。

デボンさん、この最新のデータセンターのグラフで、イェール大学にとって関連性が高いと思われる分野について、改めて説明していただけますか？ また、右側のテレメトリについては、ロジックモニターからどのような種類のデータを取得されているのでしょうか？

はい、もちろんです。そのため、現代のデータセンターでは、メトリクスの収集にオンプレミスのインフラストラクチャに大きく依存しています。

当社のコア インフラストラクチャの多くはオンサイトで物理デバイスを使用しているため、そのデータのメトリックを収集するには、SNMP MIB の両方に大きく依存しています。

当社もクラウド インフラストラクチャに大きく依存しており、少なくともクラウド部門はそうしています。

先ほど言ったように、ロジック モニター内に AWS 環境と Azure 環境の両方があります。

そして、彼らは、トランジットゲートウェイだけでなく、仮想パロアルトも監視していると思います。

テレメトリ側に関しては、イベント部分を使用して、Cisco DNA Center ソリューションで発生するすべてのイベントを監視しています。

トポロジにも大きく依存しています。ネットワークのトポロジをある程度簡略化して把握している環境もいくつかあります。また、先ほども申し上げたように、構成情報にも大きく依存しています。コアインフラストラクチャの構成を24時間ごとに収集することで、状況を把握し、トラブルシューティングに役立つ変更が加えられていないかを確認できます。

素晴らしいですね。なるほど。先ほどおっしゃったメトリクスと構成に加えてですね。つまり、このテレメトリスペクトルのほぼすべてに対応しているということですね。素晴らしいですね。それでは、Devinさん、お時間をいただきありがとうございました。本日はご参加いただき、Yale での Logic Monitor の活用方法、そしてハイブリッド環境のより包括的な分析とトラブルシューティングの迅速化において、チームにどのようなメリットがもたらされたかについてお話いただき、本当に感謝しています。

では、この図をもう少し詳しく見ていきましょう。左側、真ん中の機能、そして右側のソリューションについて詳しく説明したいと思います。まず左側から見ていきましょう。これは、現代の企業が複雑なハイブリッド環境全体で備えるべき機能です。Devonのケースでは、オンプレミスとクラウドを併用するだけのシンプルな構成でしたが、Logic Monitorでアプリケーションを監視しているお客様もいらっしゃいます。IoTも検討しており、AIの導入も開始し、LLM（論理リソース管理）の監視も行っています。つまり、私たちは現代のデータセンターを、ElementVisionプラットフォームで可視化したいと考えているのです。

この最新のデータセンター環境全体で収集しているテレメトリの種類についてですが、メトリクス、ログ、イベントに注目しています。アプリケーションのトレースを取得し、自動化されたトポロジマッピングで、監視対象のインフラストラクチャとアプリケーションをマッピングしています。さらに、Devinが述べたように、構成データについては、ネットワークデバイスやクラウドベースの構成駆動型インフラストラクチャから定期的に構成データを取得しています。

そして、真ん中のほうに移ると、Element Vision プラットフォームとそれを構成するさまざまな機能があり、これによって顧客はトラブルシューティングを迅速化し、環境に対するプロアクティブな洞察を得て、最終的にはダウンタイムを防ぐことができます。

サービスインサイトは、サービスレベルのビューを可能にします。リソースエクスプローラー、カスタマイズ可能なダッシュボード、そしてレポートは、監視対象データをお客様にとって有意義なビューにするために役立ちます。さらに、動的なしきい値設定を中心としたAIとインテリジェンス機能スイートも備えており、異常検出を用いてインテリジェントなアラート、予測、予測を行い、インフラストラクチャの規模や容量ニーズの予測を支援します。さらに、Edwin AIによる根本原因分析とイベントインテリジェンスは、プラットフォーム内で発生するアラートノイズを大幅に削減し、インシデント対応を効率化します。

そして、右側には、これらの機能で提供しているソリューションがあります。Edwin 側の AI エージェントから、ハイブリッド エンタープライズ環境に提供している完全なインフラストラクチャの可観測性、クラウド監視、クラウド コストの最適化 (後ほど説明します)、さらに持続可能性監視やアプリケーションの可視性など、あらゆるものが含まれています。

これを少し異なる文脈で示すと、この図は非常に似ています。左側には、オンプレミスかパブリッククラウドかを問わず、お客様の環境があります。中央にはロジックモニタープラットフォームがあり、お客様はダッシュボードやレポートを取得し、環境から自動的に取得される豊富なモニターデータや、構築されている自動トポロジビューを理解できます。

そして右側には、既存のITエコシステムへのより適切な統合について記載します。つまり、アラートが適切な担当者に、適切なタイミングで、適切な場所に、チームが使い慣れたツールで確実に届くようにしたいのです。また、自動化のために何かツールをご利用の場合は、それらとも連携できるようにしたいと考えています。

最後に、Edwin AIの概要を簡単にご説明します。Edwin AIはLogic Monitorを基盤として、プラットフォームのインテリジェンスを次のレベルに引き上げ、アラートノイズを削減します。左側では、まずオブザーバビリティスタックから始めます。これはLogic Monitorのみの場合もあれば、セキュリティ関連やAPM関連などと組み合わせた場合もあります。そして、包括的なオブザーバビリティ製品スイートからイベントをEdwin AIプラットフォームに取り込みます。

そこから、下部に沿って、統合されたナレッジ グラフを使用して、ServiceNow CMDB などのソースからのデータを強化していることを確認しています。このデータを使用して、可観測性スタック全体で取り込んだイベント間で提供している相関関係を強化できます。

そして右側では、これらの相関分析情報が、ServiceNow やその他の適切なプラットフォームに出力されていることを確認します。

では、ロジックモニタープラットフォームのデモを見てみましょう。

これは、ハイブリッド企業が規模拡大と成長を目指し、営業部門、財務部門、運用部門といった特定の部門に注力したい場合に活用できるダッシュボードです。上部には、各部門のステータスと各部門が依存するインフラストラクチャを示す包括的なビューが表示されています。下にスクロールしていくと、Logic Monitor が構築した自動トポロジビューが表示されます。これらはここにマッピングされており、右側にはデバイスの物理的な位置も表示されています。

このダッシュボードを進んでいくと、エンドユーザーエクスペリエンスに関する洞察が得られます。例えば、世界中からアクセスしているエンドユーザーの給与計算アプリケーションの利用時間はどれくらいでしょうか？これらのグラフは、合成トランザクションとウェブサイト監視によって生成されています。さらに下に進むと、各部門のサービスベースのビューが表示されます。営業部門を見てみると、CRMへのアクセスが非常に重要であることがわかります。そのため、ここに表示されている統計情報や健全性データを使って、CRMへのアクセスを監視しています。財務部門を見ていくと、給与計算へのアクセスは非常に重要です。ネットワーク共有も同様に重要です。そこで、Azureベースの環境の監視も行われ、すべてがこの統合ダッシュボードにまとめられています。

運用面では、お客様をあるVPNから別のVPNに移行しています。その際には、ファイアウォールセッションを常に監視する必要があります。そのため、Logic Monitorsの異常検出機能を使用して、何か異常なアクティビティがないか確認します。Logic Monitorsによって異常なアクティビティとしてハイライト表示された赤いスパイクがいくつかあるのがわかります。VPN移行が正常に進んでいることを確認するために、これらのアクティビティを調査する必要があります。

スクロールダウンしていくと、この組織を支えるAzure環境について、パフォーマンスデータから正常性データ、そしてサービス制限まで、より詳細な情報が得られることがわかります。Azureがサービスごと、リージョンごとに設定しているデフォルトの制限にはどのようなものがあるか、注意が必要です。アラートも用意されています。これらのアラートについて詳しく説明する前に、少し視点を変えて、リソースエクスプローラーを使ってこのエンタープライズ環境を見てみましょう。

リソースエクスプローラーを使用して、Logic Monitorが環境から取り込む豊富なメタデータを活用します。今回は、インフラストラクチャが部門別にタグ付けされているため、タグを使用します。ここでは、財務部門と営業部門の詳細な内訳を確認できます。アラートステータスがオーバーレイ表示されているので、財務チームが抱えている問題の1つを、Tomcatサーバーのレポートと一緒に確認してみましょう。メタデータとアラートの詳細が表示されています。アラートの詳細をクリックして、Logic Monitorがトラブルシューティングにどのように役立つかを見てみましょう。

Tomcatサーバーの状態が良好から悪化していることがわかります。以前は200エラーを返していたのに、今は400エラーに近いエラーコードを返しています。Logic Monitorはこれを赤くハイライト表示し、異常としてフラグ付けしています。これは調査が必要な兆候であり、動的なしきい値に基づいてアラートが発せられています。下にスクロールすると、応答時間などの追加の指標が表示されます。これはそれほど異常ではないように見えますが、ログも表示されており、特にログ内の異常がハイライト表示されています。アラートが発生した直後に、いくつかの異常がフラグ付けされていたことがわかります。

では、異常なログを詳しく調べてみましょう。特定のパスが存在しないことがわかります。「web」は「b」が2つ使われているようです。

これはタイプミスのようですので、調査が必要かもしれません。つまり、これがTomcatサーバーがダウンして応答しなくなった原因である可能性があり、年末報告を修正する解決策にもなりそうです。

これは非常にシンプルなシナリオで、メトリクスとログを使うだけで、Logic Monitorが適切な方法で答えを導き出してくれたため、すぐに答えが見つかりました。しかし、大量のアラートが発生し、どのアラートから分析を始めれば良いのかさえ分からないようなアラートストームが発生した場合はどうなるでしょうか？まさにここでEdwin AIの出番です。Edwin AIは、オブザーバビリティスタック全体からイベントとアラートを取り込み、相関分析を行います。このアカウントでは、実際に3,000件以上のアラートを処理し、それらを相関分析して41件のインサイトにまとめ、ServiceNowに送信したことがわかります。

シングルトンまたは相関関係のないアラートがないことがわかりますが、もしあったとしても、システムは時間の経過とともに継続的に学習しており、その数はかなり低いままになるはずです。

それでは、これらのインサイトの1つとアラートの数を見てみましょう。ここでは13件のアラートが表示されています。

まず最初に目につくのは、タイムラインビューと詳細情報です。これらの詳細情報には、Edwin AIによって自動生成されたタグが含まれています。

ServiceNow CMDBから影響を受けるCIを取得しています。また、このCMDBを使用してメタデータを取得し、相関分析に使用しています。

タイムライン ビューでは、特定の Meraki の問題が環境全体にどのように影響を及ぼし、実際に配送および支払いサービスに影響を与えたかが表示されます。

下の方では、Edwin AIがLogic Monitor、Splunk、そしてこの場合はDynatraceからのアラートを相関させているのが分かります。つまり、3つの異なるオブザーバビリティツールからのアラートが統合されているということです。

AI分析により、人間が読みやすい非常に分かりやすいビューが提供され、Merakiセキュリティアプライアンスのトンネル問題が決済サービスと配送サービスに支障をきたし、データベース同期のタイムアウトなどを引き起こしていることが分かります。さらに、トラブルシューティングや問題解決に必要な修正点の特定に役立つ根本原因情報も提供されます。

では、これらのアラートの1つ、理想的にはロジックモニターにあった発生元のアラートを見てみましょう。ここにあるソースIDリンクをクリックします。すると、ロジックモニターに戻り、先ほどTomcatサーバーで確認したアラートの詳細ページが表示されます。ここでも、メトリックがプロットされていますが、特に注目すべき点はありません。しかし、ログの異常もすぐに取得でき、構成テンプレートが変更されたことが分かります。おそらく、これがMerakiアプライアンスで最初に発生した問題の原因であり、配送および支払いサービスに混乱を招いたのでしょう。これは、Edwin AIが適切なアラートを絞り込み、ロジックモニターが持つ豊富なデータを活用してトラブルシューティングを迅速化する方法を示すもう1つの例です。

次に、プラットフォームのもう一つの側面、昨年リリースした新しいコスト最適化製品についてご紹介します。この製品には大きく分けて2つの側面があります。1つ目は課金機能で、複数のクラウドの課金情報を単一のダッシュボードに表示します。リソースタイプ、リージョン、そして下の表にある詳細な内訳など、様々なディメンションで内訳を確認できます。

これらのデータは、細かく分析したり、ドリルダウンしたりすることができます。また、環境のメタデータに基づいて内訳を絞り込むこともできます。例えば、特定の事業部門だけを見たい場合、IT運用チームと製品開発チームに焦点を絞り、それぞれの支出を具体的に確認することができます。

週ごとの傾向を見れば、支出がどのように変化しているかが分かりますよね？増えているのか？減っているのか？月末にはどうなるのか？予算内に収めるために何か変更する必要があるのか​​？

また、プロバイダーなどのビューでは、使用している複数のクラウド プロバイダー (この場合は AWS と Azure) 全体での支出状況がわかります。

右側にタブが追加され、アカウントとリージョンのビューが表示されます。ここでも、クラウドインフラストラクチャが稼働しているリージョンや、クラウドプロバイダー間で使用しているリソースの種類など、様々な要素ごとに内訳が表示されます。これにより、非常に詳細なビューを取得し、支出状況を細かく分析できます。

「推奨事項」タブでは、クラウド支出を実際に最適化するための具体的な推奨事項が表示されます。ここでは、Logic Monitor が保有するパフォーマンスデータと支出データを組み合わせて、コスト削減の機会を特定しています。

クリーンアップできるアイドル状態の ec 2 インスタンスがいくつかあるようです。また、サイズを変更できる ec 2 インスタンスもあるかもしれません。

ここには、アクションを実行するための AWS コンソールへの直接リンク、このアクションを提供している理由を説明するデータ、このリストが長期にわたって関連性を保つように実行できるさまざまなライフサイクルアクションなどの情報があります。

これは、ロジック モニターがパフォーマンスと可用性の監視だけにとどまらず、クラウド支出などのビジネス メトリックの最適化を通じて価値を提供できることを示した例です。

このプラットフォーム概要がお役に立てば幸いです。特に、先ほどDevinがYale社がロジックモニタープラットフォームをどのように活用してきたかについてお話しいただいたことと合わせて、より深くご理解いただけたかと思います。そして、皆様がElement Visionについてより深くご理解いただけたと感じていただければ幸いです。