
Sumo LogicのLog Analyticsは、DevOps、SRE、およびIT運用チームがインフラストラクチャの管理やクエリ構文への対応ではなく、システムの稼働を維持するという本来の業務に集中できるように設計されています。チームは継続的なリリースを通じて、ここ数カ月で意味のある一連のアップデートを提供してきました。実務者にとって最も重要なポイントを見ていきましょう。
AI調査:新しいログ分析パートナーをご紹介します
調査は単一の問いではなく、一連の問いの連鎖です。症状に気づき、ログを取得し、手がかりを見つけ、別のデータソースにピボットし、それを繰り返します。そのプロセスには、コンテキストの把握、パターン認識、そして時間が必要ですが、インシデント発生時にそれらを十分に確保できるチームは多くありません。
Mobotは、Dojo AIプラットフォーム内にあるSumo Logicの対話型AIアシスタントであり、クエリツールから完全な調査パートナーへと進化しました。現在は、適切なデータソースを推定し、異なるログを横断的に推論し、推奨される次のステップとともに完全な因果関係を提示することで、複数段階にわたる調査を自律的に実行します。Mobotは一度に1つの質問に答えるのではなく、調査プロセス全体をあなたと一緒に進めるため、チームはより少ない手作業のピボットで、より迅速に根本原因に到達できます。
注: Mobotの調査機能は現在パブリックプレビュー中です。アクセスをリクエストするには、アカウントチームにお問い合わせください。

クエリを1つも実行せずにメトリクスを探索する
何かが壊れたとき、まず最初の本能は検索することですが、どのメトリックをクエリすべきか、あるいはその構造がどうなっているかを正確に把握していないと、推測に基づく検索を実行して何も得られず、調整しては再試行することになります。そのサイクルは、診断を開始する前の段階で時間を消費し、不必要なスキャンコストを発生させます。
Metrics Browserなら、こうした手探りを排除できます。これは、お使いの環境で利用可能なすべてのメトリック、ディメンション、およびディメンション値を網羅した、インタラクティブで検索可能なカタログです。メトリック名で閲覧し、関連するディメンションと値を探索し、探索的検索を一度も実行することなく、メトリックをそのままクエリに挿入できます。その結果、根本原因分析が迅速化され、データ消費コストを削減できます。

Claudeを可視化する
AIツールは本番スタックの一部になりつつあり、つまり他の本番システムと同様に監視する必要があります。しかし、ほとんどのチームは、APIが健全かどうかといった基本的な問いに答えるだけの可視性を持ち合わせていません。リクエストは正常に完了していますか?レイテンシーの急増はどこから発生しているのか、また、使用制限内に収まっているのか?
新しいClaude Compliance APIアプリは、DevOpsチームとSREチームに、組織全体でのClaude APIの使用状況を監視するための事前構築済みダッシュボードを提供します。リクエスト量、エラー率、レイテンシ、およびコンプライアンス関連の使用パターンを追跡します。
ChatGPTアプリは、OpenAIのツールに対して同様の範囲をカバーします。詳細なメタデータ、コンテンツ分析、監査証跡を利用してインタラクションパターンを明らかにし、ポリシーに違反するデータ共有行動を検知して警告することで、チームはコンプライアンスリスクが報告対象となるインシデントに発展する前に把握できます。
この2つのアプリを組み合わせることで、従業員が実際に使用しているAIツールに関する可視性のギャップを解消できます。ClaudeとChatGPTがお客様のスタックの一部である場合、他の本番サービスと同様に、これらのサービスについても運用面とコンプライアンス面の可視性を確保できるようになりました。

クエリロジックは一度定義すれば、どこでも利用できます
ほとんどのチームは、環境タグ、サービス識別子、エラーパターンなど、数十のダッシュボード、保存済み検索、アラートに同じフィルタリングロジックを維持しています。そのロジックを変更する必要が生じた場合、誰かがすべての該当箇所を探し出し、手動で更新しなければなりません。手作業で探す場合、必ず何かを見落としてしまいます。
新しいマクロ演算子を使用すると、再利用可能なクエリロジックを一度定義して、あらゆる場所から参照できます。マクロを1カ所変更するだけで、それを参照しているすべてのダッシュボード、アラート、検索が自動的に更新されます。ドリフトなし、コピー漏れなし、手動での突き合わせも不要です。

UIからコレクターを管理、サーバーアクセスは不要です
Windows上でOTel Collectorを実行しているチームでは、これまでは定期的な設定変更のたびにサーバーへの直接アクセスが必要でした。つまり、適切な認証情報を手元に用意するか、チケットを発行して待つかのどちらかが必要でしたが、いずれもインシデント発生中には有効に機能しません。現在、WindowsはAnsible、Chef、Puppetと並んで、OTel Collectorのリモート管理で完全にサポートされています。設定変更はSumo Logic UIから直接行うことができ、サーバーへのアクセスは不要です。
インストール済みコレクターからOpenTelemetryへの移行を簡素化
インストール済みコレクターからOpenTelemetryへの移行は、これまで多大な労力を要し、エラーが発生しやすいプロセスでした。ソース構成を手作業で再構築する必要があり、その途中で間違いを検出するためのセーフティーネットは一切ありませんでした。
新しいガイド付きのプラットフォーム内ワークフローにより、既存のインストール済みコレクターソースを、段階的にOpenTelemetryソーステンプレートへと変換できます。これにより手動設定が削減され、よくある設定ミスを検出し、この種の移行に従来必要だった時間を大幅に短縮します。
ダッシュボード上で注意が必要な箇所を即座に特定
ウォールームやライブのポストモーテムでは、誰にも、密度の高い運用テーブルのすべての数字を読んでいる時間はありません。しかし、重要な外れ値を見つけるために、チームはまさにそれを強いられていました。
Conditional Thresholdsを使うと、しきい値に基づいて表グラフの行やセルに色分けルールを適用できます。重要な値は即座に強調表示されるため、ダッシュボードが読み込まれた瞬間に、チームはどこに注意を向けるべきかを把握できます。

すべてのコレクターを1カ所で確認
複数の組織や大規模なデプロイメントがある環境では、コレクターフリートの健全性スナップショットを取得するには、各組織に個別にログインする必要がありました。デプロイメント全体で、何が稼働しているか、何が劣化しているか、何に注意が必要かを一元的に把握できるビューは存在しませんでした。
新しいコレクション概要ページでは、子組織全体にわたるインストール型、ホスト型、およびOTelコレクターすべてを、健全性ステータス、デプロイ状態、ドリルダウンアクセスなどとあわせて、1カ所から統合的に確認できます。

システム制限が運用に影響する前に先手を打つ
Lookup Table、パーティション、フィールド、フィールド抽出ルールのクレジット使用量は、最悪のタイミング、つまり通常は本番環境で何かが壊れたときに初めて気づかれることが多くあります。現在、これらのいずれかの制限に対する使用率が90%に達すると、自動的にヘルスイベントがトリガーされます。スケジュールされた検索を設定してチームにメールで通知すれば、制限によって障害が発生する前に対応するための余裕を確保できます。

探索を開始する
上記に記載されている機能は、特記がない限り、すべて一般提供中です。リリースの詳細については、新機能ページをご覧いただくか、アカウントチームにお問い合わせのうえ、詳しいご説明をお受けください。



