AWS 19 AWS_Monitoring_Audit_CloudWatch_X-Ray_CloudTrail

AWS监控、故障排除和审计CloudWatch、X射线和CloudTrail

为什么监控很重要
?我们知道如何部署应用程序
?安全
?自动
?将基础设施用作代码
?利用最好的AWS组件！
?我们的应用程序已经部署，我们的用户不在乎我们是如何做到的…
?我们的用户只关心应用程序是否正常工作！
?应用程序延迟：它会随着时间的推移而增加吗？
?应用程序中断：不应降低客户体验
?用户联系IT部门或投诉不是好结果
?故障排除和补救
?内部监测：
?我们能在问题发生之前预防它们吗？
?性能和成本
?趋势（缩放模式）
?学习和改进

自动气象站的监测
?AWS CloudWatch：
?指标：收集和跟踪关键指标
?日志：收集、监控、分析和存储日志文件
?事件：当AWS中发生某些事件时发送通知
?警报：对指标/事件做出实时反应
?AWS X射线：
?对应用程序性能和错误进行故障排除
?微服务的分布式跟踪
?AWS CloudTrail：
?对正在进行的API调用进行内部监控
?审核用户对AWS资源的更改

-------------------------------------------------------------------------------------------------

AWS CloudWatch Metrics
AWS CloudWatch指标
?CloudWatch为AWS中的每项服务提供指标
?指标是一个需要监控的变量（CPU利用率、网络等）
?指标属于名称空间 namespaces
?维度是度量的属性（实例id、环境等）。
?每指标最多10个维度
?指标有时间戳
?可以创建CloudWatch指标仪表盘

EC2详细监控
?EC2实例指标“每5分钟”有一个指标
?通过详细监控（收费），您可以“每1分钟”获取数据
?如果您想更快地扩展ASG，请使用详细监控！

?AWS免费层允许我们拥有10个详细的监控指标
?注意：默认情况下，EC2内存使用率不会被推送（必须作为自定义指标从实例内部推送）

CloudWatch自定义指标
?可以定义自定义指标并将其发送到CloudWatch
?示例：内存（RAM）使用情况、磁盘空间、登录用户数…
?使用API调用PutMetricData
?能够使用维度（属性）划分指标
? Instance.id
? Environment.name
?指标分辨率（StorageResolution API参数–两个可能的值）：
?标准：1分钟（60秒）
?高分辨率：1/5/10/30秒–成本更高
?重要提示：在过去两周和未来两小时内接受度量数据点（确保正确配置EC2实例时间）

-------------------------------------------------------------------------------------------------

CloudWatch日志
?Log groups：任意名称，通常代表一个应用程序
?Log stream:：实例中的应用程序/日志文件/容器
?可以定义日志过期策略（永不过期、30天等）
?CloudWatch日志可以将日志发送到：
?亚马逊S3（出口）
?运动数据流
?动力数据消防水带
?AWS Lambda
?弹性搜索
? Amazon S3 (exports)
? Kinesis Data Streams
? Kinesis Data Firehose
? AWS Lambda
? ElasticSearch

CloudWatch日志-来源
?SDK、CloudWatch日志代理、CloudWatch统一代理
?Elastic Beanstalk：从应用程序收集日志
?ECS：从容器中收集
?AWS Lambda：从功能日志收集
?专有网络流量日志：专有网络特定日志
?API网关
?基于过滤器的CloudTrail
?路由53：记录DNS查询

CloudWatch日志度量过滤器和洞察
?CloudWatch日志可以使用过滤器表达式
?例如，在日志中查找特定IP
?或统计日志中出现的“错误”
?Metric filters可用于触发CloudWatch警报
?CloudWatch Logs Insights可用于查询日志并将查询添加到CloudWatch仪表盘

CloudWatch日志–S3导出
?日志数据最多需要12小时才能导出
?API调用是CreateExportTask
?不接近实时或实时…改用日志订阅

-------------------------------------------------------------------------------------------------

EC2的CloudWatch日志
?默认情况下，没有来自EC2机器的日志进入CloudWatch
?您需要在EC2上运行CloudWatch代理来推送所需的日志文件 IAM Role
?确保IAM权限正确
?CloudWatch日志代理也可以在本地设置

CloudWatch日志代理和统一代理
?用于虚拟服务器（EC2实例、内部部署服务器…）
?CloudWatch日志代理
?旧版本的代理
?只能发送到CloudWatch日志
?CloudWatch统一代理
?收集其他系统级指标，如RAM、流程等…
?收集日志以发送到CloudWatch日志
?使用SSM参数存储进行集中配置

CloudWatch统一代理–指标
?直接在Linux服务器/EC2实例上收集
?CPU（活动、来宾、空闲、系统、用户、窃取）
?磁盘指标（可用、已用、总计）、磁盘IO（写入、读取、字节、iops）
?RAM（空闲、非活动、已用、总计、缓存）
?Netstat（TCP和UDP连接数、网络数据包数、字节数）
?进程（总、死、膨胀、空闲、运行、睡眠）
?交换空间（免费、已用、已用%）
?提醒：EC2的现成指标——磁盘、CPU、网络（高级别）

-------------------------------------------------------------------------------------------------

CloudWatch日志度量过滤器
?CloudWatch日志可以使用过滤器表达式
?例如，在日志中查找特定IP
?或统计日志中出现的“错误”
?公制过滤器可用于触发报警
?过滤器不会追溯过滤数据。过滤器仅发布度量数据过滤器创建后发生的事件的分数

-------------------------------------------------------------------------------------------------

CloudWatch警报
?警报用于触发任何指标的通知
?各种选项（采样、百分比、最大值、最小值等）
?警报状态：
?好的 OK
?数据不足 INSUFFICIENT_DATA
?警报ALARM
?期间：
?评估指标的时间长度（秒）
?高分辨率定制指标：10秒、30秒或60秒的倍数

CloudWatch警报目标
?停止、终止、重新启动或恢复EC2实例
?触发自动缩放操作
?向SNS发送通知（从SNS你几乎可以做任何事情）

EC2 Instance Recovery EC2实例恢复
?状态检查：
?实例状态=检查EC2虚拟机
?系统状态=检查底层硬件
?Recovery：相同的私有、公共、弹性IP、元数据、安置组

CloudWatch闹钟：很高兴知道
?可以根据CloudWatch日志和度量过滤器创建警报
?要测试报警和通知，请使用CLI将报警状态设置为报警
aws cloudwatch set-alarm-state --alarm-name "myalarm" --state-value
ALARM --state-reason "testing purposes"

-------------------------------------------------------------------------------------------------

CloudWatch事件
?事件模式：截获来自AWS服务的事件（来源）
?示例来源：EC2实例启动、代码构建失败、S3、可信顾问
?可以通过CloudTrail集成拦截任何API调用
?时间表或Cron（例如：每4小时创建一次活动）

?从事件中创建JSON负载，并将其传递给目标…
?计算：Lambda、批处理、ECS任务
?集成：SQS、SNS、动静数据流、动静数据消防软管
?编排：步骤功能、代码管道、代码构建
?维护：SSM、EC2行动

-------------------------------------------------------------------------------------------------

亚马逊事件桥 EventBridge

?EventBridge是CloudWatch事件的下一个演变
?默认事件总线：由AWS服务生成（CloudWatch事件）
?合作伙伴事件总线：从SaaS服务或应用程序接收事件
(Zendesk, DataDog, Segment, Auth0…)
?定制事件总线：用于您自己的应用程序
?其他AWS帐户可以访问事件总线
?规则：如何处理事件（类似于CloudWatch事件）

Amazon事件桥模式注册表
?EventBridge可以分析总线中的事件并推断模式
?Schema Registry允许您为应用程序生成代码将提前知道事件总线中数据的结构
?模式可以进行版本控制

亚马逊事件桥vs CloudWatch事件
?Amazon EventBridge构建并扩展了CloudWatch事件。
?它使用相同的服务API和端点，以及相同的基础服务基础设施
?EventBridge允许扩展为您的应用程序和您的第三方SaaS应用程序的定制添加事件总线
?事件桥具有模式注册功能
?EventBridge使用不同的名称来标记新功能
?随着时间的推移，CloudWatch事件的名称将被EventBridge取代。

-------------------------------------------------------------------------------------------------

AWS X-Ray
?在生产中进行调试，这是一种很好的老方法：
?本地测试
?到处添加日志语句
?在生产中重新部署
?使用CloudWatch和analytics的应用程序的日志格式不同
?调试：整体“简单”，分布式服务“困难”
?对您的整个架构没有共同的看法！
?进入AWS X射线！

AWS X射线
应用程序的可视化分析

AWS X射线优势
?性能故障排除（瓶颈）
?了解微服务体系结构中的依赖关系
?查明服务问题
?审查请求行为
?发现错误和异常
?我们是否在开会时间SLA？
?我被限制在哪里？
?识别受影响的用户

X射线兼容性
?AWS Lambda
?弹性豆茎
?ECS
?ELB
?API网关
?EC2实例或任何应用服务器（即使是内部部署）

AWS X射线利用追踪
?跟踪是跟踪“请求”的端到端方式
?处理请求的每个组件都会添加自己的“跟踪”
?跟踪由段（+子段）组成
?可以在跟踪中添加注释，以提供额外信息
?追踪能力：
?每一个请求
?样本请求（例如百分比或每分钟的速率）
?X射线安全：
?IAM授权
?KMS用于静态加密

AWS X射线
如何启用它？
1） 您的代码（Java、Python、Go、Node.js、.NET）必须导入AWS X-Ray SDK
?几乎不需要修改代码
?然后，应用程序SDK将捕获：
?calls AWS服务
?HTTP/HTTPS请求
?数据库调用（MySQL、PostgreSQL、DynamoDB）
?排队call（SQS）
2） 安装X射线守护程序或启用X射线AWS集成
?X-Ray守护进程用作低级别UDP数据包拦截器（Linux/Windows/Mac…）
?AWS Lambda/其他AWS服务已经为您运行了X射线守护程序
?每个应用程序必须具有IAM向X射线写入数据的权限

X射线魔法magic
?X射线服务从所有不同的服务收集数据
?服务地图由所有路段和轨迹计算得出
?X射线是图形化的，所以即使是非技术人员也可以帮助排除故障

AWS X射线故障排除
?如果X射线对EC2不起作用
?确保EC2 IAM角色具有适当的权限
?确保EC2实例正在运行X射线守护程序
?要在AWS Lambda上启用：
?确保其具有适当政策的IAM执行角色(AWSX-RayWriteOnlyAccess)
?确保在代码中导入X射线

-------------------------------------------------------------------------------------------------

代码中的X射线检测
?仪器是指测量产品性能、诊断错误和写入跟踪信息。
?要插入应用程序代码，请使用X射线SDK
?许多SDK只需要更改配置
?您可以修改应用程序代码以进行自定义和注释
SDK使用拦截器、过滤器和处理程序发送给X射线的数据
，中间件…

X射线概念
?分段：每个应用程序/服务都会发送它们
?细分市场：如果你需要细分市场的更多细节
?跟踪：收集在一起形成端到端跟踪的段
?采样：减少发送到X光的请求量，降低成本
?注释：用于索引跟踪并与过滤器一起使用的键值对
?元数据：键值对，未编制索引，不用于搜索

?X射线守护程序/代理具有跨帐户发送跟踪的配置：
?确保IAM权限正确——代理将担任该角色
?这使您可以拥有一个用于所有应用程序跟踪的中央帐户

X射线取样规则
?通过采样规则，您可以控制记录的数据量
?您可以在不更改代码的情况下修改采样规则

?默认情况下，X-Ray SDK每秒记录第一个请求
任何额外请求的百分之五。
?每秒有一个请求是存储，这确保至少有一个
只要服务为请求提供服务，每秒都会记录跟踪。
?百分之五是超出对水库规模进行采样

X射线自定义采样规则
?你可以根据储液罐和流速制定自己的规则

-------------------------------------------------------------------------------------------------

X射线写入API（由X射线守护进程使用）

?PutTraceSegments：将片段文档上传至AWS X-Ray
?PutTelemetryRecords：由AWS X射线守护程序用于上传遥测数据。
?分段接收计数、分段接收计数、后端连接错误…
? SegmentsReceivedCount,SegmentsRejectedCounts,BackendConnectionErrors…
?GetSamplingRules：检索所有采样规则（以了解发送内容/时间）
?GetSamplingTargets&GetSamplingStatisticsSummaries：高级
?X射线守护程序需要有一个IAM策略，授权正确调用arn:aws:IAM:：aws:policy/AWSXrayWriteOnlyAccess函数的正确API
?GetServiceGraph：主图
?BatchGetTraces：检索由ID指定的跟踪列表。每个跟踪都是一个源于单个请求的段文档集合。
?GetTraceSummaries：检索可用于使用可选筛选器指定的时间范围。要获得完整的跟踪，请将跟踪ID传递给BatchGetTraces。
?GetTraceGraph：检索一个或多个特定跟踪的服务图身份证。
-------------------------------------------------------------------------------------------------

弹性豆茎X射线
?AWS Elastic Beanstalk平台包括X射线守护程序
?您可以通过在Elastic Beanstalk控制台中设置一个选项来运行守护程序
或者使用配置文件（在.ebextensions/xray daemon.config中）
?确保为您的实例配置文件提供正确的IAM权限，以便
X射线守护程序可以正常工作
?然后确保您的应用程序代码使用X-Ray SDK进行检测
?注意：多容器Docker不提供X射线守护程序

-------------------------------------------------------------------------------------------------
ECS + X-Ray integration options

ECS Cluster
X-Ray Container as a Daemon
run each instance, UDP port: 2000

ECS Cluster
X-Ray Container as a “Side Car”
each ap contoiner now run x-ray side car

Fargate Cluster
X-Ray Container as a “Side Car”
control

任务定义， UDP port: 2000
， environment variable: aws AWS_XRAY_DAEMON prot:2000
-------------------------------------------------------------------------------------------------

?AWS CloudTrail：
?对正在进行的API调用进行内部监控
?审核用户对AWS资源的更改

AWS云迹
?为您的AWS帐户提供治理、合规和审计
?默认情况下启用CloudTrail！
?通过以下方式获取AWS账户内的事件/API调用历史记录：
?控制台
?SDK
?CLI
?AWS服务
?可以将CloudTrail中的日志放入CloudWatch日志或S3
?轨迹可以应用于所有区域（默认）或单个区域。
?如果在AWS中删除了资源，请首先调查CloudTrail！

CloudTrail事件
?管理活动：
?对AWS帐户中的资源执行的操作
?例如：
?配置安全性（IAM附件策略）
?为路由数据配置规则（Amazon EC2 CreateSubnet）
?设置日志记录（AWS CloudTrail CreateTrail）
?默认情况下，跟踪配置为记录管理事件。
?可以将读取事件（不修改资源）与写入事件（可能修改资源）分开
?数据事件：
?默认情况下，不会记录数据事件（因为高容量操作）
?Amazon S3对象级活动（例如：GetObject、DeleteObject、PutObject）：可以分离读写事件
?AWS Lambda函数执行活动（调用API）
?CloudTrail Insights活动：
?使CloudTrail Insights能够检测您帐户中的异常活动：
?不准确的资源调配
?达到服务极限
?AWS IAM行动的爆发
?定期维护活动中的差距
?CloudTrail Insights分析正常管理事件，以创建基线
?然后持续分析写入事件，以检测异常模式
?CloudTrail控制台中出现异常
?事件被发送到Amazon S3
?生成EventBridge事件（用于自动化需求）

CloudTrail事件保留
?事件在CloudTrail中存储90天
?要将事件保持在这段时间之后，请将其记录到S3并使用Athena

-------------------------------------------------------------------------------------------------
CloudTrail vs CloudWatch vs X射线
?CloudTrail：
?审核用户/服务/AWS控制台发出的API调用
?用于检测未经授权的呼叫或更改的根本原因
?CloudWatch：
?用于监控的CloudWatch指标
?用于存储应用程序日志的CloudWatch日志
?CloudWatch警报，在出现意外指标时发送通知
?X光：
?自动跟踪分析和中央服务地图可视化
?延迟、错误和故障分析
?跨分布式系统的请求跟踪
-------------------------------------------------------------------------------------------------