OpsチームがLMログから利益を得る3つの方法

おそらくこの言葉を耳にしたことがあるでしょう LMオペレーション 以前はそうでした。Web上では、機械学習の運用や大規模言語モデル運用（LLMOps）と関連付けられることが多くあります。モデルのデプロイ、プロンプトのチューニング、パイプライン管理などを考えてみてください。

しかし、LogicMonitorにおけるLM Opsは、別の意味を持ちます。IT運用チームが当社の可観測性プラットフォーム、特にLM Logsを活用して、監視を効率化し、トラブルシューティングを迅速化し、ダウンタイムを削減する仕組みを指します。

あなたが ITOps、DevOps、または SRE チームで、問題が雪だるま式に大きくなる前に問題を見つける能力を高めたいと考えていますか? あなたは間違いなく正しい場所にいます。

LM Logsがあれば、データを闇雲に精査する必要はありません。この記事では、LM OpsがITOps、DevOps、SREのプロフェッショナルにとって、ノイズを排除し、異常をリアルタイムで特定し、「何が起こっているのか、どこで起こっているのか、そしてなぜ起こっているのか」という重要な疑問に答える上でどのように役立つかを詳しく説明します。

LogicMonitorのTechOpsチームをご紹介します

の使命 技術運用 LogicMonitorのチームの使命は、顧客にLogicMonitorのサービスを提供する信頼性の高いコンピューティングプラットフォームの構築、拡張、維持です。彼らの仕事は、以下の2つの優先事項に重点を置いています。

＃1 – サービスの可用性を向上させて顧客体験を向上させる

＃2 – プロセスのスケーリングや自動化、アラートの積極的な調整、他部門からのリクエストへの対応などにより、同僚の仕事を楽にする

目標は、お客様に信頼性の高いLogicMonitorエクスペリエンスを提供すること、潜在的な障害をエスカレートする前に特定すること、事後対応ではなく予防的な対応を維持すること、そして技術的負債の蓄積を防ぐことです。また、チームはLogicMonitor自体も使用して、LMの自社サーバーの円滑な運用を監視し、確保しています。

LMログの概要

ログは、システム内で何が起こっているかを記録するものです。これには、ユーザーの操作、自動化されたプロセス、予期しないエラーなどが含まれます。ログは、アプリケーションの動作を理解し、問題をトラブルシューティングし、メトリックだけでは提供できない詳細情報を補うために不可欠です。

しかし、正直に言うと、従来のログレビューは時間がかかり、手作業で、多くの場合、推測の連続です。ツールを切り替え、山のようなデータを精査し、文脈もほとんどないまま点と点を繋げようとします。特に、時間に余裕がなくプレッシャーが大きい場合には、非常に苦痛です。

LM Logs は、ログ データをすぐに実行可能にし、既存の監視ワークフローに直接統合することでこの問題を解決します。

特許取得済みのアルゴリズムを使用し、あらゆるログ、データポイント、イベントをプラットフォームに到達した瞬間に分析します。独自のクエリ言語を習得したり、膨大なメッセージの中から重要な情報を見つけ出す必要はありません。LM Logs は異常を自動的に特定し、重要なイベントをリアルタイムでエスカレーションします。

LogicMonitorのメトリクスとダッシュボードと完全に統合されているため、プラットフォームを離れることなく完全なコンテキストを取得できます。ログデータは、パフォーマンスグラフやアラートからすぐにアクセスでき、すぐに活用できます。

この図は、LM Logs が環境全体（クラウドプロバイダー、サーバー、コンテナ、SaaS アプリなど）からデータを収集し、LogicMonitor プラットフォームにフィードしてリアルタイムの異常検知を行う仕組みを示しています。ログとメトリクスは単一のシステムを通過するため、チームはツールを切り替えることなく、より迅速にトラブルシューティングを行うことができます。

LM Logs が導入される前は、インシデントの根本原因の特定や事後検証に何時間もかかることがよくありました。エンジニアはツールを切り替えたり、コンテキストのないログを解釈したり、イベントにメトリクスを手動で関連付けたりする必要がありました。これにより調査が遅延し、プレッシャーの中で行動することが困難になっていました。

LM Logs を使用すると、ログとパフォーマンス データが 1 か所に並べて保存されるため、すべての運用チームが知っておく必要のある 3 つの質問に即座に答えることができます。

何が起こっているのか、どこで起こっているのか、そしてなぜ起こっているのか。

LMログが登場する前は、問題のトラブルシューティングには専門知識が必要でした。今では、ログが重要な情報を教えてくれます。

LMログが現実世界の運用をどのように強化するか

LogicMonitorでは、ログデータは簡単にアクセスでき、簡単に対応でき、すべての運用チームの日常的なワークフローに組み込まれるべきだと考えています。LM Logsは、 IT運用チームとDevOpsチームを念頭に置いて構築.

LM TechOps チームが LM Logs の統合によってどのようなメリットを得たか、実際の例を以下に示します。

#1 – Kafkaブローカーインシデント = 不確実性から明確さへ

チームは、サーバーは機能し続けたものの、Kafka ブローカーがリーダーシップを失い、データを適切に複製しなくなったという問題に遭遇しました。

LMログの前に、アプリケーションは カフカ それ自体は問題の原因を特定するのに役立たず、複数のチーム メンバーが何時間もかけて問題が何であるかを正確に把握する必要がありました。

LM Logs の後、チームは別のサーバーで同じ問題に関するアラートを受け取りました。今回は、社内の知識ではなく、アラートとログメッセージが並んだ LM Logs によって、すぐに原因を特定できました。

 メトリックベースのアラートと相関ログの異常の組み合わせにより、何が起こっているかを簡単に理解できるようになりました。

#2 – TSDB + Kafka RCA = 数百万のログ、XNUMXつの答え

マルチテナント TSDBサーバー Kafka からのメッセージの消費を停止し、150 社を超える顧客のサービスに影響を及ぼしました。

通常、このような問題を診断するには、複雑なログ クエリとアプリケーション サーバーの動作に関する深い知識が必要になります。 

LM Logs を導入する前は、根本原因の調査に数時間、場合によっては数日かかることもありました。LM Logs を導入した後、チームはわずか80分で問題を特定の顧客に限定することができました。6.2万行のログのうち、LM Logs は91件の異常を検出しましたが、これは全体のわずか0.0000145%に相当します。これにより、最も重要な点に焦点をすぐに絞り込むことができました。

#3 – MTTRの短縮 = 戦略会議での時間の短縮

運用チームは、特に容量の制約に関係する場合は、パフォーマンスの問題を早期に積極的に特定できる必要があります。この例では、オンコール エンジニアが、応答時間が低下したことを示すメトリック ベースのアラートを受信しました。

場合によっては、問題の原因を見つける唯一の方法は、実際のログを読むことです。LM Logsが導入される前は、800,000万件以上のメッセージをスクロールして確認する必要があり、これは不可能でした。LM Logsの導入後、オンコールエンジニアはアラートに対応する際に、関連するログをすぐに確認できるようになりました。  ログ異常.

ある異常は、手動での解決が必要なバグを明らかにしました。また、長期的な是正措置を講じ、問題の再発を防ぐために必要な洞察も提供しました。 

この場合、ログの異常は、パフォーマンスの問題が発見された 04 分間の合計ログ量の 90% を占めていました。

オンコール エンジニアは LM ログを使用して、841,000 行を超えるログの中からこの異常を検出しました。

ログの過負荷から即時の洞察に移行する準備はできていますか?

LM Logs は、すべてのログデータとITインフラストラクチャのパフォーマンス指標を単一の統合プラットフォームに集約します。高度なアルゴリズムを用いてログの異常を自動的に検出・識別し、手間のかかる分析作業を排除します。

LMログは、トラブルシューティングと根本原因分析にかかる時間を大幅に短縮し、インシデント対策本部の設置を回避します。問題の原因を明らかにするだけでなく、チームが長期的な是正措置を講じるために必要なデータも提供します。