GrafanaでAWSのリソースを監視してみた
こんにちは、クラウドサーカス インフラチームの朱です。
AWSエンジニアとして、クラウドサーカスの取り組みを知っていただきたいと思い、技術ブログとして発信することにしました。初回は、インフラ監視ツールにGrafanaを導入したことについて述べさせていただきます。
Grafana導入の背景
抱えていた課題感
クラウドサーカスでは、プロダクトにおけるパフォーマンスの監視ツールを統一できていないという課題があります。
現在、プロダクトごとに目的に合わせた監視ツールを使っており、AWS CloudWatch メトリックス、ZabbixやUptime Kumaなど採用していますが、パフォーマンス状況を確認するために各サービスに毎回ログインしなけばいけません。今後も監視ツールは増える想定のため、このままでは障害調査時の工数が多くなるなどデメリットが大きくなると考え、既存のデータソース（監視ツール）を統一可視化でき、サポートしているデータソースが多いGrafanaを導入しました。
Grafanaとは
データの視覚化とモニタリングのためのオープンソースのプラットフォームで、主に以下の機能があります。
主な機能
CloudWatchやZabbixとは違い、サーバーから直接リソース情報を取得してくるというより、他の監視ツールデータを可視化する
アラート機能として、データの異常をメールやSlackに通知できる
AWSにマネージドサービスがある
CloudWatch以外にも、PostgreSQLやMySQLといった各種DBからGoogle Sheetsのようなサービスまで、さまざまなデータソースと連携できる
どのように実践したか？
GrafanaからAWS CloudWatch、GrafanaからUptime Kumaへの連携について説明します。
AWS CloudWatch
具体的にどうやったか？
CCでは複数のSaaSサービスを提供しており、各サービスごとに独立したAWSアカウントでインフラの環境構築をした
Grafanaも同じく、他プロダクトと独立したAWSアカウントのEC2上で構築した
注意点
GrafanaからCloudWatchのデータを取得するために、権限付与をするためのIAM PolicyをIAM Roleにアタッチする必要がある
上図のようなマルチアカウント構成の場合、Grafanaから別AWSアカウント上のリソースを取得するクロスアカウントアクセスのロール設定が必要となる
監視対象
EC2（CPU、メモリ、ストレージ）
RDS（CPU、同時接続数）
ALB（リクエスト数、レスポンス時間）
CloudFront（リクエスト数、エラー率）
Lambda（実行数、エラー数、スロットリング）
S3（バケットサイズ、オブジェクト数、リクエスト数）
Uptime Kuma
具体的にどうやったか？
Uptime KumaはOSSの稼働率モニタリングツールなので、対象URLに対するレスポンスチェック、証明書監視、ドメイン監視、アラートといった機能を活用した
ポイント
Grafanaは多くのデータソースに直接連携できるが、Uptime Kumaに関するプラグインは存在しない
Uptime Kumaは公式でPrometheusとの連携をサポートしており、Prometheus経由であればUptime Kuma上の監視データを取得することができる
Grafanaを使って検証してみた感想
良かったところ
分散していた様々な監視情報をダッシュボードに統一できた
インフラメンバーだけでなく、開発メンバーもインフラのパフォーマンス情報を確認しやすくなった
導入前と比べて、開発メンバーやPMからのインフラ周りの相談が多くなった（気がする…）！
ダッシュボードを見れば情報がわかる状態になったことで、状況を確認するメンバーと確認する回数が多くなったからだと思います。また、MTGの場でも、ダッシュボードを見ながらディスカッションすることが増え、データ駆動でプロダクトが潜在的に抱える問題を発見しやすくなりました。何よりも様々な情報を一つの画面で見比べながら調査ができるため、障害発生時に原因調査が格段にやりやすくなりました！
これからやりたいこと
基本的なメトリックス以外に、ログの確認やDB情報も可視化したいと考えています。Grafanaでより堅牢な監視体制を組むことで、障害を素早く検知できるようになると考えています。他にもプロダクトごとで見えていない障害ポイントや障害の傾向を検知できるようにしたいです。
今年度導入したばかりで全プロダクト（全環境）を網羅できておらず、模索しながらの運用でもあるので、まずは全プロダクトを網羅できるよう頑張りたいです。