背景與現(xiàn)狀
我司技術(shù)選型選擇skywalking，希望通過本文章能讓作者從0到1 認識及了解SkyWalking，并學會如何使用相關(guān)功能；
并分析下APM通信。而不關(guān)心 持久化[倉儲]（因需要運維精力，團隊目前有相關(guān)人去運維，其中包括云上和云下）
介紹
我們看官網(wǎng)的 SkyWalking top2 版本 v8.9.1歡迎語，從8以后采用全新API，并不兼容8以下。從幾個方面去了解SkyWalking。
1.概念和設計
其中包括what，why；brobe，backend（trace，metrics and log）,ui,cli,event;
what
SkyWalking is an open source observability platform used to collect, analyze, aggregate and visualize data from services and cloud native infrastructures. SkyWalking provides an easy way to maintain a clear view of your distributed systems, even across Clouds. It is a modern APM, specially designed for cloud native, container based distributed systems.
翻譯如下
SkyWalking是一個開源的可觀測平臺，用于收集、分析、聚合和可視化來自服務和云本地基礎設施的數(shù)據(jù)。SkyWalking提供了一種簡單的方法來維護分布式系統(tǒng)的清晰視圖，甚至是跨云。它是一個現(xiàn)代的APM，專門為云原生的、基于容器的分布式系統(tǒng)設計。
why
SkyWalking provides solutions for observing and monitoring distributed systems, in many different scenarios. First of all, like traditional approaches, SkyWalking provides auto instrument agents for services, such as Java, C#, Node.js, Go, PHP and Nginx LUA. (with calls out for Python and C++ SDK contributions). In multi-language, continuously deployed environments, cloud native infrastructures grow more powerful but also more complex. SkyWalking’s service mesh receiver allows SkyWalking to receive telemetry data from service mesh frameworks such as Istio/Envoy and Linkerd, allowing users to understand the entire distributed system.
翻譯如下
SkyWalking在許多不同的場景中為觀察和監(jiān)控分布式系統(tǒng)提供了解決方案。首先，像傳統(tǒng)的方法一樣，SkyWalking為服務提供了自動儀表代理，如Java、c#、Node.js、Go、PHP和Nginx LUA。(調(diào)用Python和c++ SDK貢獻)。在多語言、持續(xù)部署的環(huán)境中，云原生基礎設施變得更加強大，但也更加復雜。SkyWalking的服務網(wǎng)格接收器允許SkyWalking從Istio/Envoy和Linkerd等服務網(wǎng)格框架接收遙測數(shù)據(jù)，允許用戶了解整個分布式系統(tǒng)。
SkyWalking allows users to understand the topology relationship between Services and Endpoints, to view the metrics of every Service/Service Instance/Endpoint and to set alarm rules.
architecture
2.設置，體質(zhì)
其中包括 支持哪些領(lǐng)域，哪些版本，如何設置相關(guān)配置，如何啟動項目
3.UI 介紹
從視圖層 介紹下SkyWalking 的 核心功能trace，metrics and log，alarm等。
4 協(xié)議
How
搭建及演示 https://gitee.com/tjhuey/huey-2022
skyswakling 8.9.1
skyswakling-agent 8.9.0
nacos 2.x
spring-gateway 2021.0.x
spring-boot-user 2.6.3
redis-sa-token 1.29.0
UI
3.1 儀表盤
3.2 拓撲圖
3.3 追蹤 演示
3.4 性能剖析
No data shown and backend replies with "Variable 'serviceId' has coerced Null value for NonNull type 'ID!'"
一個服務只能同時執(zhí)行一個， 演示
3.5 日志 演示
3.6 告警 事件
3.7 調(diào)試 略
APM通信_源碼
1.grpc-java （protobuf） ，2.spi 3,設計模式 4 c/s 事件
1.客戶端已服務端通過grpc協(xié)議 封裝 stub , 通過 命令模式發(fā)出 服務端接收數(shù)據(jù) 的命令
2.服務端通過xxhandler組件進行 接收數(shù)據(jù) 。
client 看情況具體演示
>org.apache.skywalking.apm.agent.SkyWalkingAgent#premain
>>org.apache.skywalking.apm.agent.core.boot.ServiceManager#boot
>>>org.apache.skywalking.apm.agent.core.boot.ServiceManager#startup
>>>>org.apache.skywalking.apm.agent.core.remote.GRPCChannelManager#boot
>>>>>org.apache.skywalking.apm.network.management.v3.ManagementServiceGrpc.ManagementServiceBlockingStub#reportInstanceProperties
>>>>>>io.grpc.stub.ClientCalls#blockingUnaryCall(io.grpc.Channel, io.grpc.MethodDescriptor<ReqT,RespT>, io.grpc.CallOptions, ReqT)
>>>>>>>io.grpc.internal.ManagedChannelImpl.RealChannel#newCall
>>>>>>>io.grpc.stub.ClientCalls#futureUnaryCall
>>>>>>>>io.grpc.stub.ClientCalls#asyncUnaryRequestCall(io.grpc.ClientCall<ReqT,RespT>, ReqT, io.grpc.stub.ClientCalls.StartableListener<RespT>)
>>>>>>>>>>org.apache.skywalking.apm.plugin.grpc.v1.client.TracingClientCall#start
>>>>>>>>>>>org.apache.skywalking.apm.agent.core.context.ContextManager#inject
>>>>>org.apache.skywalking.apm.network.management.v3.ManagementServiceGrpc.ManagementServiceBlockingStub#keepAlive
SPI
舉例2個GRPCChannelManager （NettyChannelBuilder），ServiceManagementClient
server 看情況具體演示
>org.apache.skywalking.oap.server.starter.OAPServerStartUp#main
>>org.apache.skywalking.oap.server.starter.OAPServerBootstrap#start
>>>org.apache.skywalking.oap.server.library.module.ModuleManager#init
>>>>org.apache.skywalking.oap.server.library.module.BootstrapFlow#start
>>>>>org.apache.skywalking.oap.server.core.CoreModuleProvider#start ( receiver.scan()及annotationScan 執(zhí)行processor的create)
>>>>>org.apache.skywalking.oap.server.receiver.register.provider.RegisterModuleProvider#start
>>>>org.apache.skywalking.oap.server.library.module.BootstrapFlow#notifyAfterCompleted
>>>>>org.apache.skywalking.oap.server.core.CoreModuleProvider#notifyAfterCompleted
>>>>>org.apache.skywalking.oap.server.receiver.register.provider.handler.v8.grpc.ManagementServiceHandlerCompat#reportInstanceProperties
>>>>>>org.apache.skywalking.oap.server.receiver.register.provider.handler.v8.grpc.ManagementServiceHandler#reportInstanceProperties
>>>>>>>org.apache.skywalking.oap.server.core.source.SourceReceiverImpl#receive
>>>>>>>>org.apache.skywalking.oap.server.core.analysis.DispatcherManager#forward
>>>>>>>>>org.apache.skywalking.oap.server.core.analysis.manual.instance.InstanceTrafficDispatcher (各種轉(zhuǎn)發(fā)器)
>>>>>>>>>org.apache.skywalking.oap.server.core.analysis.manual.segment.SegmentDispatcher#dispatch(各種轉(zhuǎn)發(fā)器)
>>>>>>>>>>org.apache.skywalking.oap.server.core.analysis.worker.MetricsStreamProcessor#in
>>>>>>>>>>org.apache.skywalking.oap.server.core.analysis.worker.MetricsAggregateWorker#in
其他
對比 及 原理
https://skywalking.apache.org/zh/2019-02-24-skywalking-pk-pinpoint/
后期
維護，持久性
精選問題
精選提問
問1：想問問選型的時候用pinpoint還是SK好？
答：選型問題
要結(jié)合具體的業(yè)務場景， 比如你的代碼運行環(huán)境 是java、php、net還是什么。
pinpoint在安裝部署上要比skywalking略微復雜
pinpoint和sw支持的組件列表是不同的。 https://github.com/apache/incubator-skywalking/blob/master/docs/en/setup/service-agent/java-agent/Supported-list.md你可以參照這里的支持列表對比下pinpoint的支持對象做一個簡單對比。
sw經(jīng)過測試在并發(fā)量較高的情況下比pinpoint的吞吐量更好一些。
問2：有沒有指標統(tǒng)計，比如某個url 的top10 請求、響應最慢的10個請求？某個服務在整個鏈條中的耗時占比？
答：1.sw自帶有響應最慢的請求top10統(tǒng)計針對所有的endpoint的統(tǒng)計。 2.針對每個url的top10統(tǒng)計，sw本身沒有做統(tǒng)計，數(shù)據(jù)都是現(xiàn)成的通過簡單的檢索就可以搜到你想要的結(jié)果。 3.沒有具體的耗時占比，但是有具體總鏈路時間統(tǒng)計以及某個服務的耗時統(tǒng)計，至于占比自己算吧，可以看ppt中的調(diào)用鏈路監(jiān)控的span時間解釋。
問3：能不能具體說一下在你們系統(tǒng)中的應用？
答：EOS8LA版本中，我們整合sw對應用提供拓撲、調(diào)用鏈路、性能指標的監(jiān)控、并在sw數(shù)據(jù)的基礎上增加系統(tǒng)的維度。 當服務數(shù)很龐大的時候，整體的拓撲其實就是一張密密麻麻的蜘蛛網(wǎng)。我們可以通過系統(tǒng)來選擇具體某個系統(tǒng)下的應用。 8LA中SW是5.0.0alpha版本，受限于sw功能，我們并沒有提供告警能力，這在之后會是我們的考慮目標。
問4：業(yè)務訪問日志大概每天100G，kubernetes 環(huán)境中部署，使用穩(wěn)定嗎？
答：監(jiān)控數(shù)據(jù)沒有長時間的存儲必要，除非你有特定的需求。它有一定的時效性，你可以設置ttl自動清除過時信息。100g，es集群還是能輕松支撐的。
問5：和pinpoint相比有什么優(yōu)勢嗎？
答：
部署方式、使用方式簡單
功能特性支持的更多
高并發(fā)性能會更好一些
問6：skywalking的侵入式追蹤功能方便進行單服務鏈的服務追蹤。但是跨多臺服務器多項目的整體服務鏈追蹤是否有整體設計考慮？
答：sw本身特性就是對分布式系統(tǒng)的追蹤，他是無侵入式的。無關(guān)你的應用部署在多少臺服務器上。
問7：應用在加上代理之后性能會下降。請問您有什么解決方法嗎？
答：性能下降是在所難免的，但是據(jù)我了解，以及官方的測試，他的性能影響是很低的。這是sw的測試數(shù)據(jù)供你參考。 https://skywalkingtest.github.io/Agent-Benchmarks/README_zh.html。
問8：有異構(gòu)系統(tǒng)需求的話可以用sw嗎？
答：只要skywalking的探針支持的應該都是可以的。
問9：sw對于商用的web中間件，如bes、tongweb、websphere、weblogic的支持如何？
答：商業(yè)組件支持的比較少，因為涉及到相關(guān)license的問題，sw項目組需要獲得他們的支持來進行數(shù)據(jù)上報，據(jù)我了解，支持不是很好。
參考
官網(wǎng)相關(guān)
https://skywalking.apache.org/
https://github.com/apache/skywalking-java.git
https://github.com/apache/skywalking.git
https://skywalking.apache.org/blog/
#對比 及 原理
https://skywalking.apache.org/zh/2019-02-24-skywalking-pk-pinpoint/
釘釘告警 ，飛書 來源
https://skywalking.apache.org/zh/2020-12-13-skywalking-alarm/ 跳轉(zhuǎn)github鏈接
微服務監(jiān)控分析
https://skywalking.apache.org/zh/2019-01-03-monitor-microservice/#skywalking-trace%E7%9B%91%E6%8E%A7
博客相關(guān)
介紹
https://juejin.cn/post/7049920780569673736
指標
https://blog.csdn.net/lizz861109/article/details/107535100
