SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

これだけは押さえておきたい! AWSサービス最新アップデート

AWSの運用がもっと楽になる!「CloudWatch」で注目の新機能と使い方4選

第12回 Metrics Insights、CloudWatch Agent、クロスアカウントオブザーバビリティ、Internet Monitor

  • X ポスト
  • このエントリーをはてなブックマークに追加

見たいメトリクスを楽に表示できる「Metrics Insights」

 まずはMetrics Insightsについてご紹介します。こちらはCloudWatch Metricsに対してSQLのクエリを実行する機能です。この機能を利用することで、メトリクスを手動で1つ1つ選択する必要がなくなり、見たいメトリクスを楽に表示させることができるようになります。

 例えば、全LoadBalancerのRequestCountの合計値を見たいという要件があったとします。

 これまでは、まず全LoadBalancerのRequestCountのメトリクスをグラフ化し、その後Metric Mathを使って合計値を計算する必要がありましたが、Metrics Insightsを利用するとクエリを1文書くだけで、全LoadBalancerのRequestCountの合計値を表示することができます。

Metrics Insights
Metrics Insights

 また、複数のリソースに対して任意のメトリクスを見たい場合にもMetrics Insightsは有効で、手動で1つ1つメトリクスを選択してグラフ化する必要はなく、クエリを書くだけで各リソースのメトリクスを表示させることが可能です。

 クエリは以下構文で実行することができます。

SELECT FUNCTION(metricName)
FROM namespace | SCHEMA(...)
[ WHERE labelKey OPERATOR labelValue [AND ... ] ]
[ GROUP BY labelKey [ , ... ] ]
[ ORDER BY FUNCTION() [ DESC | ASC ] ]
[ LIMIT number ]

 コンソール上からMetrics Insightsを実行する場合は、GUIで条件を選択してクエリを実行することも可能です。

 コンソールからクエリを実行する場合は無料ですが、GetMetricData API(CloudWatchのメトリクス値を取得できるAPI)を使用してクエリを実行する場合は、分析した1000メトリクスごとに0.01USD[1]がかかります。

[1] 本記事で紹介している料金は全て東京リージョンでの料金です。

 また、Metrics Insightでは制約があるため、利用する際はご注意ください。筆者が特に気をつけてほしい制約は、以下2つです。

  • クエリが可能なのは直近3時間のデータのみ
    • 3時間以前のメトリクスを見たい場合は、これまで通り手動でメトリクスを選択する必要があります。
  • 1つのクエリで返される結果は500個まで。ORDER BY句を使用すると最大値または最小値を持つ500個が返され、ORDER BY句を使用しない場合はどの結果を返すか制御することができない
    • 500個以上のクエリ結果が返ってくる場合は、条件を更に絞るかORDER BY句の利用を検討してください。

 また、Metrics Insightsのクエリ結果のアラームの設定ができるようになりました。

 例えば、CPU使用率が80%超えているEC2インスタンスを監視したいという要件があった場合、これまでは1メトリクス当たりに1アラームを設定する必要があったため、監視対象のリソースが増えるたびにアラームを作成する必要がありました。しかし、EC2でCPU使用率が80%超えているサーバを取得するというクエリにアラームを設定することで、アラーム設定後に作成したリソースも自動的に監視できるようになります。

 これを利用すれば、EC2インスタンス単位で設定するようなアラームの数を減らことができそうです。

 Metrics Insightsのアラームは1リージョンあたり75個まで設定可能で、料金は「アラーム数×クエリで分析したメトリクス数×0.1USD」です。

CloudWatch Agentでログのフィルタリングとログ保持期間が設定可能に 

 CloudWatch Agentを利用してサーバのログをCloudWatch Logsへ転送する際に、ログのフィルタリングロググループでのログの保持期間を設定することが可能になりました。

 これまではログファイルに出力された全てのログをCloudWatch Logsに転送し、CloudWatch Logsの機能でフィルタリング処理を行う必要がありましたが、本アップデートによってCloudWatch Agentの設定ファイルにフィルタ設定を追加することでCloudWatch Logsに転送するログをサーバ側でフィルタリングできるようになりました。

 これによって必要なログのみをCloudWatch Logsで保管でき、フィルタを実装する際に利用していたサービスも利用しなくて良くなるため、AWS利用料を削減することができます。

 またロググループのログの保持期間についても、CloudWatch Agentの設定ファイルで指定することができるようになりました。

 CloudWatch Logsのログ保管にかかる料金は0.033USD/GBのため、ログの保持期間の設定を忘れると費用が嵩んでしまうため、CloudWatch Agentで設定すべき項目としておくのがよいと思います。

 CloudWatch Agentでのログのフィルタリングとロググループの保持期間の設定は以下のように設定します。

 以下はロググループの保持期間を1日に設定し、「INFO」が含まれるログをドロップするという設定になります。

 CloudWatch Agentの設定ファイルの詳細についてはユーザガイドをご参照ください。

"retention_in_days": 1,
"collect_list": [ 
  {
    "file_path": "/opt/aws/amazon-cloudwatch-agent/logs/test.log", 
    "log_group_name": "test.log", 
    "log_stream_name": "test.log",
    "filters": [
      {
        "type": "exclude",
        "expression": "INFO"
      }
    ]
  },
  .....
]

次のページ
複数のAWSアカウント間でのクロスアカウントオブザーバビリティが利用可能に

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
これだけは押さえておきたい! AWSサービス最新アップデート連載記事一覧

もっと読む

この記事の著者

竹山 菜記(株式会社NTTデータ)(タケヤマ ナツキ)

 2019年にNTTデータに入社。 パブリッククラウドを活用したシステム基盤の構築・運用やオンプレミスからパブリッククラウドへのマイグレーション案件に携わる。 注目しているキーワードは"クラウドネイティブ"。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/18046 2023/08/22 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング