Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

システム監視って結局なに?

More than 3 years have passed since last update.

こんなことありませんか??

システム監視?とりあえずツール入れたろ!

1週間後
なんかアラートメールいっぱいくるンゴ

1か月後
特に問い合わせもなさそうだし大丈夫かな・・・

3か月後
メール届き過ぎ、うざいからフォルダ分けして隔離したろ!

ある日
監視してたのに障害起こったンゴw

何が問題??

・通知のさせすぎで重要な通知を見落とす可能性
・監視ツールを導入したが、実際に今システムがどんな状態なのかわからない
・監視したい項目がカバーしきれない

今回は過去のプロジェクトを例に、監視ツール(NewRelic)と監視スクリプト(powershell)を使い監視基盤を改善しました、というお話です。

※当時のリソースが見れなくなってしまったので、画像すくなめです・・

AsIs

参画以前から基盤自体は存在していました
image.png

◆やっていること
 ・アプリで発生したエラーをTableStorageに格納。
  オンプレの監視サーバからTableStorageを監視スクリプト(powershell)で数分おきに確認。
  エラーがあればメール通知。
 ・サーバのメモリ使用量等のインフラ寄りなアラート通知は
  Azureの標準監視機能を使用。

◎ポイント
 ・アプリケーションではログ出力以外に、エラー発生のタイミングで検知用のエラーコードをTableStorageに出力している。

ある程度監視構成はできていますが、以下の問題がありました。
 ・検知したエラーは全て通知
 ・検知したいエラーが不足している
 ・通知されたエラーの原因がわからない、そのための調査材料はログだけ
 ・そもそも現在システムが稼働しているのかどうかわからない

次のToBeでは監視スクリプトの改修と監視ツールを導入した状態になります。

ToBe

image.png

構成としては
  監視スクリプト     :アプリケーションから出力される細かなエラーの検知
  監視ツール(NewRelic):サーバ(CPU、メモリ使用率)監視、アプリの死活監視
といった使い分けとなりました。

ToBeに向けてやったこと

①エラーの原因を調査

結果からエラー毎に重要度のレベル分け
 アラート:単発でも発生したらまずい
 警告  :頻度が高ければ調査が必要

② エラー別に通知の閾値を設定

①の結果を踏まえ監視スクリプトでエラー検知時に、同一エラーコードに対し閾値を設定
image.png
閾値を超えていればエラー通知処理(ごりごり・・・)
image.png

③監視ツール(NewRelic)の導入

不足していた監視項目をカバー(システムの死活監視など)また、通知用の閾値も設定。
   

NewRelicについて

NewRelicはアプリケーションのパフォーマンス計測や、サーバのリソース監視はもちろんですが自分でプラグインの開発もできます。
そのため柔軟性のある監視をすることができるので(後述)、導入メリットは高いと思います。

サーバのアラート(メモリ使用量が90%超えたみたいな)が通知されてきたとしても、それだけでは実際に何が起こっているのかわかりません。
NewRelicはサーバやプロセス単位で、現在と過去の状態をグラフィカルな画面から確認することができるので、アラート発生時に何が起きていたかという点を探りやすいのも魅力です。
⇒NewRelicポータルからサーバやアプリの状態履歴を確認し原因調査にも使用
 開発時のパフォーマンスチェックにも使用可能

サーバの状態の傾向をつかむことができれば、重大な障害が起こる前に予兆を知ることもできます。

※NewRelicポータル画面例※
image.png

image.png

※公式
https://newrelic.com/

結果どうなった??

必要な分のエラー通知とその原因調査の簡略化が可能になり、通知されるエラーを確認する運用担当者、エラー原因を調査し改善する開発担当者の双方の負担を減らすことができました。

監視ツールは導入や通知設定が簡単な一方で、アプリケーションエラーの検知は標準機能だけではできないことが多いです。
今回は逆の導入順序となりましたが、そのカバーのためにpowershellを使えば素敵な監視基盤となるのではと思います。

おわりに

話がそれましたが、システム監視とは
  障害が起きたことを通知する
だけではなく
  障害が起きる前に危険性を通知する
というこだと感じました。

そのためには、必要な情報を必要なタイミングで知ることが大切です。そういった環境をシステム構築時に用意したいものです。

最後にNewRelicを少しアレンジして使った監視例を載せてみます。

NewRelicを用いた監視例

死活監視

監視のトリガーとアラートメール通知をNewRelicで実行しています。
NewRelicからのリクエストをAPIで受け取り、そこから監視対象のサービスを決めた条件に従って確認します。
最終的に全サービス稼働しているかどのサービスが稼働していないかをNewRelicから返しています。
image.png

本来アプリのエンドポイント用の監視機能ですが、レスポンスの内容をアレンジできるため1度のリクエストでシステムを構成する全サービスの稼働が確認できました。

プラグイン作成

既存のプラグインも多くあり、そこから選んで使用できますが自作することもできます。

NewRelicはAPIも充実しており
監視したいデータをポストするだけで、その閾値・アラート通知・ポータル画面での履歴確認まで簡単に行えます。
image.png

定期的にDBからデータを取得し、その結果をNewRelicへ送るというプログラムを監視サーバ上で実行します。
データが特定の値を超えたらアラート通知させる、というように監視したい項目やアラート条件を自分で設定することができます。

U1second
Blessing Softwareの大林雄一郎です。 新浦安が好きです。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away