翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
で分析する CloudWatch
ログとメトリクスを一貫したフォーマットと場所にキャプチャした後、それらを検索および分析して、問題の特定とトラブルシューティングに加えて、オペレーション効率を向上させることができます。ログを検索および分析しやすくするために、ログを適切な形式 (JSON など) でキャプチャすることをお勧めします。ほとんどのワークロードでは、ネットワーク、コンピューティング、ストレージ、データベースなどの AWS リソースをまとめたものを使用します。可能な場合は、これらのリソースからのメトリクスとログをまとめて分析し、それらを関連づけ、AWS ワークロードの全てを効果的にモニタリングおよび管理する必要があります。
CloudWatch には、ログとメトリクスの分析に役立ついくつかの機能があります。例えば、さまざまな AWS リソースにわたるアプリケーションのメトリクスとログをまとめて定義してモニタリングする CloudWatch Application Insights、メトリクスの異常を検出する CloudWatch Anomaly Detection、CloudWatch ログ内のログデータをインタラクティブに検索して分析する CloudWatch Logs Insights などです。
CloudWatch でアプリケーションインサイトを使用したアプリケーションのモニタリングと分析
アプリケーションの所有者は Amazon CloudWatch アプリケーションインサイトを使用して、ワークロードの自動モニタリングと分析を設定できます。これは、アカウント内のすべてのワークロードに対して設定されたデフォルトのシステムレベルのモニタリングに追加して、設定できます。また、 CloudWatch アプリケーションインサイトを使用したモニタリングの設定は、アプリケーションチームが事前にオペレーションと連携し、平均復旧時間（MTTR）を削減するのに役立ちます。 CloudWatch アプリケーションインサイトは、アプリケーションレベルのロギングとモニタリングを確立するために必要な労力を削減するのに役立ちます。また、チームによるロギングとモニタリングの責任分担を支援するコンポーネントベースのフレームワークも提供します。
CloudWatch アプリケーションインサイトは、アプリケーションとしてまとめてモニタリングする必要があるリソースを特定します。Resource Groups 内のサポートされているリソースは、 CloudWatch アプリケーションインサイトのアプリケーションの個別に定義されたコンポーネントになります。 CloudWatch アプリケーションインサイトのアプリケーションの各コンポーネントには、独自のログ、メトリクス、アラームがあります。
ログについては、コンポーネントと CloudWatch Application Insights アプリケーション内で使用するログパターンセットを定義します。ログパターンセットは、正規表現に基づいて検索するログパターンの集まりで、パターンが検出されたときの重大度が低、中、または高です。メトリクスについては、サービス固有およびサポートされているメトリクスのリストから、各コンポーネントについてモニタリングするメトリクスを選択します。アラームの場合、 CloudWatch アプリケーションインサイトは、モニタリング対象のメトリクスの標準または異常検出アラームを自動的に作成して設定します。 CloudWatch アプリケーションインサイトのログキャプチャの自動設定があります CloudWatch 。 CloudWatch 次の図は、 CloudWatch アプリケーションインサイトのコンポーネントとそのロギングおよびモニタリングの設定との関係を示します。各コンポーネントは、 CloudWatch ログとメトリクスを使用してモニタリングする独自のログとメトリクスを定義しています。
CloudWatch アプリケーションインサイトによってモニタリングされる EC2 インスタンスには、Systems Manager CloudWatch とエージェント、およびアクセス許可が必要です。詳細については、 CloudWatch ドキュメントの「 CloudWatch アプリケーションインサイトを使用したアプリケーションの設定の前提条件」を参照してください。 CloudWatch アプリケーションインサイトは、Systems Manager CloudWatch を使用してエージェントをインストールおよび更新します。 CloudWatchアプリケーションインサイトで設定されたメトリクスとログは、 CloudWatch エージェント設定ファイルを作成し、このファイルは、AmazonCloudWatch-ApplicationInsights-SSMParameter CloudWatch各アプリケーションインサイトのコンポーネントのプレフィックスを付けて Systems Manager パラメータに格納されます。これにより、別の CloudWatch エージェント設定ファイルが EC2 CloudWatch インスタンスのエージェント設定ディレクトリに追加されます。Systems Manager コマンドを実行して、EC2 インスタンスのアクティブな設定にこの設定を追加します。 CloudWatch アプリケーションインサイトを使用しても、 CloudWatch 既存のエージェント設定には影響しません。 CloudWatch 独自のシステムおよびアプリケーションレベルの設定に加えて、 CloudWatch アプリケーションインサイトを使用できます。ただし、設定が重複しないようにする必要があります。
CloudWatch でログ分析する
CloudWatch Logs インサイトを使用すると、単純なクエリ言語を使用して複数のロググループを簡単に検索できます。アプリケーションログが JSON 形式で構造化されている場合、 CloudWatch Logs Insights は、複数のロググループの JSON フィールドを自動的に検出します。 CloudWatch Logs インサイトを使用して、アプリケーションおよびシステムログを分析できます。 CloudWatch Logs インサイトのクエリ構文は、アプリケーションやパフォーマンス分析のトラブルシューティングに役立つ sum ()、avg ()、count ()、min ()、max () などの関数による集計などの機能をサポートしています。
CloudWatch 組み込みメトリクス形式を使用してメトリクスを作成する場合、サポートされている集計関数を使用して、組み込みメトリクス形式のログをクエリして、1 回限りのメトリクスを生成できます。これにより、カスタムメトリクスとしてアクティブにキャプチャするのではなく、必要に応じて特定のメトリクスを生成するために必要なデータポイントをキャプチャすることで、 CloudWatch モニタリングコストを削減できます。これは、基数が高いディメンションで多数のメトリクスが発生する場合に特に効果的です。 CloudWatch Container Insights もこのアプローチをとり、詳細なパフォーマンスデータをキャプチャしますが、 CloudWatch このデータのサブセットのみを生成します。
たとえば、次の埋め込みメトリクスエントリは、 CloudWatch組み込みメトリクス形式ステートメントでキャプチャされたメトリクスデータから、限定されたメトリクスセットのみを生成します。
{ "AutoScalingGroupName": "eks-e0bab7f4-fa6c-64ba-dbd9-094aee6cf9ba", "CloudWatchMetrics": [ { "Metrics": [ { "Unit": "Count", "Name": "pod_number_of_container_restarts" } ], "Dimensions": [ [ "PodName", "Namespace", "ClusterName" ] ], "Namespace": "ContainerInsights" } ], "ClusterName": "eksdemo", "InstanceId": "i-03b21a16b854aa4ca", "InstanceType": "t3.medium", "Namespace": "amazon-cloudwatch", "NodeName": "ip-172-31-10-211.ec2.internal", "PodName": "cloudwatch-agent", "Sources": [ "cadvisor", "pod", "calculated" ], "Timestamp": "1605111338968", "Type": "Pod", "Version": "0", "pod_cpu_limit": 200, "pod_cpu_request": 200, "pod_cpu_reserved_capacity": 10, "pod_cpu_usage_system": 3.268605094109382, "pod_cpu_usage_total": 8.899539221131045, "pod_cpu_usage_user": 4.160042847048305, "pod_cpu_utilization": 0.44497696105655227, "pod_cpu_utilization_over_pod_limit": 4.4497696105655224, "pod_memory_cache": 4096, "pod_memory_failcnt": 0, "pod_memory_hierarchical_pgfault": 0, "pod_memory_hierarchical_pgmajfault": 0, "pod_memory_limit": 209715200, "pod_memory_mapped_file": 0, "pod_memory_max_usage": 43024384, "pod_memory_pgfault": 0, "pod_memory_pgmajfault": 0, "pod_memory_request": 209715200, "pod_memory_reserved_capacity": 5.148439982463127, "pod_memory_rss": 38481920, "pod_memory_swap": 0, "pod_memory_usage": 42803200, "pod_memory_utilization": 0.6172094650851303, "pod_memory_utilization_over_pod_limit": 11.98828125, "pod_memory_working_set": 25141248, "pod_network_rx_bytes": 3566.4174629544723, "pod_network_rx_dropped": 0, "pod_network_rx_errors": 0, "pod_network_rx_packets": 3.3495665260575094, "pod_network_total_bytes": 4283.442421354973, "pod_network_tx_bytes": 717.0249584005006, "pod_network_tx_dropped": 0, "pod_network_tx_errors": 0, "pod_network_tx_packets": 2.6964010534762948, "pod_number_of_container_restarts": 0, "pod_number_of_containers": 1, "pod_number_of_running_containers": 1, "pod_status": "Running" }
ただし、キャプチャしたメトリクスをクエリして、さらなるインサイトを得ることができます。例えば、次のクエリを実行して、メモリページ障害のある最新の 20 ポッドを表示できます。
fields @timestamp, @message | filter (pod_memory_pgfault > 0) | sort @timestamp desc | limit 20
Amazon OpenSearch サービスでログ分析する
CloudWatch はAmazon OpenSearch Serviceと統合されており、 CloudWatch ロググループのログデータをサブスクリプションフィルタを使用して任意のAmazon OpenSearch Serviceクラスターにストリーミングできます。でログやメトリクスをキャプチャおよび分析し、Amazon OpenSearch Service でログデータを強化し、以下のようなユースケースに対応します。 CloudWatch
-
きめ細かなデータアクセス制御 — Amazon OpenSearch Serverce を使用すると、データへのアクセスをフィールドレベルまで制限し、ユーザーのアクセス許可に基づいてフィールド内のデータを匿名化できます。これは、機密データを公開せずにトラブルシューティングをサポートしたい場合に便利です。
-
複数のアカウント、リージョン、インフラストラクチャにまたがるログを集約して検索 — 複数のアカウントとリージョンからのログを共通の Amazon OpenSearch Service クラスターにストリーミングできます。集中化されたオペレーションチームは、トレンドや問題を分析し、アカウントとリージョン間で分析を実行できます。また、Amazon OpenSearch Serverice CloudWatch へのログをストリーミングすることで、複数のリージョンのアプリケーションを一元的に検索および分析することができます。
-
ElasticSearchエージェントを使用してログを直接に送信および強化する — アプリケーションおよびテクノロジースタックのコンポーネントは、 CloudWatch エージェントでサポートされていない OS を使用できます。 OpenSearch ログデータをロギングソリューションに出荷する前に、ログデータをエンリッチして変換したい場合もあります。Amazon OpenSearch Service は、標準的な Elasticsearch クライアントをサポートしています。Elastic Beats ファミリーデータの送信者
および Logstash は、ログデータを Amazon OpenSearch サービスに送信する前に、ログの強化と変換をサポートします。 -
既存のオペレーション管理ソリューションではElasticSearch、ロギングとモニタリングに Logstash、Kibana
(ELK) 用のスタックを使用 — またはAmazon OpenSearch Service またはオープンソースのElasticsearchに多額の投資を行い、多くのワークロードがすでに設定されている場合があります。また、継続して使いたいKibana で作成されているオペレーションダッシュボードがある場合もあります。
CloudWatch ログドライバ、ライブラリ（例えば、Fluent Bit、Fluent Bit、Fluent Bit、Fluent Bit、Fluentd、logstash および Open Distro for API) に直接ログをに送信するおよびAmazon OpenSearch Serverのログドライバ、ライブラリ（例えば、Fluent Bit、Fluent Bit、Fluentd、logstash および Open Distro for ElasticSearch API
アカウント、リージョン、 ElasticSearch およびアプリケーションのログを集約するために、集中型アカウントまたは共有アカウントに集中型アカウントをセットアップすることを検討する必要があります。例えば、ログの集中化に使用されるログアーカイブアカウントを AWS Control Tower 設定します。AWS Control Tower で新しいアカウントが作成する時、AWS CloudTrail および AWS Config ログは、この集中型アカウントの S3 バケットに配信されます。AWS Control Tower によって計測されるロギングは、設定、変更、および監査ロギング用です。
Amazon OpenSearch Service を使用して集中型アプリケーションログ分析ソリューションを確立するには、集中型ロギングアカウントに1 つ以上の集中型クラスターをデプロイし、他のアカウントのロググループを設定して、集中型 Amazon OpenSearch サービスにログをストリーミングすることができます。 OpenSearch クラスタ。
アカウントに分散しているアプリケーションや、クラウドアーキテクチャのレイヤーを処理するために、別々の Amazon OpenSearch Service クラスターを作成することができます。別々の Amazon OpenSearch Serverce クラスターを使用すると、セキュリティと可用性のリスクを減らすことができ、共通の Amazon OpenSearch Service クラスターを持つことで、同じクラスター内のデータ検索や関連付けを簡単にすることができます。
