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