NRQL アラート: どんな項目もアラート条件として扱える最強のアラート設定

New Relic Advent Calendar 6日目。[昨日](https://qiita.com/kumatronik/items/969473367aa76c937dfe)に引き続き、New Relic APM のアラートに今年追加された設定 **NRQL(エヌアールキューエル) アラート** の紹介。

これは、アラート条件の項目自体を任意の項目で設定できるし、その条件も変更することができるという。いうなれば、なんでもアラート条件の設定項目にできるというすぐれもの。

例えば、EC ストアを運営していたら、あるストア専用のアラート設定を作れたりする。ストア123のレスポンスタイムが0.5秒を越えたらアラート通知とか。

昨日紹介したこれまでのアラート設定では、レスポンスタイムやパーセンタイルなど設定項目自体は用意されていて、そこから選ぶという方式。NRQL はそれが自由ってこと。
自由とは何かというと、NRQL が数字を返す問い合わせなら、その項目を使って設定できる。これを説明するには、NRQL が何かというのを説明する必要があるのでそこから始めていきます。

## NRQL とは

NRQL  (New Relic Query Language) は、[New Relic Insights](https://qiita.com/kumatronik/items/7c115d574c698b81baac) という New Relic の各製品が集めたデータをテーブルとして NRQL という SQL ライクな構文で、問い合わせ文を作って、その結果をダッシュボードにぱしぱし貼って構築していくサービス。(ぱしぱし張ると以下のような感じにできる）

![スクリーンショット 2017-12-06 23.49.04.png](https://qiita-image-store.s3.amazonaws.com/0/46003/48a6670f-bac6-ce97-73da-0aaab1c60408.png)

これを使うと、APM や Browser、Infrastructure のデータを１つのダッシュボードで見えたり、APM だけでも APM の UI より細かいデータを好きな条件でデータを抽出できる。

例えば、直近１時間の全トランザクションの内、レスポンスタイムが2秒を越えたトランザクションの割合を求める NRQL はこんな感じ。`from` の **Transaction** は APM が収集したデータの入っている DB のテーブル名。

```sql
SELECT percentage(count(*), WHERE duration > 2) FROM Transaction
```

![スクリーンショット 2017-12-06 1.06.38.png](https://qiita-image-store.s3.amazonaws.com/0/46003/b4d8ad27-8786-6a73-6793-9f955327d1bf.png)

この場合、結果は上にあるように 0.77%。

このように好きな期間/条件でデータ分析ができる。

New Relic Insights は、New Relic APM などの製品の有料版を使っていれば無料で利用できる。APM の Essentials であれば３日、Pro の場合は過去8日分にデータに対して問い合わせができる。

今回は、NRQL 自体の説明はしないので NRQL を知りたい方は以下の記事を見て下さい。

- [New Relic Insights: NRQL をいろいろ試しみよう（基本編）](https://qiita.com/kumatronik/items/f8c93fdeed7f945b7d32)
- [ドキュメント: NRQL について](https://newrelic.degica.com/docs/insights/nrql-new-relic-query-language/using-nrql/introduction-nrql)

## NRQL アラート

なんとなく NRQL が分かってもらえたと思うので、本題に入る。

**NRQL アラートとは、NRQL が返した結果に対して、アラート設定が行えるもの**です。

先ほどの NRQL をアラートとして設定してみよう。先ほどの NRQL は「直近1時間のトランザクションの内、レスポンスタイムが2秒を越えたトランザクションの**割合**」を求める問い合わせ文。なので、閾値として設定するのは、割合である。何%以上を越えたら、アラート通知したいかを設定する。

閾値の設定方法として、以下の２つから選べる。静的(固定)な値か、動的な値。動的な方は前回説明したベースラインアラートを使って設定する。

## 静的な閾値で設定する方法 (Query)

設定方法は、前回紹介した設定方法とほぼおなじ。[前回同様手順5](https://qiita.com/kumatronik/items/969473367aa76c937dfe#%E3%82%A2%E3%83%A9%E3%83%BC%E3%83%88%E6%9D%A1%E4%BB%B6%E3%81%AE%E8%A8%AD%E5%AE%9A%E6%89%8B%E9%A0%86)から示す。

1. カテゴリ: product として **NRQL** を選択する(デフォルト）、type of condition として "Query" を選択する。"Next, define threshold" をクリック。(NRQL の場合は、エンティティはここでは指定しない）
2. NRQL 入力欄が表示されるので、そこに NRQL を打ち込み、Enter を押すと右下に過去6時間での結果がチャートに表示される。この結果を参考に閾値を決めると良い。
3. Critical の閾値を設定する
4. Warning も設定したい場合は "Add a warning threshold" をクリックし、Warning の閾値を設定する。
4. 画面左下の "Name this condition" にこのアラート条件の名前を付けて、"Create condition" を押す。

![スクリーンショット_2017-12-06_1_16_04.png](https://qiita-image-store.s3.amazonaws.com/0/46003/f7723608-8def-c6bb-d08d-f6fcf90220f4.png)

### Essentials ユーザーでも重要なトランザクションに対してアラート設定ができる

ふと思ったんだけど、これ使えば PRO でしか使えないキートランザクションのように、特定のトランザクションに対してアラート条件を設定できる。Essentials ユーザーの方は是非、これを使って、重要なトランザクションに対してアラート設定してもらえれば重要なトランザクションが異常な状態になった場合にすぐに気付くことができる。

特定のトランザクションの平均レスポンスタイムが 0.5秒以上なった場合にアラート通知する NRQL 

```sql
SELECT percentile(duration, 75) FROM Transaction WHERE name LIKE 'Controller/checkout/%'
```


## 動的な閾値で設定する方法(Baseline query)

前回説明したダイナミックベースラインアラートの NRQL 版。ダイナミックベースラインアラートに関して知りたい方は[前回の記事](https://qiita.com/kumatronik/items/969473367aa76c937dfe)を見てください。

設定方法は、前回紹介した設定方法とほぼおなじ。[前回同様手順5](https://qiita.com/kumatronik/items/969473367aa76c937dfe#%E3%82%A2%E3%83%A9%E3%83%BC%E3%83%88%E6%9D%A1%E4%BB%B6%E3%81%AE%E8%A8%AD%E5%AE%9A%E6%89%8B%E9%A0%86)から示す。

<img width="400" alt="スクリーンショット 2017-12-06 22.29.43.png" src="https://qiita-image-store.s3.amazonaws.com/0/46003/4ebfc655-5e07-08ca-db8b-18082dcea79c.png">

1. カテゴリ: product として **NRQL** を選択する(デフォルト）、type of condition として "Baseline query" を選択する。"Next, define threshold" をクリック。
2. NRQL 入力欄が表示されるので、そこに NRQL を打ち込み、Enter を押すと、右下に過去6時間での結果がチャートに表示される。
3. 閾値はスライダーを調節し、Critical の許容範囲を設定する。左に動かせば、より狭く（基準からはずれれば、アラートが出やすくなる）。右に動かせば、少しくらいいつもと違ってもアラートは出なくなる。どれくらいで、アラートが出やすくなるかは、スライダーを動かしていけば、チャートに赤い垂直線が出たところが今の設定でアラートが出たところ。これでどれくらいがベストかを調整していく。
4. Warning も設定したい場合は "Add a warning threshold" をクリックし、Warning の閾値を設定する。Warning の許容範囲は、薄いグレーで表示され、Warning が出た箇所は、黄色の垂直線がでる。
5. "Create condition" を押す。

※ 前回同様、ベースラインアラート機能は、APM PRO ユーザー専用機能。

## NRQL アラートのすごいとこ

### カスタム属性

NRQL アラートがすごいのは、ここから。New Relic APM には、[カスタム属性](https://newrelic.degica.com/docs/insights/insights-data-sources/custom-attributes/insights-custom-attributes-apm-agents)という任意のパラメーターを APM エージェントが収集するデータに載っけて収集してくれる機能がある。先ほど説明したように、APM のデータは、Insights では、**Transaction** というテーブルに入っている。で、以下のような感じのコードをプロジェクトに埋め込んでおくと、そのキーがカラムになって、その値を Insights 上で見えるようになる。

```ruby
NewRelic::Agent.add_custom_attributes({ user_id: "xxx", store_id: "xxxx" })
```

このような情報をプロジェクトの処理内に埋め込んでおくと、以下のような NRQL が使える。

過去１時間の store_id: 456 の平均処理時間:

```sql
Select average(duration) from Transaction where store_id = '456' 
```

過去１時間に user_id: 123 の 95パーセンタイルの処理時間:

```sql
SELECT percentile(duration, 95) from Transaction where user_id = '123' 
```

### NQRL アラートで、カスタム属性を使ってサービスに有用なアラートを作成しよう

上記で紹介したような NRQL がそのままアラートにも使える。これは、事実上どんな項目に対してもアラートが設定できるようになったといっていい。

これを使うことで、EC ショップを複数運営するサービスの場合、非常に大きな(ビジネス上)サイトを重点的に監視したい場合に、上記のように、カスタム属性を送るようにし、そのストアIDを指定して NRQL アラートを設定することができる。

これは非常に柔軟性のある設定項目なので、是非、みなさんが使っているサービス固有の情報を軸にアラートの設定をしてみてもらえば、より効率的なアラート管理ができるのではないかと思う。この機会に是非、New Relic Insights も使ってみてください。


## 参考情報

本記事でちょっとだけ NRQL で使うアラートを紹介したけど、以下の記事でもサンプルの NRQL を紹介しているので、是非、アクセスして、参考にしてください。

- [ドキュメント:NRQL クエリを使ったアラート条件の作成](https://newrelic.degica.com/docs/alerts/new-relic-alerts/configuring-alert-policies/create-alert-conditions-nrql-queries-cot)
- [翻訳: NRQL アラート正式リリース: アラート条件が NRQL クエリで利用可能に!](https://newrelic.degica.com/blog/2017-05-17-nrql-alerts-generally-available)
- [翻訳: NRQL アラートを活用するための New Relic データの使い方](https://newrelic.degica.com/blog/2017-05-04-nrql-alerts)