公司背景

公司由前Google工程师Ben Sigelman于2015年成立（创始人曾经是Dapper的开发者，专注于分布式链路追踪），LightStep的使命是削减软件的规模和复杂性，帮助公司能够持续保持对其系统的控制。第一个产品LightStep [x]PM能够在任何时间点提供整个软件系统准确、详细的快照，基于快照能够快速识别问题、瓶颈并解决。

估值：最新一次是2018.10，估值在1-5亿美元之间
规模：100-200人左右
营收：客户数 1.1万，每年营收1600万美元

里程碑

2015 公司成立
2017.11 发布 LoghtStep [x]PM产品
2018 公司至少募集了 27M$
2018.9 入选Gartner创新性五大APM工具
2018.9 《福布斯》将LightStep列为年度云计算100强新星
2018.10 募集 40M$，估值 $100M - $500M 之间
2019.4 被评为旧金山最佳工作企业之一
2019.9 OpenTelemetry为可观察性指明发展方向
2020.1 提供了一种可以使开发人员快速识别部署前后的性能回归方案
2020.6 提出了仅需3次Click即可定位问题根因的方案
2020.9 提供了基于OpenTelemetry的一行代码接入方案

核心理念

由于是一家非常新的公司（2015年成立），所以公司最开始面对的大环境就是微服务、容器化、SaaS，因此这也深刻影响了LightStep的定位与公司宗旨，主要的一些理念如下：

公司的软件系统架构会逐渐复杂，微服务、容器是未来的发展方向
IT人员不应该专注于基础的Metrics，而应该有一个更强大的软件/服务来帮他们解决复杂系统分析的问题
不采样，支持全时间100%的链路追踪
灵活，支持任意维度GroupBy
实时性，能够实时显示结果，缩短问题定位时间
遵循OpenTracing、OpenTelemetry标准来提供服务

和传统的APM厂商不同，LightStep不是把所有的数据都直接暴露给用户，而引擎本身就做了很多数据分析和问题定位的工作，把复杂的算法包装成简单的操作，让用户能够非常快的去定位问题（后面将详细展开）。

产品形态与售卖方式

类型：纯SaaS化服务，
免费版：终身免费版，每个月100GB数据，3用户
高级版：每月每个服务100$，5个用户，不限制数据量
企业版：单独报价（不确定是否支持线下部署），无任何限制，有专业的客户经理支持

核心功能剖析

数据接入

目前LightStep支持主流语言的Trace接入，并且一些库（Java、NodeJS等）中还带有一些Metric的接入方式。当前绝大部分语言都逐渐迁移到OpenTelemetry标准上，可预见后期所有的接入方式都是OT标准。官方推荐使用的是自动埋点，这也是当前各家推荐的主流方式。

语言	支持自动埋点	标准化	接入复杂度	侵入性
Java	支持	OpenTelemetry	低	Jar包
NodeJS	支持	OpenTelemetry	低	代码
Ruby	支持	DataDog	低	代码
Golang	否	OpenTelemetry	高	代码
Python	支持	OpenTelemetry	低	代码
C#	否	OpenTelemetry	高	代码
C++	否	OpenTracing	高	代码
Swift	否	OpenTelemetry	高	代码
Php	否	OpenTelemetry	高	代码

三方数据兼容

目前LightStep除支持OpenTelemetry协议外，还支持Jaeger、Zipikin、DataDog数据接入方式，秉承LightStep用户简单化的理念，他们是尽可能直接提供支持这些协议写入的Endpoint，而不是通过Agent进行格式转换。

实现方式：

HTTP/HTTPS：提供 ingest.lightstep.com 域名用来接入这些数据，不需要额外的URLPath
GRPC：对于OpenTelemetry的支持直接写入到LightStep，Jaeger需要自己部署Satellites

问题排查

和传统的APM产品不同，LightStep第一个步骤是接入数据，第二步便是教你该如何查看服务的健康度，然后就是各种类型的问题排查（其他很多传统的公司可能把产品的功能使用花很大的篇幅来介绍，问题排查的经验可能就放在最佳实践里面）。通过问题排查把各项功能的作用讲解给用户，代入感更强。

延迟回归分析

发现某个Service延迟升高，点击延迟升高时间段的Metric图，选择和未升高的时间进行对比
查看基础的Metric指标，看基础指标是否有变化
查看Latency的分布，看是否是因为部分引起
按照Attribute进行关联性分析，查看是否是因为部分Attribute引起
排查下游调用延迟贡献度
搜索/查看Trace附加的日志信息
使用Trace分析功能直接进行回归分析
过滤出问题的Trace

排查错误率升高

发现某个Service错误率升高，点击错误率升高时间段的Metric图，选择和未升高的时间进行对比
查看基础的Metric指标，看基础指标是否有变化
通过error=true来过滤出想要的Trace，然后进行Dependency绘制，找到错误传播路径
对服务的错误率进行回归分析，找到贡献率最大的服务
对该服务进行Attribute关联分析，找到服务内贡献度最大的Attribute组合
搜索/查看Trace附加的日志信息
使用Trace分析功能直接进行回归分析
过滤出问题的Trace

部署回归分析

这个场景主要针对的是最常见的版本发布，对于A/B两个版本进行对比分析，LightStep从产品本身就支持了版本号的概念，支持按照版本号来对比性能、错误率等，操作起来也十分方便：

直接在Service详情页选择一个版本，然后再Operation的Metric列表中可以看到具体是什么时候这个版本发布。
Metric列表会显示当前选中版本和其他版本的延迟、qps、错误率对比（和之前的图是一样的，也就是说一张图在两个模式下会有两种不同的表现方式）

此外LightStep还支持和其他任一版本进行对比，这里有一点比较有意思的是，LightStep支持time-shifted的方式，也就是说会把历史的一个版本平移过来显示在一张图上，方便进行比对。

查找关联性（模式分析）

LightStep提供了内置的关联性分析功能，可以快速的找到引起延迟、错误率上升的最大关联系组合。其本质上也是分析Trace的各个属性对当前问题的影响，和SLS的模式分析函数比较类型。但其产品功能的设计上非常的友好，使用起来非常便捷。

可以直接选择一个时间段或者对于指定的条件结果进行关联性分析
支持对于Attribute内部的子字段进行分析
关联性分析会直接告诉你哪些属性的组合造成了延迟上升、错误率提高
关联出来的数据还支持进行Filter和GroupBy可以快速的进行点击来筛选对应的数据

亮点分析

理念

瞄准未来微服务、云原生的场景，直接从分析/定位问题出手，而不是提供一堆基础工具让用户来做
一开始就提供的SaaS话服务，对于后续的估值提升会有很大的帮助。
紧跟开源标准，OpenTracing、OpenTelemetry，应该是我当前遇到第一家把OpenTelemetry推荐给用户生产使用的公司。

引导页

引导页做的非常好，无需登录，无需Moc数据，直接从四个场景让你来使用LightStep的功能，对于获客帮助非常大。需要我们好好学习！

Satellite

Satellite其实也就是相当于扮演了Collector、Logtail的角色，但是LightStep还支持公共的Satellite集群（免费，不保证SLA），用户第一次接入数据可以直接使用一个免费的endpoint，不需要额外再部署Agent集群（但最后上生产的时候还是要部署），进一步降低了用户第一次接入的成本。

回归分析

回归分析有一个专门的页面，能够支持两个时间相关数据的对比分析，包括Metrics/Traces/Logs，能够在一个页面查看到服务的所有相关信息。

关联性分析

关联性分析对于问题排查十分有用，和Trace这种标准Schema的数据结合意义重大，还是有很大的潜力可以挖。

Stream Dashboard

Dashboard的配置非常简单，只需要有一个条件能够过滤出一组Traces即可，LightStep就会创建出下述这一个Dashboard。

其中上部分是一个多Y轴的图表，Y轴能同时展示延迟（PXX）、错误率、QPS，而且还能把一些关键的Trace以小点的形式展示在图中，信息量非常的大。
下半部分是Trace Explorer中的图标功能，支持过滤、GroupBy，用来自定义分析上述这些Trace。

总结

LightStep整体的创新性满满，功能使用起来很酷很赞，算是可观察性领域创新性公司的领导者之一。无论是从产品定位、文档、功能等都独具一格，对于Trace场景应该是非常好的参考者。

虽说有那么多的创新点，但LightStep还是有一些美中不足：

基础的监控信息获取不到，Metrics领域的能力基本没有
Logs的能力也非常弱，只能支持Trace附带的Logs的查询
很多图表没有针对性的对大数据量做一些优化
不支持一些自定义的分析统计功能
数据想要导出很麻烦，基本上只有一些Query的接口
没有立体化的问题排查能力，只能纯粹的看Trace，没办法关联CMDB、基础监控、PaaS监控等

LightStep调研