前言

當(dāng)前全球企業(yè)云化、數(shù)字化進(jìn)程持續(xù)加速，容器、微服務(wù)等云原生技術(shù)在軟件架構(gòu)中快速滲透，IT 架構(gòu)云化、復(fù)雜化持續(xù)驅(qū)動性能監(jiān)控市場。企業(yè)云化、數(shù)字化持續(xù)轉(zhuǎn)型，以及為了考慮系統(tǒng)的彈性、效率，企業(yè)軟件開發(fā)中大量云原生技術(shù)的應(yīng)用推動全球 IT 監(jiān)控市場快速變化，如何全面、有效的對容器、K8s、微服務(wù)進(jìn)行監(jiān)控是當(dāng)下云原生技術(shù)面臨的重要課題。

背景和挑戰(zhàn)

云化產(chǎn)品通常采用服務(wù)化框架，由一系列微服務(wù)組成，且微服務(wù)是可以獨(dú)立運(yùn)行的進(jìn)程，不同服務(wù)可使用不同開發(fā)語言，可能分布部署在幾千臺服務(wù)器上，甚至可能橫跨多個(gè)不同的數(shù)據(jù)中心，服務(wù)間使用輕量的通信機(jī)制；服務(wù)之間存在復(fù)雜的調(diào)用關(guān)系，對運(yùn)維人員理解系統(tǒng)的行為或分析系統(tǒng)性能帶來巨大挑戰(zhàn) 如：

（1）容器是否正常運(yùn)行

（2）K8S是否正常運(yùn)行。

（3）微服務(wù)是正常

（5）業(yè)務(wù)調(diào)用出現(xiàn)問題，如何快速找出哪個(gè)服務(wù)發(fā)生失敗？

（6）某個(gè)業(yè)務(wù)調(diào)用耗時(shí)較長，如何快速找到性能瓶頸點(diǎn)？

（7）如何快速獲取某次調(diào)用的業(yè)務(wù)日志進(jìn)行分析定位？

解決方案

概述

云原生監(jiān)控體系包括：Healthchecks、Metrics、Logging、Tracing。Healthchecks：健康檢查可以定期檢查某個(gè)應(yīng)用的存活狀態(tài)；Metrics：度量指標(biāo)監(jiān)控，在離散的時(shí)間點(diǎn)上產(chǎn)生數(shù)值點(diǎn)；Logging：日志監(jiān)控；Tracing：調(diào)用鏈監(jiān)控。

各種監(jiān)控工具適用場景如下圖所示：

健康檢查

微服務(wù)架構(gòu)，為了保證所有服務(wù)可用，當(dāng)服務(wù)發(fā)生問題時(shí)能及時(shí)摘除有問題的服務(wù)需要定期檢測服務(wù)可用性，即健康檢查。通常健康健康檢查包括TCP與HTTP兩種。即定時(shí)發(fā)送TCP或HTTP請求，根據(jù)響應(yīng)來確定服務(wù)是否可用。一般通過TCP定期請求來判定網(wǎng)絡(luò)層是否正常，而通過Http請求判斷應(yīng)用層是否正常。服務(wù)要配置好請求接口，檢測服務(wù)定期向指定的接口發(fā)送http請求，并根據(jù)接口響應(yīng)碼和響應(yīng)時(shí)間判斷。Spring boot的end port /health可以檢查應(yīng)用的健康狀態(tài)，舉例說，當(dāng)我們訪問 http://localhost:8088/health 時(shí)，可以看到 HealthEndPoint 給我們提供默認(rèn)的監(jiān)控結(jié)果，包含 磁盤檢測和數(shù)據(jù)庫檢測。

{

"status": "UP",

"diskSpace": {

"status": "UP",

"total": 398458875904,

"free": 315106918400,

"threshold": 10485760

},

"db": {

"status": "UP",

"database": "MySQL",

"hello": 1

}

}

容器監(jiān)控

容器監(jiān)控使用Prometheus-cAdvisor，cAdvisor是谷歌專為監(jiān)控容器性能狀態(tài)設(shè)計(jì)的一個(gè)開源工具，cAdvisor提供有Push和Pull兩種獲取性能數(shù)據(jù)的接口。Push接口指的是由cAdvisor主動將數(shù)據(jù)周期性的推送到遠(yuǎn)端的存儲服務(wù)中，Influxdb與cAdvisor的對接就是通過這個(gè)接口完成的。而Pull接口則允許外部訪問服務(wù)隨時(shí)主動從cAdvisor獲取到當(dāng)時(shí)時(shí)刻的性能數(shù)據(jù)，然后自行處理，Prometheus與cAdvisor的對接用的是這種方法。

基于容器的微服務(wù)監(jiān)控和原始的監(jiān)控是有很大區(qū)別的，因?yàn)榉?wù)的實(shí)例生存周期很短，分分鐘可能就會有容器的生滅。微服務(wù)的容器與宿主機(jī)的監(jiān)控離不開CPU、內(nèi)存、磁盤、網(wǎng)卡這些基礎(chǔ)的性能指標(biāo)，對于宿主機(jī)的監(jiān)控來說，我們可以依然使用原始的監(jiān)控方式，每個(gè)宿主機(jī)安裝一個(gè)代理來采集服務(wù)器的性能指標(biāo)，代理在采集性能指標(biāo)的時(shí)候可以打上時(shí)間戳和相應(yīng)的標(biāo)簽來區(qū)分不同性能指標(biāo)的數(shù)據(jù)維度（metric），然后將監(jiān)控?cái)?shù)據(jù)匯總到時(shí)間序列數(shù)據(jù)庫，里面的數(shù)據(jù)可以對接目前一些開源的組件來進(jìn)行可視化的展示，也可以對接報(bào)警服務(wù)（結(jié)合報(bào)警服務(wù)的報(bào)警策略）進(jìn)行報(bào)警。

容器的監(jiān)控自然就和宿主機(jī)不太一樣了，我們不能說給每個(gè)容器鏡像內(nèi)部都集成一個(gè)監(jiān)控代理（agent）,這樣的話侵入性太強(qiáng)，不易于維護(hù)。Prometheus有很多的Exporter可以用來采集監(jiān)控?cái)?shù)據(jù)，例如我們想采集Kubernetes上所有容器（pod）的性能指標(biāo)的話，Promethus可以通過直接配置多個(gè)Kubernetes ApiServer的Endpoints來監(jiān)控整個(gè)Kubernetes集群。

K8S監(jiān)控

K8S集群層面選擇使用Prometheus。集群層面的監(jiān)控又分為Node、K8S基礎(chǔ)組件、K8S資源對象三大類。

1.對于Node的監(jiān)控，Prometheus提供了node-exporter，可采集到CPU、內(nèi)存、磁盤IO、磁盤使用率、網(wǎng)絡(luò)包量、帶寬等數(shù)據(jù)；

2.K8S基礎(chǔ)組件類的kubelet、kube-apiserver、kube-controller-manager 和 kube-scheduler等，都提供了 metrics接口暴露自身的運(yùn)行時(shí)的監(jiān)控?cái)?shù)據(jù)，這些數(shù)據(jù)都可被部署在K8S集群中的Prometheus 直接拉取到；

3.結(jié)合cadvisor 和kube-state-metrics ，可直接采集到K8S中Pod的 CPU、內(nèi)存、磁盤 IO、網(wǎng)絡(luò) IO 等數(shù)據(jù)。由CoreOS開源的Kube-Prometheus項(xiàng)目，極大簡化了Prometheus的安裝部署運(yùn)維工作。

基于Kubernetes實(shí)現(xiàn)的微服務(wù)應(yīng)用級的監(jiān)控插件，如下圖：

在Kubernetes的master節(jié)點(diǎn)，也就是安裝apiserver的那臺服務(wù)器上運(yùn)行一個(gè)監(jiān)控插件，該插件可以通過一個(gè)kubernetes提供的官方客戶端來訪問apiserver,首先我們要告知插件要監(jiān)控哪個(gè)namespace下的哪個(gè)service，然后，插件通過和apiserver進(jìn)行交互獲取某個(gè)service下所有Pods的實(shí)例，插件會并發(fā)訪問所有pod提供的/metrics接口（Path可配）,并給每個(gè)pod的返回?cái)?shù)據(jù)（json格式，遵守一定的數(shù)據(jù)格式契約）打上pod_name的標(biāo)簽來標(biāo)識每個(gè)pod返回的metrics，打上pod_name標(biāo)簽的同時(shí)也會打上service_name的標(biāo)簽用來區(qū)分具體是哪個(gè)service的監(jiān)控?cái)?shù)據(jù)。

Kubernetes主要提供了如下5種服務(wù)發(fā)現(xiàn)模式和Prometheus進(jìn)行集成：Node、Pod、Endpoints、Service、Ingress。監(jiān)控K8S將使用Prometheus federation的形式，k8s集群外部的Prometheus從k8s集群中Prometheus拉取監(jiān)控?cái)?shù)據(jù)，外部的Prometheus才是監(jiān)控?cái)?shù)據(jù)的存儲。k8s集群中部署Prometheus的數(shù)據(jù)存儲層可以簡單的使用emptyDir，數(shù)據(jù)只保留24小時(shí)(或更短時(shí)間)即可，部署在k8s集群上的這個(gè)Prometheus實(shí)例即使發(fā)生故障也可以放心的讓它在集群節(jié)點(diǎn)中漂移。

1）創(chuàng)建namespace取名ns-monitor

2）在k8s中部署node-exporter

Node-exporter用于采集kubernetes集群中各個(gè)節(jié)點(diǎn)的物理指標(biāo)，比如：Memory、CPU等。可以直接在每個(gè)物理節(jié)點(diǎn)是直接安裝，這里我們使用DaemonSet部署到每個(gè)節(jié)點(diǎn)上，使用 hostNetwork: true 和 hostPID: true 使其獲得Node的物理指標(biāo)信息，配置tolerations使其在master節(jié)點(diǎn)也啟動一個(gè)pod。

#創(chuàng)建node-exporter.yml文件：

3-1）創(chuàng)建編輯rabc.yml。

rbac.yml定義了Prometheus容器訪問k8s apiserver所需的ServiceAccount和ClusterRole及ClusterRoleBinding。

3-2）創(chuàng)建編輯configmap.yml 進(jìn)行configmap中的prometheus的配置文件。

3-3）prometheus-deploy.yml定義Prometheus的部署    。

3-4）prometheus-svc.yml定義Prometheus的Service。

需要將Prometheus以NodePort, LoadBalancer或使用Ingress暴露到集群外部，這樣外部的Prometheus才能訪問它 。

3-5）使用yml文件創(chuàng)建對象。

kubectl create -f rbac.yml
      kubectl create -f configmap.yml
      kubectl create -f prometheus-deploy.yml
      kubectl create -f prometheus-svc.yml

4）配置配置Prometheus Federation

完成Kubernetes集群上的Prometheus的部署之后，下面將配置集群外部的Prometheus使其從集群內(nèi)部的Prometheus拉取數(shù)據(jù)。實(shí)際上只需以靜態(tài)配置的形式添加一個(gè)job就可以。

5）配置pushgateway

日志監(jiān)控

Fluentd是一個(gè)通用的信息收集、整理、轉(zhuǎn)發(fā)的流式數(shù)據(jù)處理工具。默認(rèn)情況下Docker會將所有容器輸出到系統(tǒng)控制臺的內(nèi)容重定向到以容器ID命名的一個(gè)本地目錄中，只需要定期采集所有這些目錄的內(nèi)容就能一字不漏的將容器的輸出捕獲出來，這種方式的侵入性很小，但由于是周期性的收集，日志在匯聚端（例如Kibana）的展示會有一定的延時(shí)，延時(shí)長度與日志收集的周期相關(guān)。相反的，如果使用Docker的日志驅(qū)動（啟動docker后臺服務(wù)時(shí)指定參數(shù)–log-driver=fluentd）將獲得實(shí)時(shí)性很好的匯聚端日志展示，但由于日志直接發(fā)送到了遠(yuǎn)端的Fluentd服務(wù)，會使得在本地主機(jī)上的docker logs命令失效。

兩種方式的共性在于：不論通過哪一種方式，收集到的日志都能夠以容器名稱、鏡像、標(biāo)簽等對容器使用十分友好的維度進(jìn)行檢索。Kubernetes 集群本身不提供日志收集的解決方案，我們采用fluentd-->kafka-->logstash-->elasticsearch-->kibana的方式，直接在應(yīng)用程序中將日志信息推送到采集后端。

調(diào)用鏈監(jiān)控

調(diào)用鏈定義：在系統(tǒng)完成一次業(yè)務(wù)調(diào)用的過程中，把服務(wù)之間的調(diào)用信息(時(shí)間、接口、層次、結(jié)果)打點(diǎn)到日志中，然后將所有的打點(diǎn)數(shù)據(jù)連接為一個(gè)樹狀鏈條就產(chǎn)生了一個(gè)調(diào)用鏈。跟蹤系統(tǒng)把過程中產(chǎn)生的日志信息進(jìn)行分析處理，將業(yè)務(wù)端到端的執(zhí)行完整的調(diào)用過程進(jìn)行還原，根據(jù)不同維度進(jìn)行統(tǒng)計(jì)分析；從而標(biāo)識出有異常的服務(wù)調(diào)用，能夠快速分析定界到出異常的服務(wù)；同時(shí)可根據(jù)數(shù)據(jù)統(tǒng)計(jì)分析系統(tǒng)性能瓶頸。

Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的機(jī)制。模型中包含的術(shù)語也很多，理解最主要的兩個(gè)即可：

Trace：一次完整的分布式調(diào)用跟蹤鏈路。

Span：跨服務(wù)的一次調(diào)用；多個(gè) Span 組合成一次 Trace 追蹤記錄。

下面通過一次用戶服務(wù)請求來完成調(diào)用鏈過程模擬：

左圖為一個(gè)和5臺服務(wù)器相關(guān)的一個(gè)服務(wù)，包括：前端（A），兩個(gè)中間層（B和C），以及兩個(gè)后端（D和E）。當(dāng)一個(gè)用戶（這個(gè)用例的發(fā)起人）發(fā)起一個(gè)請求時(shí)，首先到達(dá)前端，然后發(fā)送兩個(gè)RPC到服務(wù)器B和C。B會馬上做出反應(yīng)，但是C需要和后端的D和E交互之后再返還給A，由A來響應(yīng)最初的請求。右表示對應(yīng) Span 的管理關(guān)系。每個(gè)節(jié)點(diǎn)是一個(gè) Span，表示一個(gè)調(diào)用。至少包含 Span 的名、父 SpanId 和 SpanId。節(jié)點(diǎn)間的連線下表示 Span 和父 Span 的關(guān)系。所有的 Span 屬于一個(gè)跟蹤，共用一個(gè) TraceId。從圖上可以看到對前端 A 的調(diào)用 Span 的兩個(gè)子 Span 分別是對 B 和 C 調(diào)用的 Span，D 和 E 兩個(gè)后端服務(wù)調(diào)用的 Span 則都是 C 的子 Span。跟蹤系統(tǒng)根據(jù)用戶請求每次生成的全局唯一的ID（TraceId），TraceId 在span間傳遞，將不同服務(wù)的“孤立的”日志串在一起，重組還原出更多有價(jià)值的信息。如今調(diào)用鏈系統(tǒng)有很多實(shí)現(xiàn)，用的比較多的如 zipkin ，還有已經(jīng)加入 CNCF 基金會并且用的越來越多的 Jaeger。

調(diào)用鏈模型格式

為了能將一系列埋點(diǎn)串接成一個(gè)完整的調(diào)用鏈，并區(qū)分不同請求的調(diào)用鏈日志信息，同時(shí)信息中需要包含請求狀態(tài)與時(shí)長，對于不同業(yè)務(wù)應(yīng)用可能需要有特殊的信息記錄到日志中；所以調(diào)用鏈日志信息(Span)應(yīng)包含如下內(nèi)容：

一次業(yè)務(wù)請求調(diào)用鏈模型：

對于Trace而言，最基礎(chǔ)的能力是能夠記錄請求在多個(gè)服務(wù)之間調(diào)用的傳播、依賴關(guān)系并進(jìn)行可視化。而從Trace本身的數(shù)據(jù)特點(diǎn)而言，它是規(guī)則化、標(biāo)準(zhǔn)化且?guī)в幸蕾囮P(guān)系的訪問日志，因此可以基于Trace去計(jì)算并挖掘更多的價(jià)值。下面是SLS OpenTelemetry Trace的實(shí)現(xiàn)架構(gòu)，核心是通過數(shù)據(jù)編排計(jì)算Trace原始數(shù)據(jù)并得到聚合數(shù)據(jù)，并基于SLS提供的接口實(shí)現(xiàn)各類Trace的附加功能。例如：

1.依賴關(guān)系：這是絕大部分的Trace系統(tǒng)都會附帶的功能，基于Trace中的父子關(guān)系進(jìn)行聚合計(jì)算，得到Trace Dependency

2.服務(wù)/接口黃金指標(biāo)：Trace中記錄了服務(wù)/接口的調(diào)用延遲、狀態(tài)碼等信息，基于這些數(shù)據(jù)可以計(jì)算出QPS、延遲、錯(cuò)誤率等黃金指標(biāo)。

3.上下游分析：基于計(jì)算的Dependency信息，按照某個(gè)Service進(jìn)行聚合，統(tǒng)一Service依賴的上下游的指標(biāo)

4.中間件分析：Trace中對于中間件（數(shù)據(jù)庫/MQ等）的調(diào)用一般都會記錄成一個(gè)個(gè)Span，基于這些Span的統(tǒng)計(jì)可以得到中間件的QPS、延遲、錯(cuò)誤率。

告警相關(guān)：通常基于服務(wù)/接口的黃金指標(biāo)設(shè)置監(jiān)控和告警，也可以只關(guān)心整體服務(wù)入口的告警（一般對父Span為空的Span認(rèn)為是服務(wù)入口調(diào)用）。

Metrics：

• 通常都是range查詢，每次查詢某一個(gè)單一的指標(biāo)/時(shí)間線，或者一組時(shí)間線進(jìn)行聚合，例如統(tǒng)一某個(gè)應(yīng)用所有機(jī)器的平均CPU
• 時(shí)序類的查詢一般QPS都較高（主要有很多告警規(guī)則），為了適應(yīng)高QPS查詢，需要把數(shù)據(jù)的聚合性做好
• 對于這類數(shù)據(jù)都會有專門的時(shí)序引擎來支撐，目前主流的時(shí)序引擎基本上都是用類似于LSM Tree的思想來實(shí)現(xiàn)，以適應(yīng)高吞吐的寫入和查詢（Update、Delete操作很少）
• 同時(shí)可觀測性數(shù)據(jù)還有一些共性的特點(diǎn)，例如高吞吐寫入（高流量、QPS，而且會有Burst）、超大規(guī)模查詢特點(diǎn)、時(shí)間訪問特性（冷熱特性、訪問局部性等）。

業(yè)務(wù)調(diào)用鏈路監(jiān)控

Skywalking是一款比較優(yōu)秀的開源的應(yīng)用性能監(jiān)控工具，支持對分布式系統(tǒng)的監(jiān)控、跟蹤和診斷。它提供了如下的主要功能特性：

Service Topology監(jiān)控

調(diào)用鏈路監(jiān)控可以從兩個(gè)角度去看待。通過給服務(wù)添加探針并產(chǎn)生實(shí)際的調(diào)用之后，我們可以通過Skywalking的前端UI查看服務(wù)之間的調(diào)用關(guān)系。我們簡單模擬一次服務(wù)之間的調(diào)用。新建兩個(gè)服務(wù)，service-provider以及service-consumer，服務(wù)之間簡單的通過Feign Client 來模擬遠(yuǎn)程調(diào)用。

從圖中可以看到:

• 有兩個(gè)服務(wù)節(jié)點(diǎn)：provider & consumer
• 有一個(gè)數(shù)據(jù)庫節(jié)點(diǎn)：localhost【mysql】
• 一個(gè)注冊中心節(jié)點(diǎn)

consumer消費(fèi)了provider提供出來的接口。

一個(gè)系統(tǒng)的拓?fù)鋱D讓我們清晰的認(rèn)識到系統(tǒng)之間的應(yīng)用的依賴關(guān)系以及當(dāng)前狀態(tài)下的業(yè)務(wù)流轉(zhuǎn)流程。細(xì)心的可能發(fā)現(xiàn)圖示節(jié)點(diǎn)consumer上有一部分是紅色的，紅色是什么意思呢？

紅色代表當(dāng)前流經(jīng)consumer節(jié)點(diǎn)的請求有一段時(shí)間內(nèi)是響應(yīng)異常的。當(dāng)節(jié)點(diǎn)全部變紅的時(shí)候證明服務(wù)現(xiàn)階段內(nèi)就徹底不可用了。運(yùn)維人員可以通過Topology迅速發(fā)現(xiàn)某一個(gè)服務(wù)潛在的問題，并進(jìn)行下一步的排查并做到預(yù)防。

Skywalking Trace監(jiān)控

Skywalking通過業(yè)務(wù)調(diào)用監(jiān)控進(jìn)行依賴分析，提供給我們服務(wù)之間的服務(wù)調(diào)用拓?fù)潢P(guān)系、以及針對每個(gè)endpoint的trace記錄。

我們在之前看到consumer節(jié)點(diǎn)服務(wù)中發(fā)生了錯(cuò)誤，讓我們一起來定位下錯(cuò)誤是發(fā)生在了什么地方又是什么原因呢？

在每一條trace的信息中都可以看到當(dāng)前請求的時(shí)間、GloableId、以及請求被調(diào)用的時(shí)間。我們分別看一看正確的調(diào)用和異常的調(diào)用。

Trace調(diào)用鏈路監(jiān)控

圖示展示的是一次正常的響應(yīng)，這條響應(yīng)總耗時(shí)19ms，它有4個(gè)span：

• span1 /getStore = 19ms  響應(yīng)的總流轉(zhuǎn)時(shí)間
• span2 /demo2/stores = 14ms  feign client 開始調(diào)用遠(yuǎn)程服務(wù)后的響應(yīng)的總時(shí)間
• span3 /stores = 14ms 接口服務(wù)響應(yīng)總時(shí)間
• span4 Mysql = 1ms  服務(wù)提供端查詢數(shù)據(jù)庫的時(shí)間

這里span2和span3的時(shí)間表現(xiàn)相同，其實(shí)是不同的，因?yàn)檫@里時(shí)間取了整。

在每個(gè)Span中可以查看當(dāng)前Span的相關(guān)屬性。

• 組件類型: SpringMVC、Feign
• Span狀態(tài): false
• HttpMethod: GET
• Url:

http://192.168.16.125:10002/demo2/stores

這是一次正常的請求調(diào)用Trace日志，可能我們并不關(guān)心正常的時(shí)候，畢竟一切正常不就是我們期待的么！我們再來看下，異常狀態(tài)下我們的Trace以及Span又是什么樣的呢。

發(fā)生錯(cuò)誤的調(diào)用鏈中Span中的is error標(biāo)識變?yōu)閠rue，并且在名為Logs的TAB中可以看到錯(cuò)誤發(fā)生的具體原因。根據(jù)異常情況我們就可以輕松定位到影響業(yè)務(wù)的具體原因，從而快速定位問題，解決問題。通過Log我們看到連接被拒，那么可能是我們的網(wǎng)絡(luò)出現(xiàn)了問題（可能性小，因?yàn)閷?shí)際情況如果網(wǎng)絡(luò)出現(xiàn)問題我們連這個(gè)trace都看不到了），也有可能是服務(wù)端配置問題無法正確建立連接。通過異常日志，我們迅速就找到了問題的關(guān)鍵。

服務(wù)性能監(jiān)控

服務(wù)性能可以實(shí)現(xiàn)以下關(guān)鍵指標(biāo)：

1.關(guān)鍵業(yè)務(wù)指標(biāo)：響應(yīng)時(shí)間、Apex、吞吐率、錯(cuò)誤率

2.事務(wù)：耗時(shí)百分比、響應(yīng)時(shí)間、吞吐量、Apdex、錯(cuò)誤率、調(diào)用次數(shù)

3.數(shù)據(jù)庫：SQL耗時(shí)、平均響應(yīng)時(shí)間、吞吐率、SQL語句執(zhí)行計(jì)劃、代碼堆棧

4.NoSQL：Memcached/Redis/MogooDB的操作總耗時(shí)、平均響應(yīng)時(shí)間、吞吐率

5.外部應(yīng)用：HTTP/Thrif/Dubbo/Web Service的響應(yīng)時(shí)間占比、平均響應(yīng)時(shí)間、響應(yīng)總時(shí)間、吞吐率、錯(cuò)誤率

6.MQ：RabbitMQ/JMS/ActiveMQ生產(chǎn)者、消費(fèi)者的消息總數(shù)、每分鐘消息數(shù)、平均消息發(fā)送時(shí)間、總流量

7.JVM：內(nèi)存使用量、線程、HTTP會話