NewRelicで基本的な監視項目を設定してみた

## はじめに
:::note info
この記事は「[Infocom Advent Calendar 2022](https://qiita.com/advent-calendar/2022/infocom)」カレンダーの15日目の記事です
:::
業務でNewRelicを調査する機会があったので、
NewRelicの基本的な監視項目の概要と、これまで触ってみた感想をまとめてみます。

## 前置き

みなさんはサービス監視をどのように実施しているでしょうか？
私がこれまで担当してきたサービスはZabbixが多かったです。

## Zabbixの気になる点
Zabbixは柔軟に監視設定できるので、「ちょっと監視難しそうだけど、Zabbixならなんとかできるっしょ」みたいなことはよくありました。Zabbixすごい。
が、あえて気になる点についてまとめてみます。

* 柔軟に設定できるがゆえに学習コストが高い
私自身、テンプレート、アイテム、トリガーなどの仕組みの理解に苦しんだ経験が、、、
担当者が変わると監視項目のメンテナンスができないことがある。
（Zabbixを扱うチームには、一人はZabbix職人がいるはず。）

* Zabbixサーバが停止したら全監視がストップする
Zabbixサーバを監視するためにZabbixサーバを立てて・・・みたいなことが必要に。

* ZabbixエージェントをPaaS環境に移行できない
Zabbixエージェントをインストールできないため、PaaSではZabbixを用いた監視ができない。

そこで、私のチームではZabbixからクラウドサービスのNewRelicへの移行を検討しています。

## NewRelicとは

> New Relic is an observability platform that helps you build better software. You can bring in data from any digital source so that you can fully understand your system and how to improve it.

https://docs.newrelic.com/docs/new-relic-solutions/get-started/intro-new-relic/

監視できる項目が多すぎて、最初度肝抜かれたのを覚えています。

今回は、インフラ監視(Infrastructure)、外形監視(Synthetic)、アラート(Alerts & AI)、エラーインボックス(Errors inbox)について話していきます。
導入手順については割愛しますが、インフラ監視(Infrastructure)はNewRelicプラットフォームの「Add data」から環境にあったボタンをポチポチと押していくだけで導入スクリプトが表示され、それを環境で実行するだけだったのですごく簡単でした。

## インフラ監視(Infrastructure)
インフラ監視は、CPU稼働率、メモリ使用率、ストレージ使用率など。(個人的に監視といったらこれ)
![Infrastructure_system](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2993387/ca770950-dc95-621b-a936-c552f9ffc6e8.png)

また、settingsタブから、アラートのためにトリガー条件を設定することができます。
障害の深刻度はCritical(下画像中の赤`!`)とWarning(黄`!`)が登録できます。
![Infrastructure_settings](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2993387/95628b8e-7aee-370a-8ee4-77fb1433f12f.png)

## 外形監視(Synthetic)
システム環境の外側からアクセスして稼働状況を確認するために使用しています。
ログインページなどのURLを指定し、指定した間隔でサイトにリクエストを投げてくれます。
また、スクリプトを用いてシナリオ監視を実行することも可能です。（例えばID/PASSを入力してログインするなど）
ここでは`Success rate:100%`と出ているので、WEBサービスに問題は無いと分かります。
![Synthetics](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2993387/7c1fc16a-0a29-1e19-7c5c-1dc5d7aca8a0.png)


## アラート(Alerts & AI）
トリガー条件(閾値)を設定し、メールはもちろんSlackなどでも通知してくれます。通知の内容はカスタマイズできないっぽい。
（`AI`と書いてある通り、メトリクスの変動をAIが学習し自動で通知してくれるようにする設定もありますが、まだ使ったことはありません、、、）

メールはこんな感じ。障害がactiveかcloseかは件名では判断できず、本文中の`High priority issue is active`の部分を確認する必要があり、少し分かりづらい印象です。
<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2993387/900b2de9-6129-dda5-8d9b-f548ee10ff34.png">

Slackはこんな感じ。メールよりも気づきやすそう。closeしたらスレッドで返信されるため、どの障害がcloseしたかSlack上で把握しやすいと感じました。
<img width="800" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2993387/49c6a7b5-3b05-d41f-3d66-03b5db7c0ed1.png">

## エラーインボックス（Errors inbox）
今回取り上げていないAPM機能などで出力されたエラーログを一元管理し、Slackで通知してくれます。この機能が一番感動しました。

* エラーがグループ化されるので、過去にも出たエラーかどうかを把握しやすい。
* 無視して良いエラーを`ignore`にすることで以降通知しないようにすることもできるため、使い続けるうちに本当に通知してほしいエラーだけを厳選でき、ノイズを削減することにつながる。
* `QueryFailedError`をクリックすると詳細なスタックトレースやHTTPレスポンスヘッダなどを確認できて、調査が簡単にできる。
![Errorsinbox](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2993387/adb279dd-3385-1a9d-837a-2c2c23a51eeb.png)


## 最後に
今回はNewRelicを触ってみた感想と、基本的な監視項目についてまとめてみました。
私自身勉強中で、まだ把握できていない便利な機能がたくさんあると思うので、いろいろ触りながら理解していこうと思います。

途中でも書いたように、NewRelicは非常に監視の項目が多くて魅力的な分、NewRelicの導入初期段階に、あれもこれもといろんな機能に手を出してしまうと、やりたいことが発散してしまうかなあと感じました。そのため、最初はNewRelicを導入する目的を明確にした上で、監視対象を絞ってNewRelicを触っていくのが良いと思います。

私の場合は、まずは「いまのZabbix監視をNewRelicに置き換えるぞ！」という目標を掲げていたので、取り組みやすく感じています。


## 最後の最後に
今回が初投稿でした。これから少しずつアウトプットを増やしていけれるように頑張ります！

## 参考
https://newrelic.com/jp/blog/best-practices/new-relic-infrastructure-analysis

https://newrelic.com/jp/blog/how-to-relic/newrelic-synthetics-overview

https://newrelic.com/jp/blog/nerdlog/error-tracking-with-errors-inbox