企业官网建设流程全解析

做网站设计抬头,系统优化软件有哪些,2021年军事新闻,北京口碑好装修公司基础设施可观测性对于维持系统正常运行时间、优化云环境以及保护云边界安全至关重要。云环境会产生大规模的可观测性数据。VPC Flow Logs#xff08;流日志#xff09;、ELB Access Logs#xff08;访问日志#xff09;、CloudTrail 和 CloudWatch 日志可以轻松达到每秒数十…基础设施可观测性对于维持系统正常运行时间、优化云环境以及保护云边界安全至关重要。云环境会产生大规模的可观测性数据。VPC Flow Logs流日志、ELB Access Logs访问日志、CloudTrail 和 CloudWatch 日志可以轻松达到每秒数十万个事件。处理如此巨大的规模本身就是一个复杂的问题。今天我们要介绍EDOT Cloud Forwarder它构建于 OTel Collector 之上是将你的云环境连接到 Elastic Observability 的最简单、最快可能也是最“无聊”意味着省心的方式并且它现已在 AWS 上正式发布。使用 EDOT Cloud Forwarder你可以在几秒钟内上手获得整个云资产的可观测性并轻松处理任何体量的遥测数据。在 District Line 的列车上部署 Cloud Forwarder于是我开始着手在我的 AWS 账户中部署 EDOT Cloud Forwarder。我是在上下班通勤的路上做的仅仅依靠还算不错的 4G 信号并祈祷我那 27% 的电池电量能够撑住。我点击了 Terraform 模板的部署按钮并开始等待。我开始看到事件流入 Elastic Observability。当列车驶入 Putney Bridge 站时日志流达到峰值屏幕上滚动着每秒一百万个事件1M EPS。部署完成后我得到了我能期望的最好的“三个零”零人工干预Zero Intervention我看着流量攀升至整整 100万 EPS。Lambda 函数自动从几个实例横向扩展到所需的 60-65 个并发执行。无需任何手动调整。扩缩容是即时且自动的。零数据丢失Zero Data Loss它实现了稳定的处理速率每一个事件都被索引到了 Elasticsearch 中。零闲置成本Zero Idle Cost当没有事件时Cloud Forwarder 会缩容至零——它没有固定的基础设施成本。你只需为数据处理的那一刻付费而无需为长期闲置的超额配置服务器付费。就在列车停稳之前我看了一下在 Parsons Green 站和 Putney Bridge 站之间运行 Cloud Forwarder 这两分钟的总成本——我们转发了大约 120GB 的遥测数据总成本不到 0.10 英镑。当然除非你把 2.50 英镑的火车票也算进去让任何规模的可观测性变得简单开始观测你的基础设施是很难的而一旦它变得可观测从中挖掘出可操作的价值需要从海量的遥测数据有时每秒数百万个事件中进行筛选和提炼。适用于 AWS 的新版 EDOT Cloud ForwarderGCP 和 Azure 版本也处于预览阶段非常易于部署只需一个 Terraform 模板即可。为了确保容易上手我们将其设计为尽可能接近一键部署只需点击下面的链接即可在你的 AWS 账户中启动 CloudFormation 堆栈最棒的部分是什么这种开始使用 Elastic Observability 的最快方式可以扩展到任何规模的工作负载有了 EDOT Cloud Forwarder你只需这就一个解决方案它既可以自动缩容至零也可以扩展到每秒处理数百万个事件。那么什么是 EDOT Cloud ForwarderEDOT Cloud Forwarder 是一个无服务器Serverless的 OpenTelemetry 收集器在 AWS 上作为 Lambda 函数运行。在 AWS 中它由事件触发处理来自 VPC Flow Logs、ELB Access Logs、CloudTrail、CloudWatch Logs 和 CloudWatch Metrics 等服务的日志和指标。它具有以下核心功能从云服务提供商收集可观测性和安全数据将数据解析为原生 OpenTelemetry 格式通过 OTLP 转发数据根据流量自动扩缩容适用于 AWS 的 ECF 是纯无服务器解决方案无需管理虚拟机、容器或 Kubernetes 控制平面。下车后一个更受控的场景为了进行更受控的测试场景我们使用了生成的合成 VPC Flow Log 数据以展示 EDOT Cloud Forwarder 如何轻松可靠地维持每秒一百万个事件且无数据丢失。在配置方面我们保留了所有 EDOT Cloud Forwarder 的配置/设置为默认值。在 AWS 中Lambda 的最大并发数默认为 5。如果保持默认值 5预期可以达到约 50k EPS。对于我们的场景我们将此值提高到 100以确保我们的测试有足够的余量。我们分 10 分钟一个阶段运行该场景每个阶段的数据量都更大。我们在该阶段内保持摄入量平稳以便为我们提供短期稳态窗口来抓取指标。我们在所有场景阶段均未遇到错误未出现预期行为之外的重试在摄入的 54 亿个事件中没有数据丢失。写给可观测性极客的数据统计因为我们知道你们喜欢这些增量负载阶段我们使用增量负载阶段测试了 EDOT Cloud Forwarder逐渐将流量从大约每秒 300,000 个事件增加到每秒超过 100 万个事件。下图显示了整个测试期间的 Elasticsearch 摄入率。你可以看到当我们通过六个不同阶段提升时的清晰进程每个平台期代表 10 分钟的稳定期。系统平滑地处理了每次流量增加最终达到了持续的每秒 100 万个文档的摄入量且没有瓶颈或数据丢失。Lambda如 CloudWatch 指标所示无需手动调整。在整个测试期间未发现错误和限流。并发执行数同时运行 60 到 65 个实例。Lambda 平均执行时间每次执行大约耗时 5 秒。内存使用率内存使用稳定在 450 MB 左右低于 512 MB 的默认限制。Elasticsearch 索引Elasticsearch 每秒索引一百万个文档几秒钟内即可在 Discover 中看到事件没有索引延迟或瓶颈。设计高效基于 S3 的 Lambda 实现 1M EPS在 AWS 上以 1M EPS 运行 ECF 的成本约为每小时 3.87 美元。其中大约 66%每小时 2.57 美元是数据传输费用同区域34%每小时 1.32 美元是 Lambda 计算费用不到 1% 是 S3 请求费用。这是完全无服务器的没有闲置成本。你只需在转发事件时付费。对于 S3数据以大对象预批处理的形式到达这保持了较低的 Lambda 调用次数并严格控制了计算成本。在持续吞吐量下Lambda 成本与 EKS 相当——但无需集群管理或闲置容量。其他选项在 EKS 上运行 OTel Collector 处理 1M EPS在 EKS 上为 1M EPS 配置 OTel Collector 的基准成本约为每小时 3.69 美元。其中大约每小时 0.33 美元是计算相关费用EC2 节点、EKS 控制平面和 EBS。其余来自数据传输和 SQS这部分随流量扩展不随利用率变化。闲置计算对 EKS 实际成本的影响考虑到 EKS 通常是为峰值负载预置的计算部分的实际成本会受到闲置容量的影响。在100% 利用率下总成本为每小时 3.69 美元。在50% 利用率吸收突发流量的常见基准下总成本上升至约每小时 4.02 美元。在30% 利用率下它进一步增加到约每小时 4.46 美元。为工作量付费 vs 为容量付费适用于 AWS 的 ECF 提供了 1M EPS 的处理能力成本与峰值利用率下的 EKS 相当且无需闲置计算或容量规划。EKS 可以达到同样的峰值吞吐量但随着平均利用率下降总成本会进一步增加因为必须提前预置计算容量。结论一个枯燥的事实对于 EDOT Cloud Forwarder 来说每秒一百万个事件与其他任何工作负载没有什么区别。由于无需部署基础设施没有闲置成本也就无需手动扩缩容我想最好的做法就是停止过度思考开始转发数据这就像踏上了线路上最快的列车你只需上车就能立即踏上前往目的地的旅程毫不费力地应对任何距离或者在这种情况下应对任何数据量。所以我们发布了它。适用于 AWS 的 ECF 现已正式发布。