小浩負責公司存儲架構層,需要確保存儲層不會成為公司業務系統的性能瓶頸,讓數據讀寫達到最佳性能。那么小浩可以從哪些方面著手優化性能呢?他繼續求助系統架構師大雷。
小浩:雷哥,PD反饋公司系統最近響應很慢,需要排除客戶端、流量負載層、服務端、存儲層各個模塊哪里出現了瓶頸,我要負責存儲層的性能問題排查和性能優化,您有什么建議嗎?
大雷:那你首先需要和PD對齊性能的要求,從對象存儲OSS的角度來看,我們可以從以下維度來分析:
性能優化簡介
對存儲進行性能優化,有利于降低系統的不可服務時間,提高效率并改善用戶體驗。小浩結合大雷建議首先確定了應用系統的基準性能要求,系統在創建Bucket時已經考慮了區域因素(資源創建在更靠近業務的位置以減少延遲,比如部署應用的ECS在杭州地域,建議在同一地域創建Bucket),之后就開始研究優化性能的方法......
小浩反復琢磨架構師大雷給出的幾個建議:
(1)系統規劃階段:應合理規劃對象文件(object)的前綴;
(2)系統開發階段(使用阿里云OSS?SDK):業務通過并行請求實現高吞吐量、通過超時和重試機制可以在連接失敗時恢復;
(3)業務發展中(系統初期規劃時未考慮到)可能需要系統改造:使用CDN緩存頻繁訪問的靜態數據、利用傳輸加速應用到遠距離文件的上傳、下載;
小浩按照自己的理解對大雷的建議進行梳理之后,開始對以上優化手段進行研究。
使用前綴
小浩在開始研究前綴之前,對OSS?Object的命名模式進行回顧學習:
對象存儲命名模式
說明:dir1為示范,在實際業務生產過程中,可根據實際情況設置適當的前綴,比如設備類型、公司名等
為什么合理使用前綴能可以優化性能
在了解前綴時,小浩了解到分區,那什么是分區呢?分區的作用是什么呢?
分區是對象存儲OSS中的一個邏輯的概念,內部用來建立object?key索引的信息,每個object?key的索引都會在某一個分區內。隨著業務的發展,吞吐量的增長,OSS會按照文件名UTF-8編碼的順序對用戶數據進行自動分區,基于Range?Partition方式管理,OSS將海量對象的索引信息根據負載分布到不同的Range?Partition,不同的Range?Partition會分配給各個分區服務器來進行管理,并提供超大規模的并發請求、自動負載均衡。
下圖說明:p1-p4代表分區,dir1/ob1.txt等為示例代表對象鍵索引信息,不同對象鍵的索引信息會分布到不同的機器上,提供大規模的并發請求
了解完分區的概念,小浩理解得還是很模糊,設想如果沒有合理設置前綴,會產生什么結果呢?
不合理使用前綴,比如如果在命名上使用順序前綴(時間戳等),可能會出現大量文件索引集中存儲于存儲空間(Bucket)中的某個特定分區的情況,這樣就會造成:
-
該分區成為熱點分區,導致分區的I/O能力被耗盡,或超過系統速率限制系統自動限制請求速率。
-
熱點分區的存在會觸發系統進行持續的分區數據再均衡,這個過程可能會延長請求處理時間
這樣就導致所有的請求壓力落在了單分區上,此時整個集群的性能就是單臺機器的性能,未能充分利用OSS分布式的性能,那應該怎么辦呢?
合理使用前綴解決方案
示例:如果在存儲數據時使用日期與客戶ID生成文件名,路徑會包含順序時間戳前綴,此時就可能會造成分區熱點。
demo-share/2023-06-06/customer-1/file1
demo-share/2023-06-06/customer-2/file1
demo-share/2023-06-06/customer-3/file1
......
demo-share/2023-06-07/customer-1/file1
demo-share/2023-06-07/customer-2/file1
demo-share/2023-06-07/customer-3/file1
針對這種情況,需要避免object?key出現按順序索引的情況,我們可以對客戶ID計算哈希、文件名反轉等方式避免出現順序前綴,此處可以對客戶ID計算哈希(即MD5),并取若干字符的哈希前綴作為文件名的前綴。假如取4個字符的哈希前綴,這樣就可以把之前以日期的順序前綴轉變為隨機前綴,結果如下:
demo-share/8b11/2023-06-06/customer-1/file1
demo-share/s5c2/2023-06-06/customer-2/file1
demo-share/d2b3/2023-06-06/customer-3/file1
......
demo-share/9fc2/2023-06-07/customer-1/file1
demo-share/afv1/2023-06-07/customer-2/file1
demo-share/de4b/2023-06-07/customer-3/file1
到此小浩已掌握了存儲數據時合理設計前綴及其原理,此時小浩思考既然OSS是分布式系統,數據會落在不同的分區上,那提高并發是不是也能實現高吞吐量以提升性能呢?
并行請求
學習完上個課時中分區的概念,小浩明白了OSS可以利用其規模,將并行請求水平擴展到OSS服務終端節點,這種擴展方式有助于通過網絡將負載分布在多個路徑上(多個分區上),充分利用其分布式系統性能,從而獲得更高的速度和可靠性。
調整并發的請求數時,性能測量非常重要。建議從單個請求開始,測量當前的網絡帶寬以及其他資源的使用情況,從而識別瓶頸資源(即使用率最高的資源),以及可能的并發請求數。比如,如果一次處理一個請求導致CPU使用率為10%,則表明最多可以支持10個并發請求。
同時,OSS還提供了分片上傳向OSS實現并行寫入,分片上傳將待上傳的文件分成多個碎片(Part)分別上傳,上傳完成之后再調用接口將這些Part組合成一個Object。
分片上傳場景
-
大文件加速
當文件大小超過5?GB時,使用分片上傳可實現并行上傳多個Part以加快上傳速度。
-
網絡環境較差
網絡環境較差時,建議使用分片上傳。當出現上傳失敗的時候,您僅需重傳失敗的Part。
-
文件大小不確定
可以在需要上傳的文件大小還不確定的情況下開始上傳,這種場景在視頻監控等行業應用中比較常見。
分片上傳優勢
-
并行上傳part提高吞吐量
-
上傳失敗時,只需要重傳失敗的part
-
可調用接口進行終止、恢復上傳
更多詳情可參考分片上傳
超時退避重試
在研究退避重試之前,小浩思考什么情況下需要重試呢?重試解決了什么問題?
對象存儲OSS等大型分布式系統中,出現故障或超過產品限制的quota(賬號級QPS:10,000/s)等問題是不可避免的,這時可能會收到HTTP?503響應,當然也可能會收到少量的其他?HTTP?5XX系列錯誤響應,這時建議延遲幾秒進行重試。
為什么超時退避重試可以優化性能
超時可防止應用程序不合理地長時間等待,重試可幫助在發生故障時進行恢復,而退避可以提高利用率并減少系統堵塞問題。
超時:
超時時間是指客戶端將會等待請求完成的最長時間。
當應用程序等待一項請求完成的時間超過正常水平時,它持有該請求資源(例如內存或連接)的時間也會相應延長。設置超時時間可以減輕這種問題。
重試:
重試可讓客戶端在連接失敗/請求失敗后重新發送相同的請求,從而恢復連接。可以通過阿里云對象存儲OSS提供的默認重試機制或自定義重試策略在應用程序中構建重試邏輯。
退避:
當過載導致連接失敗/請求失敗時,頻繁發出重試也會增加負載,從而加劇過載問題。可能導致高負載問題在原始問題解決后仍然長時間存在,延誤恢復。
退避可以避免這種問題,例如您在2秒重試后,然后等4秒后再次重試等。
通過對象存儲OSS?SDK實時重試
對象存儲OSS提供了可配置重試次數、自定義重試策略、超時時間的ClientBuilderConfiguration,以下為JAVA?SDK如何配置超時時間,重試次數、自定義重試策略的示例。
小浩到這里已經掌握了超時退避重試的原理,學會了通過阿里云OSS提供的JAVA?SDK進行操作配置,但是如何根據業務情況配置合適的超時時間和重試次數呢,有沒有一些原則進行指導呢?
超時和重試的原則
要確定應用程序設置合理的重試次數和和超時時間,需要考慮以下問題:
-
當網絡連接變差或無法訪問?OSS服務時,OSS?SDK和應用程序應該如何響應?希望請求快速失敗還是適當繼續重試?
-
應用程序屬于要求低時延的程序還是可容忍較大延遲的后臺處理?
-
應用程序是部署在低延遲的可靠網絡上,還是部署在連接不可靠的遠程位置?
示例:
當您發出大量不同大小的請求時(例如超過128?MB),建議您測量吞吐量,并重試最慢的5%請求。當您發出較小的請求時(例如小于512?KB),時延通常在數十毫秒以內。建議您在2秒后重試GET或PUT操作。如果需要額外的重試,最好的做法是退出。例如,建議您在2秒后重試,然后等4秒后再次重試。
如果您的應用程序向OSS發出固定大小的請求,您期望每個請求的響應時間趨于一致。在這種情況下,推薦的策略是識別最慢的1%請求并重試。通常情況下,即使一次重試也能有效減少時延。
使用CDN緩存優化
小浩發現前面幾種優化手段更多的是從業務/應用程序著手,充分利用OSS的分布式系統的性能及SDK提供的能力來進行優化,剛好小浩公司的應用程序有大量的靜態資源供用戶訪問,結合大雷給的建議,小浩開始研究使用阿里云CDN緩存來優化性能。
那什么是CDN呢?CDN可以解決什么問題?
阿里云CDN是建立并覆蓋在承載網上,由不同區域的服務器組成的分布式網絡。CDN將源站資源緩存到全國各地的邊緣服務器,供用戶就近獲取,降低源站壓力。采用緩存可帶來低時延和高傳輸速率。使用緩存的應用程序向OSS發送的直接請求更少,請求成本也更低。
了解完其原理,小浩結合公司的網站架構,設計了增加CDN緩存的網站架構:
云上網站架構(使用CDN)
該架構實現了動態和靜態資源的分離,將OSS作為CDN的源站,通過CDN加速分發,使用戶通過CDN節點就近獲得數據,解決海量用戶訪問的性能瓶頸。
CDN使用操作
使用前提:
-
已開通阿里云CDN服務
-
已注冊有域名
操作步驟詳情參考CDN加速OSS訪問
使用OSS傳輸加速
OSS傳輸加速是利用全球分布的云機房,將全球各地用戶對您存儲空間的訪問,經過智能路由解析至就近的接入點,使用優化后的網絡及協議,為云存儲在互聯網上的上傳下載提供端到端的加速方案。
使用場景
-
? ?遠距離數據傳輸加速
????????全球性的論壇、Top在線協同辦公平臺等,部分客戶會因傳輸距離較遠導致上傳和下載體驗非常差。傳輸加速功能可以讓全球各地的客戶使用優化后的網絡來傳輸數據,極大地提升上傳和下載速度,讓不同地域的用戶都能有很好的訪問體驗;
????????2、大文件上傳、下載
通過互聯網遠距離上傳和下載大文件時,經常會因為網絡延遲過大而導致傳輸失敗。傳輸加速功能使用優化的互聯網傳輸鏈路、調優的協議棧與傳輸算法,可大幅減少遠距離互聯網傳輸超時的比例。同時還可以讓傳輸加速功能與分片上傳、斷點續傳下載結合,形成遠距離大文件上傳和下載的解決方案。
????????3、非靜態、非熱點數據下載加速
游戲、電商、社交應用的評論內容、企業門戶網站、金融類APP等,用戶的下載體驗直接影響產品競爭力和客戶留存率。傳輸加速功能作為專為OSS上傳、下載加速而設計的功能,可以最大限度利用客戶端的網絡能力,提升用戶的下載體驗。
OSS傳輸加速配置
步驟:
-
登錄OSS管理控制臺。
-
單擊Bucket?列表,然后單擊目標Bucket名稱。
-
在左側導航欄,選擇Bucket配置?>?傳輸加速。
-
在傳輸加速頁面,打開傳輸加速開關,然后在彈出的對話框單擊確定。
通過瀏覽器使用傳輸加速
通過瀏覽器訪問OSS時,將文件路徑的Endpoint字段需替換為傳輸加速Endpoint:
例如https://test.oss-cn-hangzhou.aliyuncs.com/myphoto.jpg?需改為https://test.oss-accelerate.aliyuncs.com/myphoto.jpg。如果文件訪問權限為私有,則還需要加上簽名信息。
傳輸加速訪問域名如下圖:
測試傳輸加速效果
阿里云對象存儲OSS提供了在線測試工具,測試結果如下圖:
至此小浩已掌握了多種性能優化手段,小浩休息片刻,回憶了整個的研究學習內容,發現使用CDN緩存優化和使用傳輸加速還是會出現一些混亂,小浩決定整理下兩者的區別:
CDN加速和OSS傳輸加速的區別
實現原理
-
CDN加速:是建立并覆蓋在承載網之上,由遍布全球的邊緣節點服務器群組成的分布式網絡。阿里云CDN能分擔源站壓力,避免網絡擁塞,確保在不同區域、不同場景下加速網站內容的分發,提高資源訪問速度。由CDN全球廣泛分布的邊緣節點緩存OSS存儲的靜態數據,從而實現客戶端從邊緣節點直接獲取數據的方式來實現訪問的加速。
-
OSS傳輸加速:利用全球分布的云機房,將全球各地用戶對您存儲空間(Bucket)的訪問,經過智能路由解析至就近的接入點,使用優化后的網絡及協議,為云存儲互聯網的上傳、下載提供端到端的加速方案。
資源加速場景介紹
OSS傳輸加速是針對OSS的鏈路加速,使用OSS傳輸加速后支持OSS提供的任意特性。CDN通過全球邊緣節點緩存OSS資源,加速同時可降低帶寬成本。OSS傳輸加速和CDN加速完全是兩個不同的產品,且應對的場景不同,詳情請參見CDN應用場景和傳輸加速場景。
-
如果您的業務是第三方數據源加速,推薦您使用CDN加速。
-
如果您的OSS資源需要進行多次下載的操作,并且不要求數據強一致性,推薦您使用CDN加速。
-
如果您的OSS資源需要加速下載,并且訪問量少,推薦您使用OSS傳輸加速。
-
如果您的OSS資源需要進行多次下載的操作,并且要求數據強一致性,推薦您使用OSS傳輸加速。
-
如果您的業務存儲的是動態資源,且數據更新頻繁,推薦您使用OSS傳輸加速。
-
如果您的業務存儲的是靜態資源,且更新少,推薦您使用CDN加速。
梳理完成之后,小浩瞬間對其原理和使用場景清晰了很多,接下來小浩準備繼續學習對象存儲運維保障相關的內容......
思考:如何監控存儲的運行狀態
小浩作為存儲層負責人,隨著對OSS的不斷深入,為了保障業務更平穩地運行,小浩思考到:
-
是否可以主動監控對象存儲OSS的運行狀態;
-
當有人操作存儲的文件時是否可以及時觸發事件通知;
-
能否把對資源的操作都能記錄下來,以滿足一些合規需求。
帶著上述問題,小浩繼續找系統架構師大雷請教。
小浩:雷哥,我想監控對象存儲OSS的運行狀態,我應該從哪里入手呢?
大雷:首先你需要明確需要哪些監控指標,確定這些指標后是否還需要有一些聚合的監控圖展示,以及這些可以幫助你解決什么業務問題。
小浩:我可以根據業務出現問題的時間段,查看這個時間段存儲的監控初步判斷存儲服務是否正常,后續還可以基于此為依據進行問題的診斷。
大雷:是的,出現問題之前,你是否也希望它能給你提供一些告警?順著這個脈絡你可以去深入研究一下OSS的監控指標,并熟練地掌握使用它。
小浩:明白了,雷哥,我這就開始去研究,有問題再向您請教。
監控指標及功能
小浩查看OSS文檔發現:
OSS監控服務提供系統基本運行狀態、性能以及計量等方面的監控數據指標,并且提供自定義報警服務,幫助用戶跟蹤請求、分析使用情況、統計業務趨勢,及時發現以及診斷系統的相關問題。
同時OSS提供的監控指標主要分為基礎服務指標、性能指標和計量指標,從用戶使用角度來看,OSS的指標分為用戶層級和存儲空間(Bucket)層級,小浩對這些指標進行總結梳理:
經過對監控指標的梳理,小浩逐漸理解了OSS監控指標的作用,通過對這些指標的監控為后續問題的診斷和故障的排查提供有力的數據支撐,接下來小浩準備嘗試使用OSS監控服務和告警服務。
監控服務使用操作
用戶層級監控
步驟:
-
登錄云監控控制臺。
-
在左側導航欄,單擊云產品監控。
-
篩選并進入對象存儲OSS監控頁面,如下圖。
? ? ?4、單擊用戶概況頁簽,查詢用戶監控詳情,如下圖。
? ? ?5、在用戶概況頁下,切換到“請求狀態詳情”,如下圖。
Bucket監控
步驟:
-
登錄云監控控制臺。
-
在左側導航欄,單擊云產品監控。
-
篩選并進入對象存儲OSS監控頁面,如下圖。
? ? ? ?4、在對象存儲OSS頁簽,會列出Bucket列表基本信息,包括Bucket名稱、地域、存儲大小、公網流出流量、Get類請求數和Put類請求數,如下圖。
? ? ? ? ? 5、單擊目標Bucket操作列的監控圖表,按照服務監控總覽、請求狀態詳情、計量參考、平均延時、最大延時、成功請求操作分類6個維度查詢相應的監控圖表,如下圖。
至此,小浩已經掌握了監控服務的使用,回顧前面梳理的oss監控指標體系,結合對監控服務的使用,發現監控服務可以很好地呈現出用戶/單個Bucket請求的狀態分布以及請求狀態詳情,可以有效幫助他監控資源的運行狀態。
報警服務使用操作
小浩在監控OSS資源使用情況時發現,監控服務只支持主動查看對應的監控信息,小浩需要當資源的監控指標達到一定閾值時能夠自動發送報警通知,這樣小浩就能及時監控異常數據并作出快速響應。
步驟:
-
登錄云監控控制臺。
-
在左側導航欄,選擇報警服務?>?報警規則。
-
在報警規則列表頁面,單擊創建報警規則,如下圖。
?
? ? ? 4、在創建報警規則頁面,設置報警規則相關參數。
查詢報警規則
步驟:
-
登錄云監控控制臺。
-
在左側導航欄,選擇報警服務?>?報警規則。
-
在報警規則列表頁面,會展示創建的報警規則,可以對報警規則詳情、報警歷史查看、修改報警規則等操作
至此,小浩已經完成了報警規則的配置,針對指標設定了一定的閾值,在達到一定的閾值后能及時自動報警,讓小浩能及時響應處理,降低對業務造成的影響,掌握了這些技能后,小浩對存儲層性能保障充滿了信心。
事件通知
小浩學習了監控用戶層級和單個Bucket運行狀態之后,突然想到研發人員提的需求,希望能對某些Object操作時收到系統通知,小浩發現監控服務并不能滿足此需求,于是帶著這個問題再次找到架構師大雷請教。
小浩:雷哥,我已初步了解對象存儲OSS的監控服務,現在我希望有人在操作文件時OSS能及時地發出通知,我看了下OSS自身是不支持的。
大雷:對的,你可以通過消息服務MNS來實現,通過創建事件的規則,當操作object的請求(比如DeleteObject、PutObject等)到OSS時,由消息服務MNS來推送事件通知。
小浩:原來是這樣,那我去研究下如何基于消息服務MNS來實現事件通知的。
大雷:去吧,你現在已經開始主動思考問題了,加油,有問題隨時來找我。
事件類型
小浩開始研究對Object操作的事件通知之前,梳理了OSS支持的事件類型如下:
小浩已經知道在創建OSS事件通知時,需要開通MNS服務,那什么是MNS服務呢?小浩查找到MNS的介紹文檔:
消息服務MNS文檔地址:什么是消息服務MNS_消息服務(MNS)-阿里云幫助中心
事件通知使用流程
小浩帶著對技術的極致熱情開始研究事件通知的使用流程,當有請求觸發了設置的事件規則時,消息是如何完成推送流程的呢?小浩一邊學習一邊梳理:
通過對流程梳理小浩發現,首先需要創建事件通知規則......
事件通知配置
步驟:
-
登錄OSS管理控制臺。
-
單擊Bucket列表,然后單擊目標Bucket名稱。
-
在左側導航欄,選擇數據處理?>?事件通知。
-
在事件通知頁面,單擊創建規則。
-
在創建規則面板,進行參數配置:
?
說明:事件規則配置完成后一般在10min后生效。
事件通知驗證
步驟:
-
小浩結合之前的oss所學內容,根據配置的刪除文件事件類型,小浩首先刪除了目標Bucket內一個名為111.jpg的文件;
-
登錄消息服務MNS控制臺。
-
在左側導航欄,單擊隊列列表。
-
在頂部菜單欄,選擇隊列所在地域。
-
在隊列列表頁面,單擊目標隊列或單擊目標隊列右側詳情。
-
在目標隊列詳情頁面會看到可用消息條數,單擊收發消息,如下圖。
? 7、進入收發消息快速體驗頁面,單擊接收消息,出現消費的消息,如下圖。
?
? 8、單擊消息對應的詳情,進入消息詳情,下滑頁面看到解碼后的消息內容,可驗證是否為刪除的文件,如下圖。
至此,小浩已完整的體驗了事件通知的配置、觸發、推送等整個流程,小浩舒展了一下身體,露出開心的笑容,小浩準備休息一下,繼續研究如何進行OSS日志管理......
日志管理
小浩前面提出的對象存儲OSS服務運維保障的三個問題已經解決了兩個,還剩一個問題:“是否可以把資源的操作記錄下來,以滿足一些合規需求”,小浩決定主動學習一下日志管理相關的內容,首先小浩思考:
-
有哪些日志管理方式?
-
操作日志會保存在哪里?
-
保存后的日志如何進行分析以輔助業務決策。
帶著上述幾個小問題,小浩開始了以下學習......
日志管理概述
訪問OSS的過程中會產生大量的日志,通過OSS提供的日志轉存或者使用日志服務SLS組件可以幫助用戶完成OSS訪問的操作審計、訪問統計、異常事件回溯和問題定位等工作,提升工作效率并可以更好地基于數據進行決策。
什么是日志轉存
OSS提供了可以將訪問OSS過程中的操作記錄到同一賬號下相同地域的Bucket內、以文件形式保存在自定義的前綴(目錄)下的功能。以下是日志轉存的開啟方式:
學習完小浩迫不及待地打開控制臺進行實操。
日志轉存配置
步驟:
-
登錄OSS管理控制臺。
-
單擊Bucket列表,然后單擊目標Bucket名稱。
-
在左側導航欄,選擇日志管理?>?日志轉存。
-
在日志轉存頁面,打開日志存儲開關,并設置日志存儲位置及日志前綴。
-
單擊保存。
小浩開啟日志轉存后,就興奮地開始對OSS進行訪問操作,上傳、下載了一些文件,然后去查看對應日志是否有生成,卻發現并未產生日志文件。小浩疑惑地查看產品文檔發現,日志轉存功能開啟后,需要以小時為單位生成日志文件寫入您指定的存儲空間(Bucket),開通日志轉存會立刻生效,但日志最晚?24?小時內生成,剛好小浩也想休息一下......
休息過后,小浩查看配置的Bucket發現日志已經生成,小浩想把日志下載下來看看日志的內容及格式。
日志轉存格式及內容示例
小浩下載了生成的日志文件,查看文件發現日志內容如下:
通過查看日志內容和格式小浩發現,日志文件及內容較少時,直接下載文件打開查看也很方便,但當大量日志產生時,人工查看及關鍵信息檢索的效率會大大降低,于是小浩繼續尋找是否有工具輔助查詢,經過查看文檔小浩找到了分析方法:
-
通過日志服務SLS對日志文件進行分析。對日志文件進行分析前,需要通過數據導入方式將OSS日志文件導入到日志服務。詳情可參考導入OSS數據。有關日志服務分析功能可參考分析概述。
-
OSS與日志服務SLS相結合,提供了實時日志查詢的能力。
實時日志查詢
學習完日志轉存功能之后,小浩發現OSS與日志服務SLS結合還提供了實時日志查詢的能力,可以在實際生產業務中帶來較大的效率提升。小浩發現通過OSS控制臺即可直接查詢OSS的訪問日志,輔助完成OSS訪問的操作審計、訪問統計、異常事件回溯和問題定位等工作,小浩開始嘗試實操起來......
實時日志查詢實操
首先需要先開通日志服務且進行云資源訪問授權
開通步驟如下圖:
開通SLS服務之后,OSS免費提供最近7天內的日志查詢,頁面如下:
日志聚類地址:如何開啟、查看、對比日志聚類_日志服務(SLS)-阿里云幫助中心
小浩已初步掌握了實時日志查詢的技能,但是小浩發現基于原始日志需要輸入查詢條件,他對查詢語法還需要進一步學習,詳情參考查詢語法。
小浩在研究實時日志查詢的過程中,發現日志服務SLS還提供了CloudLens?for?OSS功能,小浩的好奇心又啟動起來:
-
什么是CloudLens?
-
什么是CloudLens?for?OSS?
-
CloudLens?for?OSS能做什么?
帶著三個疑問,小浩又孜孜不倦地開啟了新的求知之路......
CloudLens?for?OSS
小浩帶著自己的三個疑問開始了學習:
CloudLens資料地址:CloudLens的原理及應用場景_日志服務(SLS)-阿里云幫助中心
CloudLens?for?OSS資料地址:CloudLens for OSS使用前須知_日志服務(SLS)-阿里云幫助中心
文檔中小浩了解到:
CloudLens基于日志服務構建統一的云產品可觀測能力,通過日志、指標、配置計量等數據的關聯分析,提供阿里云產品的用量分析、性能監控、安全分析、數據保護、異常檢測、訪問分析等服務,從成本、性能、安全、數據保護、穩定性、訪問分析六個維度,快速構建云產品的可觀測性,輔助用戶更好地使用云產品。
CloudLens?for?OSS是日志服務聯合阿里云OSS推出的,支持Bucket粒度的統一管理視圖,支持資源用量、訪問分析、異常檢測、安全分析等可視化分析能力,提供場景化運維管理,實現Bucket資產的可觀測性。
小浩設想,CloudLens?for?OSS也可以和前面學習到的運維保障互為補充,更好地保障OSS的狀態,也能保障公司業務的穩定,降低業務不可服務概率。那還等什么,開始研究用起來吧,小浩說干就干,開啟了使用CloudLens?for?OSS之旅......
如何登錄CloudLens?for?OSS
小浩登錄到日志服務SLS控制臺,按照提示開通日志服務SLS(若已開通,請忽略),進入SLS產品頁,找到云產品Lens--->CloudLens?for?OSS
開啟CloudLens?for?OSS
-
進入CloudLens?for?OSS,若未開啟服務,則會彈出開啟頁面
2、點擊立即開啟按鈕后彈出如下頁面,選擇存儲地域,日志服務自動在指定地域創建專屬Project,然后單擊立即開通
說明:由于CloudLens會默認幫用戶開啟中心化存儲的計量日志和時序監控數據,因此首次使用時會需要您選擇一個中心化地域,該地域一旦選擇,不允許修改,如果是公有云地域,建議優先選擇北京、上海、杭州、深圳等公有云相對較大的地域或Bucket比較集中的地域。
等待數分鐘后,小浩發現之前創建的Bucket已出現在接入管理的Bucket列表下。
說明:后臺對Bucket資產的同步時間,具體取決于用戶Bucket的數量,一般不超過半小時。
開啟功能后,小浩首先查看CloudLens提供了哪些功能,通過上圖左側菜單欄發現CloudLens?for?OSS?提供了接入管理、查詢分析、異常檢測、報表中心等功能,小浩對這些功能進行梳理:
功能梳理
那日志數據是如何接入的呢?
日志數據的接入
小浩查閱文檔發現:當前提供訪問明細日志(原實時日志)、計量日志、時序監控數據三種日志,其中訪問明細日志需要用戶按需手動開啟,其他兩種日志將會由后臺異步自動開啟,會有一定的延遲。
-
訪問明細日志:記錄相關OSS?Bucket的所有訪問日志及批量刪除日志時具體的刪除信息,實時采集,同時也包含計量日志。
-
計量日志:記錄特定OSS?Bucket每小時累計的計量數據。延遲時間為幾小時,用于輔助分析,默認免費開通。
-
時序監控數據:記錄10秒粒度的請求、延遲、流量等指標及5分鐘粒度的請求、流量等指標。默認免費開通。
了解完CloudLens?for?OSS提供的功能特性及日志接入流程后,小浩開始練習起來,首先小浩先手動接入訪問明細日志......
接入訪問明細日志
開通對應Bucket的訪問明細日志,可以查看詳細的訪問操作日志,可通過接入管理頁面開啟。
說明:有默認7天(每天900G)的免費額度,基本上都可以免費使用,可以放心開通。您也可以隨時關閉Bucket的訪問日志采集,關閉后對應Bucket新的訪問明細日志將不會再寫入日志庫,但不影響繼續查詢歷史數據。
存儲目標庫管理
訪問明細日志默認存儲7天,計量日志、時序監控數據默認存儲60天,如需調整存儲時間,可通過目標存儲庫進行修改。
說明:超過免費存儲時間將會產生費用,可根據實際需要評估。超過30天的數據支持開啟智能冷熱分層,費用更低,查詢分析會有10秒延遲,參考智能冷熱分層,如果是在免費周期內,您可無需開啟。
查詢分析日志
-
進入查詢分析-->訪問明細分析,得到根據條件查詢出來的日志信息如下圖:
說明:如果對應地域下沒有開啟過任意一個Bucket的訪問明細日志,則需要先行開啟(見接入訪問明細日志步驟),否則無法直接查詢。
2、進入查詢分析-->計量日志,可以查詢分析所有Bucket的計量數據,也可選擇過濾條件。
如果您不想或還不熟悉查詢分析語句,可以切換至交互模式,您動動鼠標即可自動構建需要的語句,詳情可參考Data?Explorer。
訪問明細日志交互模式下內置了一些高頻分析場景,可一鍵快速進行分析。
快速發現異常事件
CloudLens內置了一些比較常用的告警規則,可以快速發現Bucket使用過程中的一些異常情況,從而能夠及時響應,避免不必要的損失,詳情參考監控規則。
-
創建告警
進入異常告警-->告警管理,進入Bucket試圖的告警頁面,可以針對指定的Bucket配置需要的告警規則。
說明:告警名稱默認為規則名稱,一般保持默認即可,可以根據需要進行調整,其他默認閾值也都需要根據實際配置一個合理的值。
2、編輯行動策略
首次創建告警時,由于默認的行動策略為SLS?OSS內置行動策略,該內置策略關聯的用戶組下默認沒有用戶,需要用戶先創建用戶加入到該用戶組,同時默認的行動組只支持郵件,如果需要增加其他通知渠道也需要修改行動策略,具體操作可參考創建行動策略,也可以選擇創建新的行動策略。
?
????????3、創建用戶
如果用戶已創建,則直接將對應用戶加入用戶組即可,如下:
如果用戶未創建,可取消修改用戶組的對話框,點擊用戶組管理,選擇用戶管理-->創建用戶,詳情參考創建用戶。
用戶創建完成后,繼續點擊上方用戶管理標簽頁,切換到用戶組管理,修改用戶組,添加剛剛創建的用戶即可。
4、添加通知渠道
如需添加通知渠道,可參考通知渠道管理。
5、管理已有告警
如果需要修改已創建的告警規則,可通過操作列的告警管理進入。
可以編輯修改告警相關閾值參數等,也可以關閉/開啟告警,或直接刪除告警。
數據的可觀測性
CloudLens?for?OSS提供了一些核心數據的可視化報表,方便用戶對歷史、實時數據進行快速分析,主要涵蓋:
-
資源用量:提供OSS存儲、流量等基本維度的用量概覽,方便全局把握OSS使用情況。
-
訪問分析:從使用視角分析OSS各bucket的流量分布、訪問TOP分布等。
-
安全分析:暴露OSS?Bucket配置的風險點和高危Object操作。
各報表均支持選擇地域、存儲類型、Bucket作為過濾器進行過濾分析。
-
資源用量
進入報表中心-->資源用量,查看存儲量趨勢、寬帶等核心資源的使用等情況。
說明:流量/帶寬/請求等依賴中心化的時序監控數據,可以方便您全局分析Bucket的內外網出入流量、帶寬及讀寫請求等趨勢分析。
?
2、訪問分析
進入報表中心-->訪問分析,了解使用行為情況,輔助產品使用和業務運營分析。
下滑上圖頁面,可以看到流量top分析、請求top分析、文件請求top20等信息。
3、安全分析
進入報表中心-->安全分析,暴露不合理的配置和高危操作,給出優化建議。
-
Bucket?配置健康分析:主要針對Bucket的配置風險點提供優化建議,盡量避免可能的隱患
說明:從下圖可以看到配置健康分析中的風險類型,以及出現某類風險的Bucket數量及名稱
?
2、Object操作風險分析:依賴訪問明細日志,展示文件刪除等高危操作的執行情況。
至此,小浩已基本熟悉了CloudLens?for?OSS的操作流程如何查看資源訪問明細情況、資源用量情況、訪問分析、安全分析情況、告警大盤、告警管理等,同時也熟悉了其中各指標代表的含義,如何依據這些數據去分析具體問題等。
因為小浩之前有了解到使用SLS需要創建Project(項目),創建Logstore(日志庫)、MetrticStore(時序庫),但是參照文檔實操完成之后,小浩并未進行創建,又查看文檔資料發現,在開通CloudLens?for?OSS之后,日志服務會在專屬的Project中創建Logstore、MetricStore等,無需小浩再去創建。
到此小浩已掌握了對象存儲OSS大部分的功能,但在深入學習研究的過程中也發現了一些不足,對于OSS周邊生態產品比如SLS還不夠熟悉,經過本階段的學習,小浩對對象存儲OSS的研究暫告一段落,可以助力公司提高存儲運維效率及降本增效,同時小浩也暗自給自己加油打氣:“小浩,加油,下階段目標爭取熟練掌握日志服務SLS”。