背景
第一次感受到OpsCruise的存在是他们在今年2月份获得了5Million的天使轮融资，最近看到他们有一套永久免费的方案，这才开始真正试用他们的产品并进一步去调研。
公司简介
- 公司2018年1月成立，位于加利福尼亚州
- 目前员工约为30-40人
- 最近一次融资2021年2月，天使轮，500万美元，领投The Fabric
- 关键词：Cloud、Applications、Performance、Operations、Assurance、SLA、Autonomous、AI和ML
- 营收未知、用户数未知
公司产品与特色
- 专注云应用、Kubernetes（针对K8s应用的可观测性方案）
- 无侵入采集（eBPF）、自动化发现
- Log/Trace/Metirc可观测性方案
- 异常诊断和根因分析（还专门有一个专利）
- 兼容开源方案：OpenTelemetry、Prometheus、Loki、Jaeger
- 5节点内的K8s永久免费
产品介绍的思路
产品介绍的思路相对没有什么特点，但是其中的介绍比较全面，思路也和我们规划的工作路径比较吻合
背景1：Cloud Applications Introduce Fundamentally New Observability Challenges
- 应用分层和额外的依赖
- 动态的、易逝的容器和Serverless环境
- SRE/DevOps人才紧缺
背景2：Existing Monitoring Tools are Completely Inadequate
- 无法适应K8s和容器的环境
- 多套工具，数据无法贯通
- 传统APM耗时、昂贵还可能对应用产生影响
核心解决方案1：统一可观察性数据
- 兼容各种开源的数据，而不是自有的Agent，封闭的数据。
- 所有的可观测数据都在管理范围内，不需要向更多的服务商支付费用。
- 数据的可重复利用，包括对于安全、容量规划、业务分析等。
- 支持自定义的Tag
核心解决方案2：结合配置数据来实现数据串联
- 将Traces、Logs、Metrics结合变更数据、事件、配置信息、CICD流程全部统一到一个应用视图中
- 自动分析应用程序的关联关系，包括第三方的云服务和底层的技术设施
- 能够发现一些意想不到的交互和关联，例如跨数据中心、Region等
- 回溯每个时间点的应用状态，发现每个变更对于应用的整体影响
核心解决方案3：一流的Kubernetes全栈监控（Contextual）
- 无需配置、自动发现和监控动态易逝的K8s上的微服务
- 无需切换方案即可实现K8s数据和基础设施、应用的监控、日志信息进行关联
- 基于Istio或者其他ServiceMesh方案的流量数据，实现端到端可观测性的完整覆盖
- 支持动态的Cluster Map功能，能够实时了解K8s集群中的健康状态、服务依赖信息。分层导航视图支持快速从应用下钻到Pod、容器和节点级别
- 能够支持快速隔离K8s的问题，例如Pod驱逐、容器、服务不可达、资源分配等
核心解决方案4：在客户受损前预测问题
- 基于行为预测建模技术自动检查问题，模型支持自动学习应用程序的行为，支持跨应用组件、K8s和基础设施来关联问题
- 基于eBPF的流量追踪技术来可视化应用性能、监控SLO指标（延迟、错误率、流量变化），实时、无需变更应用
- 基于ML技术自动化异常检测，无需进行阈值设定、不需历史和异常的统计数据
核心解决方案5：降低多部门协作代价
- 基于关联信息定位因果关系，基于应用拓扑结构梳理故障传播链
- 一体化和自动化，不需要在多个方案中不断切换，自动分析因果关系，同时关联系统中非预期的变更行为
- 关联众多可能引起故障的原因，例如资源变更、配置变更、应用变更、事件信息等
- 基于ML来推断整个应用栈中可能出现的问题根因
- 支持自动化事件管理对接ITSM，例如PagerDuty、Slack等
产品试用
整个注册过程比较奇怪，首先需要先注册（不需要填写账号的密码），收到邮件后点击确认，然后会再告诉你即将给你申请一个实例（几分钟）。实际上等了几个小时才发来一个实例。
安装起来非常简单，这个产品只支持K8s的安装，所以核心就是安装了两个Helm Chart。
- 安装的时候遇到了一个问题，因为指标监控完全依赖Prometheus，而且这个Prometheus就是原生的Operator，所以如果之前有安装了别的Prometheus会产生冲突
- 默认安装不是所有的组件
- 对于非AWS、Azure、GCP支持不是很好
功能概览
- 标准的列表形式，可能会分为多层
- 第一个是Dashboards，支持定制化，但是定制化功能极弱，只能拉对应的指标。但是也能看出是想在Dashboard中增加很多自定义的扩展（内置了一些报表）
- Application应该是核心功能，但是默认是没有的，具体需要怎么配置出来完全不清楚，没有文档。。。。没有文档。。。。
- Kubernetes监控提供了一个K8sMap，这个功能还是比较好用，列出了所有在运行的一些资源和配置
- Service是一个列表，也没有数据
- Time Travel支持按照时间去回放整个系统的状态
- Events现在能看到的是K8s的事件信息
- Logs只支持Loki
- Alerts显示集群的告警信息，目前能看到的是事件告警，这个比较简单
特色功能分析
应用地图
没有实际用过有数据的
- 支持多种布局方式，便于不同类型的服务进行组织
- 对于AWS的支持特别的好，很多都是围绕AWS来进行开发
- 支持跨多个集群的关联
- 一个应用点击后，会展示分层信息，支持查询对应的Pod、容器、节点上的数据和监控
- 会把异常直接标注在上面，便于DrillDown
K8s监控
K8s的监控做的比较一般，但是有一些特色还可以参考一下：
- K8s Map：罗列出各个资源的统计信息，另外还支持一些过滤，能够快速观察到整个集群的大致状态
- 每种资源的实现大同小异（Namespace列表、分类的单值图、详细的列表），复用性会比较好
- 列表中的Name字段可以点击，会浮窗显示详细的配置信息
- 支持在Pod、Deployment中关联应用的指标、日志、事件等信息
节点视图
- Map形式列出所有的节点，节点少应该还OK，稍微多点估计要爆炸
- 列出每个节点上运行了多少个Pod
- Node上支持关联查看负载均衡、指标、日志、配置等信息
Cloud视图
- 阿里云上不支持，显示空
- 很多监控产品都会和AWS去兼容，这个显示方式看起来OK，因为没有经验，也不知道实际使用的体验如何
Time Travel
- 支持显示多个时间点的应用拓扑状态（多个Tab页）
- 实际上就是把时间范围限定在某个阶段进行查询
- 如果支持多个时间点进行Compare效果会更好（文档介绍说支持，但不知道是怎么体现出来的）
K8s自动化告警
- 支持K8s的自动化告警，不需要任何配置，支持：Pod部署失败、启动失败、健康检查失败、Pending等，实际上就是基于K8s事件告警
- 鱼骨线的图看起来比较有创意
异常检测
- 还是鱼骨图造型，关联节点的所有的指标信息
- 异常数据会标红，能够一眼看出所有的异常
根因分析
- 上半张图显示故障传播的路径，把相关的这些都显示出来
- 下半张的曲线图展示每个传播点上的延迟信息，这样能看出实际上哪个应用的延迟贡献度最高
- 故障路径中，还会关联一些其他信息来帮助你辅助判断（不仅仅是延迟高的异常），比如K8s上的事件告警、ML预测告警等
