前言

前段时间有个 researcher 回报说，他可以通过使用 X-Frame-Bypass 来绕过我们站点的 X-Frame-Options 机制，从而将我们的站点内嵌在他的网页上，从而造成 Clickjacking

对于 Clickjacking 来说，我们一般是使用设置 X-Frame-Options header 来防止站点被第三方内嵌，具体可以看我之前的文章:

• web 页面防iframe嵌入（防止点击劫持Clickjacking）

通过 X-Frame-Options 我们可以很好的防止我们的站点被第三方内嵌。

那么 X-Frame-Bypass 是怎么绕过 X-Frame-Options 这个限制的呢?

分析

我后面看了一下他的代码，他的方式其实很简单，既然 X-Frame-Options 是在 response 的 header 返回的，那么我只要在请求的时候，先去通过第三方服务将我想要的站点的内容取出来，然后只转发这个 body 体，不转发 header，就可以绕过了。

举个例子，比如我内嵌别人站点的代码是这样子的:

1

<iframe src="https://api.codetabs.com/v1/proxy/?quest=https://test-example.com/my_test.html"></iframe>

这个逻辑很简单，就是这个 第三方 api.codetabs.com, 会去请求 https://test-example.com/my_test.html，并且将源代码返回，其实就是转发

前言

前段时间在项目的安全审计中，有发现了一个关于后端开发中，使用 aws sdk 的一个安全隐患，就是后端的一些项目中，有用到了 aws 的一些功能，包含 s3，ses，dynamodb 等，而这些功能用的 key 都是同一个 key， 都是属于在 aws 后台创建的 develop 用户。

这个 develop 用户在 aws 后台具有以下的策略权限(policy):

• dynamodb 功能的所有权限 –> AmazonDynamoDBFullAccess
• s3 功能的所有权限 –> AmazonS3FullAccess
• ses 功能的所有权限 – AmazonSESFullAccess

因为这个 develop 用户拥有的权限太大了， 一旦 key+secret 泄露了， 黑客就可以通过类似于 aws-cli 的命令行工具来做一些不好的事情，比如:

• 往 s3 上的 bucket 随意上传某些木马文件
• 修改 s3 bucket 的 acl 权限，将所有的 bucket 都改成公开桶，直接暴露在外网，或者给自己插入一个另一个账号的登录后门
• 直接使用 ses 发送垃圾邮件，然后受到投诉过多之后，就会可能导致这个 aws 账号被封禁
• 删除 dynamodb 的记录或者表

因此我们必须在后端开发中，根据具体项目所使用到的 aws 的功能，尽可能做最小化的权限分配，并且要设置请求的 ip 白名单，这样子一来，哪怕不小心这个用户的 key+secret 泄露了，我们也不用担心会造成太大的影响。

前言

经过上一节我们初步定义了一些标签的规范: prometheus + grafana 实战篇(1) - 定义标签组和规范, 本节我们来讲一下怎么监控 nginx

nginx

nginx 作为最受欢迎的 web server 之一，我的不少文章都有涉及到 nginx， 这边不再赘述。

我们假设在使用 prometheus 采集 nginx 之前，我们线上环境已经有 nginx 服务来跑了。

关于 nginx 的安装，可以看我的这一篇文章: CentOS 7 安装 Nginx

1
2
3
4

[root@VM-16-223-centos sbin]# netstat -anlp | grep 80
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      29841/nginx: master
tcp        0      0 172.26.16.223:37134     169.254.0.4:80          TIME_WAIT   -                   
udp6       0      0 fe80::5054:ff:fe23::123 :::*                                656/ntpd

nginx-vts-export

prometheus 常用的 nginx 的导出器，目前比较常用的是 nginx-vts-exporter

nginx_vts_exporter 依赖 nginx 的这个 nginx-module-vts 模块, 因此我们要先在 nginx 上重新编译安装 nginx-module-vts 模块

前言

经过前面的学习，我们已经能够很好的掌握 prometheus 并建立监控后台了，但是那个毕竟是学习篇，用于循循渐进的学习和掌握。

• 基于 prometheus 打造监控报警后台

但是真正涉及到线上的实战，其实复杂度还是跟学习的情况差很多的， 因此我这边结合在实际项目上的一些实战，也捋了个实战篇。

prometheus 推荐的最佳实践

在仪表板(dashboard)上显示尽可能多的数据虽然很爽，尤其是当像 Prometheus 这样的系统提供了对应用程序进行如此丰富的检测的能力时。这可能会导致控制台由于包含太多信息而变得难以理解，即使是系统专家也难以从中获得意义。

所以千万不要将所有的数据都往 dashboard 上面搬，请考虑你建这个 dashboard 的初衷是什么，想要解决什么问题，如果你想要解决的问题是一个很复杂的问题的话，请把他进行拆解，并且分成多个 dashboard 来分批解决。

prometheus 官方推荐的 dashboard 指南:

1. dashboard 上面的图表最好不要超过 5 个
2. 每张图的图(线) 也不超过 5
3. 如果使用的是 dashboard 的第三方模板，请避免右侧表格中的条目超过 20-30 个

前言

经过前面的 prometheus 系列的学习，我们知道 prometheus 要监控和抓取的端点都要写在 prometheus.yml 这个配置文件，这种方式对于要监控实例较少的情况还行，但是不适合大规模的的集群。

尤其不适合用于使用容器和基于云的实例的动态集群，这些实例经常会出现变化，有可能新创建，有可能是下架。

而 prometheus 通过使用 服务发现 来通过自动化的机制来检测，分类新的变更实例情况。

服务发现的几种类别

prometheus 提供的服务发现其实种类很多，有很多是跟第三方集成，从配置文件所支持的 参数 来看，分别有:

具体集成的服务列表，官方文档也有: Service Discovery

前言

之前我们的所有的场景，都是通过 prometheus server 定期去实例(instance)拉取(pull)数据, 但是有以下两种情况会有问题:

1. 由于子网络或者防火墙的关系， prometheus server 不能直接拉取各个 instance 的指标数据
2. 监控程序不是在线服务系统，而是批处理作业，批处理作业的特点是它们不会连续运行，这使得抓取它们变得困难。所以 prometheus 如果是定期拉取的话，就会出现 instance 没有运行的情况

基于以上的情况，所以 prometheus server 提供了另一种让实例(instance) 主动 push 指标数据的能力， 那就是借助另一个程序: Pushgateway 来进行代理， 让其他的程序先把数据抛送到 Pushgateway， 然后再让 prometheus server 定期去 Pushgateway 拉取数据

Pushgateway 使用场景

使用 Pushgateway 会有几个问题:

1. 当通过单个 Pushgateway 监控多个实例时，Pushgateway 会有单点故障的潜在问题
2. 没有实例的自动健康监控指标 up
3. 只要是通过 Pushgateway 代理推送给 prometheus server 的实例的指标，会一直存在，哪怕这个实例后面不再抛送指标给 Pushgateway，但是 prometheus 依然会保留这个实例的指标

前言

我们都知道 prometheus 是一个监控程序， 并且可以采集指标，但是之前我们的测试都是用的官方的 exporter ，比如 node_exporter 这种监控主机的。

其实 prometheus 采集的指标一样可以用于我们的自己写的程序, 关于 prometheus 的 客户端的 sdk lib 可以看: prometheus client libraries

里面很多主流语言都有包含，比如 Golang, Python, Java, Node.js, PHP 等，有一些是 prometheus 官方自己维护的，有一些是第三方贡献者写的。

当然如果你自己使用的语言不在上面，也可以按照 prometheus 标准实现一个该语言的 客户端 sdk 库: 编写客户端库的指南

所以本节我们就自己用一个程序来实现 prometheus 的 客户端功能，然后自定义一些抛送的指标。

指标和数据模型

在实现 prometheus 的 客户端功能，那么就要了解 prometheus 的指标和数据模型，这一块直接看 基于 prometheus 打造监控报警后台 (2) - 指标类型和数据模型, 文章已经讲的很详细了。

我们只需要在我们程序中通过实现这四种类型(Counter, Gauge, Histogram, Summary)之一的指标，那么就是符合 prometheus 客户端的抛送指标了。

前言

之前我们已经尝试了在 prometheus 上创建警报，并且使用 alertmanager 来发送通知了: 基于 prometheus 打造监控报警后台 (4) - 使用 alertmanager 发送警报

但是正常情况下，我们都是在 grafana 后台查看我们所创建的 dashboard 仪表盘。 同时 grafana 后台也可以显示我们在 prometheus 上创建的规则 (包含警报规则和记录规则)

不同版本的 grafana 可能界面会有差，甚至操作也会有区别，本节演示的 grafana 的版本是 v9.2.5 (042e4d216b)

grafana 显示 prometheus 创建的规则

继续延伸上一节的规则配置 (配置了两个 rule 文件，一个是警报规则，一个是记录规则)，当我们查看 grafana 后台的 alerting 的时候，可以看到他也有把我们创建的规则一起显示出来

前言

通过 基于 prometheus 打造监控报警后台 (4) - 使用 alertmanager 发送警报 我们知道 prometheus 可以创建 警报规则 来触发警报，然后再把报警信息发送给 alertmanager ，然后 alertmanager 来发送报警通知。

但是其实 prometheus 还有一种规则，就是 记录规则

记录规则(recording rule)

记录规则允许您预先计算经常需要或计算量大的表达式，并将其结果保存为一组新的时间序列。查询预先计算的结果通常比每次需要时都执行原始表达式要快得多。这对于每次刷新时都需要重复查询相同表达式的仪表板特别有用。

也就是每一条记录规则，其实都会作为时间序列存入时序数据库，有点类似于 mysql 的 索引，这些都是有开销，所以也不能无止境的建记录规则，因为会有额外的开销。

关于记录规则的语法，其实跟警报规则一样，他们的配置差别仅仅在于 rules 小节下的第一个配置的 key 是 record 还是 alert。 其他都一样

所以语法这一块，之前在讲警报规则的时候，就讲解过了， 可以看之前讲警报规则的文章: 基于 prometheus 打造监控报警后台 (4) - 使用 alertmanager 发送警报

前言

通过 基于 prometheus 打造监控报警后台 (4) - 使用 alertmanager 发送警报 我们已经能够在 prometheus 创建警报规则，并且使用 alertmanager 发送警报预警了。

但是 alertmanager 还有几个特性，并没有在上述文章讲述，本节继续延续上节的内容，讲一下 alertmanager 的几个概念。

1. 分组(Grouping)

Grouping 是把同类型的警报进行分组，合并多条警报到一个通知中。在生产环境中，特别是云环境下的业务之间密集耦合时，若出现多台 Instance 故障，可能会导致成千上百条警报触发。在这种情况下使用分组机制， 可以把这些被触发的警报合并为一个警报进行通知，从而避免瞬间突发性的接受大量警报通知，使得管理员无法对问题进行快速定位。

举个例子，比如我在 aws 的美西部署了 100 台服务器， 上面都部署了 node_exporter，然后突然有一天， aws 的美西服务商出现网络波动，导致 prometheus server 连接不到这 100 台服务器，这时候这 100 个节点就会全部触发告警， 瞬间往你的邮箱发送了 100 封邮件，直接给你造成邮件轰炸。

但是如果你有设置分组，将 100 台的主机的 up 检测都放到同一个分组内，那么这个 100 封告警就会合并成一条发送。

前言

通过 基于 prometheus 打造监控报警后台 (3) - 使用 grafana 创建仪表盘 我们已经能够在 grafana 上面创建漂亮的数据监控仪表盘了。

本节我们讲一下怎么在 prometheus 上设置预警并且发送警报。

简单的架构图如下

在 prometheus 监控系统中，采集与警报是分离的，所以是分为两个步骤的:

1. 在 prometheus 中创建警报规则，并监控警报和触发警报
2. 触发警报之后(firing)，prometheus 将报警信息转发给独立组件 alertmanager，然后经过 alertmanager 对报警信息处理之后，最后通过接收器发送给指定用户

同时 alertmanager 支持多种接收器(receiver), 比如 Email, Slack , 钉钉, 企业微信 , Webhook

前言

通过 基于 prometheus 打造监控报警后台 (2) - 指标类型和数据模型 我们可以知道，虽然 prometheus 采集数据很棒， 但是数据渲染这一块，实在是做的不咋的， 而且官方也推荐使用 grafana 来进行数据渲染: grafana support for prometheus

所以本节就安装一下 grafana 并创建 dashboard 仪表盘

安装

接下来我们直接按照官方文档进行安装: Download Grafana, 一样采用二进制包的方式来安装

1
2
3
4
5
6
7
8
9
10
11
12

# 下载安装
[root@VM-64-9-centos ~]# cd /usr/local/
[root@VM-64-9-centos local]# wget https://dl.grafana.com/enterprise/release/grafana-enterprise-9.2.5-1.x86_64.rpm
[root@VM-64-9-centos local]# sudo yum install grafana-enterprise-9.2.5-1.x86_64.rpm

# 加入到 system 并启动 (安装的时候，有创建 grafana-server.service 文件了，这边不再需要手动创建)
[root@VM-64-9-centos local]# systemctl enable grafana-server.service
[root@VM-64-9-centos local]# systemctl start grafana-server.service

# 查看端口监听， 3000 端口
[root@VM-64-9-centos local]# netstat -anlp  | grep 3000
tcp6       0      0 :::3000                 :::*                    LISTEN      8897/grafana-server

前言

之前从 基于 prometheus 打造监控报警后台 (1) - 初试和安装 我们安装了 prometheus 服务，并且监控了当前的主机。 但是数据是有抓取了，怎么看指标乃至图表呢?

从后台查询指标

我们可以从 prometheus ui 后台的 graph 里面来查看， 他有两个 tab 视图展示，一个是 Graph 的图表展示，一个是 Table 的表格展示， 通过输入某一个指标 （Metric），我们就可以查看所有实例中有关于这个指标的所有的数据。 其中有表格形式展示的， 也有图表形式展示，图表形式还可以自己选择时间区间

然后查询的方式，提供了一种称为 PromQL 的函数式查询语言，可以让用户实时选择和聚合时间序列数据。表达式的结果可以显示为图形，也可以以表格数据的形式查看，或者由外部系统通过HTTP API 使用。

PromQL（Prometheus Query Language）是 Prometheus 自己开发的表达式语言，语言表现力很丰富，内置函数也很多。使用它可以对时序数据进行筛选和聚合。

关于查询的话，官网有提供了几个查询实例可供参考: 查询示例

其中包括几个常见的，比如:

prometheus 介绍

1. 诞生背景

1. IT 环境中，监控系统陈旧，监控指标单一，监控误报等，基于 zabbix 搭建，不能有效针对测试环境中k8s和容器的原生支持
2. IT 环境监控类型繁多，有主机监控，也有应用监控。如：物理服务器、VMWare vSphere 虚拟化体系、交换机等网络设备、其他特殊主机、应用类监控，如 nginx 和 mysql 等
3. IT 环境监控链路长，并指标复杂

2. 什么是 prometheus

Prometheus 是一个开源系统监控和警报工具包，最初由 SoundCloud 构建。自 2012 年启动以来，许多公司和组织都采用了 Prometheus，该项目拥有非常活跃的开发者和用户社区。它现在是一个独立的开源项目，独立于任何公司进行维护。为了强调这一点，并明确项目的治理结构，Prometheus 于 2016 年作为继 Kubernetes 之后的第二个托管项目加入了云原生计算基金会(CNCF)。

Prometheus 将其指标收集并存储为时间序列数据，即指标信息与记录时的时间戳以及称为标签的可选键值对一起存储。

说是现在最流行的系统监控后台，一点都不为过

前言

通过 bug 追踪系统 Sentry (3) -- 项目引入 sdk 抛送 bug 我们已经知道怎么在项目中引入 sentry 的 sdk，并且将 error 抛送到线上。 但是线上的代码都是通过构建打包压缩过的，基本上没有可读性。

如果抛上去查看的话，错误堆栈长这样子，很难分析:

如果能像开发环境那样子，可以在控制台查看 sourceMap 的话，就可以直接查看对应的源代码就好了。 Sentry 有提供这个功能。

原理

我们都知道构建生成的 sourceMap 不能上传到 release 的线上环境，因为会有安全问题(源代码泄露)。 所以一般也就在开发环境，才会用 sourceMap 去 debug。

那么 sentry 可以使用 sourceMap 原理很简单，就是我们将源代码(包含 sourceMap) 上传到 sentry 后台，他会通过 release 版本来关联， 其实就是结合每次的 release 版本号来管理不同版本号的 sourceMap

因为我们是自建的，所以不用担心代码泄露问题，可以放心的用。

这一块 sentry 官方是有文档的: Sentry - JavaScript - Source Maps, 为此还提供了一个 cli 工具来上传这些 sourceMap: Command Line Interface

前言

之前花了两个篇幅，讲了 sentry 的 部署和邮件客户端的配置:

• bug 追踪系统 Sentry (1) -- 单机安装
• bug 追踪系统 Sentry (2) -- 账号初始化和邮件发送配置

本篇我们讲一下，怎么在项目中引入 sdk 并且抛送 bug 统计, 因为 sentry 支持很多语言:

前言

之前通过 bug 追踪系统 Sentry (1) -- 单机安装 我们成功在单机上部署了 sentry 服务，这一节我们讲进入后台的账号初始化和邮件发送配置。

账号初始化

其实在执行 instaill.sh 脚本的时候， 就会有用户初始化账号的引导流程，只不过我之前是通过 --skip-user-prompt 来跳过这个交互。

所以安装完之后，我们就要通过 docker-compose run --rm web createuser 来创建初始账号，具体执行如下

1

[root@VM-64-9-centos self-hosted-master]# docker-compose run --rm web createuser

并且在设置的过程中，也可以指定设置为 superuser 权限

前言

现在的前端项目，如果一旦发布上线，代码一般都会进行混淆、压缩甚至加密，如果线上没有bug跟踪系统，客户端一旦报错，前端就无法及时感知，这个时候就需要使用人员上报，一层层上报到技术这边，技术如果要调试或者获得更具体的信息，就没有办法了，大部分情况下只有一张图片，但光靠一张图片，要追查bug产生的原因，有的时候是蛮困难的，等真正查清楚了，黄花菜都凉了。

所以其实是需要一个可以记录 bug 或者抛送异常数据的一个系统的。 其实这一块业内是有一些解决方案，除了一些系统之外， 各大云服务厂商其实也有类似的产品，比如

1. frontjs
2. fundebug
3. trackjs
4. instabug
5. rollbar
6. sentry

但是规模大了，基本上都要商用，都需要钱， 再加上之前也有用过美团开源的 Logan: 使用 Logan 来做前端日志系统, 基本上体验了一阵子下来，也有一些问题没有解决，比如:

1. 没有多项目管理
2. 搜索功能鸡肋
3. 日子列表缺少筛选功能，希望能加上分类筛选，例如用户信息、设备型号、浏览器环境、或者添加自定义字段进行筛选。
4. 没有分页，无法查看20条以后的数据
5. 日志丢失内容
6. 希望可以自定义日志类型与颜色
7. 在日志详情页面上看不到环境等信息
8. 日志条目无法显示颜色，例如时间用其他颜色显示
9. 日志条目详情希望可以解析json

前言

之前我们已经有使用 ionCube 对 PHP 项目进行加密: 使用 ionCube 对 PHP 项目进行加密

之前拿来做测试的是 免费申请试用版本, 后面就直接买了一个正式版的 Cerberus 的，$399 一个 license 的，永久使用 (除非换机器)

激活

本质上这个正式的 release 版本和申请试用的版本在功能上没啥差别 (都是 Cerberus 版本)，除了加密器的有效期 14 天以及加密文件的有效期 36 小时之外。

不过 release 版本在使用之前是需要先执行激活的，而且一旦激活之外，接下来就只能在这一台机器上才能加密了

XSS

跨网站脚本(Cross-site scripting，通常简称为XSS或跨站脚本或跨站脚本攻击)是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。

即使到了 2022 年， 在 OWASP(Open Web Application Security Project，是一个开放式Web应用程序安全项目组织，旨在帮助计算机和互联网应用程序提供公正、实际、有成本效益的信息。) 的 top10 漏洞中， XSS 依然排名前三 (2021 年的第三名的 注入(Injection)，其中 XSS 就属于这一类)

正常我们常用的防护手段一般是对于任何的参数请求以及页面中涉及到的用户信息全部都要进行特殊字符的过滤，进行 html转义，防止触发恶意脚本

但是如果能够理解 XSS 的实际攻击方式，真的要对用户的利益造成损失的话 (不是单纯的只是弹个 alert 框)， 一般就两种方式:
1 注入恶意脚本，执行或者引导用户，从而盗取信息或者执行恶意操作
2 直接获取该页面上的用户信息，比如 cookie， 然后抛到攻击者自己的服务器