1.?服務(wù)級別幫助你定義客戶滿意的程度和標(biāo)準(zhǔn)，以便你在解決性能、可擴(kuò)展性挑戰(zhàn)等事情與開發(fā)內(nèi)部工具之間做出時間權(quán)衡

2.?服務(wù)水平指標(biāo)（SLI）

2.1.?如何衡量客戶是否滿意

3.?服務(wù)水平目標(biāo)（SLO）

3.1.?為了確?？蛻魸M意，能允許SLI達(dá)到的最低限度是多少

3.2.?將特定的SLI視為健康服務(wù)的目標(biāo)范圍

3.2.1.?必須定義為給定時間范圍內(nèi)的一個具體值，以確保每個人都對SLO的含義保持一致的理解

3.2.2.?如果SLI的指標(biāo)是服務(wù)正常運(yùn)行的時間，那么在給定的時間范圍內(nèi)，運(yùn)行時間達(dá)到幾個9就是SLO

4.?服務(wù)水平協(xié)議（SLA）

4.1.?我同意的SLO會產(chǎn)生什么后果

4.1.1.?SLA是可選的

4.2.?與一個或多個業(yè)務(wù)客戶（付費(fèi)客戶，而非內(nèi)部利益相關(guān)者）簽訂的協(xié)議中包含的SLO，如果未滿足該SLA，將受到財務(wù)或其他處罰

4.3.?如果團(tuán)隊(duì)沒有達(dá)到其承諾的SLO，則不應(yīng)繼續(xù)進(jìn)行新特性的工作

5.?怎樣才能讓客戶滿意

5.1.?目標(biāo)是定義確?？蛻魸M意的最低標(biāo)準(zhǔn)

5.2.?選擇指標(biāo)和目標(biāo)的目的是隨時使用客觀指標(biāo)評估團(tuán)隊(duì)是否能夠利用新功能進(jìn)行創(chuàng)新，或者穩(wěn)定性是否有可能降至客戶可接受的水平以下，因此需要更多的關(guān)注和資源

5.3.?承諾的“9”越多，就越難實(shí)現(xiàn)，團(tuán)隊(duì)為實(shí)現(xiàn)這一承諾所花費(fèi)的工程時間也就越昂貴

5.4.?達(dá)到3個9的可用性

5.4.1.?一年中的3個9相當(dāng)于8個多小時的停機(jī)時間

5.4.2.?轉(zhuǎn)換到一周則只有10分鐘

5.5.?999圖

文章來源地址http://www.zghlxwxcb.cn/news/detail-652272.html

5.6.?工程時間是有限的資源

5.6.1.?選擇SLO時必須注意不要過于追求完美

5.6.2.?將工程時間花在新功能上

5.6.3.?將時間花在可恢復(fù)性和修復(fù)問題上

5.7.?不是產(chǎn)品中的所有特性都需要這么多個9才能讓客戶滿意

5.7.1.?隨著產(chǎn)品特性集的增長，將會有不同的SLI和SLO，具體取決于特定功能的影響或其帶來的收入

5.8.?區(qū)分不同用戶的需求，以便可以為他們提供合理的SLI和SLO

5.8.1.?檢測數(shù)據(jù)集何時成為不同用戶的不同查詢概要文件（query profile）的瓶頸，從而影響性能

6.?有效管理MySQL的一個關(guān)鍵點(diǎn)在于對數(shù)據(jù)庫的健康狀況進(jìn)行良好的監(jiān)控

7.?可用性

7.1.?能夠無錯誤地響應(yīng)客戶的請求

7.1.1.?明確成功的響應(yīng)

7.1.1.1.?200響應(yīng)代碼

7.1.2.?成功接受請求并承諾異步完成相關(guān)工作的響應(yīng)

7.1.2.1.?202已接受

7.2.?沒有要求必須做到100%，因?yàn)槲覀冊谝粋€不可避免失敗的世界中運(yùn)作

7.3.?不應(yīng)該用一個指標(biāo)來確定所有要求

7.4.?如果一個供應(yīng)商的競爭優(yōu)勢是分析MySQL性能的特定任務(wù)，那么付費(fèi)是可以給組織帶來回報的

7.4.1.?SolarWinds數(shù)據(jù)庫性能管理工具

7.5.?Percona監(jiān)控和管理工具是一個成熟的開源選項(xiàng)

7.5.1.?PMM

7.5.2.?儀表盤的組織是由Percona社區(qū)在監(jiān)控MySQL性能方面的長期經(jīng)驗(yàn)指導(dǎo)的

7.6.?將數(shù)據(jù)庫慢查詢?nèi)罩竞蚆ySQL PerformanceSchema的輸出信息發(fā)送到一個集中的位置，然后可以使用像pt-query-digest（Percona Toolkit包中的工具）這樣的成熟工具來分析日志，并更深入地了解數(shù)據(jù)庫實(shí)例在哪些方面花費(fèi)了時間

7.7.?在性能倒退的情況下，花費(fèi)生產(chǎn)之外的精力去調(diào)查“發(fā)生了什么”遠(yuǎn)比試圖重新創(chuàng)建一個模擬更大代碼路徑的基準(zhǔn)測試套件要具體得多

7.8.?可用性轉(zhuǎn)換為數(shù)據(jù)庫架構(gòu)的SLI和SLO時

7.8.1.?在處理不可避免的災(zāi)難性故障時，哪些功能是不可協(xié)商的，哪些功能是“最好擁有的”

7.8.2.?將哪些類型的失敗定義為“災(zāi)難性的”

7.8.3.?“降級功能”是什么樣子的

7.8.4.?給定一組可能的故障場景

7.9.?驗(yàn)證可用性的首選方法是從客戶端或遠(yuǎn)程端點(diǎn)來進(jìn)行訪問

7.10.?MySQL中有一個Threads_running狀態(tài)計數(shù)器可以作為可用性問題的關(guān)鍵指標(biāo)

7.11.?Thread_running與max_connections的差距，將此差距作為另一個數(shù)據(jù)點(diǎn)，以檢查正在進(jìn)行的工作是否過載

8.?監(jiān)控查詢延遲

8.1.?MySQL引入了許多長期需要的增強(qiáng)功能來跟蹤查詢運(yùn)行所需的時間

9.?監(jiān)控報錯

9.1.?MySQL客戶端在訪問運(yùn)行著的服務(wù)的過程中出現(xiàn)錯誤并不一定意味著服務(wù)遭到破壞

9.2.?間歇性錯誤，通過簡單地重試失敗的查詢就可以解決這些錯誤

9.3.?錯誤發(fā)生的頻率可能是潛在問題的關(guān)鍵指標(biāo)

9.3.1.?如果報錯的頻率加快，則是將要出現(xiàn)問題的跡象

9.4.?Lock wait timeout

9.4.1.?如果客戶端中該報錯急劇增加，可能是主節(jié)點(diǎn)上的行級鎖爭用在不斷擴(kuò)大，即事務(wù)不斷重試但仍然失敗

9.4.2.?可能是無法寫入的前兆

9.5.?Aborted connections

9.5.1.?如果客戶端中該報錯突然激增，可能表明客戶端和數(shù)據(jù)庫實(shí)例之間的某個訪問層出現(xiàn)了問題

9.5.2.?跟蹤這一點(diǎn)會導(dǎo)致大量客戶端重試，這會消耗資源

9.6.?too many connections

9.7.?操作系統(tǒng)級別的“cannot create new thread

9.8.?應(yīng)用程序創(chuàng)建和打開的連接數(shù)超過了數(shù)據(jù)庫服務(wù)器配置中允許的連接數(shù)，這個限制可能來自服務(wù)器的max_connections變量或者M(jìn)ySQL進(jìn)程被允許打開的線程數(shù)

10.?主動監(jiān)控

10.1.?不要將所有精力都集中在顯示事故發(fā)生的指標(biāo)上，而是應(yīng)花一些時間來監(jiān)控可以幫助預(yù)防事故的事情

10.2.?磁盤空間使用率增長

10.2.1.?設(shè)置多個閾值，其中較低的警告可以設(shè)置為僅在工作時間觸發(fā)，而較高的、更嚴(yán)重的值則作為對非工作時間隨叫隨到的告警

10.3.?連接數(shù)增長

10.3.1.?流量不斷增長時，數(shù)據(jù)庫服務(wù)器可以支持有限的連接池，這被配置為服務(wù)器參數(shù)max_connections

10.3.2.?應(yīng)用程序?qū)哟蜷_了大量未使用的連接，導(dǎo)致產(chǎn)生了毫無理由的連接過多的風(fēng)險

10.3.2.1.?連接的線程數(shù)（threads_connected）很高，但運(yùn)行的線程數(shù)（threads_running）仍然很低

10.3.3.?應(yīng)用程序?qū)诱诜e極地使用大量的連接，并有導(dǎo)致數(shù)據(jù)庫過載的風(fēng)險

10.3.3.1.?連接的線程數(shù)（threads_connected）和運(yùn)行的線程數(shù)（threads_running）都處于高值并持續(xù)增加

10.4.?復(fù)制延遲

10.4.1.?能夠被視為一種重要的SLI指標(biāo)，它能引起異常事故

10.4.2.?復(fù)制延遲可能會使數(shù)據(jù)看起來不一致

10.4.3.?即使復(fù)制延遲從未達(dá)到影響客戶體驗(yàn)的程度，如果偶然出現(xiàn)，這仍然是一個比較明顯的跡象，說明當(dāng)前配置下源節(jié)點(diǎn)寫入設(shè)備的性能要強(qiáng)于副本節(jié)點(diǎn)，這可能預(yù)示系統(tǒng)寫容量出現(xiàn)不足

10.5.?I/O使用率

10.5.1.?“盡可能多地在內(nèi)存中工作，因?yàn)檫@樣更快”

10.5.1.1.?數(shù)據(jù)庫工程師不斷努力的目標(biāo)之一

10.5.2.?不要從磁盤讀取太多的數(shù)據(jù)，否則查詢就只能等待那些寶貴的I/O周期

10.5.3.?iostat這樣的工具可以監(jiān)控I/O等待

10.5.4.?如果數(shù)據(jù)庫服務(wù)器有很多線程位于IOwait狀態(tài)，則需要監(jiān)控發(fā)出告警，這表示它們正在隊(duì)列中等待某些磁盤資源可用

10.6.?自增鍵空間

10.6.1.?自動遞增主鍵在默認(rèn)情況下被創(chuàng)建為有符號整數(shù)，并且可能會耗盡鍵空間

10.6.2.?為所有使用自增主鍵的表監(jiān)控剩余整數(shù)空間是一個簡單的操作，但幾乎可以肯定的一點(diǎn)是，它會在將來為你避免一些重大事故，因?yàn)榭梢蕴崆邦A(yù)測需要更大的鍵空間

10.6.3.?使用了PMM及其Prometheus導(dǎo)出器（exporter），那么已經(jīng)自帶監(jiān)控方法，你需要做的就是開啟collect.auto_increment.columns設(shè)置

10.7.?創(chuàng)建備份/恢復(fù)時間

10.7.1.?監(jiān)控將備份從文件恢復(fù)到運(yùn)行的數(shù)據(jù)庫（該數(shù)據(jù)庫自創(chuàng)建備份以來還一直在復(fù)制所有更改）需要多長時間

10.7.2.?功能分片（Functional sharding）是指將服務(wù)于特定業(yè)務(wù)功能的特定表分割到一個專用的集群中，以便單獨(dú)管理該數(shù)據(jù)集的正常運(yùn)行時間、性能甚至訪問控制

10.7.3.?水平分片（Horizontal sharding）是指當(dāng)數(shù)據(jù)集的大小超過了可以在單個集群中可靠地提供服務(wù)的規(guī)模時，將它拆分為多個集群，并從多個節(jié)點(diǎn)提供數(shù)據(jù)，這依賴于某種查找機(jī)制來定位所需的數(shù)據(jù)子集

11.?長期性能

11.1.?業(yè)務(wù)節(jié)奏

11.1.1.?業(yè)務(wù)節(jié)奏可能意味著峰值流量時間比“平均值”大幾個數(shù)量級，如果數(shù)據(jù)庫基礎(chǔ)架構(gòu)沒有準(zhǔn)備好，將產(chǎn)生很多不良結(jié)果

11.1.2.?業(yè)務(wù)周期可能會因業(yè)務(wù)所滿足的客戶需求而大不相同

11.1.3.?了解業(yè)務(wù)周期以及對業(yè)務(wù)收入、聲譽(yù)的影響至關(guān)重要

11.2.?業(yè)務(wù)的長期規(guī)劃

11.2.1.?為未來的容量做規(guī)劃

11.2.2.?預(yù)見何時需要重大改進(jìn)，何時增量修改就夠了

11.2.3.?為運(yùn)行基礎(chǔ)架構(gòu)增加的成本做規(guī)劃

11.3.?提高透明度，重點(diǎn)是跟蹤結(jié)果而不是輸出

11.4.?對平均值說不

11.4.1.?平均值的數(shù)據(jù)點(diǎn)圖很可能會讓你產(chǎn)生錯誤的安全感

11.5.?與百分位為友

11.5.1.?百分位依賴于在給定的時間范圍內(nèi)對數(shù)據(jù)點(diǎn)進(jìn)行排序，并根據(jù)目標(biāo)百分位移除最高值的數(shù)據(jù)點(diǎn)（例如，如果要尋找95百分位，則移除最頂端的5%）

11.6.?使用SLO來指導(dǎo)整體架構(gòu)

11.6.1.?在業(yè)務(wù)增長的同時保持良好一致的客戶體驗(yàn)不是一件容易的事

11.6.2.?隨著業(yè)務(wù)規(guī)模的增長，保持相同的SLO都將變得越來越困難，更不用說制定更雄心勃勃的SLO了

11.6.3.?你希望實(shí)現(xiàn)的SLO越嚴(yán)格，工作成本就越高，因?yàn)槊棵氲臄?shù)據(jù)庫事務(wù)數(shù)峰值或數(shù)據(jù)量也會呈數(shù)量級的方式增長

到了這里，關(guān)于讀高性能MySQL（第4版）筆記03_監(jiān)控的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！