建站
咨詢
售后
建站咨詢
新聞中心
隨著企業(yè)運(yùn)營(yíng)數(shù)據(jù)的不斷增長(zhǎng)，數(shù)據(jù)庫成為了承載數(shù)據(jù)的核心存儲(chǔ)介質(zhì)。然而，在大量數(shù)據(jù)存儲(chǔ)與快速查詢的同時(shí)，數(shù)據(jù)庫日志的復(fù)雜性不斷增加也成為數(shù)據(jù)庫管理員的煩惱。
創(chuàng)新互聯(lián)專注于望謨網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供望謨營(yíng)銷型網(wǎng)站建設(shè)，望謨網(wǎng)站制作、望謨網(wǎng)頁設(shè)計(jì)、望謨網(wǎng)站官網(wǎng)定制、小程序制作服務(wù)，打造望謨網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供望謨網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。
為解決這一難題，數(shù)據(jù)庫日志分析技術(shù)應(yīng)運(yùn)而生。本文將，為讀者提供一份指引。
1. 數(shù)據(jù)庫日志的基本概念
數(shù)據(jù)庫日志是對(duì)數(shù)據(jù)庫中所有操作的詳細(xì)記錄，包括對(duì)表的創(chuàng)建、修改和刪除，對(duì)記錄的增、刪、改等操作。日志通常由兩個(gè)部分組成：操作日志和恢復(fù)日志。
操作日志記載了每一個(gè)操作對(duì)數(shù)據(jù)庫的影響，例如修改了哪一個(gè)表格中的哪些數(shù)據(jù)、向表格中插入了哪些數(shù)據(jù)、刪除了哪些數(shù)據(jù)?；謴?fù)日志則用于恢復(fù)操作發(fā)生前的狀態(tài)。
在實(shí)際應(yīng)用中，數(shù)據(jù)庫日志的數(shù)量和大小與業(yè)務(wù)數(shù)據(jù)規(guī)模和工作負(fù)載有關(guān)。特別是在關(guān)鍵業(yè)務(wù)場(chǎng)景下，數(shù)據(jù)庫日志越來越大，其內(nèi)容也越來越復(fù)雜，這時(shí)候數(shù)據(jù)庫管理員需要通過分析日志，以便及時(shí)發(fā)現(xiàn)潛在問題，迅速做出調(diào)整。
2. 數(shù)據(jù)庫日志分析的重要性
數(shù)據(jù)庫日志分析是一項(xiàng)重要的任務(wù)，其目的在于幫助數(shù)據(jù)庫管理員識(shí)別潛在的問題，以優(yōu)化數(shù)據(jù)庫的性能和可用性。下面是數(shù)據(jù)庫日志分析的重要性：
（1）避免數(shù)據(jù)丟失
數(shù)據(jù)庫日志記錄了對(duì)數(shù)據(jù)庫的每一個(gè)操作，包括對(duì)表的創(chuàng)建、修改和刪除，對(duì)記錄的增、刪、改等操作。這有助于管理員快速恢復(fù)數(shù)據(jù)，減少數(shù)據(jù)丟失。
（2）優(yōu)化數(shù)據(jù)庫性能
通過分析日志中的數(shù)據(jù)，管理員可以發(fā)現(xiàn)哪些查詢或事務(wù)開銷非常高，并采取相應(yīng)的優(yōu)化措施，以提高數(shù)據(jù)庫性能。
（3）監(jiān)控?cái)?shù)據(jù)庫安全
數(shù)據(jù)庫日志分析可以監(jiān)測(cè)非授權(quán)的數(shù)據(jù)訪問、SQL注入攻擊、錯(cuò)誤登錄等問題。管理員可以通過日志分析快速發(fā)現(xiàn)問題，并及時(shí)采取防范措施。
3. 數(shù)據(jù)庫日志分析的核心技術(shù)
數(shù)據(jù)庫日志分析的核心技術(shù)主要包括數(shù)據(jù)采集、解析、存儲(chǔ)、分析和可視化五個(gè)部分。
（1）數(shù)據(jù)采集
數(shù)據(jù)采集是數(shù)據(jù)庫日志分析的之一步。這一過程通常使用日志采集器來實(shí)現(xiàn)，該工具可以自動(dòng)反復(fù)收集日志數(shù)據(jù)，以便管理員可以對(duì)日志進(jìn)行分析和審計(jì)。唯有采集到數(shù)據(jù)，才能進(jìn)行后續(xù)操作。
（2）解析
解析是日志分析的第二步，該過程主要涉及將日志數(shù)據(jù)轉(zhuǎn)換成容易理解的格式。例如，將SQL命令從二進(jìn)制日志轉(zhuǎn)換成文本格式，以便管理員可以查看、分析和發(fā)送SQL。
（3）存儲(chǔ)
存儲(chǔ)是指將日志數(shù)據(jù)存儲(chǔ)在中央倉庫中，以供未來分析和審計(jì)。數(shù)據(jù)庫管理員的重要使命之一是保護(hù)日志數(shù)據(jù)安全，以免泄漏數(shù)據(jù)庫機(jī)密。
（4）分析
分析是日志分析的關(guān)鍵步驟，這其中包括識(shí)別潛在問題、分析占用資源的查詢和事務(wù)、分析安全事件。管理員可以使用日志分析工具進(jìn)行分析，如：LogStash、ELK、Graylog等。
（5）可視化
可視化是最后一步，這需要將各項(xiàng)分析結(jié)果展示給管理員。通常，將其表示在 Dashboard 和報(bào)告中，這可以讓管理員很容易查看和理解分析結(jié)果。這一步驟有助于數(shù)據(jù)庫管理員了解數(shù)據(jù)庫的狀況，同時(shí)也可以向管理層匯報(bào)數(shù)據(jù)庫的性能和安全情況。
4. 數(shù)據(jù)庫日志分析的實(shí)踐
下面我們將以ELK為例，介紹日志分析的實(shí)踐過程。
在使用ELK進(jìn)行日志分析之前，您需要安裝以下軟件：
– Elasticsearch – 用于存儲(chǔ)數(shù)據(jù)和搜索。
– Logstash – 用于采集數(shù)據(jù)并將其傳送到Elasticsearch。
– Kibana – 用于可視化數(shù)據(jù)，并將數(shù)據(jù)從 Elasticsearch 檢索。
在ELK安裝之后，您首先需要配置Logstash，以安裝數(shù)據(jù)庫的日志收集器插件，然后將數(shù)據(jù)發(fā)送到 Elasticsearch。
在分析數(shù)據(jù)之前，您需要先配置Elasticsearch，以便它可以搜索和分析數(shù)據(jù)。
您可以使用Kibana進(jìn)行數(shù)據(jù)可視化，運(yùn)用Dashboard、圖形等方式對(duì)數(shù)據(jù)進(jìn)行分析。
5. 結(jié)論
數(shù)據(jù)庫日志分析對(duì)于維護(hù)和優(yōu)化數(shù)據(jù)庫的性能是至關(guān)重要的。通過數(shù)據(jù)采集、解析、存儲(chǔ)、分析和可視化，管理員可以發(fā)現(xiàn)數(shù)據(jù)庫中隱藏的問題并及時(shí)解決。
若你正遇到日志分析問題，不妨試試ELK或其他類似工具，這可以大幅簡(jiǎn)化日志分析程序，同時(shí)幫您提高數(shù)據(jù)庫的性能和可用性。將這些步驟納入到日?；顒?dòng)中，您可以讓數(shù)據(jù)庫更可靠、可預(yù)測(cè)、并在有限的預(yù)算下，為組織提供更多的價(jià)值。
相關(guān)問題拓展閱讀：
- 數(shù)據(jù)日志是什么？
- oracle數(shù)據(jù)庫的警告日志如何查看
數(shù)據(jù)日志是什么？
269-什么是凳陪數(shù)據(jù)遲答庫日棗旦蠢志
希望對(duì)你有幫助!Oracle數(shù)據(jù)庫的日志有：Redologfile—-重做日志Archivelogfile—-歸檔日志Tracefile—-跟蹤日答碧虛志backupground_dump_dest—-后臺(tái)進(jìn)程跟蹤core_dump_dest—-Oracle內(nèi)核日志User_dump_dest—-用戶跟蹤（服務(wù)器進(jìn)程）簡(jiǎn)稱日志一般指的是聯(lián)機(jī)重做日志文件（Redlog）。主要功能是恢復(fù)異常關(guān)閉的數(shù)據(jù)庫和保證數(shù)據(jù)的完整性、一致性。還有可恢復(fù)近期丟失的數(shù)據(jù)（這要看重做日志文件的容量）。重做文件的原理是：把DML（Insert、Update、清燃Delete）語句所處理的前后記錄都寫入重做日志慧姿文件中。當(dāng)數(shù)據(jù)庫的數(shù)據(jù)出故障時(shí)利用重做日志文件中的數(shù)據(jù)重新運(yùn)行一次之前做過的業(yè)務(wù)，以此來恢復(fù)數(shù)據(jù)庫中除了故障的數(shù)據(jù)。重做日志文件至少要有兩組，一般是三組。寫滿之一組寫第二組，寫滿第二組寫第三組，寫滿第三組返回覆蓋寫之一組，以此類推。
oracle數(shù)據(jù)庫的警告日志如何查看
告警日志文件是一類特殊的跟蹤文件（trace file）。告警日志文件命名爛察一般為alert_.log，其中SID為ORACLE數(shù)據(jù)庫脊歷空實(shí)例名稱。數(shù)據(jù)庫告警日志是櫻瞎按時(shí)間順序記錄message和錯(cuò)誤信息。
?測(cè)試環(huán)境中出現(xiàn)了一個(gè)異常的告警現(xiàn)象：一條告警通過 Thanos Ruler 的 HTTP 接口觀察到持續(xù)處于 active 狀態(tài)，但是從 AlertManager 這邊看這條告警為已解決狀態(tài)。按照 DMP 平臺(tái)的設(shè)計(jì)，告警已解決指的是告警上設(shè)置的結(jié)束時(shí)間已經(jīng)過了當(dāng)前時(shí)間。一條發(fā)送至 AlertManager 的告警為已解決狀態(tài)有三種可能：1. 手動(dòng)解決了告警2. 告警只產(chǎn)生了一次，第二次計(jì)算告警規(guī)則時(shí)會(huì)發(fā)送一個(gè)已解決的告警3. AlertManager 接收到的告警會(huì)帶著一個(gè)自動(dòng)解決時(shí)間，如果還沒到達(dá)自動(dòng)解決時(shí)間，則將該時(shí)間重置為 24h 后首先，因?yàn)榱私獾綔y(cè)試環(huán)境沒有手動(dòng)解決過異常告警，排除之一條；其次，由于該告警持續(xù)處于 active 狀態(tài)，所以不會(huì)是因?yàn)楦婢划a(chǎn)生了一次而接收到已解決狀態(tài)的告警，排除第二條；最后，告警的告警的產(chǎn)生時(shí)間念亂與自動(dòng)解決時(shí)間相差不是 24h，排除第三條。那問題出在什么地方呢？
分析
下面我們開始分析這個(gè)問題。綜合之一節(jié)的描述，初步的猜想是告警在到達(dá) AlertManager 前悉含的某些階段的處理過程太長(zhǎng)，導(dǎo)致告警到達(dá) AlertManager 后就已經(jīng)過了自動(dòng)解決時(shí)間。我們從分析平臺(tái)里一條告警的流轉(zhuǎn)過程入手，找出告警在哪個(gè)處理階段耗時(shí)過長(zhǎng)。首先，一條告警的產(chǎn)生需要兩方面的配合：
metric 數(shù)據(jù)
告警規(guī)則
將 metric
數(shù)據(jù)輸入
到告警規(guī)則進(jìn)行計(jì)算，如果符合條件則產(chǎn)生告警。DMP 平臺(tái)集成了 Thanos 的相關(guān)組件，數(shù)據(jù)的提供和計(jì)算則會(huì)分開，數(shù)據(jù)還是由 Prometheus Server 提供，而告警規(guī)則的計(jì)算則交由 Thanos Rule（下文簡(jiǎn)稱 Ruler）處理。下圖是 Ruler 組件在集群中所處的位置：
看來，想要弄清楚現(xiàn)告警的產(chǎn)生到 AlertManager 之間的過程，需要先弄清除 Ruler 的大致機(jī)制。官方文檔對(duì) Ruler 的介紹是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。
不難推測(cè)，Ruler 應(yīng)該是在 Prometheus 上封裝了一層，并提供一些額外的功能。通過翻閱資料大致了解，Ruler 使用 Prometheus 提供的庫計(jì)算告警規(guī)則，并提供一些額外的功能。下面是 Ruler 中告警流轉(zhuǎn)過程：
請(qǐng)點(diǎn)擊輸入圖片描述
請(qǐng)點(diǎn)擊輸入圖片描述
首先，圖中每個(gè)告警規(guī)則 Rule 都有一個(gè) active queue（下面簡(jiǎn)稱本地隊(duì)列），用來保存一個(gè)告警規(guī)則下的活躍告警。
其次，從本地隊(duì)列中取出告警，發(fā)送至 AlertManager 前，會(huì)被放入 Thanos Rule Queue（下面簡(jiǎn)稱緩沖隊(duì)列），該緩沖隊(duì)列有兩個(gè)屬性：
capacity（默認(rèn)值為 10000）：控制緩沖隊(duì)列的大小，
maxBatchSize（默認(rèn)值為 100）：控制單次發(fā)送到 AlertManager 的更大告警數(shù)
了解了上述過程，再通過翻閱 Ruler 源碼發(fā)現(xiàn)，一條告警在放入緩沖隊(duì)列前，會(huì)為其設(shè)置一個(gè)默認(rèn)的自動(dòng)解決時(shí)間（當(dāng)前時(shí)間 + 3m），這里是影響告警自動(dòng)解決的開始時(shí)間，在這以后，有兩個(gè)階段可能影響告警的處理：1. 緩沖隊(duì)列階段2. 出緩沖隊(duì)列到 AlertManager 階段（
網(wǎng)絡(luò)延遲
影響）由于測(cè)試環(huán)境是局域網(wǎng)環(huán)境，并且也沒在環(huán)境上發(fā)現(xiàn)網(wǎng)絡(luò)相關(guān)的問題，我們初步排除第二個(gè)階段的影響，下面我們將注意力放在緩沖隊(duì)列上。通過相關(guān)源碼發(fā)現(xiàn)，告警在緩沖隊(duì)列中的處理過程大致如下：如果本地隊(duì)列中存在一條告警，其上次發(fā)送之間距離現(xiàn)在超過了 1m（默認(rèn)值，可修改），則將該告警放入緩沖隊(duì)列，并從緩沖隊(duì)列中推送最多 maxBatchSize 個(gè)告警發(fā)送至 AlertManager。反之，如果所有睜高笑本地隊(duì)列中的告警，在最近 1m 內(nèi)都有發(fā)送過，那么就不會(huì)推送緩沖隊(duì)列中的告警。也就是說，如果在一段時(shí)間內(nèi)，產(chǎn)生了大量重復(fù)的告警，緩沖隊(duì)列的推送頻率會(huì)下降。隊(duì)列的生產(chǎn)
方太
多，消費(fèi)方太少，該隊(duì)列中的告警就會(huì)產(chǎn)生堆積的現(xiàn)象。因此我們不難猜測(cè)，問題原因很可能是是緩沖隊(duì)列推送頻率變低的情況下，單次推送的告警數(shù)量太少，導(dǎo)致緩沖隊(duì)列堆積。下面我們通過兩個(gè)方面驗(yàn)證上述猜想：首先通過日志可以得到隊(duì)列在大約 20230s 內(nèi)推送了大約 2023 次，即平均 10s 推送一次。結(jié)合緩沖隊(duì)列的具體屬性，一條存在于隊(duì)列中的告警大約需要 (capacity/maxBatchSize)*10s = 16m，AlertManager 在接收到告警后早已超過了默認(rèn)的自動(dòng)解決時(shí)間（3m）。其次，Ruler 提供了 3 個(gè) metric 的值來監(jiān)控緩沖隊(duì)列的運(yùn)行情況：
thanos_alert_queue_alerts_dropped_total
thanos_alert_queue_alerts_pushed_total
thanos_alert_queue_alerts_popped_total
通過觀察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丟失的總數(shù)，也能佐證了緩沖隊(duì)列在某些時(shí)刻存在已滿的情況。
解決通過以上的分析，我們基本確定了問題的根源：Ruler 組件內(nèi)置的緩沖隊(duì)列堆積造成了告警發(fā)送的延遲。針對(duì)這個(gè)問題，我們選擇調(diào)整隊(duì)列的 maxBatchSize 值。下面介紹一下這個(gè)值如何設(shè)置的思路。由于每計(jì)算一次告警規(guī)則就會(huì)嘗試推送一次緩沖隊(duì)列，我們通過估計(jì)一個(gè)告警數(shù)量的更大值，得到 maxBatchSize 可以設(shè)置的最小值。假設(shè)你的業(yè)務(wù)系統(tǒng)需要監(jiān)控的實(shí)體數(shù)量分別為 x1、x2、x3、…、xn，實(shí)體上的告警規(guī)則數(shù)量分別有 y1、y2、y3、…、yn，那么一次能產(chǎn)生的告警數(shù)量最多是(x1 * y2 + x2 * y2 + x3 * y3 + … + xn * yn)，最多推送（y1 + y2 + y3 + … + yn）次，所以要使緩沖隊(duì)列不堆積，maxBatchSize 應(yīng)該滿足：maxBatchSize >= (x1 * y2 + x2 * y2 + x3 * y3 + … + xn * yn) / (y1 + y2 + y3 + … + yn)，假設(shè) x = max(x1,x2, …,xn), 將不等式右邊適當(dāng)放大后為 x，即 maxBatchSize 的最小值為 x。也就是說，可以將 maxBatchSize 設(shè)置為系統(tǒng)中數(shù)量更大的那一類監(jiān)控實(shí)體，對(duì)于 DMP 平臺(tái)，一般來說是 MySQL 實(shí)例。
注意事項(xiàng)
上面的計(jì)算過程只是提供一個(gè)參考思路，如果最終計(jì)算出該值過大，很有可能對(duì) AlertManager 造成壓力，因而失去緩沖隊(duì)列的作用，所以還是需要結(jié)合實(shí)際情況，具體分析。因?yàn)?DMP 將 Ruler 集成到了自己的組件中，所以可以比較方便地對(duì)這個(gè)值進(jìn)行修改。如果是依照官方文檔的介紹使用的 Ruler 組件，那么需要對(duì)源碼文件進(jìn)行定制化修改。
??
關(guān)于數(shù)據(jù)庫日志分析的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開發(fā)經(jīng)驗(yàn)。專業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
網(wǎng)頁題目：深入探究數(shù)據(jù)庫日志分析的核心技術(shù)與實(shí)踐(數(shù)據(jù)庫日志分析)
URL分享：http://m.5511xx.com/article/ccooegc.html
