ZDREAM - Thassarian 的个人博客
前途是光明的，道路是曲折的
目 录CONTENT
以下是
学习笔记
相关的文章
-
针对网站的用户行为分析：Matomo本地部署及踩坑记录 一、前言作为一个长期和数据打交道的人，我对各类数据指标有着近乎本能的关注。在维护自己的这个小网站时，很自然地就想到了要引入一套用户行为分析工具。它不仅能满足我个人的好奇心，了解一下都有谁、在什么时间、通过什么方式访问了这里，长期来看，这些数据的沉淀也能为网站内容的优化方向提供一些客观的参考。市面上的选择很多，比如强大的 Google Analytics。但在当前环境下，我更倾向于一个能将数据完全保留在自己服务器上的解决方案。这不仅是为了彻底的“数据私有”，也是出于一种技术上的“掌控感”。经过一番调研，开源的 Matomo 进入了我的视野。它功能全面，社区活跃，最关键的是，它支持完全本地化部署。为什么是 Matomo？在正式开始部署前，简单梳理一下选择 Matomo 的几个核心理由：数据所有权: 这是最重要的一点。所有访客数据都存储在自己的数据库里，不必担心隐私泄露或数据被用于其他目的。对于一些只在内网访问的政务系统，这种方案更是刚需。功能完备: 从实时访客、行为路径，到流量来源、设备统计，乃至转化漏斗分析，社区版的功能已经足够强大，完全可以满足个人网站和中小型项目的分析需求。开源免费: 无需承担额外的服务费用，只需要投入服务器资源和一些折腾的时间。良好的兼容性: 除了常规的网站，它同样支持对 APP、小程序甚至 IoT 设备的数据进行追踪，扩展性很好。二、部署体验1.平台部署和现在大多数应用一样，Matomo 的部署首选方案自然是 Docker。官方提供了相当完善的 Docker 镜像和部署指南，这让初始启动变得非常简单。我个人习惯使用 docker-compose 来编排容器，这样能更清晰地管理服务和数据卷。 一个基础的 docker-compose.yml 文件大概是下面这样，包含 Matomo 应用本身和一个独立的数据库服务。详细配置参考：https://github.com/matomo-org/docker/blob/master/.examples/nginx/compose.yml启动命令：docker run --rm --volumes-from="matomo-app-1" --link matomo-app-1 python:3-alpine python /var/www/html/misc/log-analytics/import_logs.py --url=http://ip.of.your.matomo.example --login=yourlogin --password=yourpassword --idsite=1 --recorders=4 /var/www/html/logs/access.log2.踩坑看似简单的部署，很快就遇到了第一个门槛：SSL 配置。Matomo 在初始化安装完成后，会强制要求使用 HTTPS 访问。这本身是一个非常合理的安全设定，但问题在于，官方的 Docker 镜像中，默认的 Apache 服务并未开启 SSL 模块。这就导致了一个矛盾：如果我在 docker-compose 里直接将容器的 443 端口映射出来并配置好域名，Matomo 在首次启动时会因为自身 Apache 不支持 SSL 而启动失败。这是一个典型的“先有鸡还是先有蛋”的问题。正确的解决思路是分两步走： 1. 先以 HTTP 方式完成 Matomo 的初始化安装。 2. 进入容器内部，手动为 Apache 配置 SSL，然后再将服务切换到 HTTPS。具体的步骤记录如下： #第一步：进入正在运行的 Matomo 容器。 bash docker exec -it matomo bash #第二步：在容器内为 Apache 启用 SSL 模块并重启服务。 a2enmod ssl service apache2 restart #第三步：修改 Matomo 的站点配置文件，添加 HTTPS 监听和证书配置。 nano matomo:/var/www/html/config/config.ini.php #添加https监听 <VirtualHost *:443> ServerName your.domain.com SSLEngine on SSLCertificateFile /etc/ssl/certs/fullchain.pem SSLCertificateKeyFile /etc/ssl/certs/privkey.pem </VirtualHost> #第四步：再次重启容器中的apache docker exec -it matomo service apache2 restart每次容器升级时（apache爆出的漏洞有点多，不升级不放心），证书问题都要重新处理一遍。3.网站接入部署完成后，剩下的工作就简单了。Matomo 会提供一段 JavaScript 追踪代码，只需要将它嵌入到网站所有页面的 <head> 标签里即可，比如说Halo的代码注入全局标签：对于使用 Vue 这类前端框架构建的单页面应用（SPA），虽然直接添加到index.html就能够实现访客IP时间等记录，但是无法区分出来用户具体访问了哪些页面，如果想详细的页面浏览情况分析，就需要额外配置路由切换时的页面追踪，官方文档中也有相应的说明：https://matomo.org/faq/new-to-piwik/how-do-i-install-the-matomo-tracking-code-on-websites-that-use-vue-js/?mtm_campaign=Matomo_App&mtm_source=Matomo_App_OnPremise&mtm_medium=App.CoreAdminHome.trackingCodeGenerator4.查看效果数据开始汇入后，Matomo 的仪表盘就变得鲜活起来。默认的仪表盘提供了丰富的信息模块，可以直观地看到实时的访客数量、访客的地理位置分布、访问趋势图、流量来源渠道、用户使用的操作系统和浏览器等。默认情况下，为了保护访客隐私，IP 地址是做了脱敏处理的，当然这个也可以根据需要进行修改。 通过这些数据，我可以清晰地看到哪些文章更受欢迎，访客是通过搜索引擎还是直接链接访问过来的。这些看似简单的信息，背后却能反映出很多问题，对于后续内容的调整和网站的优化，无疑是很有价值的。如果vue项目不针对性设置的话就会出现图里这种所有人只访问了/index的情况 ↑可以查看详细日志，默认是IP脱敏的，可以配置取消掉。总的来说，Matomo 的部署虽然比使用第三方 SaaS 服务要复杂一些，但整个过程完全在可控范围内。它最终交付给我的是一个完全私有、功能强大的网站分析平台，这种“拥有感”是任何第三方服务都无法替代的。 对于注重数据隐私的个人站长，或是需要对内部系统进行用户行为追踪的中小型项目来说，Matomo 无疑是一个值得投入时间去配置和使用的工具。它不仅是一个工具，其部署和配置的过程，本身也是一次不错的技术实践。 -
-
-
-
-
-
网络问题排查的一些常用命令与思路 排查网络问题，本质上是一个由表及里、逐层排除的过程。比较稳妥的思路是：先点到点（ping） -> 再到端口（telnet） -> 再看路径（traceroute）。同时结合 服务端自查（netstat、curl），逐步缩小问题范围。如果问题指向中间网络，再深入到防火墙策略和路由规则。一、 客户端/终端侧排查第一步排查始于问题发生点，无论是开发人员的本地环境、用户的PC，还是发起API调用的另一台服务器，都可以视作“客户端”。1. ping最基础也最常用的命令，用于检查网络连接的基本可达性。它通过ICMP协议发送回声请求，测试目标主机是否在线以及网络延迟。ping 114.114.114.114看到类似 time=...ms TTL=... 的返回，说明至少在网络层面上，你的设备和目标服务器之间是连通的。如果超时（Timeout），则说明网络不通，或者对方禁用了ICMP协议（部分服务器会出于安全考虑关闭ping响应）。2. ipconfig / ifconfig用于查看本地网络配置。在采取任何行动前，先确认自己的网络配置是否正确。Windows: ipconfigLinux/macOS: ifconfig 或 ip addr主要关注点是本机IP地址、子网掩码和默认网关。有时候问题仅仅是本地IP配置错误或DHCP没有获取到正确地址。3. traceroute / tracert如果 ping 不通，或者延迟很高，可以用这个命令来探测数据包从源到目的地所经过的路由路径。Windows: tracertLinux: traceroutetracert www.example.com它会列出数据包经过的每一个路由器（“跳”）。如果在某一跳开始出现 * * * 或高延迟，问题很可能就出在那个节点或其后的链路上。这对于判断问题是出在内部网络、运营商网络还是目标网络非常有帮助。4. telnet / ncping 只能确认网络层（IP层）的可达性，但服务通常运行在传输层（TCP/UDP）的特定端口上。telnet 或 netcat(nc) 可以用来检查某个IP的特定端口是否开放和监听。# 检查目标服务器的8080端口是否开放 telnet 192.168.1.100 8080如果屏幕变黑或显示连接成功信息，说明端口是开放的，应用正在监听。如果提示“Connection refused”，说明服务器拒绝了连接，可能是服务未启动或防火墙拦截。如果长时间无响应，说明请求在中间某个环节被丢弃了，很可能是网络设备（如防火墙）拦截了。二、 服务端侧排查如果客户端到服务器的路由是通的，但服务依旧不可用（例如 telnet 端口不通），焦点就要转移到服务器本身。1. netstat / ss用于检查服务器自身的网络连接和监听状态。ss 是 netstat 的一个更快、更现代的替代品。# 查看所有监听的TCP端口 netstat -tulnp # 或者使用ss，并过滤特定端口（如8080） ss -tuln | grep 8080这个命令可以快速确认服务是否已成功启动并在预期的端口上进行监听。如果没有找到对应的端口，那问题就是应用本身没有启动成功。2. curl / wget在服务器本地测试服务是否正常。这可以排除外部网络因素，验证应用本身的功能。# 从服务器本地访问自己的web服务 curl http://127.0.0.1:8080/health如果本地访问正常，但远程访问失败，那么问题几乎可以锁定在服务器的防火墙、安全组策略或上游网络设备上。3. tcpdump这是一个强大的网络抓包工具，是网络问题排查的“大杀器”。当其他方法都无法定位问题时，可以用它来捕获流经网卡的原始数据包，分析最底层的通信细节。# 抓取80端口的TCP流量 tcpdump -i eth0 tcp port 80 -nn通过分析抓包结果，可以清晰地看到TCP三次握手是否成功、数据传输是否完整、是否有异常的RST包等。4. 查看日志最后但同样重要的一点，检查应用日志、中间件日志（如Nginx、Tomcat）和系统日志（/var/log/messages 或 journalctl）。很多时候，连接问题会在日志中留下明确的错误信息。三、 网络设备/网关侧当终端和服务端自查都正常，问题很可能出在中间的链路上，比如公司的防火墙、路由器、交换机，或者云平台的安全组。这个层面通常需要网络管理员或有相应权限的运维人员介入。1. 访问控制/防火墙规则检查防火墙（无论是硬件防火墙、iptables，还是云厂商的安全组/NACL）的策略。这是最常见的“中间”问题。核心检查点： 是否允许来自源IP（或IP段）的流量访问目标IP的特定端口和协议（TCP/UDP）。规则遵循“最小权限”原则，默认拒绝所有未明确允许的流量。2. 路由规则在复杂的网络环境中，路由器需要知道如何将数据包转发到正确的目的地。核心检查点： 检查路由表。确认是否存在到达目标网段的正确路由，是否存在路由黑洞或错误的下一跳。在路由器或交换机上，通常使用 show ip route 或 display ip routing-table 等命令查看。
-
-
-
用金字塔原理做好汇报：穷举-归纳-总结 无论是周报、月报，还是临时的进展同步，繁多的汇报是一项无法回避的任务。面对繁杂的事务——系统维护、功能开发、临时需求、多方沟通——如何将这些信息组织成一份清晰、有力的汇报，而不仅仅是流水账式的罗列，是一个值得思考的问题。我对“金字塔原理”的理解是“穷举-归纳-总结”三步，并由此开展工作。第一步：穷举 - 把所有事情都摆上台面这是最基础，也是最原始的一步。在准备汇报前，先把所有与当前周期、当前项目相关的工作事项，不分大小、不分主次，全部列出来。这个阶段的目标是完整性，而非结构性。就像整理房间前，先把所有东西都拿出来摊在地上。通常，这个列表会包含以下内容：常规维护：解决了哪些线上问题，处理了多少用户工单，系统的运行状态如何。项目进展：计划内的功能开发到了哪个阶段（设计、开发、测试、上线），里程碑的达成情况。临时任务：响应了哪些计划外的需求，完成了哪些紧急的对接工作。沟通协调：与哪些合作方进行了会议，达成了什么共识，明确了哪些下一步计划。风险与问题：识别了哪些潜在风险，正在跟进或已经解决了哪些阻碍。团队内部事务：资源调配、技术评审等。“穷举”清单是后续所有工作的基础，它很凌乱，但确保了信息的全面，防止在后续整理中遗漏重要细节第二步：归纳 - 从无序到有序的梳理单纯的罗列是低效的，因为它把理解和分析的压力抛给了汇报的接收方。第二步的核心，就是对穷举出的事项进行分类和组织，找到它们背后的逻辑关联。如何归纳？没有唯一的标准，需要根据汇报的对象和目的来定。常见的归纳维度有：按工作模块：这是最直接的方式。例如，可以分为“平台稳定性保障”、“核心功能A升级”、“数据服务B优化”等几个大类。每个类别下，再放入对应的工作项。按目标导向：这种方式更进一步，关注工作的价值。例如，可以分为“提升系统性能与用户体验”、“响应核心业务需求”、“保障项目按期交付”等。这种分法能更好地体现工作的目的性。按项目状态：比如“已完成事项”、“进行中事项”、“下一步计划”。这种结构简单明了，适合用于快速的进展同步。归纳的过程，本身就是一次对工作的复盘和思考。它强迫我们去审视，每一件具体事务，究竟是为了服务于哪个更大的目标。当这些事项被有序地组织在一起后，工作的脉络就变得清晰可见了。第三步：总结 - 提炼核心结论，先说结果这是将信息结构化为“金字塔”的最后一步，也是最关键的一步。汇报的最终目的是传递信息和结论，而非单纯展示工作量。在完成了归纳之后，需要为每一个归纳好的类别提炼出一个小结。这个小结就是这个类别的“论点”。例如，在“平台稳定性保障”这个类别下，可能罗列了“修复了3个高优Bug”、“优化了数据库查询性能”、“完成了服务器安全补丁更新”等具体事项。那么，这个类别的小结就可以是：“本周平台整体运行平稳，关键性能指标得到优化。”当所有类别都有了各自的小结之后，再将这些小结进行整合，提炼出整个汇报的总览性结论，放在汇报的最顶端。一个结构化的汇报就此成型：总览结论：例如，“本周项目按计划顺利推进，核心功能开发完成，外部协作风险已得到控制。”分项论点1：平台稳定性得到提升，本周处理了X个高优问题。支撑事实1.1支撑事实1.2分项论点2：新功能模块A已完成开发，进入联调测试阶段。支撑事实2.1支撑事实2.2分项论点3：与合作方的对接工作取得进展，明确了下一步接口标准。支撑事实3.1这种“结论先行，以上统下”的结构，极大地降低了信息接收方的认知负荷。他们可以先快速了解整体情况，如果对某个部分感兴趣，再深入查看具体的支撑细节。写在最后从“穷举”的混乱，到“归纳”的有序，再到“总结”的清晰，这个过程不仅仅是一种汇报技巧，更像是一种思维习惯的养成。它帮助我们在纷繁的日常事务中，保持对整体目标的关注，并能够清晰、准确地将价值传递出去。这套方法并不复杂，贵在坚持实践。在每一次准备汇报时，都进行这样的结构化思考，久而久之，逻辑和条理便会内化于心。
