皆さん、こんにちは。Elevateコミュニティカンファレンスで私が主導するアプリケーションの可視性に関するセッションのまとめにご参加いただき、誠にありがとうございます。
これはインタラクティブなセッションです。ライブ配信だったので、その内容も触れておきます。私のことをご存知の方、あるいはご存知でない方のためにご説明しますと、私はLogicMonitorのプロダクトアーキテクトです。
私はLMログのロードマップをキュレートし、新機能や機能の追加、そして既存の機能の整理といった方向性を決定しています。さらに、ロジックモニターの他の領域のアドバイザーも務めています。サービスインサイト、Webチェック、そしてその他周辺コンポーネントなど、これらをまとめて「アプリケーション可視性」と呼ぶトピックにまとめています。
そして、私たちは APM やトレースに立ち入ることなく、アプリケーション監視の観点からこれを指揮しています。
ようこそ、ご参加いただきありがとうございます。
ここで少し免責事項を申し上げます。少し先の未来についてお話ししますが、これはセーフハーバーです。つまり、ロードマップに基づいて、機密情報や専有情報を共有することになります。これらの資料は配布したり、このセッションの文脈から外れて公開したりしないでください。
はい。それでは、これが今日の議論の原動力となり、これから詳しく説明していきます。
本日は、データソースメトリクス、インフラストラクチャ監視、ログデータなど、既存の機能を中心に、多くの機能をご紹介しました。これらの機能の一部は、これらの機能に活用できます。まずは、現在提供している機能をご紹介するとともに、課題やアプリケーション固有の要件への対応についてお話しします。そして、将来に向けて、私たちが何を構築しようとしているのか、お客様とのワークショップでどのような点を議論し、多くのインタラクティブセッションを通してこれらの要件を収集してきたのかについてもお話しします。
これから、IT運用におけるいわゆるアプリケーション可視化についてお話しします。これはどういう意味を持つのでしょうか？そして、そのロードマップはどのようなものになるのでしょうか？最後に、このロードマップを実現するために、私たちが構築しようとしているZen Worldのダッシュボードの例をお見せします。
最後に少し質疑応答をさせていただきます。
さて、そろそろアンケートに移りましょう。ライブセッション中に、聴衆に「Service Insightsってご存知ですか？現在使っていますか？」と質問してみました。すると、予想通り、手を挙げたのはほんのわずかでした。皆さん、ご存知でした。ロジックモニター画面の左側にあるアイコンとナビゲーションペインは認識していましたが、実際には使っていませんでした。仮に使っていたとしても、アプリケーション系のサービスでは必ずしも使われていなかった可能性が高いのです。
おそらく、ネットワークインフラ系のサービスやDNSサービスといったものに近いものだったでしょう。ですから、この結果に驚きはありません。
2 番目の質問は、lm ログを使用していますか?
再び、部屋の向こうから手が挙がったのは、ほんの少しだけだった。まあ、予想通りだった。
そして、そこからいくつかの洞察が得られます。例えば、LMログを使用している場合、アプリケーションログも取り込んでいるでしょうか？実際にこれを行っているのは、ごく少数のユーザーでした。ほとんどのユーザーは、ネットワークデバイスからSyslog、WindowsサーバーからWindowsイベントログなどを収集していましたが、アプリケーションログを取り込んでいるユーザーは少数でした。つまり、意識はあっても、特定の用途に絞った用途では、実際には活用されていないということです。
最後の質問です。LM Webチェックはお使いですか？ そうですね？ このWebチェックは、いわば合成ライト、いわばエンドユーザー監視機能のようなもので、Logic Monitorに組み込まれており、現在既にお客様にご利用いただけます。基本的にはウェブサイトを対象としています。そのウェブサイトは稼働中でしょうか、それともダウンしているでしょうか？ この件については、かなり多くの方に試用していただきました。つまり、WebチェックはWebチェックやpingチェックなど、様々な用途で使われているということですね。
これらは、部屋の状況を把握する上で重要でした。例えば、現在私たちが持っているものや、Element Visionプラットフォームで利用できるものについて、ご存知ですか？
それで、ここからは、現在提供している機能についてお話しします。私たちは様々なことを行っていますが、プラットフォームはここ数年で飛躍的に成長し、Edwinやイベントインテリジェンスといった機能が追加されました。
しかし、サービスインサイトのような機能は以前からありました。リソースエクスプローラーは新しく、中央あたりでそれを追跡する機能です。
ダッシュボード、異常検知機能、そして優れたログ機能が豊富に用意されており、アプリケーションサーバーに絞り込むことができます。オペレーティングシステムやアプリケーションサーバーの健全性について、多くの情報を得ることができます。カスタムデータソースの使用、アプリケーション固有のサービスやメトリクスの監視、アラートやトリガーの設定も可能です。また、これらのアプリケーションログを取り込んだ後、Webチェックインを上位または下位のログに挿入することで、ログ全体をまとめて管理することも可能です。さらに、これらをサービスインサイトグループにまとめることで、よりインテリジェントなアラートを待機状態にすることができます。
そうですね？KPIを使って、例えば「1台のWebサーバーがダウンしているけれど、全部はダウンしておらず、アプリはまだ動作している。これは重大なアラートではないはずだが、調査して修正する」といった具合です。今日私たちが実行できるのは、こういった類のことです。
特定の種類のアプリケーション向けに、APMとトレース機能も提供しています。これも提供可能です。つまり、こうした細分化された情報やチャンク、パーツはすべて揃っていますが、本当に欠けているのは、ダッシュボードビューにすべてを統合する機能です。ダッシュボードビューでは、先ほどお話ししたさまざまな要素を単一のビューにまとめ、誰にとってもフラットな単一の画面で情報を確認できます。
それで、私たちが部屋でこの議論をした時に、そういうことが明らかになったんです。「なるほど。つまり、あなたはこれらの特徴のいくつかを認識しているということですね」と私たちは言いました。
しかし、もしかしたら全部使っていないかもしれません。その理由は何でしょうか？それぞれのセグメントについて、それぞれ掘り下げて考えてみましょう。そこで、具体的な質問を部屋の中で投げかけます。
APMツールを使って監視していますか？多くの方が手を挙げています。APMは、重要なTier 1アプリケーションにとって重要な要素です。これらの最も重要な、通常は収益を生み出す顧客対応アプリケーションは、ビジネスにおいて最も重要な部分です。
APM は、通常、完全なトレース機能を備えた環境で導入されています。複数のベンダーが連携しており、4～5社のコアベンダーが、この分野で最高の制御機能を備えており、導入されているベンダーは大抵これらのベンダーです。
伐採ツールについてはどうですか？伐採会社がたくさんあることは皆さんご存知でしょう。
専門知識がなかったり、予算やノウハウがなかったりして、すべてのアプリにAPMを導入できないかもしれません。そこで、Splunkなどのログツールを使ってアプリケーションログを詳細に分析し、それらのログをメトリクスに変換してアプリケーションを監視するという方法があります。そうすれば、専門知識やコスト、そしてAPMツールのインストールを回避できます。これも私たちが尋ねたもう一つの点です。会場の参加者の中には、他にも何人か手を挙げていただいた方がいました。
APMほど多くはありませんが、確かに少しは手間が省けます。そして最後に、基本的な監視はどうでしょうか？そうですね。そうですね、アプリケーションやインフラストラクチャ環境の一部です。
それを優れたサービスに組み込むことはできますが、ただpingを打っているだけでしょうか？pullしているだけでしょうか？基本的なインフラ指標を取得できているでしょうか？皆が手を挙げます。つまり、誰もが何らかの方法でこれらのシステムを監視していますが、機能からビジネスに至るまで、包括的に監視しているわけではないということです。私たちは、特定のコンポーネントが稼働しているかダウンしているかという視点でシステムを見ています。それを知ることは重要ですが、サービス全体が稼働しているかダウンしているかを知ることはそれほど重要ではありません。
ある程度の成果が見えてきたところで、次に「では、ここで明らかになった課題は何だろう？」と考え始めました。これは、お客様との数多くのワークショップやセッションでのやり取りから生まれたものです。APMツールに関する最初の質問に手が上がった時、それはその場にいた全員がAPMのエキスパートだったという意味ではありません。つまり、その企業にはAPMを導入した人材がいるということです。通常、プロフェッショナルサービスとの緊密な連携には高度な専門知識が必要ですが、APMによって必要なレベルの詳細な可視性が得られます。
パフォーマンス上の課題がどこにあるのかを正確に特定できます。つまり、ダウンしているわけではないのに速度低下が発生している場合、これはトリアージを行い、速度低下が発生しているコードレイヤーまで診断するのに最適な方法です。しかし、それには多大なコストがかかります。これらのソリューションは非常に高価です。
そのため、一般的な企業では、アプリケーションの約20%程度にしか導入されていない傾向があります。場合によっては、それよりはるかに少ないこともあります。1つ、2つ、3つ、あるいは4つ、あるいは5つ程度でしょう。そうでしょう？つまり、次のレベルのアプリケーションセットにまで深く浸透していない可能性があるのです。
彼らには時間も専門知識もないのです。
しかし、この二次セットがあります。では、第2層のアプリはどうでしょうか？
APMを導入したくないのは、導入と保守を行う人材が足りないからです。適切な専門知識もありませんし、APMツールを追加購入する予算もありません。
ログレベルの可視性だけでこれを行う方法はありますか？例えば、レート、エラー、期間といったいわゆるレッドメトリクスを取得できるかもしれません。これらは通常APMツールによって生成されますが、ログからそのようなデータを取得できる場合もあります。
また、eBPFやカーネルレベルのメトリクスといった他のメトリクス機能もあります。ここでいくつか情報が得られるかもしれません。顧客のアプリケーションの約30%がこのカテゴリに該当する可能性があり、それが彼らがそれをカバーしている方法です。
最後の塊、氷山の底、その下にあるもの。これが最も低レベルのコンポーネントレベルの監視です。
Logic Monitorはまさにこの分野で私たちの強みを発揮し、私たちが生まれ育った場所です。デバイスの検出、個々のコンポーネントとしての監視、稼働状況の報告、パフォーマンス指標の収集、そして状況把握のための情報提供といった業務を得意としています。その後、ログイン機能を追加し、根本原因を特定できるようになりました。
しかし、本質的には、そのデバイスが稼働しているか停止しているかを知らせているだけです。そこにギャップがあり、課題となるのは、このデバイスが隣のデバイス、さらにその次のデバイスにとってどのように重要なのか、そしてそれらが実際にどのようなサービスをサポートしているのかを把握する必要があることです。
これは私の銀行アプリケーションですか？ そうですか？ Webサーバーは何台ありますか？ アプリケーション層サーバーは何台ありますか？
バックエンドのデータベースはどのような構成になっているでしょうか？そしてもちろん、それらの間にはネットワーク接続も必要です。これらの一部はクラウド上に、一部は物理的にオンプレミス上に、つまりハイブリッドな環境が考えられます。そして、ここでもLogic Monitorが真価を発揮します。
お客様が様々なツールセットを導入していることを、3つの異なる方法で明らかにしました。このギャップを少しでも埋め、APMの実際の機能に50%近づけるにはどうすれば良いでしょうか？
そこで要件について話し合い始めました。これは楽しい演習でした。私たちはお客様に「お客様の要件は何でしょうか？」とよく尋ねます。「トレース機能で全てが実現でき、pingとpull、そしてインフラメトリクスによるインフラ監視は何もしないよりはましですが、どこか中間的な機能が必要です。どこで見つければいいのでしょうか？」と。するとお客様は「十分な機能があればそれで十分です」とおっしゃいました。
「十分に良い」という言葉が何を意味するのか、さらに深く掘り下げていきます。なぜなら、それは非常に曖昧な言葉だからです。
簡単に導入できます。そうでしょう？ソリューションの導入に必要なコードレベルの専門知識やエンジニア、開発者、そして大量の専門サービスは必要ありません。そして、契約が締結され、アーキテクトが退社すると、今度は自分でメンテナンスをしなければならない状況に陥ります。
しかし、これを開発者ペルソナではなく、IT運用ペルソナに近づけることは可能でしょうか？ロジックモニターは通常、データセンターやNOCに配置されています。私たちはIT運用ペルソナに非常に近い存在です。そして、私たちがここで話しているのはまさにこのIT運用ペルソナなのです。
赤いメトリクス、つまりレポート率やエラー期間を取得できますか？これらはアプリケーションの健全性とパフォーマンスを示す指標です。
また、ログをメトリック化することはできますか？ログをメトリック化するとはどういう意味ですか？これは、生の見苦しいログデータをメトリックに変換して、傾向分析や見やすい画像、ダッシュボードに使用したい、そしてそれに対してアラートを発動できる、という意味です。「ねえ、できるの？」と言えばいいでしょうか？
この値が通常より高くなったらトリガーを設定してください。通常より低くなったらトリガーを設定してください。これらはパフォーマンスに問題があることを示す先行指標です。もちろん、基本的なインフラストラクチャの指標は必須です。
そこが私たちの強みです。私たちはそういうことにとても長けています。
先ほども申し上げたように、ログデータはコンテキストに応じて記録されます。つまり、メトリックを取得しているときにCPU使用率が高くなっているのです。その理由を知りたいのですが、その答えはログにあります。
異常検出技術を使い、それを組み合わせます。結局のところ、大金を費やすわけにはいきませんよね？経済的である必要があります。
先ほど申し上げたように、トレースツールとAPMツールはこれらの要件をすべて満たすことができます。しかし、これらのツールは非常に高額で、人件費も高く、価値が実現するまでに非常に長い時間がかかります。これらのツールの導入と展開には長い時間がかかります。
いくつか発見しました。これが私たちの小さなワードクラウドです。わかりますか？これを追跡していくと、ここで何度も繰り返し強調してきたものが前面に出てくるのがわかります。
十分だ。十分だ。十分だ。よし。それでは、製品アーキテクトとして、製品の機能は何なのか、そしてロジックモニターの様々な領域間で何を構築し、統合する必要があるのか​​を明らかにして、何が十分であるかを判断する必要があります。
では、それをもう少し掘り下げて、何が十分なのかについて話し始めるとしましょう。
アプリケーションログとエラー。非常に重要です。アプリの健全性、あるいは異常が分かります。ログはクリーンですか、それともダーティーですか？
大量のエラーコードを含むダーティログは、現在問題が発生しているか、あるいは問題が起こりそうな兆候です。これは非常に重要です。私たちは、誰もが十分だと言っていることが分かったのです。アプリケーションの応答時間です。
稼働しているだけでなく、応答もしていますか？ そうですね？ その種類のデータを再度取得することはできますか？
複数の拠点からのアプリケーションサービスの可用性。例えば、Webチェックのようなことをする場合、複数の場所から実行できるでしょうか？アメリカではパフォーマンスが良好でも、ヨーロッパやEMEAではパフォーマンス低下の問題が発生しているかもしれません。そのため、世界中の様々な地域や拠点から、アプリケーションのサービス応答時間を追跡できる必要があります。
アプリケーションメトリクス。ちょっと細かい話になってきましたね。ロードバランサとWebサーバーの比較の話ですが、これらをサービスレベルビューのようなものでまとめて表示することは可能でしょうか？アプリケーションを構成するすべてのコンポーネントから、これらの情報をまとめて表示・集約できるのがわかります。
では、サービスレベルアラートを取得できますか？ 1台目のボックスのCPU使用率が高いことだけを知りたいわけではありません。知りたいのは、アプリケーションの現在のレスポンスです。1台目のボックスがダウンしていることがサービスレベルに影響しているかどうかです。でも、2台目がダウンするとどうなるでしょうか？ なるほど。これはもっと深刻なインシデントかもしれません。もっとクリティカルなサービスアラートが必要なのかもしれません。
統合されたダッシュボードビュー。美しい画像で全てをまとめて、簡単に利用できるようにしたい。生のログを見るのは嫌だ。何千ものアラートを見るのも嫌だ。月曜日に出勤して、Acmeアプリのダッシュボードを開いて、それを見て「今日の調子はいいかな？悪いかな？」と理解したい。
他に何かありますか？何か見落としているでしょうか？これらの点についてはある程度話し合いました。でも、「十分な機能」について掘り下げた際に、私が一番印象に残ったのは、トレースのような話は聞かなかったことです。Rumやリアルユーザーモニタリングが必要だという話も聞きませんでした。
eBPFという言葉さえ耳にすることがほとんどありませんでした。時々、カーネルメトリクスがいくつか出てくることもありました。そこで、これらの十分な項目をいくつか見て、「製品とプラットフォームの様々な領域でこれらすべてを実行できるが、それをどのように統合できるだろうか？」と考えました。これで、何ができるかをより明確に把握できました。分析を進めていく中で、IT運用におけるアプリケーションの可視性というアイデアをどこに重点的に活用していくかを明確にしていきます。現在、私たちが目指しているのは、IT運用担当者に焦点を当てたアプリケーション監視ソリューションです。このソリューションを導入するために、開発者やエンジニアリングレベルの知識は必要ありません。
私たちは、Tier 1アプリケーションに重点を置くつもりはありません。それはAPMの世界、APMランドです。私たちはその領域に踏み込むつもりはありません。私たちが重点を置くのは、お客様がログツールを使ってデータを取得しようとしている30%と、ping、pull、そして基本的なインフラストラクチャメトリクスの取得のみを行っている残りの50%です。
私たちが本当に注力しているのはまさにこの領域です。繰り返しますが、開発者やエンジニアでなくても、これを理解し、デプロイし、保守し、環境に変更を加えることができるようにしたいとは思っていません。シンプルであることが求められます。そして、繰り返しますが、皆さんの負担を大きくしたくはありません。
そうですか？これが、IT運用におけるアプリケーションの可視性によって私たちが実現しようとしている目標であり、成果なのです。
それでは、製品の既存の領域と、その下にある機能改善についてお話ししましょう。これらをレベルアップし、パッケージ全体を統合していく必要があります。3つのコア領域が調和して機能し、それぞれが様々な方法で改善していくことで、私たちが明らかにした十分な要件を満たすことができるようになります。サービスインサイト、Webチェック、そしてログです。これらがロジックモニターの3つのコア領域であり、これらを改善していく必要があります。
左端のボックスにあるサービスインサイトでは、いくつかルールが必要です。すぐに使えるテンプレートがあれば、より素早くグループ化できます。これは現在でも実行可能ですが、手作業になります。面倒な作業になる場合があり、多くのお客様がルール機能のサービスインサイトを積極的に活用していないのはそのためです。
しかし、これにより、サービスを構成するこれらのサービスをグループ化し、その中で最も重要な要素を優先し、KPI とよりスマートなアラート条件を持つことができます。
そのため、サービスインサイトの機能をさらに強化する必要があります。これは2025年のロードマップ計画の一部です。これらの機能はすでに構築され、開発が進められています。しかし、統合機能も改善する必要があります。これについては後ほど詳しく説明します。
Webチェック。Logic MinerではWebチェックが長年活用されてきました。しかし、いくつかの欠陥がありました。お客様から、アラートの調整に問題があるというご意見を頻繁にいただいていました。
動的なしきい値はサポートされておらず、ウィジェットも改善されました。より優れた視覚効果や、カスタムプロパティやカスタムグラフといった機能も求められています。これらはすべて、リソースで通常実行できる機能です。
そこで私たちは、Webチェックを作成したら、それをリソースとロジックのモニターへと転換するという取り組みを始めました。これにより、動的なしきい値、アラート調整、カスタムプロパティ、カスタムグラフなど、ダッシュボードウィジェットに表示できるビジュアルと機能を大幅に強化する優れた機能をすべて利用できるようになります。繰り返しますが、これは現在進行中のプロジェクトです。私たちは既にWebチェックの改善とレベルアップに向けて、このプロジェクトの構築と開発に取り組んでいます。そして最後に、ロードマップの右端にあるのは、私が特に監修している部分です。
これらの改善を目指しています。まず、データの取得をより容易かつ効率的に行う必要があります。そのため、ホテルコレクター関連の機能をいくつか改善しています。また、Logstash、Fluent Bit、Fluent dの統合タイプも既に追加しています。まず第一に、ログを可能な限り迅速かつ容易に取得できるようにすることを目指しています。これが私たちの目標です。データの取得が容易になればなるほど、そのデータからより早く価値を引き出すことができるようになります。
エージェントをボックスにデプロイしてアプリケーションログを取得するのは、IT運用担当者でも実行できます。開発者やエンジニアでなくても構いません。次に、そのログデータを収集し、メトリクス化してグラフやダッシュボードに表示し、適切な見た目に仕上げたいと考えています。これは、先ほどリソースを使ったWebチェックについてお話ししたのと似ています。クエリトラッキングの概念を使って、同じようなことを実現したいと考えています。クエリを作成し、エラーコードや問題など、明らかにしたい事柄に焦点を当て、それらを集計してメトリクスに変換します。そして、それをダッシュ​​ボードに表示できるようにすることで、ログダッシュボード機能の大幅な改善に役立てたいと考えています。
ログ パーティション、データのスライス アンド ダイス、ボリュームが大きいためアプリケーション ログを短時間保持する機能、製品内クエリ ライブラリの追加、たとえば IAS 周辺のユーザーに情報を公開できる場所、使用できる、または使用すべきクエリの例をいくつか提供できる場所、それらをメトリック化し、クエリ トラッキングして、ビジュアルに変換できる場所などです。
最後に、クエリレスログ機能を追加します。クエリ言語に精通していない、またはエキスパートでない場合でも、ネイティブツールやチャットGPTタイプのツールを使用してクエリの作成を支援できるようになります。これらの改善をすべて組み合わせて、各領域のレベルアップを図り、十分なパフォーマンスを実現できる例に近づいていきます。
これらすべてを実現し、ロードマップに記されたすべてのものを構築し、それをうまくまとめ上げることができたら、これで十分だ、という例になりますね。基本的なビジネス指標をいくつか確認しました。現在、私のシステムでアクティブな顧客は何人いるでしょうか？
アプリケーションログから取得できます。環境内のメトリクスやコンポーネントの状況はどうなっているでしょうか？これらの情報は通常APMから取得されます。APMでは簡単に取得できるメトリクスですが、ログから取得するのはそれほど簡単ではありません。しかし、実際にデータから、期間やエラーコードといった重要なメトリクスを取得できます。
しかし、トポロジーが必要なので、サービスインサイトとこれらのトポロジービューを統合します。今回の場合、アプリケーションの名前は「ブティックショップ」です。これで完成です。オレンジ色と赤色のものがいくつかあるのがわかりますね。
アラートによると、ステータスは下の方にあります。しかし、一番上のサービスはまだ正常です。100%です。これらの点については調査が必要ですが、アラートが大量に発生しているわけではなく、お客様への影響もありません。
これは、概要レベルでは良い例です。月曜日の朝に来たアプリケーションオーナーの例です。しかし、もう少し深く掘り下げて、追加の指標やログの詳細な情報も必要になるかもしれません。これらもAPMツールを使えば簡単に得られるはずです。
しかし、ログから多くのデータを取得できます。ログデータから、エラーコードの総数、発生している問題、トランザクションの所要時間などの傾向を把握できるようになります。
これらはすべて、ログからメトリクスを抽出し、図に変換して、値に対して動的および静的なしきい値を適用できるものです。これらすべてをまとめて実行します。ログやWebチェックからこの種のデータを取得し、サービスインサイトでまとめてダッシュボードに表示できるようになりました。トレースやAPMツールを使用する必要はありませんでした。これが、私たちがまとめた概要です。まとめると、デモをご覧になりたい方は、チームまでご連絡ください。ロードマップの進捗状況を示すデモをご用意できます。現在、機能開発のプロセスを進めています。
わかりました。このセッションについてフィードバックをいただける方は、QRコードをスキャンしてください。ご参加いただきありがとうございました。
ライブでご参加いただけなかった方は、シドニーかロンドンでぜひご参加ください。また、二次セッションやフォローアップも予定しています。改めて皆様に感謝申し上げます。ご参加いただきありがとうございました。
また次回お会いしましょう。