ログパイロット
最終更新日 - 13年2026月XNUMX日
LogPilotは、LM LogsのAIを活用した生成機能で、自然言語クエリによるログ検索を可能にします。LogicMonitor Observatory Query Language(LMOQL)や正規表現を記述する必要がなくなります。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 minutesGet 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 でカウント |