New Relicでエージェントができること
NRQLで質問に答える
今週遅くなったエンドポイントや、あるお客様に出たエラーの数を尋ねると、NRQLを書いて実行し、数字が妥当かを確かめ、クエリを見せて答えます。
頼み方先週と比べて今週遅くなったトランザクションは？使ったNRQLも見せて。
発生中の問題を調べる
アラート条件で問題が開くと、インシデント、遅いトランザクションのトレース、エラーの受信箱、そのエンティティの直近の変更を読み、いちばん考えられる原因を、許可を得てSlackに投稿できる形でまとめます。
頼み方orders-serviceで重大な問題が開いています。原因は何で、まだ悪化している？
デプロイの前後を比べる
変更追跡のデプロイマーカーとGitHubでのマージをもとに、リリースごとに前後1時間の応答時間、スループット、エラー率を比べ、悪くなったサービスに印を付けます。
頼み方本番デプロイのたびに前後1時間を比べて、性能が落ちたサービスがあれば教えて。
エラーの受信箱を片付ける
毎朝、新しいエラーグループをサービスと影響人数でまとめ、関係しそうなコードの場所を示し、担当者とJiraのチケット案を提案します。割り当てや解決は事前に確認します。
頼み方平日9時に、受信箱の新しいエラーグループを確認して、それぞれの担当者を提案して。
アラート条件を見直す
先月いちばん多くインシデントを開いたのに、だれも対応しなかった条件を見つけ、実際のデータからしきい値や継続時間の案を下書きします。条件の編集は事前に確認します。
頼み方先月、だれも対応しなかったインシデントをいちばん多く開いたアラート条件は？よりよいしきい値を提案して。
サービスのダッシュボードを作る
エンドポイント別のレイテンシ、エラー率、遅いデータベース呼び出しなど、サービス用のNRQLウィジェットのダッシュボードを下書きします。アカウントへの作成は事前に確認します。
頼み方購入サービスのダッシュボードを作って。エンドポイント別のレイテンシ、エラー率、遅いクエリ。
サービスレベルを報告する
毎週月曜に、サービスレベルを読み、目標を外れたものとその理由を記して、開発の定例会議用にGoogle スライドへまとめます。
頼み方毎週月曜に、先週のサービスレベルの結果を開発レビュー用のスライド3枚にまとめて。
接続のしくみ
- 1New Relicは、ユーザーキーかあなた自身のログインで一度接続します。エージェントはそのユーザーのアカウントと役割の範囲で働くため、読み取り専用のユーザーなら、承認があってもアラートは変えられません。
- 2New Relicを使えるエージェントはあなたが選びます。開発担当には必要で、データ分析の担当がレポートのために読むこともあります。営業やサポートの担当には不要です。
- 3クエリの実行と、トレース、問題、ダッシュボードの読み取りは確認なしで行います。アラート条件やポリシーの編集、ダッシュボードの作成、ミュート、エラーの割り当てと解決は事前に確認します。
開発・ITのほかのアプリ
同じ種類のアプリでも、エージェントが働けます。それぞれのページで詳しく紹介しています。
よくある質問
AIエージェントはNRQLのクエリを書けますか？
書けます。ふだんの言葉で尋ねると、エージェントがNRQLを書いて実行し、結果を説明します。クエリも見せるので、ダッシュボードやアラートにそのまま使えます。障害の時間帯を外しているなど、最初の結果がおかしいときはそう伝えて、クエリを直します。
アプリが遅くなった理由を見つけられますか？
掘り下げを引き受けます。遅い時間帯とふだんの時間帯を比べ、トランザクションのトレースとデータベースの所要時間を読み、デプロイマーカーを確かめて、いちばん疑わしい変更を示します。作業はNew Relicとの連携で行い、連携でできない操作はエージェントが自分のブラウザーで進めます。
New Relicのアラート条件を確認なしに変えますか？
変えません。条件、ポリシー、通知の編集はどれも、変更前後の設定と、変更の根拠になったデータを載せたカードで確認します。確認なしに行うのは読み取りとクエリだけなので、あなたが変更を許可するまで、アラートはチームが設定したとおりのままです。
New Relicのユーザーキーをエージェントに渡しても安全ですか？
ユーザーキーは持ち主のユーザーの権限で動くため、仕事に必要な権限だけを持つユーザーで作ってください。変更には承認という二重の確認もかかります。キーはNew Relicでいつでも削除でき、その時点でエージェントは使えなくなります。