随着软件和云技术的遍及,越来越多的企业开始采纳微服务架构、容器化、多云部署和继续部署模式,这减少了因零碎失败而给运维 / SRE / DevOps 团队带来的压力,从而减少了开发团队和他们之间的摩擦,因为开发团队总是想尽快部署新性能并启动新的 A / B 测试。
在云时代,CI/CD 模式倒退迅速,它能帮忙研发团队疾速改良、修复零碎缺点,把新性能推向生产,极大进步开发效率。CI/CD 能实现这一点,因为它领有功能强大的工具,可能生成信息,也能实时或简直实时地从运行的应用程序中收集信息,这些信息反映了应用程序的健康状况、性能和可靠性。用户能够察看和剖析异样信号,捕获行为不端的应用程序,决定是否须要修补或禁用它们。CI/CD 模式能够帮忙开发者疾速检测异样,避免重大故障和安全漏洞的呈现,从而改善用户应用体验。
过来用于记录谬误和异样的信号传输办法倒退到当初,曾经演变成了最新的 OpenTelemetry 规范。本文将摸索 Jina 3.12 中引入的最新跟踪和监控性能,并应用 Sentry 跟踪索引或搜寻时零碎外部的工作状况。
监控和跟踪能够解决什么问题?
嘿,让咱们一起意识新敌人小博吧!他创立了一个能够在线购物的网站叫 J 多多,咱们一起来看看这个网站是如何倒退的吧,同时也能够理解一下他的监控和跟踪性能哦!
J 多多 1.0:日志作为 stdout
一开始,为了进步 J 多多网站可靠性,小博采纳了一个简略的零碎,用来监控生成、捕捉和剖析信号:
- 应用程序日志存储在本地机器上,定期旋转防止磁盘空间耗尽。如果须要缩短日志的保留期限,能够将它们导出。
- 如果客户或测试人员发现搜索引擎出现异常(例如常常超时等),能够创立投诉工单来取得解决方案。
- 接着通过检查程序日志,将客户遇到的谬误与工夫进行匹配。
小博意识到,这个过程的繁琐是因为该零碎未能改善客户的理论体验所造成的,因而他迫切尽快优化该零碎。
J 多多 2.0:结构化和长久化的日志
随着程序日志的倒退迅速,小博很快就优化了日志格局,引入了结构化日志(JSON),改善了故障的报错音讯以及提供了更加便捷的工具。有些工具甚至能够将代码度量集成到正在运行的应用程序中,以实时测量应用程序栈各层(网络、磁盘、CPU)的代码性能。此外,小博能够捕捉、可视化并长时间存储这些信号。大数据处理框架能够让小博从不同的应用领域(语言、架构、设施平台)和部署环境中聚合、剖析数据。
J 多多 3.0:应用日志跟踪故障
J 多多逐步走向成熟,它开始反对云 / 混合部署环境,解决寰球数百万用户的不同设施类型。这意味着 J 多多须要更粗疏的跟踪监控办法:
- 生成有价值的信号。
- 找出问题最可能的根本原因。
以用户小美和小智为例:
- 小美在 J 多多 Android 利用上购买侈靡耳环,她应用的是美国的数据连贯。
- 小智在 Ubuntu PC 端,从智利钻研基地购买彩色夹克。
对于他俩来说,用户体验都不太称心。为了服务寰球各地不同设施、不同语言的本地化搜寻,零碎须要采纳更精准的形式生成信号,以找出导致问题的根本原因。此外,越来越多的用户和设施类型意味着也会带来更多的谬误形式和问题起因。总之,J 多多须要进一步优化。
什么是 OpenTelemetry
OpenTelemetry[1] 是 CNCF[2] 的孵化我的项目, 它反对分布式跟踪和度量。小博要求在 Jina Flow 中实现 Telemetry。在开始之前,咱们须要理解几个概念:
- Telemetry (遥测) 是一种近程数据采集技术,用于监控零碎性能和故障,它能够主动收集数据并将其发送至接管设施进行监控。简而言之,原始察看值或日志音讯在申请期间能够用作度量。
- Instrumentation(仪表仪器)是应用仪器记录和收集原始察看值,并将其转换为信号进行传输来实现监控的过程。
- Tracing(跟踪)则是指依据应用程序的日志记录,来监督它的运行状况。
如何在 Jina 中应用 OpenTelemetry?
Jina >=3.12 曾经集成了 OpenTelemetry,本文将介绍如何应用它构建文本到图像搜寻零碎。
- DocArray 负责解决数据并与存储后端交互。
- Jina Executor 实现微服务。
- Jina Flow 用于加载、编码和存储编排微服务。
- OpenTelemetry Collector Contrib 收集微服务跟踪信息,能够实时监督微服务。
- Sentry 可视化微服务报告操作,帮忙用户及时发现和解决问题。
请留神,本文仅波及后端,如果您想要构建低代码后端加前端神经搜寻解决方案,请查看 Jina AI Cloud 的 APPs。
筹备数据
咱们利用 Finetuner 对 deepfashion 数据集进行预处理,并通过提取和格式化 Finetuner 生成的图像标签来产生每个产品的 text
属性。
注:Jina ≥ 3.12.0 才反对 OpenTelemetry 性能,肯定要记得降级!
Jina Flow 能够作为连贯微服务(也就是 Executors)的流水线。因为咱们只是为了让大家理解 OpenTelemetry 性能,所以不会深究代码,只是给出概括性的介绍。毕竟 Telemetry 才是重点。
在 Python 中定义以下内容:
from jina import Flow, DocumentArray, Document
flow = (
Flow(
host='localhost',
port=8080,
tracing=True,
traces_exporter_host='localhost',
traces_exporter_port=4317,
)
.add(
name='clip_encoder', # encode images/text into vectors
host='localhost',
port=51000,
timeout_ready=3000000,
uses_with={'name': 'ViT-B-32::openai'},
external=True,
tls=False,
)
.add(
name='qdrant_indexer',
uses='jinahub+docker://QdrantIndexer', # store vectors and metadata on disk
uses_with={
'collection_name': 'collection_name',
'distance': 'cosine',
'n_dim': 512,
},
)
)
with flow:
flow.block()
为了节省时间,Flow 应用的是 Jina Executor Hub 中事后构建的 Executors。
📎 https://cloud.jina.ai/executors
Flow 由以下局部组成:
- Gateway,治理流向底层微服务的申请,向 Flow 提供跟踪参数,使得每个部署的微服务都能应用 OpenTelemetry 跟踪性能。
- CLIP-as-service Executor,应用默认的基于 cpu 运行的
ViT-L-14-336::openai
模型,编码文本和图像。clip_encoder
服务基于独立 Flow 运行,Flow 中蕴含跟踪参数。 - QdrantIndexer,基于 Docarray 的后端存储和搜寻数据。如果数据库不是在本地默认端口运行的,则须要提供适当的 Qdrant
host
和port
参数,uses_with
是指定向量维度的参数。
索引和搜寻
当初咱们曾经把所有组件都筹备好了,把数据加进数据库,而后就能够应用文本搜寻技术搜寻商品了。
上面这段代码能够让咱们轻松地索引商品图片:
from jina import DocumentArray, Client
da = DocumentArray.pull('deepfashion-text-preprocessed', show_progress=True)
# connect to the Flow
client = Client(host="grpc://0.0.0.0:8080")
# use only 100 Documents for demo
for docs in da[:100].batch(batch_size=10):
client.post(on="/index", inputs=docs)
示例:发送一个搜寻申请
from jina import Client, DocumentArray, Document
client = Client(host='grpc://0.0.0.0:8080')
results = client.post('/search', DocumentArray(Document(text='jacket mens')))
接下来,咱们一起来合成一下下面的索引和搜寻流程:
clip_encoder
为产品的text
属性生成嵌入向量。Flow(...).add(...).add(...)
默认创立程序拓扑。申请首先会通过 clip_encoder 服务,而后后果流向qdrant_indexer
服务。qdrant_indexer
实现了用于索引操作的/index
端和用于搜寻操作的/search
端。操作都是基于嵌入向量的,不关注产品属性。
启动 Executors 跟踪
当初,开始解释 OpenTelemetry 的一些概念:
- Tracing 是指记录程序执行信息的特定日志记录程序。
- Trace 示意形成最终后果的一系列(或者并行,或者组合)操作。。
- 每个 trace 都由一个或多个跨度组成。跨度示意跟踪中的操作,如
process_docs
、sanitize_text
、或embed_text
。
Hub Executors (cloud.jina.ai/executors) 默认集成了检测工具。以下是一个简略的示例,基于有用的标签 /index
为操作提供了跨度:上面的代码来自 QdrantIndexer
,创立了两个跨度:
- Jina 会主动为
@requests
装璜器创立 /index 跨度,这是 Jina 自动检测性能之一,开箱即用。 - 你能够跟踪更细粒度的操作,如
qdrant_index
跨度,它记录了 Qdrant 的索引申请中接管的文档数量。可疑的疾速索引操作可能是因为空申请导致的,十分慢的申请则可能是因为大型文档导致的。你能够向跨度标签增加更多信息,例如指标 Qdrant Collection 和与部署相干的信息。
@requests(on='/index')
def index(self, docs: DocumentArray, tracing_context, **kwargs):
"""Index new documents
:param docs: the Documents to index
"""with self.tracer.start_as_current_span('qdrant_index', context=tracing_context) as span:
span.set_attribute('len_docs', len(docs))
self._index.extend(docs)
留神,在存储 Document 时,不同的 Flow 可能须要应用同一 Qdrant 集群,这时,service.name
属性会为你提供帮忙。
如何应用 Sentry 可视化并剖析收集的数据?
Sentry 提供了很多性能和定义,能够帮忙开发者将 Telemetry 信号转换为业务术语。咱们只关注性能、摘要、追踪 以及 Dashboard 视图,基于这些信息,咱们能够监控 Flow 和 Executor。
1 Performance view
Performance view(性能视图)给出了 Sentry 接管的指标信号的整体视图:
2 Summary view
您能够单击跨度,查看 Summary view(事务摘要)页面。在咱们的例子中,点击 /index
跨度,弹出了 index
摘要:
在下面的屏幕截图中:
- TRACE ID 显示了跨度的父追踪。
- 绿色局部列出了可能很慢的跨度,点击 trace ID 能够查看操作的残缺跟踪。
- 红色局部能够帮忙开发者辨认并理解操作期间产生的异样、谬误或问题的根本原因,跨度的持续时间和状态还可用来检测可疑对象,并显示属于可疑跨度的标签。通过向跨度属性增加有用的标签,能够更容易地检测出可疑的跨度和标签。
- 蓝色局部显示所选时间段内的顶级标签,提供更概括的视图,帮忙开发者疾速理解不同属性,并深刻理解异样的本源。
3 Trace view
在 summary view 中点击跨度的 event ID,就能看到 Trace view(跟踪视图)。让咱们一起来看单个 /search
操作的 跟踪视图:
在上图中,trace f1adb01bcb9fd18f59a5b38745f07e39
显示了生成响应跨度的端到端申请流,跨度名称以 rpc
或 default
标签为前缀,前缀由 Sentry 依据跨度标签属性确定。在这张截图中,Jina 主动创立了 rpc
跨度,它示意外部申请流。rpc
跨度有助于填补空白,并基于用户增加的 encode
, inference
, txt_minibatch_encoding
, /search
和 qdrant_search
跨度,提供残缺的视图。
在深入研究用户创立的跨度之前,咱们先理解一下 Trace view。Trace view 是一个有向无环图,从申请开始连贯到到完结(从左到右跟踪条形图)。从自上而下渲染的黑白条能够看出,所有操作都是程序的。每个操作的持续时间都会显示,在有并行操作或慢速跨度的状况下,跟踪视图的作用会更显著。左侧是一个树形示意,代表高级跨度和每个操作嵌套的跨度(自上而下)。因为 Flow 生成的拓扑构造,存在三个顶级跨度。
- 客户端申请达到网关之后,网关会调用
clip_encoder
Executor。
- 接着,Executor 会创立搜寻文本的嵌入向量,并将其转发到
qdrant_indexer
的搜寻端。
-
最初,搜寻端会依据文本查问检索商品。
如果你想要理解 Sentry 的详细信息和性能(例如,显示谬误的跨度),能够查看文档。
用户能够通过点击跨度获取更多信息,咱们能够单击clipencoder
的inference
跨度,inference
跨度会为生成申请中 Document 的text
属性生成嵌入向量:
has_img_da
和has_txt_da
属性显示了文档中是否蕴含图像和 / 或文本数据。
minibatch_size
显示了线程池生成嵌入向量的批量大小。
因为演示数据集只提供文本数据,所以将has_txt_da
设置为True
,下一个跨度仅蕴含txt_minibatch_encoding
跨度,其中文本嵌入实际上是线程池生成的。
定制 Sentry dashboard
最初,让咱们一起来钻研示例 Flow 的性能监控仪表盘。通过综合多种 Telemetry 信号,咱们为开发者提供全面的指标概览,以便他们依据这些指标来分别零碎的差别或异样行为。
对于自定义 dashboard 和 Sentry 提供的谬误剖析图的详细信息,请参阅文档。
总结
基于 OpenTelemetry,咱们为小博提供了牢靠的产品搜寻零碎。这使得在谬误产生时能够取得及时报告,从而更容易追踪零碎问题,放慢响应工夫,缩短问题修复的工夫。小博能够专一于改良网站,以减少购物网站的商品数量或增加新的搜寻性能,从而进步客户满意度、晋升业务量并增加利润。
如果您有趣味理解 OpenTelemetry,想要实现像小博这样的胜利,能够利用 OpenTelemetry 进步零碎的可察看性和可靠性,请参阅咱们的文档。
参考资料
[1] OpenTelemetry: https://opentelemetry.io/
[2] CNCF: https://www.cncf.io/
[3] Gateway: https://docs.jina.ai/fundamen…
[4] CLIP-as-service: https://github.com/jina-ai/cl…
[5] QdrantIndexer: https://cloud.jina.ai/executo…
[6] Qdrant Collection: https://qdrant.tech/documenta…
[7] 性能: https://docs.sentry.io/produc…
[8] 摘要: https://docs.sentry.io/produc…
[9] 追踪: https://docs.sentry.io/produc…
[10] 文档: https://docs.jina.ai/cloud-na…