K60至尊版狂暴引擎2.0加持：超177萬跑分?jǐn)孬@性能第一
Redmi的后性能時(shí)代戰(zhàn)略發(fā)布會(huì)今天下午如期舉辦，在本次發(fā)布會(huì)上，Redmi公布了多項(xiàng)關(guān)于和聯(lián)發(fā)科的深度合作，以及新機(jī)K60 Ultra在軟件和硬件方面的特性，例如：“K60 至尊版，雙芯旗艦
早在 OpenTelemetry 誕生之前可觀測(cè)性這個(gè)概念就一直存在了，我記得我最早接觸到這個(gè)概念是在 16 年當(dāng)時(shí)的公司所使用的一個(gè)產(chǎn)品：pinpoint
現(xiàn)如今這個(gè)項(xiàng)目依然比較活躍。
圖片
依然還記得當(dāng)時(shí)通過它可以直接看到項(xiàng)目調(diào)用的拓?fù)鋱D，在時(shí)間坐標(biāo)上框出高延遲的點(diǎn)就能列出這些請(qǐng)求，同時(shí)還能查看此時(shí)的運(yùn)行日志。
這樣強(qiáng)大的功能對(duì)于一個(gè)剛工作一年的小白來說沖擊力實(shí)屬太大了一點(diǎn)。
后來才了解到 pinpoint 屬于 APM 這類產(chǎn)品，類似的產(chǎn)品還有：
他們都是可以用于性能分析和鏈路追蹤的產(chǎn)品，到后來公司的運(yùn)維層面也接入過 Zabbix、open-falcon 之類的產(chǎn)品：
圖片
17之后全面切換到 spring boot 時(shí)，也用過社區(qū)提供的 spring-boot-admin 項(xiàng)目：
圖片
這就是一個(gè)簡(jiǎn)單的可以監(jiān)控 spring boot 應(yīng)用的產(chǎn)品，用于展示 JVM 指標(biāo)，或者自己也可以定義一些健康指標(biāo)。
再之后進(jìn)入云原生體系后可觀測(cè)性的技術(shù)棧稍有變化。
圖片
日志使用 Sidecar 代理的方式通過 Agent 將數(shù)據(jù)寫入 ElasticSearch 中。 具體日志采集方式可以參考之前的文章：
而鏈路追蹤則是使用的 skywalking，在 trace 這個(gè)領(lǐng)域 skywalking 還是非常受大家喜愛的。
不過最近也從 skywalking 切換到了我們本文所講到的 OpenTelemetry，具體可以看之前的文章：
指標(biāo)采集使用的是自然也是 Prometheus 的那一套技術(shù)棧，只是 Prometheus 換為了與它完全兼容的 VictoriaMetric 目前是為了更省資源。
客戶端使用則是直接使用 Prometheus 的庫(kù)進(jìn)行指標(biāo)暴露：
<dependency> <groupId>io.prometheus</groupId> <artifactId>prometheus-metrics-core</artifactId> <version>1.0.0</version></dependency><dependency> <groupId>io.prometheus</groupId> <artifactId>prometheus-metrics-instrumentation-jvm</artifactId> <version>1.0.0</version></dependency><dependency> <groupId>io.prometheus</groupId> <artifactId>prometheus-metrics-exporter-httpserver</artifactId> <version>1.0.0</version></dependency>最終通過配置抓取策略，由 VictoriaMetrics 的 scrape 程序來抓取指標(biāo)最終寫入到它自己的存儲(chǔ)中：
apiVersion: operator.victoriametrics.com/v1beta1 kind: VMPodScrape metadata: name: kubernetes-pod-scrape namespace: monitoring spec: podMetricsEndpoints: - scheme: http scrape_interval: "30s" path: /metrics relabelConfigs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] separator: ; regex: "true" replacement: $1 action: keep # 端口相同 - action: keep_if_equal source_labels: [ __meta_kubernetes_pod_annotation_prometheus_io_port, __meta_kubernetes_pod_container_port_number ] # 過濾INIT容器 - action: drop source_labels: [ __meta_kubernetes_pod_container_init ] regex: "true" - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] separator: ; regex: (.+) target_label: __metrics_path__ replacement: $1 action: replace - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] separator: ; regex: ([^:]+)(?::/d+)?;(/d+) target_label: __address__ replacement: $1:$2 action: replace - separator: ; regex: __meta_kubernetes_pod_label_(.+) replacement: $1 action: labelmap - source_labels: [__meta_kubernetes_namespace] separator: ; regex: (.*) target_label: kubernetes_namespace replacement: $1 action: replace - source_labels: [__meta_kubernetes_pod_name] separator: ; regex: (.*) target_label: kubernetes_pod_name replacement: $1 action: replace vm_scrape_params: stream_parse: true namespaceSelector: any: true以上是 VM 提供的 CRD
到此鋪墊完成，不知道有沒有發(fā)現(xiàn)在可觀測(cè)性中關(guān)鍵的三個(gè)部分：日志、指標(biāo)、trace 都是使用不同的開源產(chǎn)品，從而會(huì)導(dǎo)致技術(shù)棧較多，維護(hù)起來自然也是比較麻煩的。
這么一個(gè)軟件領(lǐng)域的核心能力自然需要提供一個(gè)完整方案的，將以上的不同技術(shù)棧都整合在一起，更加的方便開發(fā)者使用。
在這之前也有兩個(gè)社區(qū)想要做類似的事情：
不過他們并沒有統(tǒng)一整個(gè)可觀測(cè)領(lǐng)域，直到 2019 年 CNCF 社區(qū)宣布成立 OpenTelemetry，并且將上述兩個(gè)社區(qū)進(jìn)行合并共同開發(fā) OpenTelemetry。
背靠 CNCF 云原生社區(qū)加上許多知名廠商的支持（Google、Amazon、Redhat 等），現(xiàn)在已經(jīng)正式成為 CNCF 的頂級(jí)項(xiàng)目了。
圖片
但我們打開 OpenTelemetry 社區(qū)的 GitHub 首頁(yè)時(shí)，會(huì)看到有許多項(xiàng)目；第一反應(yīng)應(yīng)該是比較蒙的，下面我會(huì)著重介紹一些比較重要的項(xiàng)目。
在開始之前還是先簡(jiǎn)單介紹下 OpenTelemetry 的一些基礎(chǔ)組件和概念：
圖片
整個(gè) OpenTelemetry 系統(tǒng)其實(shí)可以簡(jiǎn)單分為三個(gè)部分：
第一個(gè)客戶端很好理解，也就是我們的業(yè)務(wù)應(yīng)用；如果是 Java 應(yīng)用只需要掛載一個(gè) agent 就可以自動(dòng)采集系統(tǒng)的指標(biāo)、鏈路信息、日志等上傳到 Collector 中。
也就是上圖的左邊部分。
之后就是非常關(guān)鍵的組件 collector，它可以通過 OTLP 協(xié)議接收剛才提到的客戶端上傳的數(shù)據(jù)，然后再內(nèi)部進(jìn)行處理，最終輸出到后續(xù)的存儲(chǔ)系統(tǒng)中。
collector 的架構(gòu)圖
由于 OpenTelemetry 設(shè)計(jì)之初就是要做到廠商無關(guān)，所以它就得做出更高層級(jí)的設(shè)計(jì)。
關(guān)鍵點(diǎn)就是這里的 Receiver 和 Exporter 都是模塊化的設(shè)計(jì)，第三方開發(fā)者可以基于它的標(biāo)準(zhǔn)開發(fā)不同組件從而兼容不同的產(chǎn)品。
Receiver：用于接收客戶端上報(bào)的數(shù)據(jù)，不止是自己 agent 上報(bào)的數(shù)據(jù)，也可能會(huì)來自不同的廠商，比如 kubernetes、Kafka 等。
Exporter：同理，可以將 receiver 收到的數(shù)據(jù)進(jìn)行處理之后輸出到不同的組件中；比如 Kafka/Pulsar/Promethus/Jaeger 等。
比如我們可以使用 Nginx Receiver接收來著 Nginx 上報(bào)的數(shù)據(jù)。
使用 MySQL Receiver接收來自 MySQL 的數(shù)據(jù)。
當(dāng)然通常我們使用最多的還是 OTLP Receiver，這是官方的 OTLP 協(xié)議的接收器，可以接受官方的一些指標(biāo)，比如我們只使用了 Java Agent 進(jìn)行數(shù)據(jù)上報(bào)時(shí)。
圖片
https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver
在這里是可以看到目前支持的所有第三方的 Receiver。
圖片
OpenTelemetry 所支持的 Exporter 也很多，比如一些常見的存儲(chǔ)：
Exporter 的使用場(chǎng)景很多：如果是指標(biāo)相關(guān)的數(shù)據(jù)可以直接寫入 Prometheus，如果是日志數(shù)據(jù)也可以直接寫入 ElasticSearch。
如果還有其他的特殊需求（刪減屬性等）則可以寫入消息隊(duì)列，自行處理完之后再發(fā)往 collector 進(jìn)行后續(xù)的處理。
可能你已經(jīng)發(fā)現(xiàn)了，由于 collector 非常的靈活，所以我們可以像搭積木一樣組裝我們的 receiver 和 exporter，它會(huì)以我們配置的流水線的方式進(jìn)行調(diào)用，這樣我們就可以實(shí)現(xiàn)任意可定制的處理邏輯。
而這些流水線的組裝對(duì)于客戶端來說都是透明的，也就是說 collector 的更改完全不會(huì)影響到業(yè)務(wù)；業(yè)務(wù)只需要按照 OTLP 的格式上報(bào)數(shù)據(jù)即可。
在之前的從 Skywalking 切換到 OpenTelemetry 的文章中有人問為什么要切換到 OpenTelemetry？
從這里也能看得出來，OpenTelemetry 的靈活度非常高，借助于 Exporter 可以任意的更換后端存儲(chǔ)，或者增加/刪減一些不需要的指標(biāo)數(shù)據(jù)等。
當(dāng)然我們也可以統(tǒng)一的在這里進(jìn)行搜索，可以列出所有的第三方集成的組件： https://opentelemetry.io/ecosystem/registry/。
圖片
介紹完基本的概念后，我們可以看看 OTel 社區(qū)的一些主要開源項(xiàng)目。
圖片
這里我們還是以剛才的那個(gè)架構(gòu)圖從作往右講起，也就是主要分為客戶端和 collector 端。
圖片
目前官方支持的客戶端語(yǔ)言已經(jīng)非常齊全了，大部分的版本都已經(jīng)是 Stable 穩(wěn)定版，意味著可以進(jìn)入生產(chǎn)環(huán)境。
這里我們以 Java 客戶端為例：
圖片
其中我們重點(diǎn)關(guān)注下 opentelemetry-java 和 opentelemetry-java-instrumentation 這兩個(gè)項(xiàng)目。
我們用的最多的會(huì)是 opentelemetry-java-instrumentation，它會(huì)給我們提供一個(gè) java agent 的 JAR 包：
java -javaagent:path/to/opentelemetry-javaagent.jar / -jar myapp.jar我們只需要在 Java 應(yīng)用中加上該 agent 就可以實(shí)現(xiàn)日志、指標(biāo)、trace 的自動(dòng)上報(bào)。
而且它還實(shí)現(xiàn)了不同框架、庫(kù)的指標(biāo)采集與 trace。
在這里可以查到支持的庫(kù)與框架列表：
圖片
https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks
總之幾乎就是你能想到和不能想到的都支持了。
而 opentelemetry-java 我們直接使用的幾率會(huì)小一些，opentelemetry-java-instrumentation 本身也是基于它創(chuàng)建的，可以理解為是 Java 版本的核心基礎(chǔ)庫(kù)，一些社區(qū)支持的組件就可以移動(dòng)到 instrumentation 這個(gè)庫(kù)中。
比如我在上篇文章：從一個(gè) JDK21+OpenTelemetry 不兼容的問題講起中涉及到的 HostResourceProvider 資源加載就是從 opentelemetry-java 中移動(dòng)到了 opentelemetry-java-instrumentation。
具體可以參考：https://github.com/open-telemetry/opentelemetry-java/issues/4701
之后就是 collector 的組件了，它同樣的也有兩個(gè)庫(kù)：OpenTelemetry Collector 和 OpenTelemetry Collector Contrib
其實(shí)通過他們的名字也可以看得出來，他們的作用與剛才的 Java 庫(kù)類似：
而我們生產(chǎn)使用時(shí)通常也是直接使用 opentelemetry-collector-contrib，畢竟它所支持的社區(qū)組件更多。
因?yàn)?OpenTelemetry 想要解決的是整個(gè)可觀測(cè)領(lǐng)域的所有需求，所以倉(cāng)庫(kù)非常多，社區(qū)也很開放，感興趣的朋友可以直接參與貢獻(xiàn)，這么多 repo 總有一個(gè)適合你的。
后續(xù)會(huì)繼續(xù)講解如何安裝以及配置我們的 OpenTelemetry。
參考鏈接：
本文鏈接：http://m.www897cc.com/showinfo-26-89552-0.htmlOpenTelemetry 實(shí)踐指南：歷史、架構(gòu)與基本概念
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 在 ASP.NET Core 中優(yōu)雅地處理多接口實(shí)現(xiàn)
下一篇： 基于單元的架構(gòu)綜合指南
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)