この記事では、サーバー監視については知っているけれど、Mackerelは初めてという方に向けて、Mackerelの主要な機能をご紹介します。
- 本記事で使用する構成例
- Mackerelにメトリックを投稿する
- ホストにサービスとロールを設定する
- 監視を設定する
- サービスを監視する
- アラートに気付くために通知を設定する
- ダッシュボードを使って情報を一元化する
- まとめ
本記事で使用する構成例
例として、AWSのクラウド製品を利用して構築したWebアプリケーションを監視できるよう、Mackerelを設定していきます。ALB、ECS、RDSをもちいたインターネットを介してアクセスする典型的なWebアプリケーションとしました。
Mackerelにメトリックを投稿する
監視運用を始めるためには、まずアプリケーションの状態を把握する必要があります。今回はAWSを利用するため「AWSインテグレーション」の設定を行っていきます。 監視対象のサービスにアクセス可能なIAMロールをAWS上で作成し、MackerelのAWSインテグレーション設定でそのIAMロールを指定します。MackerelのAWSインテグレーションがサポートするサービスの中からALB、ECS、RDSを選択し、それらのメトリックをMackerelに投稿するようにします。AWSでのロールの作成手順やAWSインテグレーションの設定等の詳細については、Mackerel ヘルプ内のAWSインテグレーション を参照してください。
ECSの場合は、mackerel-contaier-agentを利用してより詳細なメトリックを取得することも可能です。下記記事で解説しています。
ホストにサービスとロールを設定する
Mackerelでは、ひとつひとつのホストをそれぞれそのまま管理するのではなく、適切な単位でグルーピングし、そのグループ単位で管理や設定を行います。 サービスとロールには設計のパターンがありますが、詳しい設計パターンについてはまた後日紹介します。 サービスとロールの作成方法はサービス、ロールを作成する - Mackerel ヘルプをご確認ください。
今回は、先程あげた構成図のwebアプリケーションで、Mackerelのサービスとロールを割り当てて監視設定を行っていきます。
具体的には、システムの中の今回のWebアプリケーションを、Mackerel上ではサービスとして捉え、アプリケーションを構成する各クラウド製品をロールに割り当てます。
今回はサービスとロールの設計の一例として、サービス名を sample、ロール名を alb、ecs、rds として作成し、AWSインテグレーションで連携したホストをそれぞれに割り当てます。
用意するサービスとロール
sample:albsample:ecssample:rds
ホストの一覧画面から、AWSインテグレーションで連携されたAWSのクラウド製品に対し、それぞれサービスやロールを作成・割り当てできます。
なお、AWSインテグレーションでのサービスとロールの設定には、AWSのクラウド製品に固定のロールを設定するデフォルトロール機能や、AWSのクラウド製品に紐づけたタグからサービスおよびロールを設定する機能も用意されています。
監視を設定する
Mackerelでは、メトリック監視、式による監視、外形監視など、さまざまな方法で対象を監視できます。 ここではAWSインテグレーションで連携したクラウド製品に割り当てたロールに対して、メトリック監視・式による監視、Webアプリケーション全体に対して外形監視を設定していくことにします。
リソースの監視を行う
AWSインテグレーションで連携すると、ECSクラスタ単位でCPU使用率やメモリの使用率などがメトリックとして収集されます。例えばサービスが安全に動作するリソースの閾値をMackerelでのメトリック監視のアラート通知閾値として採用すれば、リソース不足に気付くことができます。
ECSクラスタ内のタスクに含まれるアプリケーションの詳細な状態の監視については、mackerel-container-agentにおけるプラグイン導入方法のご紹介でmackerel-container-agentとアプリケーションからの具体的な状態取得の方法を解説していますので、ご参照ください。
RDSではCPU使用率、メモリ使用率、DB接続数、ディスクの空き容量などをメトリックとしてMackerelで監視できるので、それらに対して設定を行うとよいでしょう。 Mackerel で RDS を監視するときによく使われるメトリックについてはこちらの解説記事もご参照ください。
サービスを監視する
リソースの監視のみでは、実際にWebアプリケーションの利用者がアクセスできているか、理想のパフォーマンスでサービスを提供できているかといった観点では不足してしまう場合があります。これを補う方法の１つとして、サービスの監視をしてみましょう。
Mackerelを使った外形監視を設定する
サービス監視の一例として、外形監視を設定してみましょう。Mackerelでは、さまざまな条件に応じてアラートを発生させることができます。
監視対象に設定したURLに対し、Mackerelから定期的にリクエストが送られます。実際に利用者が触れる画面や、APIのエンドポイントなどを監視することで、Webアプリケーションがアクセス可能な状態であることを確認できます。
外形監視の設定ではレスポンスタイムの閾値や期待される応答などを指定することもできますが、あくまでもMackerelからのそのリクエストへの応答に対してのみの監視となり、Webアプリケーション全体としてみると網羅性がやや不足します。そのため、ALBのメトリックとして取得できるステータスコードの割合やレスポンスタイムなどを監視項目として追加すると、より効果的です。
式監視を利用してエラーの割合を監視する
Mackerelの外型監視では、Mackerelからのリクエストに対してのみの評価となるため、外型監視ではエラーを返してなかったが、他からのリクエストはエラーを返しているような状態だと障害に気付くことができません。 そこで、ALBのメトリックで取得できるステータスコードの数をMackerelの式監視と組み合わせることで、エラーレスポンスを返している割合として監視できます。
また、式監視を利用すれば、ALBのメトリックで取得できるヘルスチェックで正常なホストの割合などでも監視を設定できます。これにより、ECSクラスタでのオートスケールなどタスク数に依存しない柔軟な監視設定が可能です。
アラートに気付くために通知を設定する
Mackerelでは、通知設定を行うことで、メールやSlack、LINE、さらにはTwilioを使った架電通知などの連携が行えます。 アラートの受け取り手段としていくつかの連携設定をすることで、例えば対応への遅れのような状況に陥るのを避けられます。
アラートの情報には詳細情報を確認できるURLも含まれており、このURLを開くとMackerel上で時間軸での変化の様子などを追跡できます。また、アラートの事象が解決するとアラートは自動でクローズされますが、詳細情報はMackerel上では削除されることはなく、サービスやロールなどで絞り込み、過去にさかのぼって検索できます。
また、Slackでの通知では、アラートのレベル（CriticalやWarningなど）でメンション先を切り替えることができます。 詳しい設定方法は Slackにアラートを通知する - Mackerel ヘルプ をご覧ください。
ダッシュボードを使って情報を一元化する
Mackerelではアラートが発生した際に、Mackerelのアラート詳細画面ではアラートの発生理由とグラフをあわせて確認できます。加えて、アラートが発生した時点での他の関連する要素なども一目で確認できると、問題解決をよりスムーズに行えるでしょう。Mackerelのカスタムダッシュボードという機能を使うと、一元的に確認しやすいページを作成できます。詳細については下記記事を参照してください。
カスタムダッシュボードに載せる情報としては、アラートが発生したときにまず見たいものを並べるのがおすすめです。例を以下に示します。
- ALBでのエラーレスポンスを返している割合
- かつて障害を検知できたメトリック
- ALB のレスポンスタイム
- ECS のリソース
- RDS のリソース
まとめ
この記事では、「手軽に始める」と題して、サーバーにエージェントを入れるといった作業なく、クラウド製品を連携させてMackerelで監視するための使いかたを説明してきました。 Mackerelには、この記事で触れなかった機能もたくさんありますので、どうぞご利用ください。
