关于mysql:Matomo-从了解到落地页面流量统计与分析最佳实践

背景

在开发面向外部应用的「内容治理平台」的过程中，咱们不时会收到一些页面问题的反馈，但在本地调试的过程中，有大量无奈在本地重现的问题，这些问题的呈现跟用户的拜访设施、网络环境、拜访门路可能存在关联。为了方便快捷地去定位这些问题，咱们试图为所有页面点击操作都加上打点记录，但在实际操作中，因为业务变更频繁，开发框架的限度，展现打点数据较为简单等因素，通过打点排查问题的实际效果并不现实，因而咱们心愿引入残缺的流量统计和用户行为剖析来定位问题。

不同的计划剖析比照

对于流量统计和用户行为剖析记录的工具，行业内曾经有大量成熟的解决方案，绝对于自行打点，这些专门的流量通过平台和工具对于业务的根本没有侵入性，也解决了如何展现数据的问题。这些平台和工具中，有驰名的 Google Analytics、百度统计、WebTrends 等，也有绝对冷门的明天的配角 —— Matomo，而这些计划之间各有优劣：

通过比照，Matomo 整体性能比拟弱小，对标了 Google Analytics 但在安全性和私密性方面更优，反对私有化部署，代码和数据都能够不走漏给第三方，并且能够通过插件的机制配合业务实现自定义，这些长处都是咱们最终抉择 Matomo 作为「内容治理平台」用户记录的工具的起因。

Matomo 是什么？

这里介绍一下 Matomo，作为一套基于 PHP 与 MySQL 的网页流量统计和剖析平台，它的大部分性能曾经开源，并且做了很好的封装，能够轻松地进行私有化部署，它的性能次要分成两块：

• 收集并存储页面拜访数据，次要是用户信息，如设施型号、分辨率、用户地区、起源，以及页面信息，如页面拜访门路、拜访操作等。
• 对收集起来的数据进行指标量化并可视化的展现，例如用户设施型号散布、地区散布、某个页面的浏览人数、拜访最多的页面、某个用户在某个页面的拜访门路和具体操作 等，并且在收集数据时，Matomo 会有大量的策略爱护用户隐衷，例如上报 IP 时暗藏最初一位字节等。

在理论应用时，用户信息的上报以及页面的拜访门路，只须要装置并引入 Matomo 即可实现，无需额定的配置。然而 开发者能够通过接口加强上报的数据，例如上报某个弹窗的展现，或者上报某个申请的后果，这样最终能够在平台上展现出残缺的用户拜访门路和操作，联合业务日志，能够很精确地定位问题以及还原问题的触发门路。

Matomo 落地到业务

在引入 Matomo 之前，先阐明一下 Matomo 的次要组成追踪器和 Matomo 服务端，追踪器基于 JS 实现，须要在网页引入，用于上报数据。服务端次要提供了三个性能：

• HTTP 接口，追踪器能够收集所在网页的数据但不上报，通过 HTTP 接口发送给 Matomo。
• 归档工作运行并预处理数据，默认分为实时动静解决（页面拜访数据，用户拜访轨迹）和 cron 工作解决（用户维度的列表）。
• 可视化展示数据，也能够数据接口或者报表接口来拜访这些数据。

引入简略落地不易

Matomo 有很成熟封装，因而自身部署很简略，次要分为两个步骤：

1. 部署私有化 Matomo 服务。
2. 在须要流量统计 ide 页面上引入追踪器。

其中部署私有化服务只须要下载 Matomo 的程序并上传到服务端，而后关上拜访地址就能够应用疏导程序部署服务，包含检测服务器环境是否符合要求，填写数据库信息，创立治理账号等，具体参考官网文档。

但在理论落地到内容平台的过程中，却遇到了问题——咱们须要基于 Docker 进行部署。

因为业务的部署都基于 Docker 和 k8s 进行，因而私有化的 Matomo 也须要基于此进行部署，这样会带来几个问题：

1. Matomo 的设置分成系统配置与性能设置，其中性能设置贮存在 MySQL 中，而零碎设置则贮存在本地的配置文件中，当部署多个容器时，配置无奈对齐，另外 Docker 重新部署后，这些配置批改也会失落。
2. 这套部署须要域名 + 门路的模式拜访 Matomo，Matomo 社区镜像中是应用 Apache2 进行路由解决的，而 Apache2 默认的配置并不适配门路，须要批改 Apache 的配置文件。

解决在 Docker 中部署 Matomo 的问题

Matomo 有官网公布的社区镜像能够间接应用，但为了解决上述的问题，须要在构建 Docker 镜像时进行额定的解决。

解决配置失落的问题

Matomo 的配置文件是 config/config.ini.php，不追随版本治理，为了获取一份默认的配置文件，能够用社区镜像事后部署好一个 Matomo 容器，并在容器中获取一份默认的配置文件，例如：

[database]
host = "${MATOMO_DATABASE_HOST}"
username = "${MATOMO_DATABASE_USERNAME}"
password = "${MATOMO_DATABASE_PASSWORD}"
dbname = "${MATOMO_DATABASE_DBNAME}"
tables_prefix = "${MATOMO_DATABASE_TABLES_PREFIX}"
charset = "utf8mb4"
multi_server_environment = 1
enable_installer = 0

[General]
force_ssl = 0
assume_secure_protocol = 1
proxy_client_headers[] = "HTTP_X_FORWARDED_FOR"
proxy_client_headers[] = "HTTP_X_ORIGINAL_FORWARDED_FOR"
proxy_host_headers[] = "HTTP_X_FORWARDED_HOST"
salt = "xxxx" // 加密串，用于解密配置内容
trusted_hosts[] = "weread.qq.com"

[Plugins]
Plugins[] = "CorePluginsAdmin"
// ...
// 须要启动的插件列表，因为篇幅无限，省略默认的启动插件

[PluginsInstalled]
PluginsInstalled[] = "Diagnostics"
// ...
// 所有插件列表，，因为篇幅无限，省略默认的插件列表

复制出默认的配置文件后，即可依据业务进行批改，次要包含：

1. 数据库的配置，倡议应用环境变量进行配置。
2. salt 是用于解密配置内容的加密串，保留默认配置中的值即可。
3. trusted_hosts[] 是部署 Matomo 的域名，反对多个域名配置，必须正确填写，否则无奈应用。
4. Plugins[] 和 PluginsInstalled[] 别离是须要启用的插件和总插件列表，有须要调整插件的激活状态能够自行调整。

在批改实现后，能够利用 Docker 的命令把自定义的配置文件笼罩到镜像中，例如：

# 复制配置文件
COPY config.ini.php /var/www/html/config/config.ini.php

解决子目录部署的问题

Matomo 部署实现后，会以 weread.qq.com/weread-matomo 的模式去拜访 Matomo 的服务，因而依据默认的 Apache2 配置，会尝试在 weread-matomo 这个目录中读取 Matomo，但实际上咱们的 Matomo 是部署在根目录的，因而须要批改 Apache2 的配置文件，把针对 ^/weread-matomo 的拜访指向根目录。

值得注意的是，出于平安思考，咱们不心愿把 Matomo 的治理后盾裸露到外网，因而在 Apache2 的配置中，能够通过正则指定只有追踪器相干的文件裸露到外网能够拜访，不便业务引入。在理解了 Matomo 的源码后，追踪器相干的文件次要有 matomo.js 和 matomo.php，其中 matomo.php 结尾会带有参数，因而最终的 AliasMatch 规定如下：

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    AliasMatch ^/weread-matomo/(matomo\.(js|php).*) /var/www/html/$1

    <Directory /var/www/html>
        Options All
        AllowOverride All
        order allow,deny
        allow from all
    </Directory>
</VirtualHost>

社区镜像中 Apache2 的配置文件寄存在 /etc/apache2/sites-available/000-default.conf，把下面的配置内容在本地保留一份 000-default.conf 后，在构建 Docker 镜像时利用命令笼罩默认的 Apache2 配置：

COPY 000-default.conf /etc/apache2/sites-available/000-default.conf

无奈显示城市信息

在解决了下面两个问题后，Matomo 的私有化部署根本曾经跑通了，但后续咱们发现，这样上报的数据中，并没有显示城市信息，Matomo 是基于 IP 信息来断定城市的，而 Matomo 自带的 IP 库仅能辨认国家信息。

如上图所示，城市都显示为“未知”。为了解决这个问题，须要引入 IP 地址库，Matomo 反对 DBIP 和 GeoIP 2 两个内部的地址库，地址库的格局都是一种非凡的地址库 .mmdb 格局。

这里倡议应用 GeoIP，在这里实现注册后，能够下载 .mmdb 格局的地址库。为了让 Matomo 辨认出额定的地址库，须要把 .mmdb 搁置到我的项目的 misc 目录，但因为 Matomo 应用了 Docker 部署，因而须要用 Docker 命令把 .mmdb 文件复制到容器的 misc 目录，最终残缺的 Dockerfile 如下：

# Dockerfile

FROM matomo:latest

MAINTAINER kayoli

# 复制 Apache2 配置文件
COPY 000-default.conf /etc/apache2/sites-available/000-default.conf

# 复制 Matomo 配置文件
COPY config.ini.php /var/www/html/config/config.ini.php

# 引入 IP 地址库，用于显示 IP 对应的城市
COPY mmdb/GeoLite2-ASN.mmdb /var/www/html/misc/GeoLite2-ASN.mmdb
COPY mmdb/GeoLite2-City.mmdb /var/www/html/misc/GeoLite2-City.mmdb
COPY mmdb/GeoLite2-Country.mmdb /var/www/html/misc/GeoLite2-Country.mmdb

前端引入追踪器也有坑

页面引入追踪器

通过下面的解决，曾经解决了在 Docker 中部署服务端的问题，在 Matomo 的部署疏导程序在实现后，会输入一段 JS 代码，用于给业务前端引入追踪器，例如：

<!-- Matomo -->
<script type="text/javascript">
  var _paq = window._paq = window._paq || [];
  /* tracker methods like "setCustomDimension" should be called before "trackPageView" */
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="//xxxx"; // 私有化部署 Matomo 的域名
    _paq.push(['setTrackerUrl', u+'matomo.php']);
    _paq.push(['setSiteId', '1']);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.type='text/javascript'; g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
  })();
</script>
<!-- End Matomo Code -->

Matomo 的追踪器蕴含了大量的选项和办法，次要包含：

1. Tracker Object，用于记录某个行为，例如下面代码中的 trackPageView 则用于记录某个页面被拜访，enableLinkTracking 则是用于开启链接跳转时自动记录的性能。
2. Configuration of the Tracker Object，用于配置 Tracker Object，例如 setDocumentTitle 能够笼罩上报页面的题目，默认是获取 document.title。
3. Ecommerce，电商相干的办法，提供了一系列记录商品信息的办法。
4. Managing Consent，提供了一种机制来治理用户的跟踪上报。

具体能够参考文档。

自动记录 Vue SPA 的页面跳转

胜利引入追踪器后发现，「内容治理平台」上报的用户行为，只有关上页面的操作，跳转页面并没有胜利上报，然而默认的追踪器代码中，曾经开启了 “ 选项。

在 Matomo 的源码中，能够看到对 “ 的阐明：

 // @param bool enable Defaults to true.
 //    If "true", use pseudo click-handler (treat middle click and open contextmenu as
 //    left click). A right click (or any click that opens the context menu) on a link
 //    will be tracked as clicked even if "Open in new tab" is not selected.
 //      If "false" (default), nothing will be tracked on open context menu or middle click.
 //    The context menu is usually opened to open a link / download in a new tab
 //    therefore you can get more accurate results by treat it as a click but it can lead
 //    to wrong click numbers.
 //
this.enableLinkTracking = function (enable) {
    linkTrackingEnabled = true;
    // ...
};

也就是说，这个选项仅对 link，也就是常见的 <a href="xxxx"> 链接 </a> 这种模式的跳转才起作用，而「内容治理平台」是基于 Vue 开发的 Spa，页面跳转不是链接跳转，因而上报的记录里只有关上页面。

要解决这个问题，能够在 Vue 进行跳转时被动调用 Matomo 的上报，但实际上曾经有开源的插件实现了这个，例如 vue-matomo，具体应用能够参考它的应用文档。

值得注意的是，vue-matomo 对 matomo 的初始参数进行封装，除了文档中列出来的选项，其余选项在初始化的时候是有效的，能够在 vue-matomo 初始化后，通过 _paq.push(['xxx']) 调用，_paq 对象的 push 办法曾经被重写，调用 push 办法实际上相当于把某个办法放入调用队列并进行调用。

Matomo 的最佳实际

通过下面的踩坑和填坑后，Matomo 最终得以在「内容治理平台」中落地投入使用，在通过一段时间的实际后，现有的自动记录还是不能满足咱们的需要，例如咱们须要主动上报 JS 错误信息，在点击 UI 元素时也须要上报，另外还须要在申请谬误时进行主动上报。在通过一系列实际后，总结了一些最佳实际。

自动记录 JS 谬误

在新版 Matomo 中，反对开启主动上报 JS 谬误的性能，但性能尚未正式公布，因而官网文档中没有该性能的阐明，须要调用的话能够通过 window._paq.push(['enableJSErrorTracking']); 开启该性能，为了爱护 _paq 没有初始化好的状况，能够先判断 _paq 是否存在，例如：

const enableJSErrorTracking = (): void => {if (window._paq) {window._paq.push(['enableJSErrorTracking']);
  } else {console.warn('can not found window._paq');
  }
};

被动上报更多操作

除了链接跳转，页面中通常还会有一些 UI 操作不波及链接变动，也不波及申请，这类操作能够应用追踪器提供的 Tracker Object 进行被动上报，为了不便起见，能够抽取成工具办法，例如：

// 上报一个事件，例如点击事件，播放事件等，在被动上报中比拟罕用。export const trackEvent = (category: string, action: string, name?: string, value?: number): void => {if (window._paq) {window._paq.push(['trackEvent', category, action, name, value]);
  } else {console.warn('can not found window._paq');
  }
};

// 二次封装，专门上报弹窗的动作，例如 action 参数能够填写 show, close
export const trackDialogEvent = (action: string, name?: string, value?: number): void => {if (window._paq) {window._paq.push(['trackEvent', 'Dialog', action, name, value]);
  } else {console.warn('can not found window._paq');
  }
};

// 上报谬误
export const trackErrorEvent = (action: string, name?: string, value?: number): void => {if (window._paq) {window._paq.push(['trackEvent', 'Error', action, name, value]);
  } else {console.warn('can not found window._paq');
  }
};

// 上报搜寻动作
export const trackSiteSearch = (keyword: string, category?: string, resultsCount?: string): void => {if (window._paq) {window._paq.push(['trackSiteSearch', keyword, category, resultsCount]);
  } else {console.warn('can not found window._paq');
  }
};

申请失败主动上报

业务中波及申请的操作通常都比拟要害，申请失败主动上报有利于记录下残缺的用户动作门路，不便定位问题，在咱们的业务中，咱们的申请都是应用 Axios 收回的，因而能够利用 axios interceptors 劫持所有申请，在遇到指定谬误时主动上报到 Matomo，例如：

const baseURL = 'xxx';
// axios instance
const service = axios.create({
  baseURL,
  timeout: 60000,
});

service.interceptors.response.use((response: AxiosResponse) => {const errCode = response.data && (response.data.errCode || response.data.errcode);
    if (errCode && errCode < 0) {
      const URL = response.config && response.config.url;
      const errMsg = response.data && (response.data.errMsg || response.data.errMsg);
      trackErrorEvent(URL, errMsg, errCode);
    }
    return response;
  },
  (error) => {return Promise.reject(error);
  }
);

至此，曾经能够很精确展现用户在拜访页面时的残缺操作门路了，开发者能够通过这些操作门路，联合业务日志，不便地去定位问题以及还原问题。

成果展现

通过以上的解决，当初曾经能够上报十分丰盛的拜访数据，以及用户门路了，例如：

访客剖析 – 拜访日志

能够看到，界面上显示了残缺的用户操作，通过时间轴的模式，配合不同的关键词和 icon 能够很好地呈现出理论的操作门路。

访客剖析 – 设施

除了设施，在 Matomo 中还有地区等用户维度，并且 Matomo 在不同的数据展现中，例如指标转化率等，都能够基于这些不同的维度进行展现，对于剖析用户组成相当不便。

转化与收益剖析 – 概览

Matomo 反对设定指定的指标，用于计算转化率，并进行多个维度的展现，包含转化流向，每个阶段的转化人数和转化率等，并且能够通过不同的维度，例如渠道类型、城市、设施类型别离展现各种维度下的转化数据，这也是 Matomo 一种重要的个性，数据的展现维度丰盛。

另外，Matomo 的插件机制也十分弱小，能够插入自定义的数据，注入到各个界面或者基于 Matomo 本身收集的数据从新展现，基于篇幅所限，后续再对 Matomo 的插件机制进行实际阐明。

Matomo 的性能剖析与局限性

从下面的阐明中能够看出，Matomo 的剖析功能强大，剖析的维度也很丰盛，但同时也带来了较大的服务端资源耗费。

Matomo 的架构能够撑持千万级甚至亿级的月 PV，但同时对于服务端的 CPU，RAM 和硬盘空间都有相应的要求。因而在理论应用时，须要留神以后服务端的配置是否足以撑持上报页面的 PV 量，否则会导致 Matomo 无奈及时处理数据甚至解体。

量化性能剖析

• Matomo 的默认配置是 1GB 内存，在默认配置下，Matomo 能够轻松撑持 1000 PV/ 天的访问量，对于这种级别的访问量，通常是一些外部平台或者面向特定人群的辅助页面。
• 对于 3000 PV/ 天访问量的业务，则倡议应用 2 核 CPU，2GB RAM，50GB 硬盘 的配置。
• 对于 30000 PV/ 天访问量的业务，则倡议应用 4 核 CPU，8GB RAM，250GB 硬盘 的配置，这个量级的拜访能够是 面向公众用户的业务页面了。
• 对于 300000 PV/ 天访问量的业务，倡议把 PHP 服务端和 MySQL 离开部署，对于这种量级的业务，MySQL 的瓶颈会更加显著，把 MySQL 部署进行独自部署，会更加稳固，倡议最低的配置是 8 核 CPU，16GB RAM, 100GB 硬盘的机器作为 PHP 服务端，8 核 CPU, 16GB RAM, 400GB 硬盘作为 MySQL 服务，。
• 对于更高访问量的业务，能够再叠加机器配置，硬盘空间主页是给 MySQL 耗费用的，一个参考数据是：大略每减少 500 万 PV，数据库就会减少 1GB 的数据。

能够看到，对于高访问量的业务，须要给予 Matomo 大量的服务器资源能力撑持，具体来说，超过 30000 PV/ 天的业务就须要留神了。因而在业务中引入时，能够思考业务引入上报的必要性，如果页面性能繁多，操作门路少，例如展现型的 H5 页面，其实引入 Matomo 的作用不是很大。

优化 Matomo 的性能的最佳实际

• Matomo 对于 PHP 的最低版本要求是 PHP5，但尽量应用 PHP7，PHP7 在性能上有大量的优化。
• 应用 PHP cache，PHP5 及以上版本默认开启了。
• 通过调整 Innodb 配置来优化 MySQL 的性能，例如减少 innodb_buffer_pool_size 来适应内存大小，另外能够把 innodb_buffer_pool_size 设置为 MySQL 可用内存的 80%。增大 innodb_flush_log_at_trx_commit 来减少追踪器的吞吐量，具体能够参考这里。
• 业务访问量比拟大的时候（例如 300000 PV/ 天的访问量），能够敞开实时动静解决的性能（治理 – 零碎 – 通用设置 – 归档设置 – 在浏览器中查看报告时进行归档 – 否），敞开实时动静解决后，页面拜访数据和用户拜访轨迹也须要期待 cron 工作进行数据处理后能力展现，归档工夫倡议是设置为 3600 秒，加重服务端的累赘。
• 对于 URL 带 Query 的状况，如果无须要辨别 Query 进行数据分析的状况，能够抉择疏忽这些 Query（治理 – 网站 – 治理 – 编辑网站 – 排除参数），否则同一个 URL 带有不同 Query，Matomo 会当作不同的 URL 来解决，大大增加 MySQL 的累赘。
• 定期删除旧数据（治理 – 隐衷设置 – 匿名化数据 – 定期删除旧的原始数据），旧数据的删除能够减小数据库的大小，既节俭硬盘空间，也放慢了数据的解决。