本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
搜索和分析日志 CloudWatch
将日志和指标捕获到一致的格式和位置后，除了识别和解决问题外，您还可以对其进行搜索和分析，以帮助提高运营效率。我们建议您以格式正确的格式（例如 JSON）捕获日志，以便于搜索和分析日志。大多数工作负载使用网络、计算、存储和数据库等AWS资源集合。在可能的情况下，您应共同分析来自这些资源的指标和日志，并将它们关联起来，以便有效地监控和管理所有工作AWS负载。
CloudWatch 提供多种功能来帮助分析日志和指标，例如CloudWatch Application Insight s 用于共同定义和监控跨不同AWS资源的应用程序的指标和日志，CloudWatch 异常检测可显示您的异常情况指标和 CloudWatch Log Insights，通过交互方式搜索并分析 Lo CloudWatch gs 中的日志数据。
使用 “应用程序洞察” 共同监控和分析 CloudWatch 应用程序
应用程序所有者可以使用 Amazon A CloudWatch pplication Insights 为工作负载设置自动监控和分析。除了为账户中的所有工作负载配置标准系统级监控外，还可以配置此功能。通过 Applicat CloudWatch ion Insights 设置监控还可以帮助应用程序团队主动调整运营并缩短平均恢复时间 (MTTR)。 CloudWatch Application Insights 可以帮助减少建立应用程序级日志记录和监控所需的工作量。它还提供了一个基于组件的框架，可帮助团队划分记录和监控职责。
CloudWatch Application Insights 使用资源组来确定应作为应用程序进行集体监控的资源。资源组中支持的资源将变成 Application Insights CloudWatch 应用程序中单独定义的组件。您的 Applicat CloudWatch ion Insights 应用程序的每个组件都有自己的日志、指标和警报。
对于日志，您可以定义应用于组件和 Application Insights CloudWatch 应用程序的日志模式集。日志模式集是要根据正则表达式搜索的日志模式集合，以及检测到该模式时的低、中或高严重性。对于指标，您可以从特定服务和支持的指标列表中为每个组件选择要监控的指标。对于警报，A CloudWatch pplication Insights 会自动为受监控的指标创建和配置标准或异常检测警报。 CloudWatch Application Insights 可自动配置日志中概述的技术的指标和日志捕获，以及 CloudWatch 文档中 App CloudWatch lication Insights 支持的指标。下图显示了 Applicat CloudWatch ion Insights 组件及其日志和监控配置之间的关系。每个组件都定义了自己的日志和指标，以使用 CloudWatch 日志和指标进行监控。
由 Applicat CloudWatch ion Insights 监控的 EC2 实例需要Systems Manager、 CloudWatch 代理和权限。有关这方面的更多信息，请参阅 CloudWatch 文档中的使用 Application Insights 配置 CloudWatch 应用程序的先决条件。 CloudWatch Application Insights 使用Systems Manager 来安装和更新 CloudWatch 代理。在 App CloudWatch lication Insights 中配置的指标和日志会创建一个 CloudWatch 代理配置文件，该文件存储在 Systems Manager 参数中，每个 App CloudWatch lication Insights 组件都有AmazonCloudWatch-ApplicationInsights-SSMParameter前缀。这会导致将单独的 CloudWatch 代理配置文件添加到 EC2 实例的 CloudWatch 代理配置目录中。运行 Systems Manager 命令将此配置附加到 EC2 实例上的活动配置。使用 A CloudWatch pplication Insights 不会影响现有的 CloudWatch 代理配置设置。除了自己的系统和 CloudWatch 应用程序级 CloudWatch 代理配置外，您还可以使用 Application Insights。但是，应确保配置不重叠。
使用日志洞察进行 CloudWatch 日志分析
CloudWatch Logs Insights 使用简单的查询语言可以轻松搜索多个日志组。如果您的应用程序日志以 JSON 格式构建，L CloudWatch ogs Insights 会自动在多个日志组中的日志流中发现 JSON 字段。您可以使用 CloudWatch Logs Insights 来分析您的应用程序和系统日志，这样可以保存您的查询以备future 使用。Log CloudWatch s Insights 的查询语法支持诸如聚合函数之类的函数，例如 sum ()、avg ()、count ()、min () 和 max ()，这些函数可能有助于对应用程序进行故障排除或性能分析。
如果您使用嵌入式指标格式创建 CloudWatch 指标，则可以使用支持的聚合函数查询嵌入式指标格式日志，以生成一次性指标。这有助于根据需要捕获生成特定指标所需的数据点，而不是主动将其捕获为自定义指标，从而降低 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 个出现内存页错误的 pod：
fields @timestamp, @message | filter (pod_memory_pgfault > 0) | sort @timestamp desc | limit 20
使用亚马逊 OpenSearch 服务进行日志分析
CloudWatch 与 Amazon S OpenSearch er vice 集成，允许您使用订阅筛选器将 CloudWatch 日志数据从日志组流式传输到您选择的 Amazon Serv OpenSearch ice 集群。您可以使用 CloudWatch 主要的日志和指标捕获和分析，然后在以下用例中使用 Amazon S OpenSearch ervice 对其进行扩展：
-
细粒度的数据访问控制 — Amazon Serv OpenSearch ice 使您可以将对数据的访问限制到字段级别，并根据用户权限帮助匿名化字段中的数据。如果您想在不暴露敏感数据的情况下支持故障排除，这很有用。
-
跨多个账户、区域和基础设施汇总和搜索日志-您可以将来自多个账户和区域的日志流式传输到一个通用的 Amazon Serv OpenSearch ice 集群中。您的集中化运营团队可以分析趋势、问题，并跨账户和地区进行分析。将 CloudWatch 日志传输到 Amazon Serv OpenSearch ice 还有助于您在中心位置搜索和分析多区域应用程序。
-
使用 ElasticSearch代理直接向 Amazon Serv OpenSearch ice 发送和丰富日志-您的应用程序和技术堆栈组件可以使用 CloudWatch 代理不支持的操作系统。在将日志数据传送到您的日志解决方案之前，您可能还需要对其进行丰富和转换。亚马逊 OpenSearch 服务支持标准 Elasticsearch 客户端，例如 Elast ic Beats 系列数据采集器
和 Logstash，它们在将日志数据发送到亚马逊 OpenSearch 服务之前支持日志丰富和转换。 -
现有的运营管理解决方案使用 LogstashElasticSearch、Kibana
(ELK) 堆栈进行日志记录和监控 — 您可能已经在 Amazon OpenSearch Service 或开源 Elasticsearch 上投入了大量资金，并且已经配置了许多工作负载。您可能还想继续使用在 Kibana 中创建的操作仪表板。
如果您不打算使用 CloudWatch 日志，则可以使用亚马逊 OpenSearch 服务支持的代理、日志驱动程序和库（例如 Fluent Bit、Fluentd、logstash 和 O pen Distro for ElasticSearch API
您应该考虑在集中式或共享账户中设置 ElasticSearch 集群，以汇总您的账户、区域和应用程序的日志。例如，AWS Control Tower设置一个用于集中记录的日志存档帐户。在中创建新账户时AWS Control Tower，其AWS CloudTrail和AWS Config日志将传送到该集中账户中的 S3 存储桶。仪表的日志记录AWS Control Tower用于配置、更改和审核日志。
要使用 Amazon OpenSearch Service 建立集中式应用程序日志分析解决方案，您可以将一个或多个集中式 Amazon OpenSearch Service 集群部署到您的集中式日志账户，并在其他账户中配置日志组，将日志流式传输到集中式 Amazon OpenSearch 服务集群。
您可以创建单独的 Amazon Serv OpenSearch ice 集群来处理可能分布在您的账户中的不同应用程序或云架构层。使用单独的 Amazon Serv OpenSearch ice 集群可以帮助您降低安全和可用性风险，而拥有一个通用 Amazon Serv OpenSearch ice 集群可以更轻松地在同一个集群内搜索和关联数据。
