关于watchtower要实现的功能讨论

[jiubafangxing]

项目的核心功能：监控预警？

[jiubafangxing]

项目以何种方式和其他项目集成

[jiubafangxing]

要用哪些手段去监控？监控日志？切面判断？

[hexiangtao]

项目的核心功能：监控预警？

一. 做一个开源的服务治理产品，（后期甚至可以基于此做商业化云平台），功能类似于目前我们用的yy服务治理平台（服务生命周期管理+apm） 定位偏业务型产品，实施起来难度与做中间件相比较小些）大概需要用到的技术组件: 时序数据库+ shell+jenkins+Java+前端

二. 做skywalking或elasticSeach apm的竞品，纯中间件产品，难度大，需要学习的技术点多 （有挑战），在现有已经有很好解决方案的市场上很难胜出

[PeterLu798]

项目的核心功能：监控预警？

一. 做一个开源的服务治理产品，（后期甚至可以基于此做商业化云平台），功能类似于目前我们用的yy服务治理平台（服务生命周期管理+apm） 定位偏业务型产品，实施起来难度与做中间件相比较小些）大概需要用到的技术组件: 时序数据库+ shell+jenkins+Java+前端

二. 做skywalking或elasticSeach apm的竞品，纯中间件产品，难度大，需要学习的技术点多 （有挑战），在现有已经有很好解决方案的市场上很难胜出

如果是一的话，感觉是基于k8s的云原生技术，使用它们的api，做些封装和界面化。好处就是做起来相对容易，也可以很好的学习云原生技术，看看大牛们怎么做平台。 关于第二点skywalking我不太了解。 我比较倾向于一

[hexiangtao]

项目的核心功能：监控预警？

一. 做一个开源的服务治理产品，（后期甚至可以基于此做商业化云平台），功能类似于目前我们用的yy服务治理平台（服务生命周期管理+apm） 定位偏业务型产品，实施起来难度与做中间件相比较小些）大概需要用到的技术组件: 时序数据库+ shell+jenkins+Java+前端

二. 做skywalking或elasticSeach apm的竞品，纯中间件产品，难度大，需要学习的技术点多 （有挑战），在现有已经有很好解决方案的市场上很难胜出

如果是一的话，感觉是基于k8s的云原生技术，使用它们的api，做些封装和界面化。好处就是做起来相对容易，也可以很好的学习云原生技术，看看大牛们怎么做平台。 关于第二点skywalking我不太了解。 我比较倾向于一

可以详细说下“k8s的云原生”，这块我不太懂，我说的服务的治理平台（服务生命周期管理+apm）大概是这样的: 先说“服务的生命周期”，你可能理解成了 服务进程的启动-运行-动态扩容缩容-停止 这一块确实可以跟k8s的服务生命周期做类比。我原本表达的意思是 服务的增删改查 然后到服务发布，后面到服务的运维指标监控（简单说就是做一个开源的yy服务治理平台。大公司有能力自建，我认为绝大多数小公司是停留在原始上传二进制包的年代的，不像环球能用yy这一套现成的，所以我理解应该有这种需求）

第二部分apm 应该就没歧义了，这部分可做大可做小，做大就如electric apm或skywalking（可能有很大的技术挑战），做小就如yy的鹰眼

[hexiangtao]

项目的核心功能：监控预警？

一. 做一个开源的服务治理产品，（后期甚至可以基于此做商业化云平台），功能类似于目前我们用的yy服务治理平台（服务生命周期管理+apm） 定位偏业务型产品，实施起来难度与做中间件相比较小些）大概需要用到的技术组件: 时序数据库+ shell+jenkins+Java+前端

二. 做skywalking或elasticSeach apm的竞品，纯中间件产品，难度大，需要学习的技术点多 （有挑战），在现有已经有很好解决方案的市场上很难胜出

如果是一的话，感觉是基于k8s的云原生技术，使用它们的api，做些封装和界面化。好处就是做起来相对容易，也可以很好的学习云原生技术，看看大牛们怎么做平台。 关于第二点skywalking我不太了解。 我比较倾向于一

可以详细说下“k8s的云原生”，这块我不太懂，我说的服务的治理平台（服务生命周期管理+apm）大概是这样的: 先说“服务的生命周期”，你可能理解成了 服务进程的启动-运行-动态扩容缩容-停止 这一块确实可以跟k8s的服务生命周期做类比。我原本表达的意思是 服务的增删改查 然后到服务发布，后面到服务的运维指标监控（简单说就是做一个开源的yy服务治理平台。大公司有能力自建，我认为绝大多数小公司是停留在原始上传二进制包的年代的，不像环球能用yy这一套现成的，极大提高研发效率，所以我理解应该有这种需求）

第二部分apm 应该就没歧义了，这部分可做大可做小，做大就如electric apm或skywalking（可能有很大的技术挑战），做小就如yy的鹰眼

我也比较倾向1

[hexiangtao]

项目以何种方式和其他项目集成

目前我知道的集成方式

1. Java探针方式,零侵入，在jvm设置Java agent，我不会 需要现学

2. 以sdk方式集成。这也分半侵入式和api侵入式两种，一种是只需要添加依赖包，做简单的配置即可，另一种是需要使用方调sdk提供的api上送数据到服务器

[jiubafangxing]

https://opentelemetry.io/docs/ 先读下这个

[jiubafangxing]

https://youtu.be/PT-Bjs6iCug

[hexiangtao]

以下内容由ChatGPT翻译

What is OpenTelemetry?

OpenTelemetry是一个开源项目，旨在为现代云原生软件开发提供一致的、标准化的跟踪、度量和日志收集。它提供了一组API、库和代理，使开发人员能够在他们的应用程序中自动收集和传输性能数据，以帮助他们理解和诊断应用程序中发生的事情。

在过去，微服务架构让开发人员能够更快地构建和发布软件，摆脱了与单块架构相关的复杂发布流程，具有更大的独立性。但随着这些分布式系统的扩展，开发人员越来越难以看到他们自己的服务如何依赖或影响其他服务，尤其是在部署或停机期间，速度和准确性变得至关重要。

可观测性使开发人员和运维人员都能够获得对他们的系统的可见性。OpenTelemetry使得在不同技术栈和不同环境中实现可观测性更加容易，从而促进了云原生应用程序的可靠性和性能。

为了使系统可观测，必须进行仪器化。也就是说，代码必须发出跟踪、度量和日志。然后，仪器化的数据必须发送到一个可观测性后端。市面上有许多可观测性后端，从自托管的开源工具（如Jaeger和Zipkin）到商业SaaS服务不等。

过去，代码的仪器化方式因每个可观测性后端都有自己的仪器化库和代理程序来发出数据，而不同。这意味着没有标准的数据格式可供将数据发送到可观测性后端。此外，如果一家公司选择更换可观测性后端，就意味着他们必须重新仪器化他们的代码并配置新代理程序，以便能够将遥测数据发出到新的首选工具。

缺乏标准化，结果是数据可移植性不足，用户需要维护仪器化库的负担。

So what?

为了认识到标准化的必要性，云社区走到了一起，诞生了两个开源项目：OpenTracing（云原生计算基金会（CNCF）项目）和OpenCensus（谷歌开源社区项目）。

OpenTracing提供了一个供应商中立的API，用于将遥测数据发送到可观测性后端。然而，它依赖于开发人员来实现自己的库以满足规范。

OpenCensus提供了一组语言特定的库，开发人员可以使用这些库来仪器化他们的代码，并将其发送到他们支持的任何一个后端。

Hello, OpenTelemetry!

为了实现一个单一的标准，OpenCensus 和 OpenTracing 在2019年5月合并成为 OpenTelemetry（简称 OTel）。作为 CNCF 的孵化项目，OpenTelemetry 继承了两者的优点并做了更多改进。

OpenTelemetry 的目标是为摄取、转换和发送数据到观测性后端（即开源或商业供应商）提供一组标准化、厂商无关的 SDK、API 和工具。

OpenTelemetry 获得了云提供商、供应商和最终用户的广泛支持和采用。它为你提供了以下功能：

针对每种语言的单一、厂商无关的仪表化库，支持自动和手动仪表化。 单一的厂商中立收集器二进制文件，可以以多种方式部署。 端到端实现来生成、发出、收集、处理和导出遥测数据。 通过配置使你能够完全掌控数据，并能够并行地将数据发送到多个目的地。 开放标准的语义约定，以确保厂商无关的数据收集。 能够支持多个上下文传播格式，以协助随着标准的演变而迁移。 无论你在观测性之旅中的哪个阶段，OpenTelemetry 都为你提供了前进的道路。 OpenTelemetry 支持多种开源和商业协议、格式和上下文传播机制，同时提供到 OpenTracing 和 OpenCensus 项目的桥接，因此采用 OpenTelemetry 很容易。

什么是"可观察性"?

可观察性让我们能够从外部了解一个系统，通过让我们在不知道其内部工作原理的情况下对该系统进行提问。此外，它还可以帮助我们轻松地解决和处理新问题（即“未知的未知”），并帮助我们回答“为什么会发生这种情况”的问题。

为了能够对系统进行这些提问，应用程序必须进行适当的仪表化。也就是说，应用程序代码必须发出跟踪、度量和日志等信号。当开发人员不需要添加更多的仪表化来解决问题时，应用程序就被适当地仪表化了，因为他们已经拥有了所有所需的信息。

可靠性和指标

遥测是指从系统中发出的关于其行为的数据。数据可以以跟踪、指标和日志的形式出现。每种形式的遥测都提供了有关系统行为的有价值信息，可用于监测、故障排除和提高系统的可靠性。

跟踪是记录流经系统的每个请求或事务的记录。它们提供了请求在移动到系统的不同组件时所采取的详细路径的视图。跟踪可以用于识别瓶颈和性能问题，以及跟踪错误和诊断问题。

指标是提供有关系统性能和健康状况的派生数字测量。它们可以包括响应时间、吞吐量和错误率等内容。指标通常是随着时间收集的，这使得可以识别趋势和模式，并用于决策系统优化和容量规划。

日志是系统生成的事件或消息的记录。它们可以提供有关系统中发生的错误、警告和其他重要事件的信息。日志通常用于调试和故障排除目的，以及用于审计和合规目的。

通过收集和分析所有这些形式的遥测数据，系统操作员可以更好地了解其系统的行为，并做出明智的决策来提高可靠性和性能。

可靠性和度量

遥测指的是系统行为发出的数据。数据可以以跟踪、度量和日志的形式出现。

可靠性回答了一个问题：“服务是否按照用户的期望工作？” 一个系统可以一直运行，但是如果当用户点击“添加到购物车”来添加黑色裤子时，系统不断添加红色裤子，那么系统就会被认为是不可靠的。

度量是关于基础设施或应用程序的数字数据的一段时间内的聚合。例如：系统错误率、CPU利用率、给定服务的请求率。

SLI或服务水平指标表示服务行为的测量。一个好的SLI从用户的角度衡量您的服务。例如，一个SLI可以是网页加载的速度。

SLO或服务水平目标是将可靠性传达给组织/其他团队的手段。这是通过将一个或多个SLIs附加到业务价值来实现的。

[hexiangtao]

如果没耐心读英文文档，open-telemetry项目了国人维护的子模块 docs-cn,里面是一些中文的资料 https://github.com/open-telemetry/docs-cn

[hexiangtao]

补一个 阿里云可观测技术峰会 2022地址 https://tianchi.aliyun.com/specials/promotion/AlibabaCloud_ObservabilityConference2022#agenda