0%

前几天排查了一个业务接口执行高延迟的问题,也挺有参考意义的,分享一下排查过程。

现象是业务反馈有一个接口业务逻辑其实很简单,但是调用一次耗时,如下图所示:

Read more »

背景

最近这段时间在处理一个 StarRocks 的关于物化视图优化的一个问题,在此之前其实我也没有接触过 StarRocks 这类主要处理数据分析的数据库,就更别提在这上面做优化了。

在解决问题之前我先花了一两天时间熟悉了一下 StarRocks 的一些概念和使用方法,然后又花了一些时间搭建环境然后复现了该问题。

之后便开始阅读源码,大概知道了相关代码的执行流程,但即便是反复阅读了多次代码也没有找到具体出现问题的地方。

所以便考虑在本地 Debug 源码,最终调试半天之后知道了问题所以,也做了相关修改,给社区提交了 PR,目前还在推进过程中。

Read more »

背景

因为公司内部在使用 PowerJob 作为我们的分布式调度系统,同时又是使用 OpenTelemetry 作为可观测的底座,但目前 OpenTelemetry 还没有对 PowerJob 提供支持,目前社区只对同类型的 XXL-JOB 有支持。

恰好公司内部也有一些开发同学有类似的需求:

于是在这个背景下我便开始着手开发 PowerJob 的 instrumentation,最终的效果如下:

Read more »

可观测性概念


当一个软件或系统出于运行状态时,如果我们不对他加以观测,那它的运行状态对我们来说就是一个黑盒。

如上图所示。

我们只能通过业务的表象来判断它是否正常运行,无法在故障发生前进行预判,从而只能被动解决问题。

Read more »

前言

在前面两篇实战文章中:

覆盖了可观测中的指标追踪和 metrics 监控,下面理应开始第三部分:日志

但在开始日志之前还是要先将链路追踪和日志结合起来看看应用实际使用的实践。

通常我们排查问题的方式是先查询异常日志,判断是否是当前系统的问题。

如果不是,则在日志中捞出 trace_id 再到链路查询系统中查询链路,看看具体是哪个系统的问题,然后再做具体的排查。

类似于这样:

日志中会打印 trace_idspan_id

如果日志系统做的比较完善的话,还可以直接点击 trace_id 跳转到链路系统里直接查询链路信息。

Read more »

前言

最近在给 opentelemetry-java-instrumentation 提交了一个 PR,是关于给 gRPC 新增四个 metrics:

  • rpc.client.request.size: 客户端请求包大小
  • rpc.client.response.size:客户端收到的响应包大小
  • rpc.server.request.size:服务端收到的请求包大小
  • rpc.server.response.size:服务端响应的请求包大小

这个 PR 的主要目的就是能够在指标监控中拿到 RPC 请求的包大小,而这里的关键就是如何才能拿到这些包的大小。

Read more »