翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ログとメトリクスを一貫したフォーマットと場所にキャプチャした後、それらを検索および分析して、問題の特定とトラブルシューティングに加えて、オペレーション効率を向上させることができます。ログを検索および分析しやすくするために、ログを適切な形式 (JSON など) でキャプチャすることをお勧めします。ほとんどのワークロードでは、ネットワーク、コンピューティング、ストレージ、データベースなどの AWS リソースのコレクションを使用します。可能であれば、すべての AWS ワークロードを効果的にモニタリングおよび管理するために、これらのリソースのメトリクスとログをまとめて分析し、関連付ける必要があります。
CloudWatch には、さまざまな AWS リソースにわたるアプリケーションのメトリクスとログをまとめて定義およびモニタリングする CloudWatch Application Insights、メトリクスの異常を表面化する CloudWatch Anomaly Detection、CloudWatch Logs でログデータをインタラクティブに検索および分析する CloudWatch Log Insights など、ログとメトリクスの分析に役立ついくつかの機能が用意されています。 CloudWatch
CloudWatch アプリケーションインサイトを使用したアプリケーションのモニタリングと分析
アプリケーションの所有者は Amazon CloudWatch アプリケーションインサイトを使用して、ワークロードの自動モニタリングと分析を設定できます。これは、アカウント内のすべてのワークロードに対して設定されたデフォルトのシステムレベルのモニタリングに追加して、設定できます。CloudWatch アプリケーションインサイトによるモニタリングの設定は、アプリケーションチームが事前にオペレーションと連携し、平均復旧時間（MTTR）を削減するのに役立ちます。CloudWatch アプリケーションインサイトは、アプリケーションレベルのロギングとモニタリングを確立するために必要な労力を削減するのに役立ちます。また、チームによるロギングとモニタリングの責任分担を支援するコンポーネントベースのフレームワークも提供します。
CloudWatch アプリケーションインサイトは、Resource Groups を使用して、アプリケーションとしてまとめてモニタリングする必要があるリソースを特定します。Resource Groups 内のサポートされているリソースは、CloudWatch アプリケーションインサイトのアプリケーションの個別に定義されたコンポーネントになります。CloudWatch アプリケーションインサイトのアプリケーションの各コンポーネントには、独自のログ、メトリクス、アラームがあります。
ログについては、コンポーネントと CloudWatch アプリケーションインサイトのアプリケーション内で使用するログパターンセットを定義します。ログパターンセットは、正規表現に基づいて検索するログパターンの集まりで、パターンが検出されたときの重大度が低、中、または高です。メトリクスについては、サービス固有およびサポートされているメトリクスのリストから、各コンポーネントについてモニタリングするメトリクスを選択します。アラームの場合、CloudWatch アプリケーションインサイトは、モニタリング対象のメトリクスのスタンダードまたは異常検出アラームを自動的に作成し、設定します。CloudWatch アプリケーションインサイトは、「CloudWatch のドキュメント」のCloudWatch アプリケーションインサイトで説明されているテクノロジーのメトリクスとログキャプチャの自動設定があります。次の図は、CloudWatch アプリケーションインサイトのコンポーネントとそのロギングおよびモニタリングの設定との関係を示します。各コンポーネントは、CloudWatch Logsとメトリクスを使用してモニタリングする独自のログとメトリクスを定義しています。
CloudWatch アプリケーションインサイトによってモニタリングされる EC2 インスタンスには、Systems Manager と CloudWatch エージェントとアクセス許可が必要です。詳細については、「CloudWatch のドキュメント」にある「CloudWatch アプリケーションインサイトを使用したアプリケーションの設定の前提条件」を参照してください。CloudWatch アプリケーションインサイトでは、CloudWatch エージェントをインストールおよび更新するために、Systems Manager を使用します。CloudWatch アプリケーションインサイトで設定されたメトリクスとログは、CloudWatch エージェント設定ファイルを作成し、このファイルは、各 CloudWatch アプリケーションインサイトのコンポーネントの AmazonCloudWatch-ApplicationInsights-SSMParameter プレフィックスを付けて、Systems Managerのパラメータに格納されます。これにより、別の CloudWatch エージェント設定ファイルが EC2 インスタンスの CloudWatch エージェント設定ディレクトリに追加されます。Systems Manager コマンドを実行して、EC2 インスタンスのアクティブな設定にこの設定を追加します。CloudWatch アプリケーションインサイトを使用しても、既存の CloudWatch エージェントの設定には影響しません。独自のシステムおよびアプリケーションレベルの CloudWatch エージェント設定に加えて、CloudWatch アプリケーションインサイトを使用できます。ただし、設定が重複しないようにする必要があります。
CloudWatch Logs インサイトを使用したログ分析の実行
CloudWatch Logs インサイトを使用すると、単純なクエリ言語を使用して複数のロググループを簡単に検索できます。アプリケーションログが JSON 形式で構造化されている場合、CloudWatch Logs インサイトは、複数のロググループでログストリーミング全体の JSON フィールドを自動的に検出します。CloudWatch Logs インサイトを使用して、アプリケーションおよびシステムログを分析できます。これにより、将来の使用に備えてクエリが保存されます。CloudWatch Logs インサイトのクエリ構文は、アプリケーションやパフォーマンス分析のトラブルシューティングに役立つ sum ()、avg ()、count ()、min ()、max () などの関数による集計などの機能をサポートしています。
組み込みメトリクス形式を使用して CloudWatch メトリクスを作成する場合、サポートされている集計関数を使用して、埋め込みメトリクス形式のログをクエリして 1 回限りのメトリクスを生成できます。これにより、カスタムメトリクスとしてアクティブにキャプチャするのではなく、必要に応じて特定のメトリクスを生成するために必要なデータポイントをキャプチャすることで、CloudWatch モニタリングのコストを削減できます。これは、基数が高いディメンションで多数のメトリクスが発生する場合に特に効果的です。CloudWatch コンテナインサイトもこのアプローチをとり、詳細なパフォーマンスデータをキャプチャしますが、このデータのサブセットの 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 Service を使用したログ分析の実行
CloudWatch は、CloudWatch ロググループから任意の Amazon OpenSearch Service クラスターにサブスクリプションフィルターを使用してログデータをストリーミングできるようにすることで、Amazon OpenSearch Service と統合されます。 CloudWatch CloudWatch は、プライマリログとメトリクスのキャプチャと分析に使用し、次のユースケースでは Amazon OpenSearch Service で拡張できます。
-
きめ細かなデータアクセスコントロール – Amazon OpenSearch Service を使用すると、データへのアクセスをフィールドレベルに制限し、ユーザーのアクセス許可に基づいてフィールド内のデータを匿名化できます。これは、機密データを公開せずにトラブルシューティングをサポートしたい場合に便利です。
-
複数のアカウント、リージョン、インフラストラクチャ間でログを集約して検索する – 複数のアカウントとリージョンから共通の Amazon OpenSearch Service クラスターにログをストリーミングできます。集中化されたオペレーションチームは、トレンドや問題を分析し、アカウントとリージョン間で分析を実行できます。CloudWatch ログを Amazon OpenSearch Service にストリーミングすると、マルチリージョンアプリケーションを一元的に検索および分析することもできます。
-
ElasticSearch エージェントを使用して Amazon OpenSearch Service に直接ログを出荷して強化する – アプリケーションおよびテクノロジースタックコンポーネントは、CloudWatch エージェントでサポートされていない OSs を使用できます。また、ログ記録ソリューションに出荷される前に、ログデータを強化して変換することもできます。Amazon OpenSearch Service は、ログデータを Amazon OpenSearch Service に送信する前に、ログのエンリッチメントと変換をサポートする Elastic Beats ファミリーデータシッパー
や Logstash などの標準 OpenSearchクライアントをサポートしています。 -
既存の運用管理ソリューションでは、ログ記録とモニタリングに ElasticSearch、Logstash、Kibana
(ELK) スタックを使用しています。多くのワークロードが既に設定されている Amazon OpenSearch Service またはオープンソースの Elasticsearch に既に多額の投資を行っている可能性があります。また、継続して使いたいKibana で作成されているオペレーションダッシュボードがある場合もあります。
CloudWatch ログを使用する予定がない場合は、Amazon OpenSearch Service がサポートするエージェント、ログドライバー、ライブラリ (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 Service クラスターを一元化されたログ記録アカウントにデプロイし、他のアカウントのロググループを設定して、ログを一元化された Amazon OpenSearch Service クラスターにストリーミングできます。
個別の Amazon OpenSearch Service クラスターを作成して、アカウント間で分散される可能性のあるクラウドアーキテクチャのさまざまなアプリケーションまたはレイヤーを処理できます。個別の Amazon OpenSearch Service クラスターを使用すると、セキュリティと可用性のリスクが軽減され、共通の Amazon OpenSearch Service クラスターを持つことで、同じクラスター内のデータの検索と関連付けが容易になります。
