LogicMonitor + Catchpoint: 自律型ITの新時代へ

さらに詳しく

LogPilotは、LM LogsのAIを活用した生成機能で、自然言語クエリによるログ検索を可能にします。LogicMonitor Observatory Query Language(LMOQL)や正規表現を記述する必要がなくなります。LogPilotを使用すると、特にインシデント対応や根本原因分析といった時間的制約のあるシナリオにおいて、ログデータを迅速に探索できます。 

LM ログの LogPilot

LogPilot を使用すると、次のことができます。

  • ログを検索するには、わかりやすい言葉のプロンプトを使用します
  • ログクエリを自動的に生成して実行する
  • フィールドレベルや正規表現の専門知識がなくてもログを分析できます

これにより、トリアージが加速され、専門家以外のユーザーにとってログ分析の障壁が下がり、洞察を得るまでの時間が短縮されます。

重要: LogPilot は厳格なデータ分離を採用しています。ログはテナント内に保存され、他のお客様と共有されたり、テナント間のデータセットに統合されたりすることはありません。入力したプロンプトや関連するログデータは、ポータル間でのモデルのトレーニングには使用されず、他のユーザーがお客様のデータから洞察を得ることもありません。

LogPilot プロンプトのガイドライン

LogPilot は、明確で具体的な自然言語プロンプトで最も効果的に機能します。正確なクエリとより関連性の高い結果を生成するには、以下のガイドラインに従ってください。

ガイドライン 詳細説明 入力テキストの例生成されたクエリ
自動フィールドマッピングLogPilot は、一般的に使用される LM ログ フィールドを認識し、自然言語のフレーズを対応するログ フィールド名にマッピングします。Show logs for resource group Resourcegroupname01_resource.group.name = "Resourcegroupname01"
ユーザー提供の値LogPilot はフィールド名を自動的に認識しますが、対応するフィールド値は必ず指定する必要があります。値の推測や生成は行いません。デバイス名 app-web-01 のログを表示リソース名 = “app-web-01”
解析と集計のためのログサンプルサンプル ログ ラインを貼り付けて、LogPilot にフィールドを抽出したり、パターン マッチングを使用して集計を適用したりするように指示できます。次のログメッセージからユーザーIDを抽出し、ユーザーIDごとにログの数をカウントします。ログメッセージ – タスクはユーザーID user1 によって 10:00:20 IST に開始されました。oql_message ~ "Task initiated by UserID"
| parse /Task initiated by UserID (.+?) at/ as UserID
| count by UserID

LogPilot による時間ベースのフィルタリング

時間範囲は自然言語入力では表現できません。LogPilot は「過去10分」や「過去1時間」といったフレーズを解釈できません。クエリを送信する前または送信後に、タイムピッカーを使用して時間範囲を定義する必要があります。

次のタイプの入力は時間フィルターとして解釈されず、LogPilot ではサポートされません。

  • Get logs from the last 10 minutes
  • Get logs for log-process in the last 10 minutes

クエリの例

自然言語入力生成されたログクエリ
リソース名 billing-server の異常を見つける_resource.name = “billing-server”、_anomaly.type = “never_before_seen”
各 Kubernetes 名前空間のログの数をカウントします。* | kubernetes.namespace_name でカウント
グループID 987内の各リソースのログサイズを合計して平均します_resource.group.id = 987 | _resource.name による合計(_size)、平均(_size)
Web サーバー ログから応答時間と URL を抽出し、各 URL の平均応答時間と最大応答時間を計算し、最大応答時間が最も長い順に並べ替えます。_resource.name = “webserver” AND _message ~ “response time” | parse /Response time: (\d+)ms for URL: (.+)/ as response_time, url | avg(response_time), max(response_time) as max_time by url | sort by max_time desc
異常な異常を見つけてリソースIDごとにカウントする
_anomaly.type=”never_before_seen” かつ (_message ~ “error” または _message ~ “fail” または _message ~ “fatal” または _message ~ “terminate” または _message ~ “kill” または _message ~ “exception” または _message ~ “timeout”) | _resource.id でカウント
名前空間「p01-us-east-1-demo」からコンテナ名「log-write」を持つリソースのログを検索します。メッセージには「flushing chunks」と「b69278」が含まれているはずです。結果は1時間ごとのバケットにグループ化され、各バケットのログエントリ数がカウントされます。最後に、結果は時間に基づいて降順で並べ替えられ、最新のバケットが先頭に表示されます。kubernetes.namespace_name = “p01-us-east-1-demo”、kubernetes.container_name = “log-write”、“flushing”、“b69278” | bucket(span=1h) | count by _bucket | sort by _bucket desc
コンテナのログプロセスのログを検索するkubernetes.container_name = “ログプロセス”
すべてのエラーログを検索し、リソースIDごとにカウントします_message ~ “error” | _resource.id によるカウント
ログから処理時間を抽出し、最大処理時間を見つける_message ~ /sql db はクエリ '(.+?)' に (\d+) ミリ秒かかりました/ | parse /sql db はクエリ '(.+?)' に (\d+) ミリ秒かかりました/ as response_time, query | num(response_time) as numeric_response_time | avg(numeric_response_time) by query
次のログから、DB 応答時間とクエリを抽出し、クエリごとの平均応答時間をカウントします。ログ メッセージ – INFO: SQL DB はクエリ 'select count(*) from admins' に 20 ミリ秒かかりました* | /processingTime=(\d+)/ を processingTime として解析 | num(processingTime) を numeric_processingTime として解析 | max(numeric_processingTime) 
各リソース ID のサイズごとの使用状況を時間ごとにログに記録します。* | バケット(スパン=1時間) | _resource.idによる_sizeの合計
ログから IP アドレスを解析し、IP アドレスごとにカウントします。* | /(\d+\.\d+\.\d+\.\d+)/ を ip_address として解析 | ip_address でカウント

14日間フルアクセス LogicMonitor プラットフォーム