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