久久久久偷看国产亚洲87,欧美性爱免费观看,日韩轮奸视频,黄色片三级网站,欧美操逼小电影,青草福利,蜜桃AV鲁一鲁,国产精品久久久久久久久免费桃花

監(jiān)控系統(tǒng)是運維體系乃至整個軟件產(chǎn)品生命周期中最重要的一環(huán)，完善的監(jiān)控可以幫助我們事前及時發(fā)現(xiàn)故障，事后快速追查定位問題。而在以微服務為代表的云原生架構(gòu)體系中，系統(tǒng)分為多個層次，服務之間調(diào)用鏈路復雜，系統(tǒng)中需要監(jiān)控的目標非常多，如果沒有一個完善的監(jiān)控系統(tǒng)就難以保證整體服務的持續(xù)穩(wěn)定。

監(jiān)控對象及分層

在實際場景中監(jiān)控系統(tǒng)按照監(jiān)控的對象及系統(tǒng)層次結(jié)構(gòu)，從底向上可以依次劃分為基礎(chǔ)層、中間層、應用層、業(yè)務層等多個層面的監(jiān)控。具體可如圖所示：

基礎(chǔ)層監(jiān)控就是對主機服務器(包括宿主機、容器)及其底層資源進行監(jiān)控，以保證應用程序運行所依賴的基礎(chǔ)環(huán)境的穩(wěn)定運行?；A(chǔ)層監(jiān)控主要有兩個方向：

資源利用：是對像I/O利用率、CPU利用率、內(nèi)存使用率、磁盤使用率、網(wǎng)絡負載等這樣的硬件資源進行監(jiān)控。避免因應用程序本身或其它特殊情況引起的硬件資源耗盡而出現(xiàn)的服務故障。
網(wǎng)絡通信：是對服務器之間的網(wǎng)絡狀態(tài)進行監(jiān)控。網(wǎng)絡通信是互聯(lián)網(wǎng)的重要基石，如果主機之間的網(wǎng)絡出現(xiàn)如延遲過大、丟包率高這樣的網(wǎng)絡問題，將會嚴重影響業(yè)務。

需要說明的是，在基于Kubernetes容器化技術(shù)的新型云原生基礎(chǔ)設(shè)施中，基礎(chǔ)層的監(jiān)控不僅要對宿主機本身進行監(jiān)控，也要對Kubernetes集群狀態(tài)及其容器資源使用情況進行監(jiān)控。這在后面我們構(gòu)建基于Kubernetes的基礎(chǔ)層監(jiān)控體系時將會具體介紹。

中間層監(jiān)控主要是指對諸如Nginx、Redis、MySQL、RocketMQ、Kafka等應用服務所依賴的中間件軟件的監(jiān)控，它們的穩(wěn)定也是保證應用程序持續(xù)可用的關(guān)鍵。一般來說特定的中間件軟件都會根據(jù)自身特點構(gòu)建針對性的監(jiān)控體系。

應用層監(jiān)控這里就是指對業(yè)務性服務程序的監(jiān)控，一般來說我們對應用程序監(jiān)控的關(guān)注點主要體現(xiàn)在以下幾個方面：

HTTP接口請求訪問。包括接口響應時間、吞吐量等；
JVM監(jiān)控指標。對于Java服務，還會重點關(guān)注GC時間、線程數(shù)、FGC/YGC耗時等JVM性能相關(guān)的指標；
資源消耗。應用程序部署后會消耗一定的資源，例如應用程序?qū)?nèi)存、CPU的消耗情況；
服務的健康狀態(tài)。例如當前服務是否存活，運行是否穩(wěn)定等；
調(diào)用鏈路。在微服務架構(gòu)中，由于調(diào)用鏈路變長，還需要重點監(jiān)控服務之間的調(diào)用關(guān)系和調(diào)用情況，避免局部上下游服務之間的鏈路故障引發(fā)系統(tǒng)全局性雪崩；

業(yè)務層監(jiān)控也是監(jiān)控系統(tǒng)所關(guān)注的一個重要內(nèi)容，在實際場景中如果你只是讓應用程序穩(wěn)定運行那肯定是遠遠不夠的。因此，我們常常會對具體業(yè)務產(chǎn)生的數(shù)據(jù)進行監(jiān)控，例如網(wǎng)站系統(tǒng)所關(guān)注的PV、UV等參數(shù)；后端如交易之類的系統(tǒng)我們則會關(guān)注訂單量、成功率等。

業(yè)務指標也是體現(xiàn)系統(tǒng)穩(wěn)定性的核心要素。任何系統(tǒng)，如果出現(xiàn)了問題，最先受到影響的肯定是業(yè)務指標。對于核心業(yè)務指標的設(shè)定因具體的業(yè)務和場景而異，所以對于業(yè)務層的監(jiān)控需要構(gòu)建具備業(yè)務特點的業(yè)務監(jiān)控系統(tǒng)。

常見的監(jiān)控指標類型

在指標類監(jiān)控系統(tǒng)中，通過統(tǒng)計指標可以感性地認識到整個系統(tǒng)的運行情況。出現(xiàn)問題后，各個指標會首先出現(xiàn)波動，這些波動會反映出系統(tǒng)是那些方面出了問題，從而可以據(jù)此排查出現(xiàn)問題的原因。下面我們分別來看下統(tǒng)計指標到底有哪些類型，以及常見的統(tǒng)計指標都有哪些，它是我們進一步理解指標類監(jiān)控系統(tǒng)的基礎(chǔ)。

從整體上看，常見的Metrics指標類型主要有：計數(shù)器（Counter）、測量儀（Gauge）、直方圖（Histogram）、摘要（Summary）這四類。它們的特點分別如下：

1.?計數(shù)器（Counter）

計數(shù)器是一種具有累加特性的指標類型，一般這個值為Double或者Long類型。例如常見的統(tǒng)計指標QPS、TPS等的值就是通過計數(shù)器的形式，然后配合一些統(tǒng)計函數(shù)計算得出的。

2.?測量儀（Gauge）

表示某個時間點，對某個數(shù)值的測量。測量儀和計數(shù)器都可以用來查詢某個時間點的固定內(nèi)容的數(shù)值，但和計數(shù)器不同，測量儀的值可以隨意變化，可以增加也可以減少。比如獲取Java線程池中活躍的線程數(shù)，使用的是ThreadPoolExecutor中的getActiveCount方法;此外，還有比較常見的CPU使用率、內(nèi)存占用量等具體指標都是通過測量儀獲取的。

3.?直方圖（Histogram）

直方圖是一種將多個數(shù)值聚合在一起的數(shù)據(jù)結(jié)構(gòu)，可以表示數(shù)據(jù)的分布情況。比如以常見的響應耗時舉例，可以把響應耗時數(shù)據(jù)分為多個桶（Bucket）,每個桶代表一個耗時區(qū)間，例如0～100毫秒、100～500毫秒，以此類推。通過這樣的形式，可以直觀地看到一個時間段內(nèi)的請求耗時分布，這將有助于我們理解耗時情況分布。

4.?摘要（Summary）

摘要與直方圖類似，表示的也是一段時間內(nèi)的數(shù)據(jù)結(jié)果，但是摘要反應的數(shù)據(jù)內(nèi)容不太一樣。摘要一般用于標識分位值，分位值其實就是我們常說的TP90、TP99等。例如有100個耗時數(shù)值，將所有的數(shù)值從低到高排列，取第90%的位置，這個位置的值就是TP90的值，如果這個桶對應的值假設(shè)是80ms，那么就代表小于等于90%位置的請求都≤80ms。

Kubernetes微服務監(jiān)控體系

前面我們從整體上描述了監(jiān)控系統(tǒng)分層以及理解指標類監(jiān)控系統(tǒng)所需要掌握的幾類常見的指標類型。接下來我們重點探討基于Kubernetes的微服務監(jiān)控體系。

從監(jiān)控對象及系統(tǒng)分層的角度看，監(jiān)控系統(tǒng)需要監(jiān)控的范圍是非常廣泛的，但從微服務監(jiān)控的角度來說，如果你的微服務部署完全是基于Kubernetes云原生環(huán)境的，那么我們需要關(guān)注的監(jiān)控對象主要就是Kubernetes集群本身以及運行其中的微服務應用容器。例如對容器資源使用情況，如CPU使用率、內(nèi)存使用率、網(wǎng)絡、I/O等指標的監(jiān)控。

當然，這并不是說像基礎(chǔ)層的物理機、虛擬機設(shè)備或者中間層軟件的監(jiān)控我們不需要關(guān)注，只是這部分工作一般會有專門的人員去維護。而如果使用的是云服務，那么云服務廠商大都已經(jīng)為我們提供了監(jiān)控支持。此外，對于基礎(chǔ)物理層及大部分中間軟件的監(jiān)控并不是本文所要表達的重點，所以也就不再做過多的實踐，大家對此有個全局的認識即可。

而回到以Kubernetes為載體的微服務監(jiān)控體系，雖然曾經(jīng)Kubernetes項目的監(jiān)控體系非常復雜，社區(qū)中也有很多方案。但是這套體系發(fā)展到今天，已經(jīng)完全演變成了以Prometheus項目為核心的一套統(tǒng)一方案。在本節(jié)的內(nèi)容中我們就將演示如何圍繞Prometheus來構(gòu)建針對Kubernetes的微服務監(jiān)控系統(tǒng)。

1.?Prometheus簡介

經(jīng)過行業(yè)多年的實踐和沉淀，目前監(jiān)控系統(tǒng)按實現(xiàn)方式主要可以分為四類：1)、基于時間序列的Metrics（度量指標）監(jiān)控；2）、基于調(diào)用鏈的Tracing（鏈路）監(jiān)控；3）、基于Logging（日志）的監(jiān)控；4）、健康性檢查(Healthcheck)。而在上述幾種監(jiān)控方式中Metrics監(jiān)控是其中最主要的一種監(jiān)控方式。

簡單理解Metrics的表現(xiàn)形式，就是在離散的時間點上產(chǎn)生的數(shù)值點[Time,Value],由某個指標組成的一組[Time,Value]數(shù)值點序列也被稱為時間序列，所以Metrics監(jiān)控也常常被稱為時間序列監(jiān)控。

如上所述，我們簡單闡述了指標系統(tǒng)的基本特點，而接下來要介紹的Prometheus就是一款基于時間序列的開源Metrics類型的監(jiān)控系統(tǒng)，它可以很方便地進行統(tǒng)計指標的存儲、查詢和告警。從整體上看Prometheus的系統(tǒng)結(jié)構(gòu)，如下圖所示：

從上圖中可以看出，Prometheus工作的核心，主要是使用Pull(拉取)的模式去收集被監(jiān)控對象的Metrics數(shù)據(jù)（監(jiān)控指標數(shù)據(jù)），然后由Prometheus服務器將收到的指標數(shù)據(jù)進行聚合后存儲到TSDB（時間序列數(shù)據(jù)庫，例如OpenTSDB、InfluxDB）中，以便后續(xù)根據(jù)時間自由檢索。

有了這套核心機制，Prometheus剩下的組件就主要是用來配合這套機制運行的了。比如PushGateway，它可以允許被監(jiān)控對象以Push的方式向Prometheus推送Metrics數(shù)據(jù)。而Alertmanager，則可以根據(jù)Metrics信息靈活地設(shè)置報警。

此外，Prometheus還提供了一套完整的PromQL查詢語言，通過其提供的HTTP查詢接口，使用者可以很方便地將指標數(shù)據(jù)與Grafana（可視化監(jiān)控指標展示工具）結(jié)合起來，從而靈活地定制屬于系統(tǒng)自身的關(guān)鍵指標監(jiān)控Dashboard（看板）。

2.?Prometheus Operator安裝部署

前面我們簡單介紹了Prometheus監(jiān)控系統(tǒng)的基本原理，接下來的內(nèi)容將以實操的方式演示如何使用Prometheus構(gòu)建一套針對Kubernetes集群的微服務監(jiān)控體系。

在實際的應用場景中，針對不同的監(jiān)控對象Prometheus的部署方式也會有所不同。例如要監(jiān)控的對象是底層的物理機，或者以物理機方式部署的數(shù)據(jù)庫等中間件系統(tǒng)，那么這種情況下一般也會將Prometheus監(jiān)控系統(tǒng)的部署環(huán)境放置在物理機下。

而如果針對的是Kubernetes集群的監(jiān)控，那么現(xiàn)在主流的方式是采用Promethues-Operator將Promethues部署到Kubernetes集群之中，這樣能以更原生的方式實施對Kubernetes集群及容器的監(jiān)控。這里所說的Promethues-Operator 是指專門針對Kubernetes的Promethues封裝包，它可以簡化Promethues的部署和配置。

接下來我們具體演示如何通過Promethues-Operator在Kubernetes中快速安裝部署Promethues（Kubernetes實驗環(huán)境可參考本專欄相關(guān)內(nèi)容），具體步驟如下：

1）、安裝Helm

在本次安裝過程中，將使用到Kubernetes的包管理工具Helm。Helm是Kubernetes的一種包管理工具，與Java中的Maven、NodeJs中的Npm以及Ubuntu的apt和CentOS的yum類似。主要用來簡化Kubernetes對應用的部署和管理。

首先從Github下載相應的Helm安裝包，具體命令參考如下：

#找到Github中Helm相關(guān)的發(fā)布包，參考鏈接如下
https://github.com/helm/helm/releases

#確定好相關(guān)版本后，將具體安裝版本下載至某個安裝了kubectl的節(jié)點?
wget?https://get.helm.sh/helm-v3.4.0-rc.1-linux-amd64.tar.gz

解壓，并將下載的可執(zhí)行Helm文件拷貝到文件夾/usr/local/bin下，命令如下：

tar?-zxvf?helm-v3.4.0-rc.1-linux-amd64.tar.gz?
#將下載的可執(zhí)行helm文件拷貝到文件夾/usr/local/bin下
mv?linux-amd64/helm?/usr/local/bin/

之后執(zhí)行helm version，如果能看到Helm版本信息，就說明Helm客戶端安裝成功了，具體如下:

$helm?version
version.BuildInfo{Version:"v3.4.0-rc.1",?
GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004",?
GitTreeState:"clean",?GoVersion:"go1.14.10"}

安裝完Helm客戶端后，由于一些公共Kubernetes包是在遠程倉庫中管理的，所以還需要添加helm charts（Helm中的Kubernetes安裝包又叫charts）官方倉庫，命令如下：

$helm?repo?add?stable?https://charts.helm.sh/stable

查看本地helm倉庫是否添加成功，命令如下：

$helm?repo?list
NAME??????URL??????????????????????????
stable????https://charts.helm.sh/stable

此時，查看Helm倉庫就能看到各種組件的charts列表了，命令效果如下：

$helm?search?repo?stable

NAME??????????????????????????????CHART?VERSION???APP?VERSION?????DESCRIPTION???????????????????????????????????????
stable/acs-engine-autoscaler??????2.1.3???????????2.1.1???????????Scales?worker?nodes?within?agent?pools????????????
stable/aerospike?
...

如上所示，此時通過“helm search”命令就可以查看到各種stable版本的Kubernetes安裝包了!

2)、Helm搜索Prometheus-Operator安裝包

在具體安裝Prometheus-Operator之前，我們先用“helm”命令搜索Prometheus相關(guān)的charts包，命令如下：

$?helm?search?repo?prometheus

具體搜索結(jié)果如下圖所示：

如上圖所示，我們可以看到Helm倉庫中可以搜索到版本為0.38.1的“stable/prometheus-operator”的安裝包。接下來就可以通過helm具體安裝了！

3)、Helm安裝Prometheus-Operator監(jiān)控系統(tǒng)

接下來啊，通過Helm具體安裝prometheus-operator監(jiān)控系統(tǒng)，命令如下：

#創(chuàng)建k8s名稱空間
kubectl?create?ns?monitoring

#通過helm安裝promethues-operator監(jiān)控系統(tǒng)
helm?install?promethues-operator?stable/prometheus-operator?-n?monitoring

執(zhí)行安裝命令后，輸出結(jié)果如下：

WARNING:?This?chart?is?deprecated
manifest_sorter.go:192:?info:?skipping?unknown?hook:?"crd-install"
manifest_sorter.go:192:?info:?skipping?unknown?hook:?"crd-install"
manifest_sorter.go:192:?info:?skipping?unknown?hook:?"crd-install"
manifest_sorter.go:192:?info:?skipping?unknown?hook:?"crd-install"
manifest_sorter.go:192:?info:?skipping?unknown?hook:?"crd-install"
manifest_sorter.go:192:?info:?skipping?unknown?hook:?"crd-install"
NAME:?promethues-operator
LAST?DEPLOYED:?Mon?Oct?26?10:15:45?2020
NAMESPACE:?monitoring
STATUS:?deployed
REVISION:?1
NOTES:
*******************
***?DEPRECATED?****
*******************
*?stable/prometheus-operator?chart?is?deprecated.
*?Further?development?has?moved?to?https://github.com/prometheus-community/helm-charts
*?The?chart?has?been?renamed?kube-prometheus-stack?to?more?clearly?reflect
*?that?it?installs?the?`kube-prometheus`?project?stack,?within?which?Prometheus
*?Operator?is?only?one?component.

The?Prometheus?Operator?has?been?installed.?Check?its?status?by?running:
??kubectl?--namespace?monitoring?get?pods?-l?"release=promethues-operator"

Visit?https://github.com/coreos/prometheus-operator?for?instructions?on?how
to?create?&?configure?Alertmanager?and?Prometheus?instances?using?the?Operator.

執(zhí)行完安裝命令后，查看具體的Kubernetes Pods信息，命令如下：

$?kubectl?get?po?-n?monitoring

NAME?????????????????????????????????????????????????????READY???STATUS????RESTARTS???AGE
alertmanager-promethues-operator-promet-alertmanager-0???2/2?????Running???0??????????5m42s
prometheus-promethues-operator-promet-prometheus-0???????3/3?????Running???1??????????5m31s
promethues-operator-grafana-5df74d9cb4-5d475?????????????2/2?????Running???0??????????6m53s
promethues-operator-kube-state-metrics-89d8c459f-449k4???1/1?????Running???0??????????6m53s
promethues-operator-promet-operator-79f8b5f7ff-pfpbl?????2/2?????Running???0??????????6m53s
promethues-operator-prometheus-node-exporter-6ll4z???????1/1?????Running???0??????????6m53s
promethues-operator-prometheus-node-exporter-bvdb4???????1/1?????Running???0??????????6m53s

如上所示，可以看到Prometheus監(jiān)控系統(tǒng)相關(guān)的組件都以Pod的方式運行在了Kubernetes集群中。

Prometheus監(jiān)控效果演示

通過前面的實際操作，我們通過Helm的方式已經(jīng)將Prometheus Operator安裝包部署在了Kubernetes集群之中。而此時的Prometheus實際上就已經(jīng)開始發(fā)揮作用，并采集了各類Kubernetes的運行指標信息?？梢酝ㄟ^Promethues內(nèi)置的監(jiān)控界面對此進行查看，具體步驟如下：

查看Kubernetes中查看內(nèi)置監(jiān)控界面所在的Pod節(jié)點，命令如下：

kubectl?-n?monitoring?get?svc

使用nodeport方式將promethues-operator內(nèi)置界面服務暴露在集群外，并指定使用30444端口，命令如下：

kubectl??patch?svc?promethues-operator-promet-prometheus?-n?monitoring?-p?'{"spec":{"type":"NodePort","ports":[{"port":9090,"targetPort":9090,"nodePort":30444}]}}'
service/promethues-operator-promet-prometheus?patched

此時在瀏覽器中輸入Pod節(jié)點所在的宿主機IP+端口地址，URL示例如下：

http://10.211.55.11:30444/graph

此時就可以看到Promethues內(nèi)置的監(jiān)控可視化界面了，效果如下圖所示：

而如果此時以PromeQL的方式查看一個具體指標，以“http_requests_total”為例，展示效果如圖所示：

由此說明，此時Promethues監(jiān)控系統(tǒng)已經(jīng)開始運行，并采集了相關(guān)Metrics指標數(shù)據(jù)！

Grafana可視化監(jiān)控系統(tǒng)

Grafana是一個強大的跨平臺的開源度量分析和可視化工具，可以將采集的指標數(shù)據(jù)進行定制化的圖形界面展示,經(jīng)常被用作為時間序列數(shù)據(jù)和應用程序分析的可視化。Grafana支持多種數(shù)據(jù)源，如InfluxDB、OpenTSDB、ElasticSearch以及Prometheus。

前面我們在Kubernetes中安裝部署Prometheus-Operator時，實際上Grafana就已經(jīng)被集成并運行了，可以通過Kubernetes的相關(guān)命令查詢Grafana的實際運行Pod，并將其Web端口對外進行暴露，具體如下：

#查看服務節(jié)點信息
kubectl?-n?monitoring?get?svc

#使用nodeport方式將promethues-operator-grafana暴露在集群外，指定使用30441端口
kubectl??patch?svc?promethues-operator-grafana?-n?monitoring?-p?'{"spec":{"type":"NodePort","ports":[{"port":80,"targetPort":3000,"nodePort":30441}]}}'

需要注意由于Grafana的應用運行的默認端口為80，為避免實驗環(huán)境沖突，這里映射時將目標容器端口指定為3000，并最終將節(jié)點端口映射為30441。完成后，瀏覽器輸入URL：

#IP地址為映射命令執(zhí)行時所在的節(jié)點
http://10.211.55.11:30441

如果映射正常，此時會返回Grafana可視化圖形界面的登錄界面，如圖所示：

這里缺省登錄賬號密碼為：admin/prom-operator。輸入后可進入Grafana主界面如下圖所示：

可以看到部署完成的Grafana已經(jīng)默認內(nèi)置了許多針對Kubernetes平臺的企業(yè)級監(jiān)控Dashboard，例如針對Kubernetes集群組件的“Kubernetes/API server”、“Kubernetes/Kubelet”，以及針對Kubernetees計算資源的“Kubernetes/Compute Resources/Pod”、“Kubernetes/Compute Resources/Workload”等等。

這里我們找一個針對Kubernetes物理節(jié)點的“Nodes”監(jiān)控Dashboard，點擊打開后看到的監(jiān)控效果如下圖所示：

上圖所示的Dashboard中展示了Kubernetes集群所在的各物理節(jié)點CPU、負載、內(nèi)存、磁盤I/O、磁盤空間、網(wǎng)絡傳輸?shù)扔布Y源的使用情況。從這些豐富的視圖可以看出Grafana強大的監(jiān)控指標可視化能力！

后記

本文給大家從理論到實踐簡單介紹了Kubernetes微服務監(jiān)控體系的構(gòu)建步驟，希望能夠?qū)Υ蠹覍W習Kubernetes有所幫助。目前以Kubernetes為代表的容器化技術(shù)已經(jīng)成為現(xiàn)代軟件應用發(fā)布的標準方式，作為一名普通研發(fā)人員，對Kubernetes的學習將有助于我們更深入的理解整體軟件系統(tǒng)的構(gòu)建原理，也是我們進階提升必不可少的知識儲備！在本公眾號的《Devops專欄》中匯總了關(guān)于Kubernetes學習的相關(guān)文章，感興趣的朋友可以進來看看！

—————END—————