OpsチームがLMログから利益を得る3つの方法
LogicMonitor + Catchpoint: 自律型ITの新時代へ
最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。
ビデオはまもなく始まります
おそらくこの言葉を耳にしたことがあるでしょう LMオペレーション 以前はそうでした。Web上では、機械学習の運用や大規模言語モデル運用(LLMOps)と関連付けられることが多くあります。モデルのデプロイ、プロンプトのチューニング、パイプライン管理などを考えてみてください。
しかし、LogicMonitorにおけるLM Opsは、別の意味を持ちます。IT運用チームが当社の可観測性プラットフォーム、特にLM Logsを活用して、監視を効率化し、トラブルシューティングを迅速化し、ダウンタイムを削減する仕組みを指します。
あなたが ITOps、DevOps、または SRE チームで、問題が雪だるま式に大きくなる前に問題を見つける能力を高めたいと考えていますか? あなたは間違いなく正しい場所にいます。
LM Logsがあれば、データを闇雲に精査する必要はありません。この記事では、LM OpsがITOps、DevOps、SREのプロフェッショナルにとって、ノイズを排除し、異常をリアルタイムで特定し、「何が起こっているのか、どこで起こっているのか、そしてなぜ起こっているのか」という重要な疑問に答える上でどのように役立つかを詳しく説明します。
LogicMonitorのTechOpsチームの使命は、顧客にLogicMonitorサービスを提供する、信頼性の高いコンピューティングプラットフォームを構築、拡張、および維持することです。 彼らの仕事はXNUMXつの主要なカテゴリーに分類することができます:
#1-サービスの可用性を向上させることにより、顧客体験を向上させます。
#2-プロセスのスケーリングまたは自動化、アラートの積極的な調整、他の部門からの要求への対応により、同僚の仕事を容易にします。
目標には、LogicMonitorサービスを顧客に確実に提供すること、潜在的または顧客が気付く前に混乱を認識できるようにすること、プロアクティブゾーンとリアクティブゾーンで時間を過ごすこと、技術的負債の蓄積を回避すること、およびLogicMonitorを利用してLMサーバーの信頼性を確保することが含まれます。
ログは、人または実行中のプロセスのいずれかによって、コンピューティングシステムで発生するイベントの記録です。 ログは、何が起こったかを追跡し、問題をトラブルシューティングするのに役立ちます。ログは、アプリケーションまたは時系列メトリックのカバレッジを監視する上で重要な部分です。
ログの確認は困難で時間がかかり、多くの場合、ログを理解するには専門知識が必要です。 LMログを挿入します。 LM Logsは、強力な特許取得済みのアルゴリズムを利用して、独自の検索クエリ言語を学習することなく、取り込み時にログ、データ、およびイベントのすべての要素を自動的に分析します。 LM Logsは、ログ内の異常をプロアクティブに識別し、これらのイベントを自動的にエスカレーションすることにより、一元化されたログ集約アプローチをさらに一歩進めます。 さらに、ログインメトリックデータは真に統合されています。つまり、ログデータは、パフォーマンスメトリックダッシュボードまたはグラフからコンテキスト内ですぐに分析できます。

この図は、LM Logs が環境全体(クラウドプロバイダー、サーバー、コンテナ、SaaS アプリなど)からデータを収集し、LogicMonitor プラットフォームにフィードしてリアルタイムの異常検知を行う仕組みを示しています。ログとメトリクスは単一のシステムを通過するため、チームはツールを切り替えることなく、より迅速にトラブルシューティングを行うことができます。
LM Logs が導入される前は、インシデントの根本原因の特定や事後検証に何時間もかかることがよくありました。エンジニアはツールを切り替えたり、コンテキストのないログを解釈したり、イベントにメトリクスを手動で関連付けたりする必要がありました。これにより調査が遅延し、プレッシャーの中で行動することが困難になっていました。
LM Logs を使用すると、ログとパフォーマンス データが 1 か所に並べて保存されるため、すべての運用チームが知っておく必要のある 3 つの質問に即座に答えることができます。
何が起こっているのか、どこで起こっているのか、そしてなぜ起こっているのか。
.section-title-center-single-column { text-align: left; background-color: white !important; padding: 20px 0; } .section-title-center-single-column__title p { font-weight: 300; margin-bottom: 10px; line-height: 1.6; color: #040F4B !important; position: relative; padding-left: 5%; } .section-title-center-single-column__title p::before { content: ""; position: absolute; left: 0; top: 0; bottom: 0; width: 8px; background: linear-gradient(0deg, var(--core-blue-500) 0%, var(--aqua-500) 100%) /* 線の青色 */ } .quotee { font-size: 16px !important; text-align: left !important; font-weight: 300; line-height: 1.6; margin-top: 10px; padding-left: 6%; margin-bottom: 25px; color: #040F4B !important; } @media only screen and (max-width: 992px) { .section-title-center-single-column__title p { padding-left: 10%; } .quotee { font-size: 16px; padding-left: 10%; } } LM Logs 以前は、問題のトラブルシューティングには専門知識が必要でした。さて、ログは何が重要かを教えてくれます。
LogicMonitorは、すべてのOpsチームがログにアクセスでき、痛みを伴わないようにする必要があると考えています。したがって、LM Logsは、これまでに作成された最初のソリューションです。 IT運用チームとDevOpsチームを念頭に置いて構築。 LM TechOpsチームがLMログの統合からどのように利益を得たかの例を詳しく見ていきましょう。これにより、最終的にMTTRが減少し、根本原因分析の決定に必要な時間が短縮され、パフォーマンスまたは可用性に影響を与えることに焦点が当てられます。何が正常か異常かを解読することなく、イベントをすぐにログに記録します。
チームはまだ機能しているサーバーに遭遇しましたが、Kafkaブローカーはリーダーシップを失い、データを適切に複製していませんでした。 LM Logsが登場する前は、Kafka自体のアプリケーションログは問題の原因を特定するのに役に立たず、問題が何であるかを正確に把握しようと複数の人が何時間も費やしていました。 LMログの後、チームは別のサーバーで同じ問題に関するアラートを受け取りました。 今回、彼らは、組織の知識からではなく、アラートとともにログメッセージを表示するLMログから問題を即座に発見しました。 イベントのタイムラインを取り巻く異常なログメッセージと一緒にメトリックベースのアラートを設定することで、状況が明確になりました。
マルチテナントTSDBサーバーがKafkaからのメッセージの消費を停止しました。 このサーバーは、80を超えるさまざまな顧客にサービスを提供しました。 通常、このような状況を診断するには、アプリケーションサーバーのログに精通した誰かによる高度なログ集計クエリが必要になります。 LMログが作成される前は、根本的な原因が明らかになるかどうかを調査するために、この問題に数時間または数日かかる場合がありました。 LMログの後で、根本原因分析プロセスを91人の顧客まで追跡することができました。 わずか6.2分の間に、0000145万のログ行からXNUMXの異常が検出されました。これは、この期間中のログの.XNUMX%のみが問題に関連していたことを意味します。 ありがとう、LMログ。
LM ログは、6.2 万のログ行のうち、わずか 91 件の異常を検出し、90 分以内に問題を特定しました。
運用チームは、顧客が容量の制約に関連するパフォーマンスの問題を経験したときに、問題を事前に特定できなければなりません。 この場合、オンコールエンジニアは、応答時間が低下したことを示すメトリックベースのアラートを受信しました。 場合によっては、問題を明らかにするために実際のログを読み取る必要があり、LMログの前は、800,000以上のメッセージをスクロールすることでこれを実行できませんでした。 LMログの後、アラートを処理すると、オンコールエンジニアは関連するログの異常をすばやく確認できました。 ログの異常により、短期的に解決するには手動による介入が必要なバグが明らかになりましたが、将来この問題を防ぐためのフォローアップアクションを作成するために必要なデータも提供されました。 この場合、ログの異常は、パフォーマンスの問題が発見された04分間の合計ログ量の.90%に相当します。

全体として、LM Logsは、すべてのログデータとITインフラストラクチャのパフォーマンスメトリックを単一の統合されたステータスベースのプラットフォームに一元化します。 強力なアルゴリズムを利用してログの異常を自動的に検出して表面化し、労働集約的な分析を排除します。 LMログは、トラブルシューティングと根本原因の分析時間を大幅に短縮し、インシデントウォールームのシナリオを回避し、原因が何であるかを理解するだけでなく、問題を解決するために何を修正する必要があるかを理解するのに役立ちます 良いのために。
LMログが、チームがトラブルシューティングを減らし、ITワークフローを合理化し、制御を強化してリスクを軽減するのにどのように役立つかについて詳しくは、 このオンデマンドウェビナーをご覧ください.
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。