关于【常见的数据采集方式有哪几种】，常见的收集数据的方法有哪些，今天涌涌小编给您分享一下，如果对您有所帮助别忘了关注本站哦。
内容导航：1、常见的数据采集方式有哪几种：常见的收集数据的方法有哪些2、得物云原生全链路追踪Trace2.0-采集篇1、常见的数据采集方式有哪几种：常见的收集数据的方法有哪些
收集数据的方法主要有普查和抽样调查两种方式，当对要求数据非常非常准确的时候可以采取普查的方式，抽样调查是在被调查的数据中随机地抽取一些数据组成一个样本，通过对样本中数据的分析去估计全体数据的情况。常见的方法还有问卷调查、查阅资料、实地考查、试验等。
常见的收集数据的方法，主要看你做哪方面的数据分析报告了，根据你分析目的选择数据收集方式，主要有普查和抽样调查两种方式，当对要求数据非常非常准确的时候可以采取普查的方式，抽样调查是在被调查的数据中随机地抽取一些数据组成一个样本，通过对样本中数据的分析去估计全体数据的情况。常见的方法还有问卷调查、查阅资料、实地考查、试验等。
还有观察法
观察法是通过开会、深入现场、参加生产和经营、实地采样、进行现场观察并准确记录(包括测绘、录音、录相、拍照、笔录等)调研情况。主要包括两个方面:一是对人的行为的观察，二是对客观事物的观察。观察法应用很广泛，常和询问法、搜集实物结合使用，以提高所收集信息的可靠性。
根据观察的场景，可以将观察区分为实验室观察和实地观察；根据观察者的参与程序，可分为参与观察和非参与观察；根据观察的准备程度，可分为结构性观察和非结构性观察。不同类型的观察，适用于不同情境，观察者也扮演着不同角色。
声明：本篇经验系「www.coozhi.com」原创，转载请注明出处。
2、得物云原生全链路追踪Trace2.0-采集篇
一、0xcc开篇
2020年3月，得物技术团队在三个月的时间内完成了整个交易体系的重构，交付了五彩石项目，业务系统也进入了微服务时代。系统服务拆分之后，虽然每个服务都会有不同的团队各司其职，但服务之间的依赖也变得复杂，对服务治理等相关的基础建设要求也更高。
对服务进行监控是服务治理、稳定性建设中的一个重要的环节，它能帮助提早发现问题，预估系统水位，以及对故障进行分析等等。从 2019 年末到现在，得物的应用服务监控系统经历了三大演进阶段，如今，整个得物的应用微服务监控体系已经全面融入云原生可观测性技术 OpenTelemetry。
回顾过去十年间，应用服务监控行业的竞争也很激烈，相关产品如雨后春笋般涌现，如推特在 2012 年开源的 Zipkin，韩国最大的搜索引擎和门户网站 Naver 开源的 Pinpoint，近几年 Uber 公司开源的 Jaeger，以及我们国内吴晟开源的 SkyWalking。
有人说，这些其实都归功于 Google 在 2010 年基于其内部大规模分布式链路追踪系统 Dapper 实践而发表的论文，它的设计理念是一切分布式调用链追踪系统的始祖，但其实早在二十年前（2002年），当年世界上最大的电商平台 eBay 就已拥有了调用链追踪系统 CAL(Centralized Application Logging)。2011 年，原eBay的中国研发中心的资深架构师吴其敏跳槽至大众点评，并且深入吸收消化了 CAL 的设计思想，主导研发并开源了CAT(Centralized Application Tracking）。
CAT 作为国人主导的开源系统，其本地化工作也是做得非常到位，而凭借着架构简单，开箱即用的特点，CAT 也是我们得物使用的第一个应用监控系统。
二、 0x01 第一阶段
从0～1基于CAT的实时应用监控
在得物五彩石项目交付之前，系统仅有基础设施层面的监控，CAT 的引入，很好地弥补了应用监控盲区。它支持提供各个维度的性能监控报表，健康状况检测，异常统计，对故障问题排查起到了积极推动的作用，同时也提供简单的实时告警的能力。
CAT 拥有指标分钟级别的聚合统计的能力，从 UI 上不难看出，它拥有丰富的报表统计能力和问题排障能力。
但随着公司业务规模逐步扩大，微服务粒度也不可避免地变小，我们发现，CAT 已经逐步无法满足我们的使用场景了：
无法直观呈现全链路视图：问题排障与日常性能分析的场景也越来越复杂，对于一个核心场景，其内部的调用链路通常复杂多变，站在流量角度上看，需要完整地知道它的来源，上下游链路，异步调用等等，这对于 CAT 来说可能略显超纲。
缺少图表定制化能力：CAT 虽供多维度报表分析，但定制化能力非常有限，在当时，业内的图表组件定制化解决方案逐步向 Grafana + Prometheus 靠拢，但若使用 CAT，则无法享受强大的图表绘制能力。与此同时，随着云原生社区可观测性项目 OpenTracing 的崛起，大约不到半年时间我们逐步下线了 CAT，向 OpenTracing 生态演进。
三、 0x02 第二阶段
持续创造 基于OpenTracing全链路采样监控
OpenTracing 为全链路追踪 Trace 定制了完整的一套协议标准，本身并不提供实现细节。在 OpenTracing 协议中，Trace 被认为是 Span 的有向无环图（DAG）。官方也例举了以下 8 个 Span 的因果关系和他们组成的单 Trace示例图：
在当时， OpenTracing 相关的开源社区也是异常活跃，它使用 Jaeger 来解决数据的收集，调用链则使用了甘特图展示：
在 OpenTracing 生态中，我们对链路的采样使用头部采样策略， 对于指标 Metrics，OpenTracing 并没有制定它的规范，但在 Google SRE Book 里，关于 Monitoring Distributed System 章节中提到了四类黄金指标：
1. 吞吐量：如每秒请求数，通常的实现方式是，设定一个计数器，每完成一次请求将自增。通过计算时间窗口内的变化率来计算出每秒的吞吐量。
2. 延迟：处理请求的耗时。
3. 错误率/错误数：如 HTTP 500 错误。当然，有些即便是 HTTP 200 状态也需要根据特定业务逻辑来区分当前请求是否属于“错误”请求。
4. 饱和度：类似服务器硬件资源如CPU,内存,网络的使用率等等。
所以，我们决定使用 Micrometer 库来对各个组件进行吞吐量，延迟和错误率的埋点，从而对 DB 类，RPC类的组件做性能监控。因此也可以说，我们第二阶段的监控是以指标监控为主，调用链监控为辅的应用性能监控。
3.1 使用 Endpoint 贯穿指标埋点帮助性能分析
在指标埋点过程中，我们在所有的指标中引入了“流量入口（Endpoint）”标签。这个标签的引入，实现了根据不同流量入口来区分关联 DB，缓存，消息队列，远程调用类的行为。通过流量入口，贯穿了一个实例的所有组件指标，基本满足了以下场景的监控：
RPC 调用排障，调用方除了拥有下游接口信息，也可溯源自身触发该调用的接口。3.2 关于选型的疑问
你可能会问，链路监控领域在业内有现成的 APM 产品，比如 Zipkin, Pinpoint, SkyWalking 等，为什么当时会选择 OpenTracing + Prometheus 自行埋点？主要有两大因素：
第一，在当时，CAT 无法满足全链路监控和一些定制化的报表分析，而得物交易链路五彩石项目交付也趋于尾声，贸然去集成外部一款庞大的 APM 产品在没有充分的验证下，会给服务带来稳定性风险，在极其有限的时间周期内不是个理智的选择。
第二，监控组件是随着统一的基础框架来发布，同时，由另一团队牵头开发的全链路影子库路由组件借助了 OpenTracing 随行数据透传机制，且与监控组件是强耦合关系，而基础框架将统筹监控，压测和其他模块，借助Spring Boot Starter 机制，一定程度上做到了功能的开箱即用，无缝集成。而使用字节码增强方式的 Pinpoint, SkyWalking，无法很好地做到与基础框架集成，若并行开发，也会多出基础框架与 Java Agent 两边的管理和维护成本，减缓迭代速度。
在之后将近两年的时间里，应用服务监控覆盖了得物技术部使用的将近 70% 的组件，为得物App在 2021 年实现全年 99.97% 的 SLA 提供了强有力的支持。现在看来，基于 OpenTracing + Prometheus 生态，很好地解决了分布式系统的调用链监控，借助 Grafana 图表工具，做到了灵活的指标监控，融合基础框架，让业务方开箱即用…然而，我们说第二阶段是基于 OpenTracing 全链路采样监控，随着业务的高速发展，这套架构的不足点也逐渐显露出来。
3.3 架构特点
体验层面指标：覆盖面广，维度细，能清晰地根据各模块各维度来统计分析，基本做到了监控灵活的图表配置需求。但不可否认它是一种时序聚合数据，无法细化为个体。假如在某个时间点发生过几次高耗时操作，当吞吐量达到一定时，平均耗时指标曲线仍然趋于平稳，没有明显的突出点，导致问题发现能力降低。迭代周期分化矛盾，与基础框架的集成是当时快速推广落地全链路监控的不二选择，通过这种方式，Java 服务的接入率曾一度接近100%，但在业务高速发展的背景下，基础框架的迭代速度已经远远跟不上业务迭代速度了，这也间接制约了整个监控系统的迭代。
数据治理层面数据治理成本逐步偏高，由于基础框架和业务系统的迭代节奏天然的不一致，且每个业务系统也有自身的迭代节奏，放眼全网后端服务上看，基础框架版本参差不齐。
尽管监控系统在每一次迭代时都会尽可能保证最大的向后兼容，但将近两年的迭代周期里，不同版本造成的数据差异也极大制约了监控门户系统天眼的迭代，开发人员长时间奔波于数据上的妥协，在很多功能的实现上曲线救国。
稳定性层面相关预案依托于 Spring 框架 Bean 的自动装配逻辑，业务方理解成本低，便于变更，但缺少细粒度的预案，比如运行时期间特定逻辑降级等等。
2021 年下半年开始，为了充分平衡以上的收益与风险，我们决定将监控采集端与基础框架解耦，独立迭代。在此之前，在 CNCF（云原生计算基金会）的推动下，OpenTracing 也与 OpenCensus 合并成为了一个新项目 OpenTelemetry。四、 0x03 第三阶段
向前一步 基于OpenTelemetry全链路应用性能监控
OpenTelemetry 的定位在于可观测性领域中对遥测数据采集和语义规范的统一，有 CNCF (云原生计算基金会)的加持，近两年里随着越来越多的人关注和参与，整个体系也越发成熟稳定。
其实，我们在2020年底就已开始关注 OpenTelemetry 项目，只不过当时该项目仍处于萌芽阶段， Trace, Metrics API 还在 Alpha 阶段，有很多不稳定因素，考虑到需尽快投入生产使用，笔者曾在 2021 年中到年末期间也或多或少参与了 OpenTelemetry 社区相关 issue 的讨论，遥测模块的开发，底层数据协议的一致和一些 BUG 的修复。在这半年期间，相关 API 和 SDK 随着越来越多的人参与也逐步趋于稳定。
OpenTelemetry架构（图源自 opentelemetry.io）
4.1 迈入 Trace2.0 时代
OpenTelemetry 的定位致力于将可观测性三大要素 Metrics,Trace,Log 进行统一，在遥测 API 制定上，提供了统一的上下文以便 SDK 实现层去关联。如 Metrics 与 Trace 的关联，笔者认为体现在 OpenTelemetry 在 Metrics 的实现上包含了对 OpenMetrics 标准协议的支持，其中 Exemplar 格式的数据打通了 Trace 与 Metrics 的桥梁：
OpenMetrics 是建立在 Prometheus 格式之上的规范，做了更细粒度的调整，且基本向后兼容 Prometheus 格式。
在这之前，Metrics 指标类型的数据无法精确关联到具体某个或某些 Trace 链路，只能根据时间戳粗略关联特定范围内的链路。这个方案的缺陷源自指标采集器 vmagent 每隔 10s~30s 的 Pull 模式中，指标的时间戳取决于采集时刻，与 Trace 调用时间并不匹配。
Exemplar 数据在直方图度量格式末尾会追加当前上下文中的 Trace ID,Span ID 信息，如下：
shadower_virtual_field_map_operation_seconds_bucket{holder="Filter:Factory",key="WebMvcMetricsFilter",operation="get",tcl="AppClassLoader",value="Servlet3FilterMappingResolverFactory",le="0.2"} 3949.0 1654575981.216 # {span_id="48f29964fceff582",trace_id="c0a80355629ed36bcd8fb1c6c89dedfe"} 1.0 1654575979.751
为了采集 Exemplar 格式指标，同时又需防止分桶标签“le”产生的高基数问题，我们二次开发了指标采集 vmagent，额外过滤携带 Exemplar 数据的指标，并将这类数据异步批量发送到了 Kafka，经过 Flink 消费后落入 Clickhouse 后，由天眼监控门户系统提供查询接口和UI。
分位线统计与Exemplar 数据关联UI示意图
在数据上报层，OpenTelemetry Java SDK 使用了比 JDK 原生的阻塞队列性能更好的 Mpsc (多生产单消费）队列，它使用大量的 long 类型字段来做内存区域填充，用空间换时间解决了伪共享问题，减少了并发情况下的写竞争来提高性能。
在流量高峰时期，链路数据的发送队列这一块的性能从火焰图上看 CPU 占比平均小于2%，日常服务CPU整体水位与0采样相比几乎没有明显差距，因此我们经过多方面压测对比后，决定在生产环境客户端侧开放链路数据的全量上报，实现了在得物技术史上的全链路 100% 采样，终结了一直以来因为低采样率导致问题排查困难的问题，至此，在第三阶段，得物的全链路追踪技术正式迈入 Trace2.0 时代。
得益于 OpenTelemetry 整体的可插拔式 API 设计，我们二次开发了 OpenTelemetry Java Instrumentation 项目 Shadower Java，扩展了诸多功能特性：
4.2 引入控制平面管理客户端采集行
使用控制平面，通过客户端监听机制来确保配置项的下发动作，包括：
实时动态采样控制诊断工具 Arthas 行为控制实时全局降级预案遥测组件运行时开关实时 RPC 组件出入参收集开关实时高基数指标标签的降级控制按探针版本的预案管理基于授权数的灰度接入策略。控制平面的引入，弥补了无降级预案的空白，也提供了更加灵活的配置，支持了不同流量场景下快速变更数据采集方案：
4.3 独立的启动模块
为了解决业务方因集成基础框架而长期面临的依赖冲突问题，以及多版本共存引起的数据格式分散与兼容问题，我们自研了无极探针工具箱 Promise, 它是个通用的 javaagent launcher, 结合远端存储，支持可配置化任意 javaagent 的下载，更新，安装和启动：
[plugins]enables = shadower,arthas,pyroscope,chaos-agent[shadower]artifact_key = /javaagent/shadower-%s-final.jarboot_class = com.shizhuang.apm.javaagent.bootstrap.AgentBootStrapclassloader = systemdefault_version = 115.16[arthas]artifact_key = /tools/arthas-bin.zip;boot_class = com.taobao.arthas.agent334.AgentBootstrapboot_artifact = arthas-agent.jarpremain_args = .attachments/arthas/arthas-core.jar;;ip=127.0.0.1[pyroscope]artifact_key = /tools/pyroscope.jar[chaos-agent]artifact_key = /javaagent/chaos-agent.jarboot_class = com.chaos.platform.agent.DewuChaosAgentBootstrapclassloader = systemapply_envs = dev,test,local,pre,xdw
4.4 基于 Otel API 的扩展
4.4.1 丰富的组件度量
在第二阶段 OpenTracing 时期，我们使用 Endpoint 贯穿了多个组件的指标埋点，这个优秀的特性也延续至第三阶段，我们基于底层 Prometheus SDK 设计了一套完善的指标埋点 SDK，并且借助字节码插桩的便捷，优化并丰富了更多了组件库。（在此阶段，OpenTelemetry SDK 主版本是 1.3.x ，相关 Metrics SDK 还处于Alpha 阶段）
Otel 的 Java Instrumnetation 主要使用 WeakConcurrentMap 来做异步链路上下文数据传递和同线程上下文关联的容器，由于 Otel 对许多流行组件库做了增强，因此 WeakConcurrentMap 的使用频率也是非常高的，针对这个对象的 size 做监控，有助于排查因探针导致的内存泄露问题，且它的增长率一旦达到我们设定的阈值便会告警，提早进行人工干预，执行相关预案，防止线上故障发生。
部分自监控面板
4.4.2扩展链路透传协
1) 引入RPC ID
为了更好地关联上下游应用，让每个流量都有“身份”，我们扩展了TextMapPropagator接口，让每个流量在链路上都知道请求的来源，这对跨区域，环境调用排障场景起到关键性作用。
此外，对于跨端场景，我们参考了阿里鹰眼调用链RPCID模型，增加了RpcID字段，这个字段在每次发生跨端调用时末尾数值会自增，而对于下游应用，字段本身的层级自增：
该字段拥有以下作用：
支持提供精简化的调用链路视图，查询臃肿链路（如那些涉及缓存，DB调用大于 2000 Span的链路）时只提供 RPC 调用节点和调用层次关系。
链路保真，客户端链路数据上报队列并不是个无界限队列，当客户端自身调用频繁时，若上报队列堆积达到阈值即会丢弃，这会造成整个链路的不完整，当然这是预期内的现象，但若没有RpcID字段，链路视图将无法关联丢失的节点，从而导致整个链路层级混乱失真。
2) 自定义 Trace ID
为了实现链路详情页高效的检索效率，我们扩展 TraceID 生成逻辑，ID的前8位使用实例IP，中8位使用当前时间戳，后16位采用随机数生成。
32位自定义traceId：c0a8006b62583a724327993efd1865d8c0a8006b 62583a72 4327993efd1865d8 | | |高8位(IP) 中8位(Timestmap) 低16位(Random)
这样的好处有两点：
通过 TraceID 反向解析时间戳，锁定时间范围，有助于提高存储库 Clickhouse 的检索效率，此外也能帮助决定当前的 Trace 应该查询热库还是冷库。
绑定实例 IP，有助于关联当前 Trace 流量入口所属的实例，在某些极端场景，当链路上的节点检索不到时，也能通过实例和时间两个要素来做溯源。
3) 异步调用识别
业务系统为了提高服务吞吐量，充分运用硬件资源，异步调用场景可谓无处不在。我们基于Otel实现的异步链路上下文传递的基础上，额外扩充了"async_flag"字段来标识当前节点相对于父节点的调用关系，从而在展示层上能迅速找出发生异步调用的场景
4.4.3 更清晰的调用链结构
在 Otel 支持的部分组件中，有些操作不涉及到网络调用，或者具有非常频繁的操作，如 MVC 过程，数据库连接获取等，通常来说这类节点在链路详情主视图中的意义不大，因此我们对这类节点的产生逻辑进行了优化调整，使得整个链路主体结构聚焦于“跨端”，同时，对部分核心组件关键内部方法细节做了增强，以“事件”的形式挂载于它们的父节点上，便于更细粒度的排查：
RPC调用关键内部事件
DB 调用连接获取事件
4.4.4 profiling 的支持
1）线程栈分析的集成。通过集成 Arthas 这类工具，可以很方便地查看某个实例线程的实时堆栈信息，同时对采样间隔做控制，避免频繁抓取影响业务自身性能。
2）通过集成 pyroscope，打通高延迟性能排查最后一公里。Pyroscope 对 async profiler 做了二次开发，同时也支持 Otel 去集成，但截至目前，官方并没有实现完整的 Profiling 行为的生命周期，而 Profiling 行为一定程度上会影响性能，于是我们对官方 Pyroscope 的生命周期做了扩展，实现“停止”行为的同时，采用时间轮算法来检测特定操作的耗时，当达到期望的阈值将触发开启 profiling, 待操作结束或超过最大阈值则停止。
关于性能诊断相关的运用，请期待后续诊断专题。
五、 0xff 结语
纵观得物在应用监控采集领域的三大里程碑迭代，第一阶段的 CAT 则是 0~1 的过程，它提供了应用服务对自身观测的途径，让业务方第一次真实地了解了服务运行状况，而第二阶段开始，随着业务发展的飞速提升，业务方对监控系统的要求就不仅只是从无到有了，而是要精细，准确。
因此，快速迭代的背景下，功能与架构演进层面的矛盾，加上外部云原生大背景下可观测领域的发展因素，促使我们进行了基于 OpenTelemetry 体系的第三阶段的演进。功能，产品层面均取得了优异的结果。如今，我们即将进行下一阶段的演进，深度结合调用链与相关诊断工具，以第三阶段为基础，让得物全链路追踪技术正式迈入性能分析诊断时代。
六、 关于我们
得物监控团队提供一站式的可观测性平台，负责链路追踪、时序数据库、日志系统，包括自定义大盘、应用大盘、业务监控、智能告警、AIOPS等排障分析。
本文关键词：常见的收集数据的方法有哪些答案，常见的收集数据的方法有哪些 质量，常见的收集数据的方法有哪些多选，常见的收集数据的方法有哪些多选题，常见的收集数据的方法有哪些 A直接测量 B问卷调查法。这就是关于《常见的数据采集方式有哪几种，常见的收集数据的方法有哪些（得物云原生全链路追踪Trace2.0-采集篇）》的所有内容，希望对您能有所帮助！