日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間:8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
如何10分鐘搭建MySQLBinlog分析+可視化方案

日志服務(wù)

創(chuàng)新互聯(lián)是一家專業(yè)從事做網(wǎng)站、網(wǎng)站設(shè)計的網(wǎng)絡(luò)公司。作為專業(yè)網(wǎng)站設(shè)計公司,創(chuàng)新互聯(lián)依托的技術(shù)實力、以及多年的網(wǎng)站運營經(jīng)驗,為您提供專業(yè)的成都網(wǎng)站建設(shè)、營銷型網(wǎng)站及網(wǎng)站設(shè)計開發(fā)服務(wù)!

最近在原有30+種數(shù)據(jù)采集渠道 基礎(chǔ)上,新增MySQL Binlog、MySQL select等數(shù)據(jù)庫方案,仍然主打快捷、實時、穩(wěn)定、所見即所得的特點。

以下我們以用戶登錄數(shù)據(jù)庫作為案例。公司內(nèi)非常多的人員依賴于用戶登錄數(shù)據(jù)以及其衍生出來的相關(guān)數(shù)據(jù):

  • 老板要看大屏,每天UV、PV增長在哪里?

  • 安全要監(jiān)控登錄是否異常,現(xiàn)在用戶賬戶是否遭到集體攻擊?

  • 客戶小二接到用戶反饋,如何實時查詢用戶登錄信息?

  • BI需要分析用戶行為,數(shù)據(jù)分析如何關(guān)聯(lián)用戶登錄數(shù)據(jù)?

  • 審計上門了,請把您3年前用戶的登錄數(shù)據(jù)拿出來吧?

接下來我們將演示如何在10分鐘內(nèi)手把手完成從binlog采集到查詢、告警、搭建報表等全過程,滿足各個老板們的需求:

  1. MySQL Binlog采集

  2. 關(guān)鍵字段索引+統(tǒng)計設(shè)置

  3. 對異常賬號進行查詢分析

  4. 對異常登錄進行告警

  5. 配置可視化儀表盤

  6. 對歷史登錄信息備份以備數(shù)據(jù)審計

環(huán)境準(zhǔn)備

數(shù)據(jù)庫

mysql類型數(shù)據(jù)庫(使用mysql協(xié)議,例如RDS、DRDS等),數(shù)據(jù)庫開啟binlog,且配置binlog類型為ROW模式(RDS默認開啟)

用戶登錄表結(jié)構(gòu)

  
 
 
  1. CREATE 
  2.  TABLE `user_login` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT  
  3. COMMENT 'id', `login_time` datetime NOT NULL, `login_ip` varchar(10) NOT 
  4.  NULL DEFAULT '', `dev_type` varchar(10) NOT NULL, `usr_id` int(11)  
  5. unsigned NOT NULL,`login_result` varchar(10) unsigned NOT  
  6. NULL,`login_err_times` int(10) unsigned NOT NULL,`next_verify_type`  
  7. varchar(10) NOT NULL,PRIMARY KEY (`id`), KEY `usr_id_index` (`usr_id`) ) 

用戶登錄表中記錄了登錄id、登錄時間、登錄ip、登錄設(shè)備、用戶id、登錄結(jié)果、連續(xù)登錄失敗次數(shù)、下一次校驗類型等信息。其中登錄驗證規(guī)則如下:

  • 正常情況只驗證賬號密碼匹配

  • 若用戶連續(xù)登錄失敗超過3次或者當(dāng)前ip和上次登錄ip不在同一省,下次登錄將彈出驗證碼

  • 若用戶連續(xù)登錄失敗超過5次,則下次登錄將使用手機驗證碼

用戶登錄時表的更新方案

  • 方案1:

    每次用戶登錄,在user_login中新增一條記錄,記錄登錄的ip、設(shè)備類型、時間信息

  • 方案2:

    考慮到用戶數(shù)量非常多,如果每次用戶登錄都在user_login中新增一條記錄,數(shù)據(jù)量會非常大,所以每次用戶登錄時,只會根據(jù)usr_id更新update表中的數(shù)據(jù)

對于方案1,優(yōu)點是數(shù)據(jù)庫中保存了所有用戶的登錄信息,缺點是user_login表會存在爆掉的問題,需要定期刪除歷史的數(shù)據(jù);對于方案2,優(yōu)點是user_login表的大小可控,缺點是會丟失歷史用戶的登錄信息。

這里我們推薦使用方案2+logtail binlog采集組成最優(yōu)的方案3:用戶最近一次登錄信息依然保存在數(shù)據(jù)庫中,通過logtail的binlog功能采集user_login表,logtail會將表中的每次修改事件上傳到日志服務(wù),日志服務(wù)中的數(shù)據(jù)可設(shè)置保存時間,超時自動刪除。同時在日志服務(wù)中,可以對實時采集上來的數(shù)據(jù)進行查詢、統(tǒng)計、查看報表、監(jiān)控報警,也支持將數(shù)據(jù)對接下游流計算、導(dǎo)入Max Compute/OSS等。

  方案1 方案2 方案3
數(shù)據(jù)庫數(shù)據(jù)量 用戶數(shù) * 運行時間 / 登錄率 用戶數(shù) 用戶數(shù)
數(shù)據(jù)庫壓力 支撐寫入以及分析,壓力大 只更新,壓力最小 更新+binlog采集,壓力較小
分析能力 基于sql進行分析,數(shù)據(jù)量大時對數(shù)據(jù)庫影響大 無歷史數(shù)據(jù),基本不能分析 使用日志服務(wù)分析,TB級數(shù)據(jù)實時查詢分析無壓力,支持眾多分析擴展函數(shù)
報表&監(jiān)控 手動搭建&運維 手動搭建&運維 基于日志服務(wù)快速創(chuàng)建儀表盤、配置自定義報警
上下游對接擴展性 手動對接上下游 手動對接上下游 對接流計算實時處理、導(dǎo)入OSS歸檔存儲、對接Max Compute離線分析等

數(shù)據(jù)采集

安裝logtail

根據(jù)文檔安裝logtail,確認版本號在0.16.0及以上。若低于0.16.0版本請根據(jù)文檔提示升級到最新版本。

采集配置

    1. 在日志服務(wù)控制臺創(chuàng)建一個新的Logstore,采集向?qū)е羞x擇自建軟件中的Mysql binlog

    2. 在配置頁面中輸入binlog采集配置,如下:

  
 
 
  1.  "inputs": [ { "type": "service_canal", "detail": { "Host":  
  2. "************.mysql.rds.aliyuncs.com", "User" : "root", "Password":  
  3. "*******", "IncludeTables": [ "user_info\.user_login" ] } } ]} 
  • 注意:

  • 數(shù)據(jù)庫開啟binlog且為ROW模式(RDS默認支持),使用的賬戶具有mysql slave權(quán)限以及需要采集的數(shù)據(jù)表的select權(quán)限。

  • binlog支持IncludeTablesExcludeTables過濾,格式均為正則表達式

  • 其他請參考binlog采集中使用限制

建立索引

配置應(yīng)用到機器組后,進入索引查詢配置頁面。在鍵值索引屬性中配置以下索引項:

字段名 類型 別名 分詞符 開啟統(tǒng)計
_event_ text    
dev_type text    
login_ip text    
usr_id text    
next_verify_type text    
login_err_times long    
login_result text    
old_dev_type text    
old_login_ip text    
old_usr_id text    
old_next_verify_type text    
old_login_err_times long    
old_login_result text    

數(shù)據(jù)預(yù)覽

應(yīng)用配置1分鐘后,點擊預(yù)覽可以看到狀態(tài)數(shù)據(jù)已經(jīng)采集上來(logtail的binlog采集會額外上傳數(shù)據(jù)操作類型、GTID等信息):

  • 對于修改的事件,Logtail會同時采集修改前和修改后的數(shù)據(jù),修改前的數(shù)據(jù)以old_開頭。因此我們可以基于修改前后的數(shù)據(jù)對比查找登錄ip變化的相關(guān)記錄。

注意: 若無數(shù)據(jù),請檢查配置是否為合法json;若配置正常,請參考數(shù)據(jù)采集異常排查文檔自助排查

自定義查詢與分析

到這一步我們就可以滿足客服和BI的需求了:查詢/關(guān)聯(lián)查詢。例如:

  1. 用戶反饋賬號信息被篡改了,客服通過日志服務(wù),查詢該用戶從上次登錄到現(xiàn)在的登錄信息:login_id : 256525,發(fā)現(xiàn)其中有一條登錄日志;繼續(xù)查詢登錄地址login_id : 256525 | select ip_tp_province(login_ip) as login_province, ip_tp_country(login_ip) as login_country,發(fā)現(xiàn)是在國外登錄的,因此很有可能該用戶賬號泄漏或被攻破了。

  2. 用戶反饋自己的賬號被限制登錄了,客服通過日志服務(wù),查詢該用戶限制登錄前的相關(guān)登錄信息:login_id : 256525 | select ip_tp_province(login_ip) as login_province, login_result, count(1) as total group by (login_province,login_result) order by total desc limit 100,發(fā)現(xiàn)該用戶在多個省異常登錄失敗了很多次。

  • 查詢相關(guān)使用幫助參見日志服務(wù)查詢

用戶登錄大盤

現(xiàn)在我們來搭建CEO要的大盤,先準(zhǔn)備一些基礎(chǔ)的統(tǒng)計信息:

  • 統(tǒng)計一天的UV&PV

  
 
 
  1. select count(distinct(usr_id)) as uv, count(1) as pv 
  • 查看登錄設(shè)備分布

  
 
 
  1. select dev_type, count(1) as count group by dev_type 
  • 每5分鐘統(tǒng)計UV&PV分布

 
  
 
 
  1. select count(1) as uv, count(distinct(usr_id)) as pv, from_unixtime(  
  2. __time__ - __time__ % 300) as time group by __time__ - __time__ % 300  
  3. order by time limit 1440 

統(tǒng)計地理位置分布

由于原始的數(shù)據(jù)中沒有用戶登錄的地理位置分布信息,但我們可以通過ip地址定位到用戶登錄的省市,這里我們使用日志服務(wù)自帶的ip地址轉(zhuǎn)換函數(shù)(具體參見分析語法IP識別函數(shù)章節(jié))

  • 統(tǒng)計top10的city(使用ip_to_city

  
 
 
  1. select ip_to_city(login_ip) as login_city, count(1) as count group by login_city order by count desc limit 10 
  • 統(tǒng)計省份分布(使用ip_tp_province

  
 
 
  1. select ip_tp_province(login_ip) as login_province, count(1) as count group by login_province order by count desc limit 100 

用戶登錄大盤搭建

根據(jù)上一節(jié)的統(tǒng)計結(jié)果,我們搭建出了用戶登錄信息的儀表盤,可以向CEO匯報了。

  • 儀表盤搭建參見日志服務(wù)儀表盤設(shè)置

異常登錄告警

異常登錄都會有誤判的可能性,因此正常情況下會有少部分異常登錄的情況,但異常登錄占比要小于1%。這里我們?yōu)橛脩舻卿浽O(shè)置一個異常登錄的告警:若當(dāng)異常登錄占總登錄的1%則觸發(fā)告警。

 
  
 
 
  1. SELECT sum( CASE WHEN  
  2. ip_tp_province(login_ip)!=ip_tp_province(old_login_ip) then 1 ELSE 0 end 
  3.  ) *1.0 / count(1) as abnormal_login_percentage 

將該查詢存為快速查詢abnormal_login,并設(shè)置告警。

  • 告警設(shè)置參見日志服務(wù)告警設(shè)置

配置項 內(nèi)容
報警規(guī)則名稱 abnormal_login_alarm
快速查詢名稱 abnormal_login
數(shù)據(jù)查詢時間(分鐘) 5
檢查間隔(分鐘) 5
觸發(fā)次數(shù) 1
字段名稱 abnormal_login_percentage
比較符 大于
檢查閾值 0.01
通知類型 通知中心
通知內(nèi)容 user abnormal login percentage exceed limit.

數(shù)據(jù)備份

用戶登錄數(shù)據(jù),一般建議在日志服務(wù)存儲一段時間(30天、半年、1年等)用于實時的查詢和分析,但對于歷史數(shù)據(jù)還需要保存下來,便于后續(xù)的審計、大數(shù)據(jù)挖掘與分析等。這里我們使用日志服務(wù)的投遞功能,將數(shù)據(jù)投遞到OSS進行長期的歸檔存儲。審計員來了想看多少年前的數(shù)據(jù)都有!


本文名稱:如何10分鐘搭建MySQLBinlog分析+可視化方案
鏈接分享:http://www.dlmjj.cn/article/djosges.html