无服务器和 AWS ECS Fargate
AWS Fargate 是一种用于 Amazon Elastic Container Service (ECS) 的无服务器按需付费引擎，用于运行 Docker 容器，而无需管理服务器或集群。Fargate 的目标是将您的应用程序容器化，并指定启动所需的 OS、CPU 和内存、网络和 IAM 策略。此外，AWS Fargate 可以以类似的方式与 Elastic Kubernetes Service (EKS) 一起使用。
尽管服务器的配置将由第三方处理，但了解无服务器环境中容器的健康状况和性能变得更加重要，这有助于识别根本原因和系统中断。无服务器仍然需要可观测性。Elastic 可观测性不仅可以为 AWS ECS 与 Fargate 提供可观测性（正如我们将在本博文中讨论的那样），还可以为许多 AWS 服务（EC2、RDS、ELB 等）提供可观测性。请参阅我们关于使用 Elastic 可观测性管理基于 EC2 的应用程序的上一篇博文。
使用 Elastic 可观测性获得全面可见性
Elastic 可观测性由创建系统内全面可见性涉及的三个支柱管理：日志、指标和跟踪。日志列出系统中发生的所有事件。指标跟踪将告诉您系统是否出现故障的数据，例如响应时间、CPU 使用率、内存使用率和延迟。跟踪根据请求的执行情况很好地指示了系统性能。
这些支柱本身提供了一些见解，但将它们结合起来可以让您全面了解您的系统以及它如何处理负载或流量随时间的增加。将 Elastic 可观测性连接到您的无服务器环境将帮助您更快地处理中断并执行根本原因分析以防止任何未来的问题。
本文将指导您如何安装 Elastic Agent 并集成AWS Fargate作为 sidecar 容器，将主机指标和日志发送到 Elastic 可观测性。
先决条件
- 已配置 AWS CLI 的 AWS 账户
- GitHub 账户
- Elastic Cloud 账户
- 在 AWS 中运行于容器中的应用程序
本教程分为两部分
- 设置 Fleet 服务器，以便 AWS 中的 sidecar 容器使用。
- 在 AWS Fargate 中创建 sidecar 容器，将数据发送回 Elastic 可观测性。
第一部分：设置 Fleet 服务器
首先，让我们登录到 Elastic Cloud。
您可以创建新的部署或使用现有的部署。
在“主页”上，使用侧边栏滚动到管理 > Fleet > Agent 策略。点击“添加策略”。
点击“创建 Agent 策略”。在这里，我们将创建一个策略来附加到 Fleet Agent。
为策略命名并保存更改。
点击“创建 Agent 策略”。您应该在策略列表中看到 Agent 策略 AWS Fargate。
现在我们有了 Agent 策略，让我们添加集成以从主机收集日志和指标。点击“AWS Fargate -> 添加集成”。
我们将添加到策略 AWS 以收集整体 AWS 指标，并添加到 AWS Fargate 以从此集成收集指标。您可以通过在搜索栏中键入它们来找到每个指标。
点击集成后，它将带您到其登录页面，您可以在其中将其添加到策略。
对于 AWS 集成，我们将配置的唯一收集设置是收集计费指标、从 CloudWatch 收集日志、从 CloudWatch 收集指标、收集 ECS 指标和收集使用情况指标。其他所有内容都可以保持禁用状态。
使用此集成时需要注意的另一件事是从 AWS 收集数据所需的权限集。这可以在 AWS 集成页面上的 AWS 权限下找到。记下这些权限，因为我们将使用它们来创建 IAM 策略。
接下来，我们将添加 AWS Fargate 集成，它不需要其他配置设置。
现在我们已经创建了 Agent 策略并附加了正确的集成，让我们创建将实施该策略的 Agent。导航回主 Fleet 页面并点击“添加 Agent”。
由于我们将通过 ECS 连接到 AWS Fargate，因此主机类型应设置为此值。所有其他默认值都可以保持不变。
最后，让我们创建注册令牌并附加 Agent 策略。这将使 AWS ECS Fargate 能够访问 Elastic 并发送数据。
创建后，您应该能够看到策略名称、密钥和 Agent 策略列表。
我们将在下一步中使用我们的 Fleet 凭据将数据从 AWS Fargate 发送到 Elastic。
第二部分：将数据发送到 Elastic 可观测性
现在是时候创建我们的 ECS 集群、服务和任务定义，以便开始运行容器。
登录到您的 AWS 账户并导航到 ECS。
我们将从创建集群开始。
为集群添加名称。对于子网，仅选择 us-east-1a 和 us-east-1b 的前两个。
为了演示的目的，我们将使其余选项保持默认设置。点击“创建”。
我们应该看到我们创建的集群列在下面。
现在我们已经创建了用于托管容器的集群，我们希望创建一个任务定义，该定义将用于设置我们的容器。但在我们执行此操作之前，我们需要创建一个与关联策略相关联的任务角色。此任务角色将允许将 AWS 指标从 AWS 发送到 Elastic Agent。
导航到 AWS 中的 IAM。
转到“策略 -> 创建策略”。
现在，我们将参考 Fleet AWS 集成页面上的 AWS 权限并使用它们来配置策略。除了这些权限之外，我们还将添加用于 ECR 的 GetAuthenticationToken 操作。
您可以使用可视化编辑器配置每个操作。
或者，使用 JSON 选项。不要忘记将
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ChangeMessageVisibility",
"sqs:ReceiveMessage",
"ecr:GetDownloadUrlForLayer",
"ecr:UploadLayerPart",
"ecr:PutImage",
"sts:AssumeRole",
"rds:ListTagsForResource",
"ecr:BatchGetImage",
"ecr:CompleteLayerUpload",
"rds:DescribeDBInstances",
"logs:FilterLogEvents",
"ecr:InitiateLayerUpload",
"ecr:BatchCheckLayerAvailability"
],
"Resource": [
"arn:aws:iam::<account_id>:role/*",
"arn:aws:logs:*:<account_id>:log-group:*",
"arn:aws:sqs:*:<account_id>:*",
"arn:aws:ecr:*:<account_id>:repository/*",
"arn:aws:rds:*:<account_id>:target-group:*",
"arn:aws:rds:*:<account_id>:subgrp:*",
"arn:aws:rds:*:<account_id>:pg:*",
"arn:aws:rds:*:<account_id>:ri:*",
"arn:aws:rds:*:<account_id>:cluster-snapshot:*",
"arn:aws:rds:*:<account_id>:cev:*/*/*",
"arn:aws:rds:*:<account_id>:og:*",
"arn:aws:rds:*:<account_id>:db:*",
"arn:aws:rds:*:<account_id>:es:*",
"arn:aws:rds:*:<account_id>:db-proxy-endpoint:*",
"arn:aws:rds:*:<account_id>:secgrp:*",
"arn:aws:rds:*:<account_id>:cluster:*",
"arn:aws:rds:*:<account_id>:cluster-pg:*",
"arn:aws:rds:*:<account_id>:cluster-endpoint:*",
"arn:aws:rds:*:<account_id>:db-proxy:*",
"arn:aws:rds:*:<account_id>:snapshot:*"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"sqs:ListQueues",
"organizations:ListAccounts",
"ec2:DescribeInstances",
"tag:GetResources",
"cloudwatch:GetMetricData",
"ec2:DescribeRegions",
"iam:ListAccountAliases",
"sns:ListTopics",
"sts:GetCallerIdentity",
"cloudwatch:ListMetrics"
],
"Resource": "*"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": "ecr:GetAuthorizationToken",
"Resource": "arn:aws:ecr:*:<account_id>:repository/*"
}
]
}
查看您的更改。
现在让我们将此策略附加到角色。导航到“IAM -> 角色”。点击“创建角色”。
选择 AWS 服务作为“受信任实体类型”，并选择 EC2 作为“用例”。点击“下一步”。
在“权限策略”下，选择我们刚刚创建的策略，以及 CloudWatchLogsFullAccess 和 AmazonEC2ContainerRegistryFullAccess。点击“下一步”。
为任务角色命名并添加描述。
点击创建角色。
现在是时候创建任务定义了。导航到ECS -> 任务定义。点击创建新的任务定义。
让我们为这个任务定义命名。
在为任务定义命名后，您需要将 Fleet 凭证添加到容器部分，您可以在 Elastic Cloud 中 Fleet 部分的“注册令牌”部分获取这些凭证。这使我们能够将 Elastic Agent 作为 Sidecar 托管在 ECS 容器上，并使用 Fleet 凭证将数据发送到 Elastic。
-
容器名称：elastic-agent-container
-
镜像：docker.elastic.co/beats/elastic-agent:8.15.3
现在让我们添加环境变量
-
FLEET_ENROLL: yes
-
FLEET_ENROLLMENT_TOKEN: <enrollment-token>
-
FLEET_URL: <fleet-server-url>
为了演示，将环境、监控、存储和标签保留为默认值。现在我们需要创建一个第二个容器来运行存储在 ECR 中的 Golang 应用程序的镜像。点击添加更多容器。
对于环境，我们将保留 1 个 vCPU 和 3 GB 内存。在任务角色下，搜索我们创建的、使用 IAM 策略的角色。
查看更改，然后点击创建。
您应该会看到您的新任务定义包含在列表中。
最后一步是创建将直接连接到 Fleet 服务器的服务。
导航到您创建的集群，然后在服务选项卡下点击创建。
让我们配置服务环境。
设置部署配置。在这里，您应该提供您在上一步骤中创建的任务定义的名称。此外，为服务提供一个唯一的名称。将所需任务的数量设置为 2 而不是 1。
点击创建。现在您的服务正在使用您提供的任务定义在您的集群中运行两个任务。
概括来说，我们在 Elastic Cloud 中设置了一个 Fleet 服务器来接收 AWS Fargate 数据。然后，我们创建了我们的 AWS Fargate 集群任务定义，并在容器中实现了 Fleet 凭证。最后，我们创建了服务以将有关主机的数据发送到 Elastic。
现在让我们验证我们的 Elastic Agent 是否运行正常，并正确接收来自 AWS Fargate 的数据。
我们还可以在可观察性概览页面上查看代理的更详细的分解。
如果我们深入到主机，通过点击主机名，我们应该能够看到更细粒度的数据。例如，我们可以看到部署在 AWS Fargate 环境中的 Elastic Agent 本身的 CPU 使用率。
最后，我们可以查看使用 Elastic Agent 收集的数据生成的 AWS Fargate 仪表板。这是一个开箱即用的仪表板，也可以根据您想要可视化的数据进行自定义。
正如您在仪表板中看到的，我们可以根据正在运行的任务进行筛选，还可以查看在我们的环境中运行的容器列表。另一个可能有用的是显示每个集群的 CPU 使用率，如“每个集群的 CPU 利用率”所示。
仪表板可以从不同的来源提取数据，在本例中显示了 AWS Fargate 和更大的 ECS 集群的数据。底部的两个容器直接显示来自 ECS 的 CPU 和内存使用情况。
结论
在本文中，我们展示了如何使用 Elastic Agent 和 Fleet 将数据从 AWS Fargate 发送到 Elastic 可观察性。无服务器架构正在快速成为行业的标准，将服务器管理的负担转移给第三方。但是，这并不能减轻运维工程师管理这些环境中生成的数据的责任。Elastic 可观察性提供了一种方法，不仅可以摄取来自无服务器架构的数据，还可以制定路线图来解决未来的问题。
通过 AWS Marketplace 注册，开始您自己的 7 天免费试用，并在全球任何 AWS 上的 Elastic Cloud 区域 内几分钟内快速启动部署。您在 AWS Marketplace 上购买的 Elastic 将包含在您每月合并的账单报表中，并将从您与 AWS 承诺的支出中扣除。
有关无服务器、可观察性和 AWS 的更多资源
- 在 Elastic 可观察性上分析 AWS 应用程序的服务指标（EC2、ELB、RDS 和 NAT）
- 使用 Elastic 可观察性深入了解 AWS Lambda 无服务器函数
- 使用 Elastic APM 和 Tracetest 进行基于跟踪的测试
- 通过 AWS Firehose 将 AWS 日志发送到 Elastic
本文中描述的任何功能或功能的发布和时间安排完全由 Elastic 自行决定。任何当前不可用的功能或功能可能无法按时或根本无法交付。