飞行的冰糖

跨域报错 报错分析 源站 origin：https://nfc-h5-test.seencom.com 目的站点：https://nfc-test.seencom,com/client/user/upload_file 报错： No 'Access-Control-Allow-Origin' header is present on the requested resource. 源站的请求头中没有添加 'Access-Control-Allow-Origin' 域名白名单。 因此要在 目的站点 添加跨域请求允许 “源站域名” 的相关策略。 解决措施只需要在目的 ingress 的资源对象中添加注释： 1234567annotations: nginx.ingress.kubernetes.io/enable-cors: "true" nginx.ingress.kubernetes.io/cors-allow-origin: "*" nginx.ingress.kubernetes.io/ ...

node_exporternode_exporter 是用于监控 Linux 系统的指标采集器：CPU、内存、硬盘、网络流量、文件描述符、系统负载、系统服务等等。 更详细的介绍说明请查看： MONITORING LINUX HOST METRICS WITH THE NODE EXPORTER 二进制安装 node_exporterLinux 被监控端获取 node_exporter 二进制安装包 1234cd /usr/local/src/wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz --no-check-certificatetar xvf node_exporter-1.7.0.linux-amd64.tar.gzmv node_exporter-1.7.0.darwin-amd64/node_exporter /usr/local/bin 配置 systemd 启动脚本 1vim /etc/syst ...

blackbox-exporter 黑盒监控什么是白盒与黑盒监控？在监控系统中会经常提到白盒监控与黑盒监控两个关键词，对这俩关键词进行一下简单解释： 黑盒监控：黑盒监控指的是以用户的身份测试服务的运行状态。常见的黑盒监控手段包括 HTTP探针、TCP探针、DNS探测、ICMP等。黑盒监控常用于检测站点与服务可用性、连通性，以及访问效率等。 白盒监控：白盒监控一般指的是日常对服务器状态的监控，如服务器资源使用量、容器的运行状态、中间件的稳定情况等一系列比较直观的监控数据，这些都是支撑业务应用稳定运行的基础设施。通过白盒能监控，可以使我们能够了解系统内部的实际运行状况，而且还可以通过对监控指标数据的观察与分析，可以让我们提前预判服务器可能出现的问题，针对可能出现的问题进行及时修正，避免造成不可预估的损失。 白盒与黑盒监控的区别：黑盒监控相较于白盒监控最大的不同在于黑盒监控是以故障为导向当故障发生时，黑盒监控能快速发现故障，而白盒监控则侧重于主动发现或者预测潜在的问题。 一个完善的监控目标是要能够从白盒的角度发现潜在问题，能够在黑盒的角度快速发现已经发生的问题。 blackbox_e ...

RocketMQ 部署方式Apache RocketMQ 5.0 版本完成基本消息收发，包括 NameServer、Broker、Proxy 组件。 在 5.0 版本中 Proxy 和 Broker 根据实际诉求可以分为 Local 模式和 Cluster 模式，一般情况下如果没有特殊需求，或者遵循从早期版本平滑升级的思路，可以选用 Local 模式。 在 Local 模式下，Broker 和 Proxy 是同进程部署，只是在原有 Broker 的配置基础上新增 Proxy 的简易配置就可以运行。 在 Cluster 模式下，Broker 和 Proxy 分别部署，即在原有的集群基础上，额外再部署 Proxy 即可。 部署 Local 模式-单节点单副本由于 Local 模式下 Proxy 和 Broker 是同进程部署，Proxy本身无状态，因此主要的集群配置仍然以 Broker 为基础进行即可。 警告：这种方式风险较大，因为 Broker 只有一个节点，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用, 可以用于本地测试。 本地环境检查查看操作系统及 ...

RabbitMQ 集群虽然官方提供了管理 UI 来监控集群状态，但是从设计上来说这种方式并不是特别方便。 RabbitMQ 从 3.8.0 版本开始就内置了对 Prometheus 和 Grafana 的支持。实质上是通过 rabbitmq_prometheus 这个插件来获取对 Prometheus 度量标准的支持，该插件是通过专用的 TCP 端口来暴露相关 RabbitMQ 指标的，默认端口是 15692。这些度量标准提供了对 RabbitMQ 节点状态和运行时的状态的支持。 查看本地环境查看本地操作系统及内核版本： 123456# $ cat /etc/redhat-release Rocky Linux release 8.8 (Green Obsidian)$ uname -aLinux rabbit1 4.18.0-425.3.1.el8.x86_64 #1 SMP Wed Nov 9 20:13:27 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux 查看三节点 rabbitmq 集群及 erlang 版本： 12345678910$ rpm ...

RabbitMQ 普通集群模式RabbitMQ 集群是一个或 多个节点，每个节点共享用户、虚拟主机、 队列、交换、绑定、运行时参数和其他分布式状态。 RabbitMQ 集群是在多台机器上启动多个 rabbitmq 实例，每个机器启动一个。 但是你创建的 queue，只会放在一个 rabbtimq 实例上，但是每个实例都同步 queue 的元数据(存放含queue数据的真正实例位置)。消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。 RabbitMQ 集群可以通过多种方式形成： 通过在配置文件中列出群集节点以声明方式 以声明方式使用基于 DNS 的发现 以声明方式使用 AWS （EC2） 实例发现（通过插件） 声明式使用 Kubernetes 发现（通过插件） 以声明方式使用基于 Consul 的发现（通过插件） 声明式地使用基于 etcd 的发现（通过插件） 手动使用 rabbitmqctl 集群部署的核心概念1、 仲裁队列仲裁队列是 RabbitMQ 实现持久、 基于Raft共识算法的复制FIFO队列。 它从 RabbitMQ 3 ...

RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。 rabbitmq 部署有三种模式：单机模式，普通集群模式，镜像集群模式。 安装 Erlang 环境首先查看本地操作系统版本： 12345$ cat /etc/redhat-release Rocky Linux release 8.8 (Green Obsidian)$ uname -aLinux bogon 4.18.0-425.3.1.el8.x86_64 #1 SMP Wed Nov 9 20:13:27 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux 由于 rabbitmq 是基于 erlang 语言开发的，所以必须先安装 erlang 环境。 我们准备安装 rabbitmq 3.11.23，根据 RabbitMQ 对 Erlang 版本要求，则需要提前安装 Erlang 25.3.x 版本的语言环境。 采用 Erlang Direct Downloads from GitHub RPM 的方式来安装 Erlang 语言环境，获取 Erlang RPM： 123cd ...

Prometheus添加邮件告警和企业微信机器人告警 添加企业微信 webhook 机器人企业微信管理后台，创建企业微信 webhook 机器人，并添加机器人到告警群，最后得到机器人 id K8S 集群内部署 prometheus-webhook-dingtalk请替换 yaml 中的 ${机器人ID} 123456789101112131415161718192021222324252627282930313233343536373839404142# deploy.yamlapiVersion: apps/v1kind: Deploymentmetadata: labels: run: prometheus-webhook-dingtalk name: prometheus-webhook-dingtalk namespace: kube-monspec: selector: matchLabels: run: prometheus-webhook-dingtalk template: metadata: l ...

Alertmanager 安装前面我们学习 Prometheus 的时候了解到 Prometheus 包含一个报警模块，就是我们的 AlertManager，Alertmanager 主要用于接收 Prometheus 发送的告警信息，它支持丰富的告警通知渠道，而且很容易做到告警信息进行去重，降噪，分组等，是一款前卫的告警通知系统。 介绍通过在 Prometheus 中定义告警规则，Prometheus 会周期性的对告警规则进行计算，如果满足告警触发条件就会向 Alertmanager 发送告警信息。 在 Prometheus 中一条告警规则主要由以下几部分组成： 告警名称：用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容 告警规则：告警规则实际上主要由 PromQL 进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后触发告警 在 Prometheus 中，还可以通过 Group（告警组）对一组相关的告警进行统一定义。Alertmanager 作为一个独立的组件，负责接收并处理来自 Prometheus Server 的 ...

Grafana前面我们使用 Prometheus 采集了 Kubernetes 集群中的一些监控数据指标，我们也尝试使用 promQL 语句查询出了一些数据，并且在 Prometheus 的 Dashboard 中进行了展示，但是明显可以感觉到 Prometheus 的图表功能相对较弱，所以一般情况下我们还是会使用 Grafana 来进行展示。这里我们在 Kubernetes 集群中使用，所以同样可以将 Grafana 安装到集群中来，当然在集群外也是可以的。 安装去 DockerHub for Grafana 镜像介绍，要注意的是 Changelog 中 v5.1.0 版本的更新介绍： 1234567Major restructuring of the containerUsage of chown removedFile permissions incompatibility with previous versionsuser id changed from 104 to 472group id changed from 107 to 472Runs as the grafana ...