iOS网络数据指标收集

Posted 2023-05-31 滴水微澜

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了iOS网络数据指标收集相关的知识，希望对你有一定的参考价值。

在平时开发中有时候需要收集网络不同阶段性能数据来分析网络情况，下面总结了2种收集方式。

1.通过NSURLSession提供的代理方法收集

2.通过NSURLProtocol做统一网络请求拦截收集

通过NSURLSession提供的代理方法收集

当NSURLSessionTask完成并返回响应时，NSURLSession会收集一些关于任务运行的性能指标，如请求时间、响应时间、传输速度、重定向次数等等。这些指标会被包装成NSURLSessionTaskMetrics对象，并在任务完成时传递给代理对象。在这个方法中可以对这些指标进行处理和记录，以便对网络性能进行分析和优化。

@interface MySessionDelegate : NSObject <NSURLSessionDelegate>

@end

@implementation MySessionDelegate
- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didFinishCollectingMetrics:(NSURLSessionTaskMetrics *)metrics 
    // 打印出请求的各项指标
    for(NSURLSessionTaskTransactionMetrics *transaction in metrics.transactionMetrics) 
        NSHTTPURLResponse *response = (NSHTTPURLResponse *)transaction.response;
        NSLog(@"Request URL: %@", transaction.request.URL);
        NSLog(@"HTTP Status Code: %ld", (long)response.statusCode);
        NSLog(@"Request Start Time: %@", transaction.startDate);
        NSLog(@"Request End Time: %@", transaction.endDate);
        NSLog(@"Request Duration: %f", [transaction.duration doubleValue]);
        NSLog(@"Bytes Sent: %lld", transaction.countOfRequestBodyBytesSent);
        NSLog(@"Bytes Received: %lld", transaction.countOfResponseBodyBytesReceived);
        NSLog(@"Redirection Count: %lu", (unsigned long)transaction.redirectCount);
        NSLog(@"Request Method: %@", transaction.request.HTTPMethod);
    


@end

通过NSURLProtocol做统一网络请求拦截收集

NSURLProtocol是自定义URL加载系统的一部分，允许开发者拦截URL请求并做自定义的逻辑处理。

NSURLProtocol的主要作用是在URL请求和URL响应之间添加拦截器，提供了对URL请求的拦截和处理的能力。

NSURLProtocol常用方法说明

canInitWithRequest:：用于判断是否需要处理该请求，如果返回YES，则会继续调用其他方法处理该请求，如果返回NO，则会终止处理该请求。

canonicalRequestForRequest:：用于获取规范化的请求对象，可以在这里修改请求头等信息。

startLoading:：用于开始处理请求，可以在这里发起网络请求、读取本地缓存等操作。

stopLoading:：用于停止处理请求，通常在此方法中取消网络请求、关闭文件等操作。

NSURLProtocol的使用非常灵活，可以用于实现自定义的网络拦截器、缓存策略、调试工具等。

代码举例

@interface MyURLProtocol : NSURLProtocol

@end

@interface MyURLProtocol()

@property(nonatomic, strong) NSURLConnection *connection;
@property(atomic, strong) NSMutableData *receivedData;

@end

@implementation MyURLProtocol

+ (BOOL)canInitWithRequest:(NSURLRequest *)request 
    if ([NSURLProtocol propertyForKey:kCustomURLProtocolKey inRequest:request]) 
        return NO;
    
    
#if defined(Debug)
    return YES;
#elif defined(Release)
    return NO;
#endif


+ (NSURLRequest *)canonicalRequestForRequest:(NSURLRequest *)request 
    return request;


- (void)startLoading 
    NSMutableURLRequest *mutableRequest = [[self request] mutableCopy];
    [NSURLProtocol setProperty:@YES forKey:kCustomURLProtocolKey inRequest:mutableRequest];
    self.connection = [NSURLConnection connectionWithRequest:mutableRequest delegate:self];


- (void)stopLoading 
    [self.connection cancel];
    self.connection = nil;


#pragma mark - NSURLConnection Delegate

#pragma mark - NSURLConnection Delegate
- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response

    [[self client] URLProtocol:self didReceiveResponse:response
            cacheStoragePolicy:NSURLCacheStorageNotAllowed];


- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data

    [[self client] URLProtocol:self didLoadData:data];
    
    if (self.receivedData == nil) 
        self.receivedData = [[NSMutableData alloc] init];
    
    
    [self.receivedData appendData:data];


-(void)connectionDidFinishLoading:(NSURLConnection *)connection

    NSURLRequest *logRequest = [self.request copy];
    NSData *data = [self.receivedData copy];
    [[self client] URLProtocolDidFinishLoading:self];
    self.connection = nil;
#if defined(Debug)
    dispatch_async(dispatch_get_main_queue(), ^
        [[LogManager sharedInstance] addNetworkLog:logRequest response:data];
    );
#else
    dispatch_async(dispatch_get_main_queue(), ^
        [[LogManager sharedInstance] addNetworkLog:logRequest response:data];
    );
#endif
    


- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error

    [[self client] URLProtocol:self didFailWithError:error];
    self.connection = nil;


@end

AWS 监控服务

AWS CloudWatch

概念

基于确定的内容监控基础设施组件
基于指定的指标发送通知并触发各种操作
分布式统计数据和收集系统，用于收集并跟踪指标
默认情况下，在管理程序级别无缝收集指标，如CPU利用率、IO字节操作、网络字节操作
CloudWatch可以触发包括启动终止重启EC2，增加减少AutoScaling组，将消息发送至SNS等操作
属性
- 面板（Dashboards）-可创建自定义面板来方便观察AWS环境中的不同监控对象
- 告警（Alarms）- 当某个监控对象超过阈值时，会发出告警信息
- 事件（Events）- 针对AWS环境中所发生的变化进行的反应
- 日志（Logs）-Cloudwatch日志帮助收集、监控和存储日志信息
监控指标
- 支持对绝大多数AWS服务的监控和指定指标，包括：
  - Auto Scaling，Amazon CloudFront，Amazon CloudSearch，Amazon DynamoDB，Amazon EC2，Amazon EC2容器服务 (Amazon ECS)，Amazon ElastiCache，Amazon Elastic Block Store(Amazon EBS) ，Elastic Load Balancing，Amazon Elastic MapReduce(Amazon EMR)，Amazon Elasticsearch服务， Amazon Kinesis Streams，Amazon Kinesis Firehose，AWS Lambda，Amazon Machine Learning， AWS OpsWorks，Amazon Redshift，Amazon关系数据库服务(Amazon RDS)，Amazon Route 53 ， Amazon SNS，Amazon Simple Queue Service(Amazon SQS)，Amazon S3，AWS Simple Workflow Service(Amazon SWF)，AWS Storage Gateway，AWS WAF和Amazon WorkSpaces。
- 自定义指标的能力，包括：
  - 那些本身对AWS不可见的应用程序指标，如网页加载时间，请求出错率，并发进程或线程数量，支持通过API调用的方式PUT各种指标
监控频率
- 基本监控以每5分钟作为数据点进行采集，免费提供有限数量的指标和监控
- 详细监控以每分钟为数据点进行采集，可自定义指标，需要付费使用
- 支持更细粒度的高分辨率指标，每1s采集
- CloudWatch支持跨可用区聚合和检索，但不支持跨区域聚合
- CloudWatch只能监视性能指标，不能跟踪变化
云设计模式 - CloudWatch 结合监控软件工作
- CloudWatch无法提供EC2内部的工作，如操作系统、中间件、应用程序等，这些都需要使用独立监控系统实现
- 可以在独立的EC2上部署 Nagios、Zabbix、Munin等软件，通过CloudWatch API来获取来自AWS的监控信息，从而进行整合

技术图片

CloudWatch Logs

可以通过自定义指标或CloudWatch Logs来处理数据，获取近乎实时的监控日志
监控并存储日志，以帮助您更好地了解并运行系统和应用程序
您可以使用 CloudWatch Logs 将日志数据长期存储在高持久性且经济高效的存储中，无需担心耗尽硬盘空间。
CloudWatch Logs 可以存储单独的测量结果及其他信息的日志文件
监控数据默认最长保留15个月。且不可手工删除
- 时段低于 60 秒的数据点可保留 3 个小时。这些数据点是高分辨率自定义指标。
- 时段为 60 秒（1 分钟）的数据点可保留 15 天
- 时段为 300 秒（5 分钟）的数据点可保留 63 天
- 时段为 3600 秒（1 小时）的数据点可保留 455 天（15 个月）
支持对日志文件进行实时监视并触发特定事件
CloudWatch Logs 可以用于以下处理方式：
- 以数据日志的实时流传输到Amazon Kinesis Stream 或者 AWS Lambda 等数据处理解决方案中
- 以批存档形式存储到 S3或者Glacier中
- 管理员可以通过控制台看到
CLoudWatch Agent
- 在EC2的Linux系统中可以通过安装CloudWatch log Agent 来搜集EC2系统内部日志
- Amazon Linux、Ubuntu、CentOS、Red Hat Enterprise Linux 和 Windows 均支持
CloudWatch Logs Insights
- 用于 CloudWatch Logs 的一项随用随付的交互式集成日志分析功能。它允许开发人员、操作人员和系统工程师搜索和可视化其日志，以帮助他们了解、改进和调试其应用程序。
  Alert
您可以在账户中创建警报来监控任何 Amazon CloudWatch 指标。例如，您可以创建警报来监控 Amazon EC2 实例 CPU 使用情况、Amazon ELB 请求延迟、Amazon DynamoDB 表吞吐量、Amazon SQS 队列长度、甚至 AWS 账单费用。
您还可以为特定于自定义应用程序或基础设施的自定义指标创建警报。如果自定义指标是高分辨率指标，您可以选择创建高分辨率警报，该警报将在 10 秒钟或 30 秒钟时段时发出提醒。
创建警报时，可进行配置，以便在所选监控指标超出所定义的阈值时执行一项或多项自动操作。例如，您可以设置发送电子邮件的警报，发布到 SQS 队列，停止或终止一个 Amazon EC2 实例，或执行 Auto Scaling 策略。由于 Amazon CloudWatch 警报与 Amazon Simple Notification Service 实现集成，因此还可使用由 SNS 支持的任意通知类型。
警报历史记录有效期为 14 天

Dashboard

Amazon CloudWatch 控制面板让您能够创建、自定义、交互和保存 AWS 资源及自定义指标的图表。
自动化控制面板预先构建了 AWS 服务建议的最佳实践，保持资源感知，并能动态更新以反映重要性能指标的最新状态。您现在可以对特定视图进行筛选和故障排除，无需添加其他代码来反映 AWS 资源的最新状态。确定性能问题的根本原因之后，您就可以直接转到 AWS 资源以快速采取行动。
控制面板处于打开状态时会自动刷新。

Event

Amazon CloudWatch Events (CWE) 是一个描述 AWS 资源更改的系统事件流。
当某个事件与您在系统中创建的某条规则匹配时，您可以自动调用一个 AWS Lambda 函数、将事件中继到 Amazon Kinesis 流、发送 Amazon SNS 主题通知，或调用一个内置工作流。
Event 并不像AWS Config一样检查合规性，也不像CloudTrail一样记录调用记录。

CloudWatch的限制

每个AWS账户最多保存5000个告警
默认监控采集和聚合粒度为1分钟
默认情况下搜集的指标数据保留15天，长时间保留需要转存到S3或者Glacier中
默认不支持监控内存和系统内部指标，需要自定义配置

AWS CloudTrail

概述

CloudTrail 可通过记录账户上执行的操作来提供用户活动的可见性。CloudTrail 可记录每个操作的重要信息，包括请求的发出方、使用的服务、执行的操作、操作的参数，以及 AWS 服务返回的响应元素。这些信息能够帮助您追踪 AWS 资源的变更情况，帮助您排查操作问题。CloudTrail 便于您确保与内部策略和监管标准的合规性。
一个事件中包含了相关活动的信息：请求的发出方、使用的服务、执行的操作、操作的参数，以及 AWS 服务返回的响应元素。
捕获AWS账户所做的各种操作，包括AWS API调用和相关事件，并将日志文件上传至S3
上传至S3后可以选择触发SNS进行通知
也可以将事件传递到CloudWatch监控日志组
日志文件在S3中使用SSE加密存储，可以定义生命周期对日志进行归档或删除
API调用会在大约15分钟内生成日志
日志文件会每5分钟发布一次
默认开启，且保留90天记录

配置

适用于所有区域的CloudTrail
每个Region使用相同的配置和策略
所有日志将被传送到单个指定的S3存储桶
这是CloudTrail的默认配置，也是推荐选项
适用于单个区域的CloudTrail
每个区域单独处理自己的Trail日志
日志传送到每个区域自己的S3存储桶

CloudTrail 跟踪

通过设置 CloudTrail 跟踪，您可以将 CloudTrail 事件传送至 Amazon S3、Amazon CloudWatch Logs、Amazon CloudWatch Events。这让您能够利用多种功能来帮助归档、分析和响应 AWS 资源中发生的更改。
将一个跟踪应用到所有地区是指创建一个可记录所有地区内 AWS 账户活动的跟踪。
您只需调用一次 API 或单击几次鼠标，即可在分区内的所有地区创建和管理跟踪。您将在一个 S3 存储桶或 CloudWatch Logs 日志组中收到在您的 AWS 账户中跨所有地区进行的账户活动的记录
Global Trail
- 将一个跟踪应用到所有地区之后，CloudTrail 会通过复制相关跟踪配置在所有地区创建一个新跟踪。CloudTrail 将记录并处理每个地区中的日志文件，并会将包含所有 AWS 地区的账户活动的日志文件传送至一个 S3 存储桶和一个 CloudWatch Logs 日志组中。
Multiple Trail
在一个 AWS 区域中，您最多可以创建五个跟踪。应用到所有区域的跟踪会出现在每个区域中，并算作每个区域的一个跟踪。
有了多个跟踪，安全管理员、软件开发人员和 IT 审计人员等不同利益相关者就可以创建并管理他们自己的跟踪。
如果在多个region开启Logging Global Service，会让Global Service的日志产生多条重复，所以建议仅在一个region启用

CloudTrail 处理库

AWS CloudTrail 处理库是一个 Java 库，可以帮助您轻松构建读取和处理 CloudTrail 日志文件的应用程序。
CloudTrail 处理库可提供处理以下任务的功能，如不断轮询 SQS 队列、读取和解析 SQS 消息、下载 S3 中存储的日志文件、以容错方式解析和序列化日志文件中的事件。

AWS Trusted Advisor

概述

借鉴大量的最佳实践，检查AWS环境对存在机会的资金节省，可用性和性能提升、弥补安全性漏洞提出建议
通过仪表盘查看AWS资源整体状态和节省预算
四个类别的最佳实践
- 成本优化
- 安全性
- 容错性
- 性能改进
颜色编码：
- 红色-建议采取行动
- ×××-建议调查
- 绿色-未检测到问题
免费检查项目
- 服务限制 - 检查超出服务限制80%，基于快照，有约24小时的延迟
- 安全组未限制端口 - 检查允许0.0.0.0/0 的端口
- IAM - 检查是否使用IAM
- 根账户MFA - 检查根账号是否启用MFA
  Trusted Advisor 特性和功能
通知：免费服务，每周发送一封电邮了解AWS资源部署的最新情况
Access Management：利用IAM控制对具体检查项目或检查类别的访问
AWS Support API: 以编程方式检索和刷新Trust Advisor 结果
操作链接：直接通过报告中的超链接进入AWS管理控制台根据建议进行操作
最近改动：在控制台仪表盘上跟踪检查近期变化
排除项目：自定义不检查不相关的项目
5分钟刷新：可以通过单击refresh all 或者自动每5分钟刷新检查项目

AWS Config

概述

提供AWS资源清单、配置历史记录和配置更改通知的完全托管服务
支持合规审计、安全分析、资源变更跟踪和故障排除
默认情况下，AWS Config会为区域中每一个被支持的资源创建配置项
每一次变更都会生成一个配置项目变化的历史记录
可以配置检查资源更改是否违规，对不合规的行为进行标记并通过SNS发送通知
支持更改管理、持续审计和合规、故障排除、安全和事件分析
AWS Config 可以基于地区启用
AWS Config 可以在多个账户间聚合数据，但不能跨账户预置规则

Config Rule

Config 规则代表某个资源的期望配置，其评估依据是 AWS Config 中记录的相关资源的配置更改。针对资源配置评估规则的结果可在控制面板中查看。使用 Config 规则，您可以从配置角度评估整体合规性和风险状态、查看一段时间内的合规性趋势，以及查明哪些配置更改导致了资源脱离规则合规性。
Config 规则不会直接影响最终用户使用 AWS 的方式。它仅在配置更改已完成并由 AWS Config 记录之后才评估资源配置。Config 规则不会阻止用户进行可能非合规的更改。
Config 规则在资源的配置项 (CI) 由 AWS Config 捕获之后评估规则。它不会在预置资源或更改资源配置之前评估规则。
默认情况下，您在 AWS 账户中最多可以创建 50 个规则
任何规则都可以作为由更改触发的规则或作为定期规则建立。由更改触发的规则在 AWS Config 为任何指定资源记录配置更改后执行。此外，还必须指定以下项之一：
- 标签键:（可选值）：“标签键:值”意味着为带有指定“标签键:值”的资源记录的任何配置更改都将触发规则评估。
- 资源类型：为指定资源类型内的任何资源记录的任何配置更改都将触发规则评估。
- 资源 ID：为由资源类型和资源 ID 指定的资源记录的任何更改都将触发规则评估。
- 定期规则以指定的频率触发。可用频率为 1 小时、3 小时、6 小时、12 小时或 24 小时。定期规则具有适用于该规则的所有资源当前配置项 (CI) 的完整快照。

Config Items

配置项 (CI) 指的是一项资源在给定时间点的配置。CI 由 5 个部分组成：
各不同资源类型共同的有关资源的基本信息（例如 Amazon Resource 名称、标签）、
资源特定的配置数据（例如 EC2 实例类型）、
与其他资源关系的映射（例如 EC2::Volume vol-3434df43“附加到实例”EC2 Instance i-3432ee3a）
与此状态相关的 AWS CloudTrail 事件 ID、
帮助您识别 CI 有关信息的元数据（如该 CI 的版本）以及捕捉到该 CI 的时间。
AWS Config 检测资源配置的更改并记录由更改导致的配置状态。如果接二连三地（例如，在几分钟内）对资源进行多次配置更改，则 Config 将只记录代表这一组更改累积影响的最终配置。
借助 AWS Config，您可以记录 AWS 账户中的 EC2 实例内软件的配置更改，还可记录本地环境中虚拟机 (VM) 或服务器的配置更改。AWS Config 记录的配置信息包括操作系统更新、网络配置、已安装的应用程序等。