问题标签 [zipkin]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - 侦探没有向 Zipkin 发送跟踪信息
即使 Zipkin 运行良好,Sleuth 也不会将跟踪信息发送到 Zipkin。我正在使用 Spring 1.5.8.RELEASE、spring cloud Dalston.SR4,并且在我的微服务中添加了以下依赖项:
我的日志总是出错:[FOOMS,2e740f33c26e286d,2e740f33c26e286d,false]
我的 Zipkin 依赖项是:
为什么我在我的 slueth 陈述中变得虚假而不是真实?但是,为所有调用正确生成了 traceId 和 SpanId。我的 Zipkin 在端口 9411 中运行
java - 如何使用 Elasticsearch 配置 Spring Cloud Zipkin 服务器以实现持久性?
我想用 elasticsearch 加载我的 Spring Cloud zipkin-server。我想,我几乎尽我所能。但是,它仍然在内存中运行。(当我重新启动 zipkin-server 时,所有数据都丢失了。)我想用 elasticsearch 设置 zipkin。请告诉我需要哪些确切的依赖项和applicartion.yml或任何其他内容。
wso2 - WSO2 ESB 分析和 Zipkin 集成怎么样?
我正在考虑使用我实现的自定义静态发布器在 Open Tracing 之后集成 WSO2 ESB 和 Zipkin 。
这个想法是在 WSO2 ESB 中启用静态和跟踪。
有没有其他方法可以实现这一目标?这种方法正确吗?
deployment - 如何部署可扩展的 zipkin 部署?
我发现 zipkin 的瓶颈是收集器和 API,这两个组件是无状态的,所以我可以部署多收集器和多 API 吗?
我想在 kubernetes 中部署 zipkin。
java - 仅当客户端提供跟踪标头时,使用 Zipkin 在 Camel 中跟踪整个路由才有效
我正在使用 camel-zipkin 组件来跟踪在两个不同服务之间流动的请求:
service-a:在 Spring Boot 上运行的 Camel 应用程序,充当简单的 HTTP 代理(出于此概念证明的目的)。camel-zipkin 模块提供的 Zipkin 支持。路线:
service-b:带有 REST 控制器的 Spring Boot 应用程序。Spring Cloud 的 spring-cloud-starter-kubernetes-zipkin 模块提供的 Zipkin 支持。
当我向 service-a 发出请求时,我在 Zipkin 中看到了部分跟踪:我看到了来自 service-a 的客户端请求,我看到了 service-b 中的服务器请求,以及我在那里添加的 span检测请求路径的各个部分。但是,我没有看到来自 Camel 部分的服务器请求,包括我在路由中设置的延迟导致的额外两秒。
跟踪camel-zipkin代码,我意识到只有在已经有跟踪ID标头的情况下才会跟踪服务器请求,因为这行: https ://github.com/apache/camel/blob/c6c02ff92a536e78f7ed1b9dd550d6531e852cee/components /camel-zipkin/src/main/java/org/apache/camel/zipkin/ZipkinTracer.java#L753
有了这些知识,如果我手动提供自己的跟踪标头(X-B3-TraceId、X-B3-Sampled 和 X-B3-SpanId),我就能够按预期获得整个跟踪。但是,即使客户端没有指定跟踪,我也希望能够开始跟踪。
根据我对 camel-zipkin 代码的阅读,我认为我可以创建一个 PR 来引发我想要的行为。不过,在此之前,我想验证几件事:
- 当客户端未提供跟踪标头时,期望自动开始跟踪是否有效?
- 我的 camel-zipkin 配置是否遗漏了什么?
谢谢!
spring - 跨线程发送 TraceId
我们有一个遵循微服务架构的分布式应用程序。在我们的一项微服务中,我们遵循生产者-消费者模式。
生产者接收请求,将其持久化到数据库,将请求推送到 BlockingQueue 并将响应发送回客户端。运行在单独线程上的消费者正在监听阻塞队列。在它获得请求对象的那一刻,它会对其执行特定的操作。
生产者收到的请求使用 CompleteableFutures 异步持久化到数据库中。
这里的问题是如何将 TraceId 转发给在消费者线程中处理 requestObject 的方法。因为消费者线程可能会在响应发送给消费者之后很久才处理这些对象。
另外如何跨异步调用转发traceId?
谢谢
spring-boot - 如何设置主rabbit模板和rabbit连接工厂
我在使用 Spring 集成连接到 RabbitMQ 的 Spring Boot 项目中遇到了一些错误。我在 XML 文件中为 RabbitMQ 进行配置,如下所示:
但我正在创建每个组件中的两个。如何设置初选?
现在问题来了,我用的是这个版本的spring cloud:
一切正常,但如果我将版本更新为:
这个错误来了:
并且由于这种依赖性而出现错误:
如果我删除此依赖项,则不会出现错误。
您可以找到一个示例项目来重现此场景。在 pom 文件中,您将看到:
https://github.com/fjmpaez911/spring-integration-zipkin-cloud
所以我需要知道如何为 RabbitMQ 设置主要配置,此外我认为这可能是一个问题,因为这个错误只有在我使用这个版本Edgware.RELEASE 时才会出现
我错过了什么吗?
html - zipkin 如何合并搜索跟踪请求的跨度?
在 zipkin web ui 中,当请求 url 为http://10.19.138.169:9411/zipkin/api/v1/trace/ae60bd175a61e820
我发现返回响应是 [ { "traceId": "ae60bd175a61e820", "id": "ae60bd175a61e820", "name": "client", "timestamp": 1511858133224433, "duration": 508444, "binaryAnnotations": [ { “key”:“lc”,“value”:“”,“endpoint”:{“serviceName”:“monitor-gw-http-c”,“ipv4”:“10.19.138.169”}}]},{“ traceId”:“ae60bd175a61e820”,“id”:“19d69c3e93bc9040”,“name”:“post”,“parentId”:“ae60bd175a61e820”,“时间戳”:1511858133239803,“持续时间”:490921,“注释”:[{“时间戳”:1511858133239803,“值”:“cs”,“端点”:{“serviceName”:“monitor-gw- http-c", "ipv4": "10.19.138.169" } }, { "timestamp": 1511858133383290, "value": "sr", "endpoint": { "serviceName": "monitor-gw-web", " ipv4": "10.19.138.169" } }, { "时间戳”:1511858133609368,“值”:“ss”,“端点”:{“serviceName”:“monitor-gw-web”,“ipv4”:“10.19.138.169”}},{“时间戳”:1511858133730724,“值”:“cr”,“端点”:{“serviceName”:“monitor-gw-http-c”,“ipv4”:“10.19.138.169”}}],“binaryAnnotations”:[{“key”:“ ca", "值": true, "端点": {"serviceName": "", "ipv4": "127.0.0.1", "port": 43928 } }, { "key": "http.path", "value": "/security/gateway", "endpoint": {“serviceName”:“monitor-gw-web”,“ipv4”:“10.19.138.169”}},{“key”:“http.path”,“value”:“/security/gateway”,“endpoint” : { "serviceName": "monitor-gw-http-c", "ipv4": "10.19.138.169"} }, { "key": "sa", "value": true, "endpoint": { "serviceName": "", "ipv4": "127.0.0.1", "port": 8090 } } ] }, { “traceId”:“ae60bd175a61e820”,“id”:“16eefe087852af41”,“name”:“ennmonitorsecuritygatewayserver/put”,“parentId”:“19d69c3e93bc9040”,“timestamp”:1511858133393425,“duration”:212916,“annotations” : [ { "时间戳": 1511858133393425, "值”:“cs”,“端点”:{“serviceName”:“monitor-gw-web”,“ipv4”:“10.19.138.169”}},{“时间戳”:1511858133588237,“值”:“sr” ,“端点”:{“服务名称”:“monitor-gw-s”,“ipv4”:“10.19.138.169”}},{“时间戳”:1511858133593907,“值”:“ss”,“端点”:{ “serviceName”:“monitor-gw-s”,“ipv4”:“10.19.138.169”}},{“时间戳”:1511858133606341,“值”:“cr”,“端点”:{“服务名称”:“monitor-gw-web”,“ipv4”:“10.19.138.169”}}]} ,{“traceId”:“ae60bd175a61e820”,“id”:“8ef78f0edefe3a4b”,“name”:“数据入队”,“parentId”:“16eefe087852af41”,“时间戳”:1511858133592958,“duration”:129,“binaryAnnotations” : [ { "key": "lc", "value": "",“端点”:{“服务名称”:“monitor-gw-s”,“ipv4”:“10.19.138.169”}}]},{“traceId”:“ae60bd175a61e820”,“id”:“97c637bcc891b86a”,“名称” “:”数据出队,发送到kafka”,“parentId”:“16eefe087852af41”,“timestamp”:1511858133593147,“duration”:2416,“binaryAnnotations”:[{“key”:“lc”,“value”:“ ", "端点": { "serviceName": "monitor-gw-s", "ipv4":“10.19.138.169”}}]},{“traceId”:“ae60bd175a61e820”,“id”:“f193c7f4193f2879”,“名称”:“”,“parentId”:“16eefe087852af41”,“时间戳”:1511858133594113,“持续时间": 7575, "注释": [ { "timestamp": 1511858133594113, "value": "ms", "endpoint": { "serviceName": "monitor-gw-s", "ipv4": "10.19.138.169" } }, { "时间戳": 1511858133601688, "值": "ws", "endpoint": { "serviceName": "monitor-gw-s", "ipv4": "10.19.138.169" } } ], "binaryAnnotations": [ { "key": "kafka.topic", "值”:“rdkafka”,“端点”:{“serviceName”:“monitor-gw-s”,“ipv4”:“10.19.138.169”}}]},{“traceId”:“ae60bd175a61e820”,“id” :“54a3f6268df0aaee”,“名称”:“”,“parentId”:“f193c7f4193f2879”,“时间戳”:1511858133600067,“持续时间”:5,“注释”:[{“时间戳”:1511858133600067,“值”:“wr”,“端点”:{“serviceName”:“monitor-kafka-consumer”,“ipv4 ": "10.19.138.169" } }, { "timestamp": 1511858133600072, "value": "mr", "endpoint": { "serviceName": "monitor-kafka-consumer", "ipv4": "10.19.138.169 " } } ], "binaryAnnotations":[{“key”:“kafka.topic”,“value”:“rdkafka”,“endpoint”:{“serviceName”:“monitor-kafka-consumer”,“ipv4”:“10.19.138.169”}}]} ]
不难发现有8个span。
当我使用 api 获取具有相同 traceId ElasticsearchStorage storage = ElasticsearchStorage.newBuilder() .hosts(Arrays.asList(" http://10.19.138.169:9200 ")).build();的跟踪时
我得到 [ {“traceId”:“ae60bd175a61e820”,“parentId”:“16eefe087852af41”,“id”:“97c637bcc891b86a”,“name”:“数据出队,发送到 kafka”,“timestamp”:1511858133593147,“duration” :2416,“localEndpoint”:{“serviceName”:“monitor-gw-s”,“ipv4”:“10.19.138.169”}},{“traceId”:“ae60bd175a61e820”,“id”:“ae60bd175a61e820”,“名称”:“客户端”,“时间戳”:1511858133224433,“持续时间”:508444,“localEndpoint”:{“服务名称”:“monitor-gw-http-c”,“ipv4”:“10.19.138.169”}},{ “traceId”:“ae60bd175a61e820”,“parentId”:“f193c7f4193f2879”,“id”:“54a3f6268df0aaee”,“kind”:“CONSUMER”,“timestamp”:1511858133600067,“duration”:5,“localEndpoint”:{ “serviceName”:“monitor-kafka-consumer”,“ipv4”:“10.19.138.169”},“tags”:{“kafka.topic”:“rdkafka”}},{“traceId”:“ae60bd175a61e820”,“ parentId”:“ae60bd175a61e820”,“id”:“19d69c3e93bc9040”,“kind”:“SERVER”,“name”:“post”,“timestamp”:1511858133383290,“duration”:226078,“localEndpoint”:{“serviceName”:“monitor-gw-web”,“ipv4”:“10.19.138.169”},“remoteEndpoint”:{“ipv4”:“127.0.0.1”,“端口”:43928}, “标签”:{“http.path”:“/security/gateway”},“共享”:真},{“traceId”:“ae60bd175a61e820”,“parentId”:“19d69c3e93bc9040”,“id”:“16eefe087852af41” ,“种类”:“客户端”,“名称”:“ennmonitorsecuritygatewayserver/put”,“时间戳”:1511858133393425,“持续时间”:212916,“localEndpoint”:{“serviceName”:“monitor-gw-web”,“ipv4”:“10.19.138.169”}},{“traceId”:“ae60bd175a61e820”,“parentId”:“19d69c3e93bc9040”,“id”:“16eefe087852af41”,“种类”:“服务器”,“名称”:“ennmonitorsecuritygatewayserver /put", "timestamp": 1511858133588237, "duration": 5670, "localEndpoint": { "serviceName": "monitor-gw-s", "ipv4": "10.19.138.169" }, "shared": true } ,{“traceId”:“ae60bd175a61e820”,“parentId”:“16eefe087852af41”,“id”:“f193c7f4193f2879”,“kind”:“PRODUCER”,“timestamp”:1511858133594113,“持续时间”:7575,“localEndpoint”:{“serviceName”:“monitor-gw-s”,“ipv4”:“10.19.138.169”},“标签”:{“kafka.topic”:“rdkafka”}}, { “traceId”:“ae60bd175a61e820”,“parentId”:“ae60bd175a61e820”,“id”:“19d69c3e93bc9040”,“kind”:“CLIENT”,“name”:“post”,“timestamp”:1511858133239803,“duration” :490921,“localEndpoint”:{“serviceName”:“monitor-gw-http-c”,“ipv4”:“10.19.138.169”},“remoteEndpoint”:{“ipv4”:“127.0.0.1”,“端口“:8090},”标签”:{“http.path”:“/security/gateway”}},{“traceId”:“ae60bd175a61e820”,“parentId”:“ae60bd175a61e820”,“id”:“19d69c3e93bc9040”,“kind”:“服务器", "名称": "post", "timestamp": 1511858133383290, "duration": 226078, "localEndpoint": { "serviceName": "monitor-gw-web", "ipv4": "10.19.138.169" }, “remoteEndpoint”:{“ipv4”:“127.0.0.1”,“端口”:43928 },“标签”:{“http.path”:“/security/gateway”},“共享”:真},{“ traceId": "ae60bd175a61e820",“parentId”:“19d69c3e93bc9040”,“id”:“16eefe087852af41”,“kind”:“SERVER”,“name”:“ennmonitorsecuritygatewayserver/put”,“timestamp”:1511858133588237,“duration”:5670,“localEndpoint”: {“serviceName”:“monitor-gw-s”,“ipv4”:“10.19.138.169”},“shared”:true },{“traceId”:“ae60bd175a61e820”,“parentId”:“16eefe087852af41”,“id ": "97c637bcc891b86a", "name": "数据出队,发送到 kafka", "timestamp": 1511858133593147, "duration": 2416, "localEndpoint": { "serviceName": "monitor-gw-s”,“ipv4”:“10.19.138.169”}},{“traceId”:“ae60bd175a61e820”,“parentId”:“16eefe087852af41”,“id”:“f193c7f4193f2879”,“kind”:“PRODUCER” ”,“时间戳”:1511858133594113,“持续时间”:7575,“localEndpoint”:{“serviceName”:“monitor-gw-s”,“ipv4”:“10.19.138.169”},“标签”:{“kafka.主题”:“rdkafka”}},{“traceId”:“ae60bd175a61e820”,“parentId”:“19d69c3e93bc9040”,“id”:“16eefe087852af41”,“种类”:“客户”,“名称”:“ennmonitorsecuritygatewayserver/put”,“时间戳”:1511858133393425,“持续时间”:212916,“localEndpoint”:{“serviceName”:“monitor-gw-web”,“ipv4”:“10.19.138.169”}},{“traceId” :“ae60bd175a61e820”,“parentId”:“ae60bd175a61e820”,“id”:“19d69c3e93bc9040”,“kind”:“CLIENT”,“name”:“post”,“timestamp”:1511858133239803,“duration”:490921,“ localEndpoint”:{“serviceName”:“monitor-gw-http-c”,“ipv4”:“10.19.138.169”},“remoteEndpoint”:{“ipv4”:“127.0.0.1”,“端口”:8090},“标签”:{“http.path”:“/security/gateway”}},{“traceId”:“ae60bd175a61e820”,“id”:“ae60bd175a61e820”,“名称”:“客户端”,“时间戳“:1511858133224433,“持续时间”:508444,“localEndpoint”:{“serviceName”:“monitor-gw-http-c”,“ipv4”:“10.19.138.169”}},{“traceId”:“ae60bd175a61e820”, “parentId”:“f193c7f4193f2879”,“id”:“54a3f6268df0aaee”,“kind”:“CONSUMER”,“timestamp”:1511858133600067,“duration”:5,“localEndpoint”:{“serviceName”:“监控卡夫卡消费者”,“ipv4”:“10.19.138.169”},“标签”:{“kafka.topic”:“rdkafka”}},{“traceId”:“ae60bd175a61e820”,“parentId”:“16eefe087852af41 ", "id": "8ef78f0edefe3a4b", "name": "数据入队", "timestamp": 1511858133592958, "duration": 129, "localEndpoint": { "serviceName": "monitor-gw-s", "ipv4 “:“10.19.138.169”}},{“traceId”:“ae60bd175a61e820”,“parentId”:“16eefe087852af41”,“id”:“8ef78f0edefe3a4b”,“名称”:“数据入队”,“时间戳”:1511858133592958,“持续时间”:129,“localEndpoint”:{“serviceName”:“monitor-gw-s”,“ipv4”:“10.19.138.169”}}]
不难发现有 18 个跨度。
似乎一些跨度合并在网络请求中,我想知道源代码在哪里处理这个。谢谢!
spring-cloud - 禁用 AMQP 与 Sleuth 的集成
我有一个使用 Spring Boot Starter AMQP 与 RabbitMQ 集成的基于 Java Spring-Cloud 的微服务(从pom.xml
下面摘录):
现在我想使用 Sleuth 将此服务连接到 Zipkin 监控。根据文档,启用 AMQP 支持后,Sleuth 通过 RabbitMQ 队列发送其所有数据。出于某种原因,我想禁用此默认行为并通过 HTTP 发送数据。可能有一个我找不到的神奇属性。你知道如何强制我的应用程序通过 HTTP 将 Sleuth 相关数据发送到 Zipkin 服务器(也是带有@EnableZipkinServer
注释的 Spring Boot 应用程序)吗?
另外我想提一下,在删除 AMQP 支持后一切正常,即 Zipkin 通过 HTTP 接收跟踪数据。
此外,同时设置spring.zipkin.collector.http.enabled: true
and spring.zipkin.collector.amqp.enabled: false
(and spring.zipkin.collector.rabbitmq.enabled: false
) 也无济于事。
profiling - ZipKin 中的异构跟踪
我有一个由多个团队编写的异构(Java、php、python、C#.Net)微服务系统。所有通信都通过 HTTP 连接进行。
我的目标是使用 Zipkin 来跟踪执行路径并识别最慢的服务并开始使用(VisualVM、dotTrace)对它们进行分析。我听说 Zipkin 支持用于跟踪的 HTTP 连接。
我该怎么做呢?Zipkin 是否是正确的方法?我正在寻找开始的方向和一些 Java 示例。是否有我可以使用的 http 格式,或者我需要使用多个(Wingtips、ZipkinTracerModule、Brave)库?
谢谢。