ガイドインストールで作成される「Golden Signals」アラートポリシーの仕組みと4つの監視コンディション

新規のアカウントに ガイドインストール (Guided Install) で New Relic エージェントを導入する際に以下のように、「Golden Signal Alerts をインストールしますか？」と聞かれたかと思います。

We've detected additional monitoring that can be configured by installing the following:
 Golden Signal Alerts

? Continue installing?  (Y/n)

Yes を選択し、インストールされたものの、実際に何が、どこにインストールされているのかよく分からない、ということがあったかもしれません。 または、UI の Alerts > Alert Policies にて「Golden Signals」という作成した覚えのないアラートポリシーが作成されていることに気がつく、ということがあったかもしれません。

本記事では、このガイドインストールで作成される「Golden Signal Alerts」について、解説します。

ガイドインストール時の挙動

下記はインフラエージェントを Linux サーバにガイドインストールで導入した際の表示で、追加のモニター項目として、Golden Signal Alerts が導入可能（見つかったので）「導入するか？」と聞かれています。

ここで Y (Yes) を選択した場合、Golden Signal Alerts が導入されることになり、さらに アラート通知設定も行うか？と続けて聞かれます。

ここでも Y (Yes) を選択した場合、利用した User Key ユーザーのメールアドレスへのアラートの通知設定が行われることになります。
デフォルトは N (No) であるため、通知設定は行われなかった方も多いかと思います。

さて、ここで導入された Golden Signal Alerts はなんなのかというと、プラットフォームにアラートポリシー、アラートコンディションと Workflow、Destination が作成されるというものになります。

ガイドインストールによるエージェントのインストール過程であるため、紛らわしいオプションとなってしまっていますが、操作しているホストに導入されるわけではなく、「Golden Signals」というアラートポリシーが設定されるという動作となります。

最初の選択「Golden Signal Alerts を導入するか？」に Yes とした場合は、アラートポリシーと 4つのアラートコンディションが作成されます。 続く「通知も設定するか？」に Yes とした場合は、同アラートポリシーに関する Workflow (および Destination) が作成されます。

各アラートコンディションで条件を満たし、閾値違反となると Email アラートが通知されることになるため、 この段階では、通知の設定は不要という場合は、2つ目の通知設定は、No を選択いただければ、通知設定が行われません。

アラートの通知は不要、という場合は UI より対象 Workflow を削除または無効化いただければ通知を行わないように設定いただけます。

Golden Signals アラートポリシーが作成された記録は、NrAuditEvent に記録されています。

ガイドインストール時 (newrelic CLI) の操作ログは、操作を行ったホストに保存されます。Golden Signals アラートを導入するかに Yes としたか No としたかなどを確認いただけます。

Linux サーバ (ROOT, (sudo 利用) での操作ログの出力パス例:
/root/.newrelic/newrelic-cli.log

Windows サーバでの操作ログの出力パス例:
C:\Users\操作ユーザー\.newrelic\newrelic-cli.log

また、「Golden Signals」アラートの設定は、すでに同名のアラートポリシーが対象アカウントに存在している場合は、以降のガイドインストールでは導入の有無を聞かれません。
ポリシー名のリネームや削除されている場合は、ガイドインストール時に再度、導入の有無が聞かれることになります。
Github > open-install-library > alerts > golden https://github.com/newrelic/open-install-library/blob/main/recipes/newrelic/infrastructure/alerts/golden.yml

各アラートコンディションの設定内容

「Golden Signals」アラートポリシーには 4つのアラートコンディションが含まれています。
各アラートコンディションの設定内容を簡単にご紹介いたします。

導入時に不要なアラートコンディションであれば、コンディションを無効化していただければと思います。

Golden Signals ポリシーには、Golden Signal (Google SRE フレームワーク > The Four Golden Signals ) に関する下記の 4つのアラートコンディションが作成されます。

• High Application Error percentage (アプリ (APM) のエラー率 (エラー数/分) を監視するコンディション)
• High Application Response Time (アプリ (APM) の応答時間が長い場合を監視するコンディション)
• Low Application Throughput (アプリ (APM) のスループットの低下を監視するコンディション)
• High CPU (ホストの 高 CPU 使用率を監視するコンディション)

High Application Error percentage (高エラー率の監視)

• アラートクエリ

FROM Metric SELECT count(apm.service.error.count) / count(apm.service.transaction.duration) as 'Error Rate' WHERE appName LIKE '%' FACET entity.guid, appName

• Window Duration: 1分
• EventFlow (delay: 2分)
• Baseline 閾値: critical: result > 3 SDs for at least 5分

各 APM において、エラーの発生率 (エラー数/トランザクション数) を 1分ごとに算出します。
閾値はベースライン閾値 (異常な振る舞い) で、5回連続 (5分)で標準偏差の 3 より大きい場合に違反と判定されます。

アプリケーションごとに閾値を調整されたい場合は、WHERE 句で対象を絞ったアラートコンディションを複数作成するなどで、ご対応ください。 また、APM が導入されていない場合は、不要なアラートコンディションとなります。

High Application Response Time (応答時間遅延の監視)

• アラートクエリ

SELECT average(newrelic.goldenmetrics.apm.application.responseTimeMs) FROM Metric FACET entity.guid, appName

• Window Duration: 1分
• EventFlow (delay: 2分)
• Baseline 閾値: critical: result > 3 SDs for at least 5分

各 APM において、レスポンス時間の平均値を 1分ごとに算出します。
閾値はベースライン閾値 (異常な振る舞い) で、5回連続 (5分)で標準偏差の 3 より大きい場合に違反と判定されます。

アプリケーションごとに閾値を調整されたい場合は、WHERE 句で対象を絞ったアラートコンディションを複数作成するなどで、ご対応ください。 また、APM が導入されていない場合は、不要なアラートコンディションとなります。

Low Application Throughput (低スループットの監視)

• アラートクエリ

SELECT average(`newrelic.goldenmetrics.apm.application.throughput`) FROM Metric FACET entity.guid, appName

• Window Duration: 1分
• EventFlow (delay: 2分)
• Baseline 閾値: critical: result < 3 SDs for at least 5分

各 APM において、スループットの平均値を 1分ごとに算出します。
閾値はベースライン閾値 (異常な振る舞い) で、5回連続 (5分)で標準偏差の 3 より小さい場合に違反と判定されます。

アプリケーションごとに閾値を調整されたい場合は、WHERE 句で対象を絞ったアラートコンディションを複数作成するなどで、ご対応ください。
テスト環境などで定常的にアクセスが発生しない環境の場合は WHERE 句で除外ください、または、日中のみの場合などは mutingRule などをミュート時間帯を設定ください。 また、APM が導入されていない場合は、不要なアラートコンディションとなります。

High CPU (高 CPU 使用率の監視)

• アラートクエリ

SELECT average(`host.cpuPercent`) FROM Metric FACET entity.guid, host.hostname

• Window Duration: 1分
• EventFlow (delay: 2分)
• 静的閾値: critical: result > 85 for at least 5分

各 ホスト において、CPU 使用率の平均値を 1分ごとに算出します。
閾値は静的閾値 (固定値) で、5回連続 (5分) で 85% を超過した場合、違反と判定されます。

ホストごとに閾値を調整されたい場合は、WHERE 句で対象を絞ったアラートコンディションを複数作成するなどで、ご対応ください。
また、Warning レベルの閾値を追加いただくことも可能です。

おわりに

New Relic を導入した初期段階において「アラート設計の難しさ」を感じられる場合があるかと思います。
ガイドインストールによって設定することができる 「Golden Signals」 ポリシーは、複雑な監視設計のステップをスキップし、業界標準のベストプラクティスに基づいたアラートコンディションを提供してくれます。

まずは、この自動作成のポリシーを Yes で作成することから始めましょう。
アラートが多すぎると感じられましたら、しきい値を少し緩める、またはアラート対象にされたくない場合は、対象から除外をする、または mutingRule を設定いただくなどで調整ください。

インフラ監視のみで APM が未導入であれば、APM に関する 3つのコンディションは不要ですので、APM を導入されるまで無効化いただければと思います。