一键采集上传常见的细节问题(分布式系统的运维挑战容器、Serverless编程方式的诞生(组图) )

优采云 发布时间: 2021-11-06 11:18

  一键采集上传常见的细节问题(分布式系统的运维挑战容器、Serverless编程方式的诞生(组图)

)

  分布式系统运维挑战

  容器和无服务器编程方法的诞生大大提高了软件交付和部署的效率。在架构演进过程中,可以看到两个变化:

  

  从以上两个变化可以看出,在这种灵活标准化的架构背后,原本对运维、诊断的需求变得越来越复杂。针对这一趋势,一系列面向 DevOps 的诊断和分析系统应运而生,包括集中式日志系统(Logging)、集中式测量系统(Metrics)和分布式跟踪系统(Tracing)。

  日志记录、指标和跟踪

  Logging、Metrics 和 Tracing 都有自己的专用部分。

  这三者也有重叠的部分,如下图所示。

  

  有了以上信息,我们就可以对现有系统进行分类。例如,Zipkin 专注于追踪领域;Prometheus 开始关注指标,随着时间的推移可能会集成更多的跟踪功能,但不太可能深入到日志领域;ELK、阿里云日志服务等系统开始关注日志领域,但与此同时,其他领域的特性也在不断的融入到系统中,上图中的圆心靠近。

  有关三者之间关系的更多详细信息,请参阅 Metrics、tracing 和 logging。下面我们重点介绍追踪。

  追踪的诞生

  追踪是一种出现在 1990 年代的技术。但真正让该领域流行的是谷歌的一篇论文“Dapper,一个*敏*感*词*分布式系统跟踪基础设施”,另一篇论文“来自采样分布式跟踪的聚合估计的不确定性”收录有关采样的信息。更详细的分析。论文发表后,一批优秀的Tracing软件诞生了。比较流行的是:

  分布式追踪系统发展迅速,种类繁多,但一般有代码嵌入、数据存储、查询展示三个核心步骤。

  下图是分布式调用的示例。客户端发起请求。请求首先到达负载均衡器,然后经过认证服务、计费服务,然后请求资源,最后返回结果。

  

  数据被采集存储后,分布式追踪系统一般会选择使用收录时间轴的时序图来呈现这条trace。

  

  但是在数据采集的过程中,由于需要侵入用户代码,并且不同系统的API不兼容,如果要切换跟踪系统,这就导致了较大的变化。

  开放追踪

  为了解决不同分布式追踪系统之间API不兼容的问题,OpenTracing规范诞生了。

  OpenTracing 是一个轻量级的标准化层,位于应用程序/类库和跟踪或日志分析程序之间。

  +-------------+ +---------+ +----------+ +------------+

| Application | | Library | | OSS | | RPC/IPC |

| Code | | Code | | Services | | Frameworks |

+-------------+ +---------+ +----------+ +------------+

| | | |

| | | |

v v v v

+------------------------------------------------------+

| OpenTracing |

+------------------------------------------------------+

| | | |

| | | |

v v v v

+-----------+ +-------------+ +-------------+ +-----------+

| Tracing | | Logging | | Metrics | | Tracing |

| System A | | Framework B | | Framework C | | System D |

+-----------+ +-------------+ +-------------+ +-----------+

  OpenTracing OpenTracing 数据模型的优势

  OpenTracing 中的 Trace(调用链)由属于该调用链的 Span 隐式定义。

  特别地,一个Trace(调用链)可以看成是一个由多个Span组成的有向无环图(DAG图),Span和Span之间的关系被命名为References。

  例如:以下示例 Trace 由 8 个 Span 组成:

  单个 Trace 中,span 间的因果关系

[Span A] ←←←(the root span)

|

+------+------+

| |

[Span B] [Span C] ←←←(Span C 是 Span A 的孩子节点, ChildOf)

| |

[Span D] +---+-------+

| |

[Span E] [Span F] >>> [Span G] >>> [Span H]

(Span G 在 Span F 后被调用, FollowsFrom)

  有时,使用以下基于时间的时序图可以更好地显示 Trace(调用链):

  单个 Trace 中,span 间的时间关系

––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time

[Span A···················································]

[Span B··············································]

[Span D··········································]

[Span C········································]

[Span E·······] [Span F··] [Span G··] [Span H··]

  每个 Span 收录以下状态:(译者注:由于这些状态会反映在 OpenTracing API 中,所以会保留一些英文说明)

  在键值对中,键必须是字符串,值可以是任何类型。

  但需要注意的是,并不是所有支持 OpenTracing 的 Tracer 都需要支持所有的值类型。

  每个 SpanContext 收录以下状态:

  有关 OpenTracing 数据模型的更多信息,请参阅 OpenTracing 语义标准。

  开放追踪实现

  本文档列出了所有 OpenTracing 实现。在这些实现中,比较流行的是 Jaeger 和 Zipkin。

  耶格

  Jaeger 是 Uber 推出的开源分布式追踪系统,兼容 OpenTracing API。

  积家架构

  

  如上图所示,Jaeger主要由以下几部分组成。

  Jaeger on Aliyun Log Service

  Jaeger on Aliyun Log Service 是一个基于 Jeager 的分布式跟踪系统。支持跟踪数据从采集到日志服务的持久化,可以通过Jaeger的原生接口进行查询和展示。

  

  优势配置步骤

  看:

  用例

  HotROD 是一个由多个微服务组成的应用程序。它使用 OpenTracing API 来记录跟踪信息。

  下面的视频展示了如何在阿里云日志服务上使用Jaeger来诊断HotROD问题。该视频收录以下内容:

  如何配置日志服务 如何通过 docker-compose 运行 Jaeger 如何通过 Jaeger UI 运行 HotROD 如何通过 Jaeger UI 检索特定的 trace 如何查看 trace 详细信息 如何通过 Jaeger UI 定位应用程序性能瓶颈 如何通过 Jaeger UI 定位应用程序性能瓶颈日志服务管理控制台 如何使用 OpenTracing API 解决性能瓶颈应用

  视频中使用的示例查询分析

  1. 统计前端服务的 HTTP GET /dispatch 操作的平均延迟和请求数,以分钟为单位。

  process.serviceName: "frontend" and operationName: "HTTP GET /dispatch" |

select from_unixtime( __time__ - __time__ % 60) as time,

truncate(avg(duration)/1000/1000) as avg_duration_ms,

count(1) as count

group by __time__ - __time__ % 60 order by time desc limit 60

  2. 比较两条trace每次操作的时间消耗

  traceID: "trace1" or traceID: "trace2" |

select operationName,

(max(duration)-min(duration))/1000/1000 as duration_diff_ms

group by operationName

order by duration_diff_ms desc

  3.时延大于1.5s的trace IP统计

  process.serviceName: "frontend" and operationName: "HTTP GET /dispatch" and duration > 1500000000 |

select "process.tags.ip" as IP,

truncate(avg(duration)/1000/1000) as avg_duration_ms,

count(1) as count

group by "process.tags.ip"

  特别感谢参考

  Jaeger on Aliyun Log Service 基于阿里云MVP@WPH95在业余时间的工作,感谢MVP

  杰出贡献!

  技术支援

  

0 个评论

要回复文章请先登录注册


官方客服QQ群

微信人工客服

QQ人工客服


线