这是一个创建于 1427 天前的主题，其中的信息可能已经有所发展或是发生改变。
示例服务器:
A-business-service: A 业务系统实现服务(业务实现方法)
A-base-service: A 基层系统实现服务(链接 Mysql)
B-business-service: B 业务系统实现服务(业务实现方法)
B-base-service: B 基层系统实现服务(链接 Mysql)
A 可以调用 A/B 的基础 但是 A 不能调用 B 业务层
.....
现在的是这样的 有一串代码
public void example(){
.....
aBusiness.aBase();
aBsuiness.bBase();
.....
}
然后在 A 调用 B 基础的时候报错了 看日志 是 B-base 报错的 然后但是我们不知道是 A-business 的调用还是 B-business 的调用...
现在的有一个想法就是用一个服务固定的 source 字段去标记 然后传递到基础服务的接口中...(管理觉得加入分布式链路追踪太麻烦了) 我的想法是用 ZipKin 之类的开源框架
V 友们也可以推荐一下好用的框架或者 Idea. Thx
 |
1
wolfie 2020-12-28 11:38:55 +08:00
|
 |
2
demobin 2020-12-28 11:53:08 +08:00
request.getRemoteAddr()
|
 |
4
monkeyWie 2020-12-28 12:17:28 +08:00 via Android
skywalking esapm 可以看看
|
 |
5
unixeno 2020-12-28 12:24:13 +08:00 via Android
第一个发起者生成一个 logid，后面的 rpc 一路传下去
|
 |
6
limuyan44 2020-12-28 12:42:14 +08:00 via Android
我几年前搞这个当时只有个 dubbo，啥配套的都没上，最简单的就是链路加个 id 就完事了，java 来搞改改 rpc 框架和日志模板用不了几行代码，还不影响现有的代码，查日志看 id 就行了。
|
 |
7
joesonw 2020-12-28 12:50:35 +08:00
java 全家桶的话就 skywalking 嘛. 不然就 opentracing 那一套, 存储可以用 jaeger.
|
 |
9
vindurriel 2020-12-28 13:33:43 +08:00 via iPhone
复议 5 楼 debug 的话透传 request id 就行 用不着实施链路追踪系统
|
 |
11
imycc 2020-12-28 13:46:56 +08:00
在 nginx 或者网关入口生成一个 traceid （如果有就不生成），改造一下业务的日志模块，打印这个 ID 。日志传到 es，剩下就自行发挥
|
 |
12
InkAndBanner 2020-12-28 14:04:50 +08:00
zipkin
|
 |
13
gmywq0392 2020-12-28 14:23:08 +08:00
谷歌有论文。
|
 |
14
xuanbg 2020-12-28 14:26:30 +08:00
网关拦截验证鉴权的同时生成一个 requestId，放在请求头一路传到底。然后 kibana 就能根据这个 requestId 找出一串日志来。
|
 |
15
clf 2020-12-28 14:28:48 +08:00
网关生成一个 ID，然后日志里全会附带这个 ID，调用链就都出来了。
|
 |
16
qfdk 2020-12-28 14:50:11 +08:00 via iPhone
apm 吧 这个简单
|
|
17
qfdk 2020-12-28 14:53:22 +08:00 via iPhone
@imycc 都有 es 了 用他家 apm 就好了， 挂个 agent 起来 给每条数据都有个 transactionId 还有个 traceId. 这样需要某些特定 log 的 改下 file beat 穿出去就好了
|
 |
18
csl1995 2020-12-28 14:54:46 +08:00
requestid
|
 |
19
Yoock 2020-12-28 15:16:36 +08:00
jaeger?
|
 |
21
Kyle18Tang 2020-12-28 15:50:44 +08:00
不知道你们是不是用的 Java，如果技术栈是 Spring Cloud 推荐使用 Spring Cloud Zipkin，默认支持很多场景的链路追踪，例如 HTTP 、RabbitMQ 、Kafka 、MySQL 、MongoDB 等都有支持。
|
 |
22
Jooooooooo 2020-12-28 15:52:04 +08:00
入口埋一个唯一 id, 然后一路传下去.
一般放在 thread local 里, 对于线程池稍微改造下 |
 |
23
cking OP @Kyle18Tang 就是 Cloud 家族
|
|
24
Kyle18Tang 2020-12-28 16:12:56 +08:00
@cking #23 我们现在使用的就是 Spring Cloud Zipkin，很舒服，整个链路都能追踪，通过 Trace Id 就能搜索到所有链路上的日志了
|
|
25
cking OP @Kyle18Tang #24 我先试下 requestId 的方式 主要是管理不太想继续集成其他框架了 除非万不得已
|
|
26
cking OP |
|
27
Kyle18Tang 2020-12-28 16:57:16 +08:00
@cking #25 微服务只需要依赖一个 starter 而已。。。然后加个往哪里发送的配置。Zipkin 的服务器另外搭建，Docker 就能启动，数据我们存到了 ES 里。自己写我是感觉真没必要，费时费力。
|
 |
28
whiler 2020-12-28 16:59:35 +08:00
业界已经有一套成熟的方案了，可以看一下 opentracing
|
|
29
Kyle18Tang 2020-12-28 17:00:16 +08:00
@cking #26 不再建议自定义 HTTP 头采用 X-前缀，https://tools.ietf.org/html/rfc6648
|
|
30
cking OP @Kyle18Tang 好的 我去把主管说服吧 哈哈哈
|
|
31
xuanbg 2020-12-28 17:14:10 +08:00
Zipkin 真心没有自己查 requestId 方便
|
 |
32
gjf 2020-12-28 17:39:19 +08:00 via iPhone
这可以用 trace 解决也叫分布式链路追踪，可以看看云原生的 opentraceing，如果 java 可以使用 specialagent，对代码没有任何侵入
|
 |
33
Yiso1573 2020-12-28 17:44:38 +08:00
spring sleuth ,好像要求 spring cloud ？目前我们用的这个
|
 |
34
xuzhzzz 2020-12-28 18:25:00 +08:00
《管理觉得加入分布式链路追踪太麻烦了》
同样的领导，明明主流方案就在那里，偏偏自己搞，搞得不三不四的，到头来难受的还是自己 |
 |
36
chogath 2020-12-28 18:49:28 +08:00
requestId
|
 |
37
laminux29 2020-12-29 01:40:49 +08:00
整个过程，每个经过的节点 ID 或组件 ID 必须都记录上，要不以列表或数组形式记录在数据里，要不分散在各组件的日志里后期汇总。
这种东西无论是调试、流控还是分布式性能调优，都有重要作用。 |
 |
38
lewis89 2020-12-29 08:05:33 +08:00
其实...最好的办法是不上微服务...大部分公司的量级根本没有达到紧迫到需要上微服务的情况
|
 |
39
liian2019 2020-12-29 17:23:50 +08:00
traceId + spanId
|
Select Language