このブログは、クラウドサービスやインターネットの新機能でよく見られる「自分が作ったものを見せる」ブログとほとんど変わらないものです。
*このブログでは、**Cloudwatch: Observability Solutions !!**の新しいアップデートに関する第一印象、良い点・悪い点を共有します
*AWS CloudWatch Observability Solutionsは、AWSサービスやワークロード向けに事前設定済みツールを用いて監視設定を簡素化することを目指しています。しかし、本当にそんなに簡単なのでしょうか?現実を探ってみましょう! *
動機
- 2024年11月15日 AWSがCloudWatch向けに新機能をリリースしました。内容は以下の通りです。
ObservabilityソリューションはAWS上のインフラおよびアプリケーションの監視を簡素化し、AWSサービス、カスタムアプリ、サードパーティワークロードのガイド付きですぐに使える例を提供します。これには計測、テレメトリ、カスタムダッシュボード、メトリックアラームが含まれます。
JVM、Kafka、Tomcat、NGINXなどのワークロード向けにカスタマイズされたソリューションのカタログから選べます。CloudWatchのエージェント設定、事前定義されたダッシュボード、アラームなどのタスクをカバーしています。
これらのソリューションは詳細な監視、コンテナインサイト、アプリケーションシグナルなどの機能に関するガイダンスを提供し、Amazon CloudWatchおよびAmazon Managed Service for Prometheusのサポートも行います。そのまま展開するか、必要に応じてカスタマイズしてください。
CloudWatch コンソール😓でのオブザーバビリティソリューションへのナビゲーション
- コンソールで観察可能性の解決策を見つけるのは**難しくはないと思いますが、**ホーム画面にしか表示されないため見落としがちです。
、見落とされやすいと言いました。なぜなら、通常は左側のパネルにあるアラームやログ、メトリクスなどに直接アクセスし、そのパネルにも観測可能性ソリューションの記載が一切ないからです。
- このブログを書いている時点でも「What's new」にも一切の記載はありません。
オブザーバビリティソリューションカタログ 🤩

- 本日(2024年11月18日)時点で、Observabilityソリューションは約34のサービスをサポートしています。
- 任意のサービスをクリックすると、どのような観測性ソリューションを提供しているか確認できます。

このアップデート😞で気に入らない点
既存機能を解決策としてラップする
- Observability Solutionsは様々な監視タスクをカバーしますが、ほとんどのサービスは共通の解決策として推奨アラームを作成します。

この機能が1年前(2023年12月20日)にすでに存在していたので、私がこの点を好まない理由です

EKS向けのコンテナインサイトもずっと前から存在していました。
このアップデート❤️で気に入った点
ドキュメントは鮮明で明確です
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Monitoring-Solutions.html
- さまざまなソリューションのドキュメントがどのように設計・提示されているかがとても気に入っています。どこでコストがかかるのか、どのような具体的な指標が期待できるのか、ソリューションの利点、さまざまな構成、そしてそれらの構成方法が明確に示されています。
注意:使用するすべてのソリューションがアカウント内のリソースを作成・使用し、請求されることを理解することが重要です。そのため、予期せぬ費用を避けるために、特定のソリューションのドキュメント内の「費用」セクションを確認することが重要です。
事前定義された顧客ダッシュボード
- ダッシュボードは説明不要で、チームは使い方や解釈まで説明しています
Ec2周辺の観測可能性ソリューション
- JVM、NGINX、Kafka、NVIDIA、tomcatなどのワークロード向けにEC2を中心に構築されたソリューションは、これらのワークロードに対して標準のテレメトリー収集を提供します。さらに、事前設定済みのダッシュボードの設定もサポートします。
- これにより、ユーザーが自分の可視性を得られるだけでなく、自社のソリューションがAWSのベストプラクティスに準拠しているという安心感も得られると思います。
Amazing Managed Grafanaを用いた観察性ソリューション

- Catalogue ScreenではJVMをサポートしていると書かれていますが、このブログ執筆時点ではAMGベースのObservabilityソリューションをサポートしているのはEKSのみです。
- Amazon Elastic Kubernetes Service インフラストラクチャの監視は、Amazon Managed Grafana がよく使われるシナリオの一つです。簡単に言えば、* 事前に設定されたエージェントレススクレイパーによる自動テレメトリを提供します。専門家推奨の監視手法。EKS インフラストラクチャ用の事前設定済み Grafana ダッシュボード。*
AMGベースのEKS観測性ソリューションの詳細解析
このソリューションは、先制的および受動的機能の両方を提供します:
- 積極的な能力:
- 過去のデータに基づいて信頼性の高いAmazon EKSワークロードに十分なCPUやメモリを割り当てるなど、より良いスケジューリング判断を行いリソース利用を最適化すること。
- 既存のワークロードに似た新しいプロジェクトのスケーリングなど、将来のリソース需要を予測する計画。Kubernetesの名前空間におけるワークロード使用パターンなどの傾向を分析し、潜在的な問題を早期に発見する。
- 反応能力:
- ダッシュボードのトラブルシューティングなどのツールでインフラやワークロードの問題を迅速に検出。
- スタック内の問題箇所(例えば、APIサーバーのオーバーロードがKubernetesの運用に影響を与える場合)を特定できる。EKS制御プレーンはAWSによって管理されているにもかかわらず。
ドキュメントによると、このソリューションは以下のリソースをセットアップしており、AWS CDKまたはterraformのいずれかを使って設定できます:
- **Prometheus Workspace:**管理型コレクターを使ってAmazon EKSクラスターからの指標を保存し、データを収集・送信します。
- **CloudWatchログ:**CloudWatchエージェントを通じてEKSクラスターログを収集し、Amazon Managed Grafanaが解析のためにクエリします。
- **Grafana Workspace:**メトリクスとログを統合し、クラスタの監視用ダッシュボードやアラートを作成します。
その結果として生成されるダッシュボードとアラートは以下の通りです:
- EKSクラスター全体の健康状態をモニタリングしてください。
- EKS制御およびデータプレーンの健康状態と性能を追跡。
- Kubernetes名前空間全体のワークロードに関する洞察を提供します。
- 名前空間間でCPU、メモリ、ディスク、ネットワークなどのリソース使用状況を表示します。
私が望んだObservability Solutions 🙏のあり方
EKS上のAMPベースの観測可能性ソリューションは良好で、IaC(CDKやTerraform)を使ってデプロイする方法もありますが、EKSアドオンで管理できればずっと簡単です。*もしAWSにベストプラクティスを提供するのが目的なら、さらに簡素化してみてはどうでしょうか? *
推奨アラームの設定などのほとんどの観察可能性ソリューションは既に存在しており、私は観察可能性ソリューションはラッパーや傘のようなもので、それを監視性ソリューションとして押し出すものだと思います。*しかし、特定のサービスのCloudwatch指標に手動でアクセスして有効化する必要があります。なぜ同じ画面からワンボタンで有効化できないのでしょうか? *
もしAWSサービス、カスタムアプリケーション、サードパーティワークロードの観察に最適な選択肢について意見を述べるガイダンスを提供するのが目的なら、*アカウント内の使用済みサービスの集中ダッシュボードとしてAWSのオブザーバビリティカタログをプッシュし、ユーザーがAWSのベストプラクティスを使っているかどうかを特定・提供できるようにすべきです。 *
現時点では、AWSが提供するオブザーバビリティソリューションを使っているかどうかを、オブザーバビリティカタログを見るだけで追跡する方法はありません。
結論
- AWSのObservabilityソリューションを理解した今、EC2ワークロードやEKS向けのAmazon Managed Grafanaソリューションの方が、AWSのオブザーバビリティのベストプラクティスを提供するという考え方を体現していると感じています。 ✅
- Observability Catalogueはまだ更新が必要で、ユーザーがAWS全体で使用されている様々なサービスのObservabilityソリューションを追跡するための中央ページとして扱えるように。 ❌
- また、Observability Solutionsは、さまざまなソリューションの実装をワンクリックで簡単に展開・カスタマイズできる方法を考え出す必要があると感じています。なぜなら、ソリューションの実装はまだ非常に手作業のプロセスだと感じているからです。 ❌
CloudWatch Observability Solutionsについてどう思いますか?