整合營(yíng)銷(xiāo)服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
在java的開(kāi)發(fā)中，使用最多也繞不過(guò)去的一個(gè)話題就是日志，在程序中除了業(yè)務(wù)代碼外，使用最多的就是打印日志。經(jīng)常聽(tīng)到的這樣一句話就是“打個(gè)日志調(diào)試下”，沒(méi)錯(cuò)在日常的開(kāi)發(fā)、調(diào)試過(guò)程中打印日志是常干的一件事，同時(shí)系統(tǒng)正常運(yùn)行過(guò)程中必要的日志打印也是必須的。
在筆者剛接觸java程序的時(shí)候，打印日志經(jīng)常使用到到下面的代碼，
System.out.println("hello log");我相信在不了解日志系統(tǒng)的前提下使用上述的方式是最多的，同時(shí)也是新手小白最常用的方式，筆者曾經(jīng)也是使用最多的。那么除了上述的方式還有其他的方式嗎？答案是肯定的
在java的API中提供了一套日志打印的方法，java程序人員在設(shè)計(jì)之初已經(jīng)想到了這方面的功能，所以從JDK1.4起提供了日志打印的API，只不過(guò)被大多數(shù)人忽略了。這套API在java.util.logging包下，使用該種方式不需要引任何的jar，只要在java環(huán)境下即可使用。
如上圖，是java提供的日志的一些類(lèi)。使用方法類(lèi)似下面的代碼，
public static Logger logger=Logger.getLogger(Test.class.toString());
logger.info("hello log");注意Logger的路徑是java.util.logging.Logger。
log4j是apache的一個(gè)項(xiàng)目，其中又分為log4j1和log4j2，所謂log4j1指的就是其大版本號(hào)為1，不過(guò)log41在很早之前就已經(jīng)停止更新了，源碼官網(wǎng)：https://github.com/apache/logging-log4j1
可以看的在2012年已經(jīng)停止更新了，也就是說(shuō)現(xiàn)在通常來(lái)說(shuō)使用的log4j都是log4j2，更確切的說(shuō)是log4j，為了準(zhǔn)確期間，這里還是和之前的版本進(jìn)行區(qū)分，使用log4j2的名字，log4j2是在log4j1基礎(chǔ)上的升級(jí)，并吸收了logback這個(gè)框架的優(yōu)秀之處且修復(fù)了其很多問(wèn)題，可以說(shuō)log4j2是一個(gè)優(yōu)秀的日志框架，其源碼官網(wǎng)：https://github.com/apache/logging-log4j2
官網(wǎng)：https://logging.apache.org/log4j/2.x/index.html
log4j2的maven依賴如下，引入log4j-api和log4j-core即可，
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.17.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.17.1</version>
</dependency>這里有個(gè)問(wèn)題要注意，log4j1和log4j2的groupId是不一樣的，log4j1的是org.apache.log4j，log4j2的是org.apache.logging.log4j，帶來(lái)的變化就是在使用的過(guò)程中要注意引用的類(lèi)的路徑，從路徑上可以確定是使用的log4j1.x還是log4j2.x，如果是org.apache.log4j開(kāi)頭的包路徑那么是版本1的，是org.apache.logging.log4j開(kāi)頭的是版本2的。
使用方式類(lèi)似如下，
private static final Logger logger=LogManager.getLogger();
logger.info();logback是一個(gè)開(kāi)源的日志框架，是log4j的作者為了代替log4j而開(kāi)發(fā)的。logback包含三部分，logback-core、logback-classic、logback-access，logback-core是其他兩個(gè)模塊的核心，常用到的是logback-core+logback-classic。logback-access常和jetty和tomcat結(jié)合。
logback的groupId為ch.qos.logback，其maven依賴如下
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.2.10</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.10</version>
</dependency>
<!--平時(shí)用不到，可不引入-->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-access</artifactId>
<version>1.2.10</version>
</dependency>使用方法可參考：https://www.jianshu.com/p/3e3b550920b3
其官網(wǎng)：https://logback.qos.ch/index.html
slf4j不能稱(chēng)之為一個(gè)日志框架，因?yàn)樗鼉H僅提供了一系列的標(biāo)準(zhǔn)，提供一系列接口，但沒(méi)有實(shí)現(xiàn)，采用的是門(mén)面模式。
其依賴為：
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.36</version>
</dependency>上面便是slf4j的核心包。
注意：如果使用slf4j出現(xiàn)下面的日志
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.說(shuō)明沒(méi)有日志實(shí)現(xiàn)框架，slf4j自己實(shí)現(xiàn)了一個(gè)日志框架，可以加上下面的依賴
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.7.36</version>
</dependency>slf4j可以和其他具體的日志實(shí)現(xiàn)框架進(jìn)行結(jié)合使用，如下
上圖是一個(gè)slf4j和其他日志框架結(jié)合的圖形展示，
slf4j+logback
需要slf4j-api、logback-api、logback-classic三個(gè)包
slf4j+JDK日志
需要slf4j-api、slf4j-jdk14，其中slf4j-jdk14是slf4j和JDK日志結(jié)合的jar。
slf4j+log4j
需要slf4j+slf4j-log4j12
slf4j+JCL
需要slf4j、common-logging
其官網(wǎng)：https://www.slf4j.org/
JCL是Jakarta Commons Logging的簡(jiǎn)寫(xiě)，又叫Apache Commons Logging，提供的是一個(gè) Java 的日志接口，同時(shí)兼顧輕量級(jí)和不依賴于具體的日志實(shí)現(xiàn)工具。它提供給中間件/日志工具開(kāi)發(fā)者一個(gè)簡(jiǎn)單的日志操作抽象，允許程序開(kāi)發(fā)人員使用不同的具體日志實(shí)現(xiàn)工具。用戶被假定已熟悉某種日志實(shí)現(xiàn)工具的更高級(jí)別的細(xì)節(jié)。JCL提供的接口，對(duì)其它一些日志工具，包括Log4J, Avalon LogKit, and JDK 1.4等，進(jìn)行了簡(jiǎn)單的包裝，此接口更接近于Log4J和LogKit的實(shí)現(xiàn)。
其包為common-logging.jar包含了所有的功能，還有其他另外兩個(gè)包c(diǎn)ommon-logging-api、common-logging-adapters
官網(wǎng)：https://commons.apache.org/proper/commons-logging/guide.html
本文簡(jiǎn)單總結(jié)了java中常用的日志，其中slf4j和JCL是日志的接口，又都進(jìn)行了簡(jiǎn)單實(shí)現(xiàn)，既可以自己?jiǎn)为?dú)使用，又可以和其他實(shí)現(xiàn)日志框架結(jié)合使用，如，log4j、logback、JDK logging等。
來(lái)源：https://www.cnblogs.com/teach/p/15887258.html
ogstash 是一個(gè)開(kāi)源的數(shù)據(jù)收集引擎，它具有備實(shí)時(shí)數(shù)據(jù)傳輸能力。它可以統(tǒng)一過(guò)濾來(lái)自不同源的數(shù)據(jù)，并按照開(kāi)發(fā)者的制定的規(guī)范輸出到目的地。顧名思義，Logstash 收集數(shù)據(jù)對(duì)象就是日志文件。由于日志文件來(lái)源多（如：系統(tǒng)日志、服務(wù)器日志、網(wǎng)絡(luò)設(shè)備日志等），且內(nèi)容雜亂，不便于人類(lèi)進(jìn)行觀察。因此，我們可以使用 Logstash 對(duì)日志文件進(jìn)行收集和統(tǒng)一過(guò)濾，變成可讀性高的內(nèi)容，方便開(kāi)發(fā)者或運(yùn)維人員觀察，從而有效的分析系統(tǒng)/項(xiàng)目運(yùn)行的性能，做好監(jiān)控和預(yù)警的準(zhǔn)備工作等。
Logstash 通過(guò)管道進(jìn)行運(yùn)作，管道有兩個(gè)必需的元素，輸入和輸出，還有一個(gè)可選的元素，過(guò)濾器。輸入插件從數(shù)據(jù)源獲取數(shù)據(jù)，過(guò)濾器插件根據(jù)用戶指定的數(shù)據(jù)格式修改數(shù)據(jù)，輸出插件則將數(shù)據(jù)寫(xiě)入到目的地。在實(shí)際工作中Logstash數(shù)據(jù)收集的一個(gè)流程大概是：數(shù)據(jù)源→通過(guò)input插件（如file、redis、stdin）→output插件→寫(xiě)到Elasticsearch。
下面我通過(guò)ELK平臺(tái)收集下圖所示的日志，舉例說(shuō)明Logstash是怎么收集一些常用各類(lèi)日志的。這些日志對(duì)zabbix服務(wù)器的正常運(yùn)行至關(guān)重要，這也是大部分應(yīng)用系統(tǒng)正常運(yùn)行會(huì)包含的一些日志。關(guān)于ELK的搭建可以參考快速搭建ELK日志分析平臺(tái)，對(duì)zabbix監(jiān)控技術(shù)有興趣的同學(xué)可以參考搭建Zabbix監(jiān)控系統(tǒng)部署詳細(xì)步驟。
1.file插件收集日志文件
在zabbix服務(wù)器172.18.20.28上編輯logstash配置文件，并將收集到的zabbix_server.log文件數(shù)據(jù)提交到elasticsearch中：
#cat logstash-zabbixserver.conf
input {
file{
path=> " /var/log/zabbix/zabbix_server.log" #文件路徑
type=> "zabbix-server" #類(lèi)似打個(gè)標(biāo)記，自定義
start_position=> "beginning" #文件頭部讀取，相反還有end
}
}
output {
elasticsearch {
hosts=> ["172.28.29.211:9200"] #輸出到elasticsearch
index=> "zabbix-%{+YYYY.MM.dd}" #按年月日格式生成索引
}
}
運(yùn)行l(wèi)ogstash：
/usr/local/logstash-6.2.4/bin/logstash -f logstash-zabbixserver.conf
在elasticsearch上查看數(shù)據(jù)：
2. if判斷收集多個(gè)日志
現(xiàn)在需要在收集另外一個(gè)日志文件mariadb.log，我們修改logstash配置文件使用if判斷進(jìn)行收集：
#cat logstash-zabbixserver.conf
input {
file{
path=> " /var/log/zabbix/zabbix_server.log"
type=> "zabbix-server"
start_position=> "beginning"
}
file{
path=> " /var/log/mariadb/mariadb.log"
type=> "mysql"
start_position=> "beginning"
}
}
output {
if [type]==" zabbix-server " { #根據(jù)type來(lái)匹配
elasticsearch {
hosts=> ["172.28.29.211:9200"]
index=> " zabbix -%{+YYYY.MM.dd}"
}
}
if [type]==" mysql " {
elasticsearch {
hosts=> ["172.28.29.211:9200"]
index=> " zabbix-mysql -%{+YYYY.MM}" #按年月
}
}
}
再次運(yùn)行l(wèi)ogstash：
/usr/local/logstash-6.2.4/bin/logstash -f logstash-zabbixserver.conf
在elasticsearch上查看另一個(gè)收集的日志數(shù)據(jù)：
3.syslog插件收集系統(tǒng)網(wǎng)絡(luò)日志
syslog默認(rèn)是通過(guò)514端口去發(fā)送日志，可以使用logstash安裝對(duì)應(yīng)的syslog插件，監(jiān)聽(tīng)514端口來(lái)收集日志。如果只是監(jiān)聽(tīng)系統(tǒng)日志可以不用安裝logstash的agent,只需要監(jiān)聽(tīng)對(duì)應(yīng)的514端口，收集系統(tǒng)數(shù)據(jù)即可。logstash在INPUT插件中提供了syslog的模塊，可以用于不安裝本地日志收集agent的設(shè)備（如硬件防火墻等），當(dāng)然支持此類(lèi)協(xié)議的普通服務(wù)器也適用。
注意：此INPUT插件會(huì)同時(shí)監(jiān)聽(tīng)TCP和UDP端口。
服務(wù)器rsyslog收集
創(chuàng)建編輯logstash-syslog配置文件，使用syslog插件：
#cat logstash-syslog.conf
input {
syslog {
type=> "system-syslog"
port=> 514 #默認(rèn)為514端口，可自行修改
}
}
output {
elasticsearch {
hosts=> ["172.28.29.211:9200"] #輸出到elasticsearch
index=> "zabbix-syslog-%{+YYYY.MM}" #名稱(chēng)按年月保存收集
}
}
運(yùn)行l(wèi)ogstash：
/usr/local/logstash-6.2.4/bin/logstash -f logstash-syslog.conf
重新開(kāi)啟一個(gè)窗口，查看服務(wù)是否啟動(dòng)：
# netstat –ntlp | grep 514 tcp6 0 0 :::514 :::* LISTEN 21544/java
修改rsyslog配置文件：
# vi /etc/rsyslog.conf … #*.* @@remote-host:514 *.* @@172.18.20.28:514 #添加遠(yuǎn)程syslog服務(wù)器IP，這里是本機(jī)
重啟rsyslog：
systemctl restart rsyslog
在elasticsearch上查看收集到的服務(wù)器rsyslog日志：
網(wǎng)絡(luò)設(shè)備syslog收集
收集交換機(jī)網(wǎng)和防火墻syslog日志，配置如下：
#cat wl-syslog.conf
input{
syslog {
type=> "wl-syslog"
port=> 514
}
}
output {
if [host]=="172.18.20.254"{ #根據(jù)host來(lái)匹配生成相應(yīng)的索引
elasticsearch {
hosts=> ["172.28.29.211:9200"]
index=> "jhj-%{+YYYY.MM}"
}
}
if [host]=="172.18.16.254"{
elasticsearch {
hosts=> ["172.28.29.211:9200"]
index=> "fhq-%{+YYYY.MM}"
}
}
}
相應(yīng)的網(wǎng)絡(luò)設(shè)備上開(kāi)啟并指定syslog服務(wù)器，以Cisco設(shè)備為例：
logging on logging host 172.28.29.211
在elasticsearch上查看收集這兩臺(tái)網(wǎng)絡(luò)設(shè)備的日志：
4.grok插件收集Apache訪問(wèn)日志
一般系統(tǒng)或服務(wù)生成的日志都是一大長(zhǎng)串。每個(gè)字段之間用空格隔開(kāi)。logstash在獲取日志是整個(gè)一串獲取，如果把日志中每個(gè)字段代表的意思分割開(kāi)來(lái)在傳給elasticsearch。這樣呈現(xiàn)出來(lái)的數(shù)據(jù)更加清晰，而且也能讓kibana更方便的繪制圖形。Grok是Logstash最重要的插件。它的主要作用就是將文本格式的字符串，轉(zhuǎn)換成為具體的結(jié)構(gòu)化的數(shù)據(jù)，配合正則表達(dá)式使用。
grok事先已經(jīng)預(yù)定義好了許多正則表達(dá)式規(guī)則，該規(guī)則文件存放路徑：
/usr/local/logstash-6.2.4/vendor/bundle/jruby/2.3.0/gems/logstash-patterns- core-4.1.2/patterns
grok插件語(yǔ)法說(shuō)明, 以一個(gè)簡(jiǎn)單的訪問(wèn)日志為例:
55.3.244.1 GET /index.html 15824 0.043
這條日志可切分為5個(gè)部分，IP(55.3.244.1)、方法(GET)、請(qǐng)求文件路徑(/index.html)、字節(jié)數(shù)(15824)、訪問(wèn)時(shí)長(zhǎng)(0.043) ，如果不做拆分的話Kibana里會(huì)將所有內(nèi)容都寫(xiě)在messages字段里。如果我們想把不同字段做分類(lèi)的話，就可以用grok來(lái)進(jìn)行定義，在默認(rèn)配置文件里其實(shí)很多配置都已經(jīng)寫(xiě)好了，只需要引用下：
%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}
大寫(xiě)的單詞是預(yù)定義的正則表達(dá)式，可以在grok-patterns文件看到其具體匹配的內(nèi)容。如果匹配的話，就將該字段名稱(chēng)重新定義為冒號(hào)后面的小寫(xiě)的單詞。用上面那條訪問(wèn)日志的客戶端IP來(lái)說(shuō)明，它將在Kibana里被定義為client字段并單獨(dú)顯示出來(lái)，而不是全部塞在了message里。
寫(xiě)到filter中：
filter {
grok {
match=> { "message"=> "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}"}
}
}
解析后:
client: 55.3.244.1 method: GET request: /index.html bytes: 15824 duration: 0.043
下面是一條zabbix服務(wù)器Apache日志:
192.168.33.203 - - [11/Jul/2018:09:37:07 +0800] "POST /zabbix/jsrpc.php?output=json-rpc HTTP/1.1" 200 65 "http://192.168.33.29/zabbix/zabbix.php?action=dashboard.view" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:61.0) Gecko/20100101 Firefox/61.0"
創(chuàng)建編輯logstash-apache配置文件，使用filter中的grok插件：
# cat logstash-apache.conf
input{
file{
path=> "/etc/httpd/logs/access_log"
type=> "apache"
start_position=> "beginning"
}
}
filter{
if[type]=="apache"{
grok{
match=> {"message"=> "%{COMBINEDAPACHELOG}"}
}
}
}
output{
if[type]=="apache"{
elasticsearch{
hosts=> ["172.28.29.211:9200"]
index=> "zabbix_apache-%{+YYYY.MM}"
}
}
}
#fileter中的message代表一條一條的日志，%{COMBINEDAPACHELOG}代表解析日志的正則表達(dá)式
運(yùn)行l(wèi)ogstash：
/usr/local/logstash-6.2.4/bin/logstash -f logstash-apache.conf
在elasticsearch上查看收集到的Apache日志：
整合到一個(gè)logstash配置文件運(yùn)行
我們已成功收集到各項(xiàng)日志，現(xiàn)在我們需要將這些單獨(dú)的logstash配置文件整合到一個(gè)配置文件中，配置如下：
#cat logstash-all.conf
input {
syslog{
type=> "system-syslog"
port=> 514
}
file{
path=> "/var/log/zabbix/zabbix_server.log"
type=> "zabbix-server"
start_position=> "beginning"
}
file{
path=> "/var/log/mariadb/mariadb.log"
type=> "mysql"
start_position=> "beginning"
}
file{
path=> "/etc/httpd/logs/access_log"
type=> "apache"
start_position=> "beginning"
}
}
filter{
if[type]=="apache"{
grok{
match=> {"message"=> "%{COMBINEDAPACHELOG}"}
}
}
}
output {
if [type]=="system-syslog" {
elasticsearch {
hosts=> ["172.28.29.211:9200"]
index=> "zabbix-syslog-%{+YYYY.MM}"
}
}
if [type]=="zabbix-server" {
elasticsearch {
hosts=> ["172.28.29.211:9200"]
index=> "zabbix _server-%{+YYYY.MM}"
}
}
if [type]=="mysql" {
elasticsearch {
hosts=> ["172.28.29.211:9200"]
index=> "zabbix-mysql -%{+YYYY.MM}"
}
}
if[type]=="apache"{
elasticsearch{
hosts=> ["172.28.29.211:9200"]
index=> "zabbix_apache-%{+YYYY.MM}"
}
}
}
至此我們配置完成收集到所有zabbix服務(wù)器上日志的logstash文件，最后在后臺(tái)運(yùn)行l(wèi)ogstash：
# nohup /usr/local/logstash-6.2.4/bin/logstash -f logstash-all.conf -w 4 &
Kibana上日志展示
Kibana是為Elasticsearch提供的可視化平臺(tái)，負(fù)責(zé)數(shù)據(jù)的美觀展示。Kibana服務(wù)默認(rèn)監(jiān)控在5601端口，瀏覽器訪問(wèn)http://IP:5601可以打開(kāi)Kibana的界面。左側(cè)導(dǎo)航欄有很多選項(xiàng)，Discover用于和Elasticsearch交互和展示搜索結(jié)果，Visualize用于報(bào)表生成。
我們新建一個(gè)收集zabbix-sever的運(yùn)行日志。點(diǎn)擊工具欄中的Management --> 選擇index patterns --> 點(diǎn)擊Create Index Pattern按鈕。
然后選擇一個(gè)包含了時(shí)間戳的索引字段，可以用來(lái)做基于時(shí)間的處理。Kibana會(huì)讀取索引的映射，然后列出所有包含了時(shí)間戳的字段。
點(diǎn)擊create之后，創(chuàng)建完成。
在DISCOVER就可以選擇查看并搜索相應(yīng)的日志了。
同理我們創(chuàng)建其他的日志，可以在discover左邊欄選擇fields更加美觀的展示日志。
埋點(diǎn)是數(shù)據(jù)采集的專(zhuān)用術(shù)語(yǔ)，在數(shù)據(jù)驅(qū)動(dòng)型業(yè)務(wù)中，如營(yíng)銷(xiāo)策略、產(chǎn)品迭代、業(yè)務(wù)分析、用戶畫(huà)像等，都依賴于數(shù)據(jù)提供決策支持，希望通過(guò)數(shù)據(jù)來(lái)捕捉特定的用戶行為，如按鈕點(diǎn)擊量、閱讀時(shí)長(zhǎng)等統(tǒng)計(jì)信息。因此，數(shù)據(jù)埋點(diǎn)可以簡(jiǎn)單理解為：針對(duì)特定業(yè)務(wù)場(chǎng)景進(jìn)行數(shù)據(jù)采集和上報(bào)的技術(shù)方案。
數(shù)據(jù)埋點(diǎn)非常看重兩件事，一個(gè)是數(shù)據(jù)記錄的準(zhǔn)確性，另一個(gè)則是數(shù)據(jù)記錄的完備性。
先講數(shù)據(jù)的準(zhǔn)確性。數(shù)據(jù)埋點(diǎn)非常強(qiáng)調(diào)規(guī)范和流程，因?yàn)閰?shù)的規(guī)范與合法，將直接影響到數(shù)據(jù)分析的準(zhǔn)確性，如果準(zhǔn)確性得不到保障，那么所有基于埋點(diǎn)得出的結(jié)論，都是不可信的。辛辛苦苦做了很久的方案，一旦因?yàn)橐粋€(gè)疏忽的小問(wèn)題，導(dǎo)致下游集中投訴，其實(shí)非常劃不來(lái)。
道理每個(gè)人都懂，但現(xiàn)實(shí)情況中，數(shù)據(jù)埋點(diǎn)所面對(duì)的客觀環(huán)境，其實(shí)非常復(fù)雜，例如：
因此本文有非常長(zhǎng)的篇幅來(lái)寫(xiě)流程問(wèn)題，其實(shí)是非常有必要的。
再講數(shù)據(jù)的完備性。因?yàn)槁顸c(diǎn)主要是面向分析使用，對(duì)用戶而言是個(gè)額外的功能，因此埋點(diǎn)的業(yè)務(wù)侵入性很強(qiáng)，很容易對(duì)用戶體驗(yàn)造成影響。別的不說(shuō)，僅僅是流量的消耗，就很容被用戶噴。因此，要提前想清楚，我們要采集哪些東西，因?yàn)樾薷姆桨傅某杀荆莻黄鸬摹?/span>
通常情況下，我們需要記錄用戶在使用產(chǎn)品過(guò)程中的操作行為，通過(guò)4W1H模型可以比較好的保障信息是完備的。4W1H包括：
規(guī)定好記錄信息的基本方法之后，按照固定的頻率，如每小時(shí)、每天，或者是固定的數(shù)量，比如多少條日志，或者是網(wǎng)絡(luò)環(huán)境，比如在Wifi下上傳，我們就可以開(kāi)心的把埋點(diǎn)數(shù)據(jù)用起來(lái)了。
當(dāng)然，數(shù)據(jù)記錄的時(shí)效性也比較重要，但因?yàn)槁顸c(diǎn)數(shù)據(jù)通常量級(jí)會(huì)比較大，且各個(gè)端數(shù)據(jù)回傳的時(shí)間不同，因此想做到實(shí)時(shí)統(tǒng)計(jì)，還是需要分場(chǎng)景來(lái)展開(kāi)。在Flink技術(shù)日漸成熟的今天，全鏈路的實(shí)時(shí)采集與統(tǒng)計(jì)，已經(jīng)不是什么難題。
在埋點(diǎn)的技術(shù)方案中，首先要重視的，是用戶唯一標(biāo)識(shí)的建設(shè)。如果做不到對(duì)用戶的唯一識(shí)別，那么基礎(chǔ)的UV統(tǒng)計(jì)，都將是錯(cuò)誤的。
因此，在數(shù)據(jù)埋點(diǎn)方案中，有兩個(gè)信息是一定要記錄的，即設(shè)備ID+用戶ID。設(shè)備ID代表用戶使用哪個(gè)設(shè)備，如安卓的ANDROID_ID/IMEI，IOS中的IDFA/UDID，瀏覽器的Cookie，小程序的OpenID等。用戶ID，代表用戶在產(chǎn)品中所注冊(cè)的賬號(hào)，通常是手機(jī)號(hào)，也可以是郵箱等其他格式。
當(dāng)這兩個(gè)信息能夠獲得時(shí)，不論是用戶更換設(shè)備，或者是同一臺(tái)設(shè)備不同賬號(hào)登錄，我們都能夠根據(jù)這兩個(gè)ID，來(lái)識(shí)別出誰(shuí)在對(duì)設(shè)備做操作。
其次，我們來(lái)看一下Web的數(shù)據(jù)采集技術(shù)。Web端數(shù)據(jù)采集主要通過(guò)三種方式實(shí)現(xiàn)：服務(wù)器日志、URL解析及JS回傳。
瀏覽器的日志采集種類(lèi)又可以分為兩大類(lèi)：頁(yè)面瀏覽日志和頁(yè)面交互日志。
除此之外，還有一些針對(duì)特定場(chǎng)合統(tǒng)計(jì)的日志，例如頁(yè)面曝光時(shí)長(zhǎng)日志、用戶在線操作監(jiān)控等，但原理都基于上述兩類(lèi)日志，只是在統(tǒng)計(jì)上有所區(qū)分。
再次，我們來(lái)看下客戶端的數(shù)據(jù)采集。與網(wǎng)頁(yè)日志對(duì)應(yīng)的，是手機(jī)應(yīng)用為基礎(chǔ)的客戶端日志，由于早期手機(jī)網(wǎng)絡(luò)通訊能力較差，因而SDK往往采用延遲發(fā)送日志的方式，也就是先將日志統(tǒng)計(jì)在本地，然后選擇在Wifi環(huán)境下上傳，因而往往會(huì)出現(xiàn)統(tǒng)計(jì)數(shù)據(jù)延遲的情況。現(xiàn)如今網(wǎng)絡(luò)環(huán)境好了很多，4G、5G流量充足，尤其是視頻類(lèi)APP基本上都是一直聯(lián)網(wǎng)，因而很多統(tǒng)計(jì)能夠做到實(shí)時(shí)統(tǒng)計(jì)。
客戶端的日志統(tǒng)計(jì)主要通過(guò)SDK來(lái)完成，根據(jù)不同的用戶行為分成不同的事件，“事件”是客戶端日志行為的最小單位，根據(jù)類(lèi)型的不同，可以分為頁(yè)面事件（類(lèi)比頁(yè)面瀏覽）和控件點(diǎn)擊事件（類(lèi)比頁(yè)面交互）。對(duì)于頁(yè)面事件，不同的SDK有不同的方式，主要區(qū)別為是在頁(yè)面創(chuàng)建時(shí)發(fā)送日志，還是在頁(yè)面瀏覽結(jié)束后發(fā)送日志，區(qū)別在于業(yè)務(wù)統(tǒng)計(jì)是否需要采集用戶的頁(yè)面停留時(shí)長(zhǎng)。
頁(yè)面事件的統(tǒng)計(jì)主要統(tǒng)計(jì)如下三類(lèi)信息：
最后，我們還需要考慮小程序等場(chǎng)景的埋點(diǎn)方案，小程序通常情況下，開(kāi)發(fā)者會(huì)聲明好相應(yīng)的方法，按照需求調(diào)用即可，例如微信提供了API上報(bào)和填寫(xiě)配置兩種方案。
埋點(diǎn)其實(shí)還需要考慮數(shù)據(jù)上傳的方案，批量的數(shù)據(jù)可以通過(guò)Flume直接上報(bào)，流式的可以寫(xiě)到Kafka，或者直接使用Flink來(lái)處理。這些框架相關(guān)的內(nèi)容不是本文考慮的重點(diǎn)，有興趣的可以自行查閱資料。
有了指導(dǎo)思路和技術(shù)方案后，我們就可以著手制定相應(yīng)的數(shù)據(jù)埋點(diǎn)流程規(guī)范了。
籠統(tǒng)上，流程規(guī)范會(huì)分成五個(gè)步驟，即需求評(píng)審、埋點(diǎn)申請(qǐng)、技術(shù)開(kāi)發(fā)、埋點(diǎn)驗(yàn)證、發(fā)布上線。
第一步，需求評(píng)審。
前文提到過(guò)，數(shù)據(jù)埋點(diǎn)的方案一旦確定，返工和排查問(wèn)題的成本都很高，但數(shù)據(jù)埋點(diǎn)之后的分析工作，又涉及到了PD、BI、算法、數(shù)據(jù)等多個(gè)角色。因此非常有必要，將需求內(nèi)容和數(shù)據(jù)口徑統(tǒng)一收口，所有人在一套口徑下，將需求定義出來(lái)，隨后業(yè)務(wù)側(cè)再介入，進(jìn)行埋點(diǎn)方案的設(shè)計(jì)和開(kāi)發(fā)。
以前文提到的4W1H模型為例，常見(jiàn)的記錄內(nèi)容如下：
最后我們統(tǒng)計(jì)時(shí)，按照上述約定，統(tǒng)計(jì)用戶在某個(gè)時(shí)間和地點(diǎn)中，看到了哪些信息，并完成了怎樣的動(dòng)作。上下游的相關(guān)人員，在使用這份數(shù)據(jù)時(shí)，產(chǎn)生的歧義或者是分歧，會(huì)小很多。
第二步，埋點(diǎn)申請(qǐng)。
當(dāng)下的熱門(mén)應(yīng)用，大多是以超級(jí)APP的形式出現(xiàn)，比如微信、淘寶、支付寶、抖音，超級(jí)APP會(huì)承載非常多的業(yè)務(wù)，因此技術(shù)方案上會(huì)十分統(tǒng)一。
因此，當(dāng)我們的技術(shù)方案確定后，通常要在相應(yīng)的埋點(diǎn)平臺(tái)上，進(jìn)行埋點(diǎn)申請(qǐng)。申請(qǐng)的內(nèi)容包括分配的SPM、SCM碼是什么，涉及到的平臺(tái)是哪些，等等。SPM、SCM是什么，有什么用，同樣可以自行查閱。
第三步，技術(shù)開(kāi)發(fā)。
當(dāng)需求確定、申請(qǐng)通過(guò)后，我們就可以開(kāi)始開(kāi)發(fā)動(dòng)作了，這里基本上是對(duì)研發(fā)同學(xué)進(jìn)行約束。埋點(diǎn)的開(kāi)發(fā)，簡(jiǎn)單講，是分成行為埋點(diǎn)和事件埋點(diǎn)兩個(gè)大類(lèi)，每一類(lèi)根據(jù)端的不同進(jìn)行相應(yīng)的開(kāi)發(fā)。具體的技術(shù)方案詳見(jiàn)前文01章節(jié)。
詳細(xì)的設(shè)計(jì)規(guī)范，是需要留文檔的，因?yàn)榇a不能反應(yīng)業(yè)務(wù)的真實(shí)意圖，而不論是事后復(fù)盤(pán)與業(yè)務(wù)交接，都需要完整的文檔來(lái)闡述設(shè)計(jì)思路。
第四步，埋點(diǎn)驗(yàn)證。
埋點(diǎn)的驗(yàn)證很關(guān)鍵，如果上線后才發(fā)現(xiàn)問(wèn)題，那么歷史數(shù)據(jù)是無(wú)法追溯的。
驗(yàn)證有兩種方式，一種是實(shí)時(shí)的功能驗(yàn)證，一種是離線的日志驗(yàn)證。
實(shí)時(shí)功能驗(yàn)證，指功能開(kāi)發(fā)好后，在灰度環(huán)境上測(cè)試相應(yīng)的埋點(diǎn)功能是否正常，比如點(diǎn)擊相應(yīng)的業(yè)務(wù)模塊，日志是否會(huì)正確的打印出來(lái)。通常而言，我們需要驗(yàn)證如下三個(gè)類(lèi)型的問(wèn)題：
除去實(shí)時(shí)驗(yàn)證，我們也需要把日志寫(xiě)到測(cè)試環(huán)境中，查看數(shù)據(jù)上報(bào)的過(guò)程是否正確，以及對(duì)上報(bào)后的數(shù)據(jù)進(jìn)行統(tǒng)計(jì)，側(cè)面驗(yàn)證記錄的準(zhǔn)確性，如統(tǒng)計(jì)基本的PV、UV，行為、事件的發(fā)生數(shù)量。
很多時(shí)候，數(shù)據(jù)是需要多方驗(yàn)證的，存在一定的上下游信息不同步問(wèn)題，比如對(duì)某個(gè)默認(rèn)值的定義有歧義，日志統(tǒng)計(jì)會(huì)有效的發(fā)現(xiàn)這類(lèi)問(wèn)題。
第五步，發(fā)布上線。
應(yīng)用的發(fā)布上線通常會(huì)有不同的周期，例如移動(dòng)端會(huì)有統(tǒng)一的發(fā)版時(shí)間，而網(wǎng)頁(yè)版只需要根據(jù)自己的節(jié)奏走，因此數(shù)據(jù)開(kāi)始統(tǒng)計(jì)的時(shí)間是不同的。最后，應(yīng)用應(yīng)當(dāng)對(duì)所有已發(fā)布的埋點(diǎn)數(shù)據(jù)，有統(tǒng)一的管理方法。
大多數(shù)時(shí)候，數(shù)據(jù)埋點(diǎn)的技術(shù)方案，只需要設(shè)計(jì)一次，但數(shù)據(jù)準(zhǔn)確性的驗(yàn)證，卻需要隨著產(chǎn)品的生命周期持續(xù)下去，因此僅僅依靠人肉來(lái)準(zhǔn)確性驗(yàn)證是不夠的，我們需要平臺(tái)來(lái)支持自動(dòng)化的工作。埋點(diǎn)的準(zhǔn)確性，大體有兩種方法保障：一種是灰度環(huán)境下驗(yàn)證真實(shí)用戶數(shù)據(jù)的準(zhǔn)確性；另一種則是在線上環(huán)境中，驗(yàn)證全量數(shù)據(jù)的準(zhǔn)確性。因此，發(fā)布上線之后，后續(xù)的管理動(dòng)作，應(yīng)該是對(duì)現(xiàn)有流程的自動(dòng)化管理，因?yàn)閳F(tuán)隊(duì)大了，需要埋點(diǎn)的東西多種多樣，讓平臺(tái)自己測(cè)試、自動(dòng)化測(cè)試，就是很多測(cè)試團(tuán)隊(duì)必須走的路。
目前行業(yè)中，已經(jīng)有很多比較成熟的數(shù)據(jù)統(tǒng)計(jì)平臺(tái)，大家對(duì)于數(shù)據(jù)埋點(diǎn)也都有自己的方案。常見(jiàn)的有：GrowingIO、神策數(shù)據(jù)、百度統(tǒng)計(jì)、谷歌分析、友盟等。官網(wǎng)都有比較詳細(xì)的介紹，這里不再贅述。
數(shù)據(jù)埋點(diǎn)只是技能的一種，通過(guò)埋點(diǎn)的數(shù)據(jù)，如何去做分析，其實(shí)也很重要。做過(guò)互聯(lián)網(wǎng)的同學(xué)，基本都會(huì)有自己的寶藏庫(kù)，來(lái)看看業(yè)界的同行都是如何分析問(wèn)題的，著名的如艾瑞咨詢的數(shù)據(jù)報(bào)告。其實(shí)再高大上的報(bào)告，歸根結(jié)底，也是通過(guò)數(shù)據(jù)+模型來(lái)分析得到的結(jié)論。
最后說(shuō)說(shuō)自己做數(shù)據(jù)埋點(diǎn)方案的利弊。一些流量型的業(yè)務(wù)模型，使用第三方是沒(méi)有問(wèn)題的，因?yàn)榈谌酵ǔＬ峁┝撕軓?qiáng)大、很完備的功能，穩(wěn)定性也有保障，但缺點(diǎn)是，無(wú)法做平臺(tái)規(guī)則之外的數(shù)據(jù)埋點(diǎn)。但如果業(yè)務(wù)數(shù)據(jù)是非常敏感的，比如金融相關(guān)，那么還是建議自己做技術(shù)方案，且現(xiàn)有的數(shù)據(jù)埋點(diǎn)方法，都是基于流量分析平臺(tái)來(lái)做的，對(duì)于一些偏傳統(tǒng)的業(yè)務(wù)場(chǎng)景，其實(shí)并不是非常適用。
最后，數(shù)據(jù)埋點(diǎn)，只是一種技術(shù)或者是工具，想要得出有價(jià)值的分析成果，需要有有科學(xué)的分析模型做指導(dǎo)，也需要有正確的學(xué)習(xí)路線來(lái)堅(jiān)持。
*請(qǐng)認(rèn)真填寫(xiě)需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
