桥下の民 - DevOps
type: channel
link: https://wordplay.work/index.php/category/DevOps
items: Ansible 详细教程
items: Prometheus 原理
items: WebLogic
items: Git 常用操作
items: Zookeeper数据导出脚本
items: Kafka 数据迁移
items: Kafka 安全(SASL+ACL)
items: Keepalived
items: Prometheus & Grafana

Ansible 详细教程
type: item
date: 2025-07-11T09:45:00+00:00
description: 一、简介 Ansible 是一个 IT 自动化工具，他能配置系统，部署软件，编排更复杂的 IT 任务，如连续部署或零停机时间滚动更新。 Ansible 用 Python 编写，Ansible 允许不需要在每个节点上安装自己的组件，可以在不止一个地方控制整个基础架构。 二、工作原理 Inventory：被管理节点的列表，资源池。 PlayBook：类似于 Shell 脚本，通过一系列命令执行自动化操作。 Module。 在 Ansible 管理体系中，存在 管理节点 和 被管理节点 两种角色。 被管理节点通常被成为资产。 在管理节点上，Ansible 将 AdHoc 或 PlayBook 转换为 python 脚本，并通过 SSH 传输到被管理节点上。 在被管理节点上依次执行 Python 脚本。 三、Ansible 安装 3.1、先决条件 3.2、安装 Ansible yum 方式： [root@localhost ~]# yum install epel-release [root@localhost ~]# yum install ansible pip 方式： [root@localhost ~]# yum install epel-release [root@localhost ~]# yum install python2-pip [root@localhost ~]# pip install ansible 查看 Ansible 版本： [root@localhost ~]# ansible --version ansible 2.9.27 config file = /etc/ansible/ansible.cfg configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python2.7/site-packages/ansible executable location = /usr/bin/ansible python version = 2.7.5 (default, Oct 14 2020, 14:45:30) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] 四、Ansible 简单部署 4.1、管理节点与被管理节点建立 SSH 信任关系 管理节点 (ansible) 中创建密钥对： [root@localhost ~]# ssh-keygen -t rsa 将本地的公钥传输到被管理节点： [root@localhost .ssh]# ssh-copy-id root@192.168.200.135 [root@localhost .ssh]# ssh-copy-id root@192.168.200.136 4.2、场景 4.2.1、检测所有被管理主机在线状态 [root@manager ~]# ansible all -i 192.168.19.135,192.168.19.136 -m ping 192.168.19.135 | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python" }, "changed": false, "ping": "pong" } 192.168.19.136 | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python" }, "changed": false, "ping": "pong" } -i : 参数后面是一个列表 (List) , 因此当为一个被管理节点时，我们后面一定要加一个英文逗号 (,) , 告知是 List。 4.2.2、确保 /tmp/a.conf 发布到所有被管理节点上 [root@manager ~]# touch /tmp/a.conf [root@manager ~]# ansible all -i 192.168.19.135,192.168.19.136 -m copy -a "src=/tmp/a.conf dest=/tmp/a.conf" 192.168.19.136 | CHANGED => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python" }, "cha…

Prometheus 原理
type: item
date: 2025-05-23T09:31:00+00:00
description: 一、Prometheus 相关概念 1.1、内部存储机制 Prometheus 有着非常高效的时间序列数据存储方法，每个采样数据仅仅占用 3.5byte 左右空间，上百万条时间序列，30 秒间隔，保留 60 天，大概花了 200 多 G（引用官方 PPT）。 Prometheus 内部主要分为三大块： Retrieval 是负责定时去暴露的目标页面上去抓取采样指标数据。 Storage 是负责将采样数据写磁盘。 PromQL 是 Prometheus 提供的查询语言模块。 1.2、数据模型 Prometheus 存储的所有数据都是时间序列数据（Time Serie Data，简称时序数据）。时序数据是具有时间戳的数据流，该数据流属于某个度量指标（Metric）和该度量指标下的多个标签（Label）。 每个 Metric name 代表了一类的指标，他们可以携带不同的 Labels，每个 Metric name + Label 组合成代表了一条时间序列的数据。 在 Prometheus 的世界里面，所有的数值都是 64bit 的。每条时间序列里面记录的其实就是 64bit timestamp (时间戳) + 64bit value (采样值)。 Metric name（指标名称）：该名字应该具有语义，一般用于表示 metric 的功能，例如：http_requests_total, 表示 http 请求的总数。其中，metric 名字由 ASCII 字符，数字，下划线，以及冒号组成，且必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。 Lables（标签）：使同一个时间序列有了不同维度的识别。例如 http_requests_total {method=“Get”} 表示所有 http 请求中的 Get 请求。当 method=“post” 时，则为新的一个 metric。标签中的键由 ASCII 字符，数字，以及下划线组成，且必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。 timestamp (时间戳)：数据点的时间，表示数据记录的时间。 Sample Value（采样值）：实际的时间序列，每个序列包括一个 float64 的值和一个毫秒级的时间戳。 例如图上的数据： http_requests_total {status="200",method="GET"} http_requests_total {status="404",method="GET"} 根据上面的分析，时间序列的存储似乎可以设计成 key-value 存储的方式（基于 BigTable）。 进一步拆分，可以像下面这样子： 上图的第二条样式就是现在 Prometheus 内部的表现形式了，__name__ 是特定的 label 标签，代表了 metric name。 再回顾一下 Prometheus 的整体流程： 上面提到了 K-V 存储，当然是使用了 LevelDB 的引擎，它的特点是顺序读写性能非常高，这是非常符合时间序列的存储的。 1.3、Metric 类型 Prometheus 定义了 4 种不同的指标类型 (metric type)：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）。 1.3.1、Counter（计数器） 一种累加的 metric，典型的应用如：请求的个数，结束的任务数， 出现的错误数等等。 【例如】查询 http_requests_total {method=“get”, job=“Prometheus”, handler=“query”} 返回 8，10 秒后，再次查询，则返回 14。 1.3.2、Gauge（仪表盘） 数据是一个瞬时值，如果当前内存用量，它随着时间变化忽高忽低。 【例如】go_goroutines {instance=“172.17.0.2”, job=“Prometheus”} 返回值 147，10 秒后返回 124。 1.3.3、Histogram（直方图） Histogram 取样观测的结果（一般是请求持续时间或响应大小）并在一个可配置的分布区间（bucket）内计算这些结果。其也提供所有观测结果的总和。 Histogram 有一个基本 metric 名称 ，在一次抓取中展现多个时间序列： 累加的 counter，代表观测区间：_bucket {le=“”} 所有观测值的总数：_sum 观测到的事件数量：_count 例如 Prometheus server 中 prometheus_local_storage_series_chunks_persisted, 表示 Prometheus 中每个时序需要存储的 …

WebLogic
type: item
date: 2025-04-10T12:59:00+00:00
description: 部署后编译的位置： $DOMAIN_HOME/servers/$SERVER_NAME/tmp/_WL_user/$APP_NAME/$VERSION/ 在 WebLogic 中，部署 WAR 包时，通常会将其解压缩并编译到以下文件夹中： $DOMAIN_HOME 是你的 WebLogic 域的根目录。 $SERVER_NAME 是你正在运行的服务器的名称。 $APP_NAME 是你的应用程序的名称。 $VERSION 是应用程序的版本号。 在这个目录下，你可以找到解压后的 WAR 包内容以及编译后的类文件。 解压缩 WAR 包： unzip yourfile.war -d yourdirectory 重新打包成 WAR 包： cd yourdirectory jar cvf newfile.war *

Git 常用操作
type: item
date: 2024-12-20T02:03:00+00:00
description: 1、初始化 Git 仓库： 在项目文件夹中打开终端，运行以下命令： git init 2、添加文件到暂存区： 将所有文件添加到 Git 的暂存区： git add . 3、提交更改： 提交暂存区的文件，并添加提交信息： git commit -m "初始化提交" 4、创建 GitHub 仓库： 登录到您的 GitHub 账户，创建一个新的仓库。记下仓库的 URL。 5、将远程仓库添加到本地仓库： 在终端中运行以下命令，将远程仓库链接到本地仓库（将 <repository-url> 替换为您的 GitHub 仓库 URL）： git remote add origin https://github.com/xxx/xxx.git # 将当前分支重命名为 main git branch -M main 6、推送到 GitHub： 将本地的提交推送到 GitHub： git push -u origin master 完成以上步骤后，您的项目文件夹将成功初始化并提交到 GitHub。 7、拉取分支代码 git pull origin main # 查看当前分支 git branch # 或者在当前分支更新 git pull

Zookeeper数据导出脚本
type: item
date: 2024-05-11T01:31:00+00:00
description: 递归算法导出： #!/bin/bash ZK_SERVER="127.0.0.1:2181" ZK_CLI_PATH="/opt/module/zookeeper-3.5.7-bin/bin/zkCli.sh" OUTPUT_FILE="/opt/module/zookeeper-3.5.7-bin/bin/zk_data_export.txt" TMP_SCRIPT="/opt/module/zookeeper-3.5.7-bin/bin/zk_command.tmp" : > $OUTPUT_FILE function zkCommand() { # echo "$1" | $ZK_CLI_PATH -server $ZK_SERVER 2>&1 echo "addauth digest cache:svcctlg" > "$TMP_SCRIPT" echo "$1" >> "$TMP_SCRIPT" $ZK_CLI_PATH -server $ZK_SERVER < "$TMP_SCRIPT" 2>&1 } # 对 ZooKeeper 进行认证 # zkCommand "addauth digest cache:svcctlg" function exportZK() { local path=$1 { echo "节点: $path" local data=$(zkCommand "get $path" | tail -2 | head -1) echo "$data" echo "" } >> $OUTPUT_FILE local children_output=$(zkCommand "ls $path") local children=$(echo "$children_output" | grep -o '\[.*\]' | tail -2 | head -1 | tr -d '[],' | tr ',' '\n') echo $children for child in $children; do local child_path="$path/$child" if [ "$path" == "/" ]; then child_path="/$child" fi exportZK "$child_path" done } exportZK "/a1" echo "ZooKeeper 数据导出完成，文件保存于 $OUTPUT_FILE"

Kafka 数据迁移
type: item
date: 2024-04-19T05:47:00+00:00
description: 两种迁移场景，分别是：同集群数据迁移、跨集群数据迁移。 一、同集群迁移 同集群之间数据迁移，比如在已有的集群中新增了一个 Broker 节点，此时需要将原来集群中已有的 Topic 的数据迁移部分到新的集群中，缓解集群压力。 将新的节点添加到 Kafka 集群很简单，只需为它们分配一个唯一的 Broker ID，并在新服务器上启动 Kafka。但是，这些新服务器节点不会自动分配任何数据分区，因此除非将分区移动到新增的节点，否则在创建新 Topic 之前新节点不会执行任何操作。因此，通常在将新服务器节点添加到 Kafka 集群时，需要将一些现有数据迁移到这些新的节点。 迁移数据的过程是手动启动的，执行过程是完全自动化的。在 Kafka 后台服务中，Kafka 将添加新服务器作为其正在迁移的分区的 Follower，并允许新增节点完全复制该分区中的现有数据。当新服务器节点完全复制此分区的内容并加入同步副本（ISR）时，其中一个现有副本将删除其分区的数据。 Kafka 系统提供了一个分区重新分配工具 kafka-reassign-partitions.sh，该工具可用于在 Broker 之间迁移分区。理想情况下，将确保所有 Broker 的数据和分区均匀分配。分区重新分配工具无法自动分析 Kafka 群集中的数据分布并迁移分区以实现均匀的负载均衡。因此，管理员在操作的时候，必须弄清楚应该迁移哪些 Topic 或分区。 分区重新分配工具可以在 3 种互斥模式下运行： --generate：在此模式下，给定 Topic 列表和 Broker 列表，该工具会生成候选重新​​分配，以将指定 Topic 的所有分区迁移到新 Broker 中。此选项仅提供了一种方便的方法，可在给定 Topic 和目标 Broker 列表的情况下生成分区重新分配计划。 --execute：在此模式下，该工具将根据用户提供的重新分配计划启动分区的重新分配。 （使用 --reassignment-json-file 选项）。由管理员手动制定自定义重新分配计划，也可以使用 --generate 选项提供。 --verify：在此模式下，该工具将验证最后一次 --execute 期间列出的所有分区的重新分配状态。状态可以有成功、失败或正在进行等状态。 1.1、迁移过程实现 分区重新分配工具可用于将一些 Topic 从当前的 Broker 节点中迁移到新添加的 Broker 中。这在扩展现有集群时通常很有用，因为将整个 Topic 移动到新的 Broker 变得更容易，而不是一次移动一个分区。当执行此操作时，用户需要提供已有的 Broker 节点的 Topic 列表，以及到新节点的 Broker 列表（源 Broker 到新 Broker 的映射关系）。然后，该工具在新的 Broker 中均匀分配给指定 Topic 列表的所有分区。在迁移过程中，Topic 的复制因子保持不变。 现有如下实例，将 Topic 为 ke01，ke02 的所有分区从 Broker1 中移动到新增的 Broker2 和 Broker3 中。由于该工具接受 Topic 的输入列表作为 JSON 文件，因此需要明确迁移的 Topic 并创建 json 文件，如下所示： > cat topic-to-move.json {"topics": [{"topic": "ke01"}, {"topic": "ke02"}], "version":1 } 准备好 JSON 文件，然后使用分区重新分配工具生成候选分配，命令如下： > bin/kafka-reassign-partitions.sh --zookeeper dn1:2181 --topics-to-move-json-file topics-to-move.json --broker-list "1,2" --generate 执行命名之前，Topic（ke01、ke02）的分区如下图所示： 执行完成命令之后，控制台出现如下信息： 该工具生成一个候选分配，将所有分区从 Topic ke01，ke02 移动到 Broker1 和 Broker2。需求注意的是，此时分区移动尚未开始，它只是告诉你当前的分配和建议。保存当前分配，以防你想要回滚它。新的赋值应保存在 JSON 文件（例如 expand-cluster-reassignment.json）中，以使用 --execute 选项执行。JSON 文件如下： {"version":1,"partitions":[{"topic":"ke02","partition":0,"replicas":[2]},{"topic":"ke02","partition":1,"replicas":[1]},{"t…

Kafka 安全(SASL+ACL)
type: item
date: 2024-03-07T08:23:00+00:00
description: 一、Security 在 Kafka 的官方文档中介绍了如下几种安全方式，以满足用户不同场景对安全的需求。 SASL/GSSAPI (Kerberos) - starting at version 0.9.0.0。主要是为 Kerberos 使用，如果当前已有 Kerberos 认证，只需要为集群中每个 Broker 和访问用户申请 Principle ，然后在 Kafka 配置文件中开启 Kerberos 的支持即可。官方文档详见 Authentication using SASL/Kerberos。 SASL/PLAIN - starting at version 0.10.0.0。一个简单的用户名和密码身份认证机制，通常与 TLS/SSL 一起用于加密，以实现身份验证。是一种比较容易使用的方式，但是也有一个很明显的缺点，这种方式会把用户账户文件配置到静态文件中，每次想要添加新的账户都需要重启 Kafka 去加载静态文件，才能生效，十分不方便。官方文档详见 Authentication using SASL/PLAIN。 SASL/SCRAM-SHA-256 和 SASL/SCRAM-SHA-512 - starting at version 0.10.2.0。通过将认证信息保存在 ZooKeeper 里面，从而动态的获取用户信息，相当于把 ZK 用作一个认证中心使用。这种认证可以在使用过程中，使用 Kafka 提供的命令动态地创建和删除用户，无需重启整个集群，十分方便。官方文档详见 Authentication using SASL/SCRAM 。 SASL/OAUTHBEARER - starting at version 2.0。Kafka 引入的新认证机制，主要是为了实现与 OAuth2 框架的集成，Kafka 不提倡单纯使用 OAUTHBEARER，因为它生成的不安全 Json Web Token，必须配以 SSL 加密才能在生产环境中使用。官方文档详见 Authentication using SASL/OAUTHBEARER 。 二、SASL+ACL 实现用户及权限认证 2.1、下载 wget https://repo.huaweicloud.com/apache/kafka/3.3.1/kafka_2.12-3.3.1.tgz -P /data cd /data tar -zxf kafka_2.12-3.3.1.tgz ln -s kafka_2.12-3.3.1 kafka cd /data/kafka 2.2、Kafka 服务配置 Kafka server 的 jaas 文件如下： /data/kafka/config/jaas/kafka_server_jaas.conf 这里创建五个用户，密码分别如下，后会会对其进行分别授权。 用户 密码 admin admin123 kwriter kwriter123 kreader kreader123 sharga sharga123 shargb shargb123 创建文件： mkdir /data/kafka/config/jaas/ vim /data/kafka/config/jaas/kafka_server_jaas.conf 配置如下： KafkaServer { org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="admin123" user_admin="admin123" user_kwriter="kwriter123" user_kreader="kreader123" user_sharga="sharga123" user_shargb="shargb123"; }; 2.3、修改 Kafka 服务启动脚本 1、复制一份作为带安全的启动脚本： cp /data/kafka/bin/kafka-server-start.sh/data/kafka/bin/sasl_kafka-server-start.sh 2、修改大概 44 行为如下，引入上面的 jaas.conf 文件，修改为如下 export LOG_DIR=/var/log/kafka-logs export KAFKA_OPTS="-Djava.security.auth.login.config=/data/kafka/config/jaas/kafka_server_jaas.conf" exec $base_dir/kafka-run-class.sh $EXTRA_ARGS kafka.Kafka "$@" 2.4、配置 serv…

Keepalived
type: item
date: 2024-01-25T16:37:00+00:00
description: 一、Keepalived 介绍 Keepalived 是 Linux 下一个轻量级别的高可用解决方案，通过虚拟路由冗余协议来实现服务或者网络的高可用。 起初是为 LVS 设计的，专门用来监控集群系统中各个服务节点的状态。 如果某个服务器节点出现故障，Keepalived 将检测到后自动将节点从集群系统中剔除。 而在故障节点恢复正常后，Keepalived 又可以自动将此节点重新加入集群中。 这些工作自动完成，不需要人工干预，需要人工完成的只是修复出现故障的节点。 1.1、特点： 1、部署简单，只需要配置一个配置文件即可。 2、加入了虚拟路由冗余协议，可以保证业务或网络不间断稳定运行。 1.2、核心功能： 1.2.1、健康检查 采用 tcp 三次握手，icmp 请求，http 请求，udp、echo 请求等方式对负载均衡器后面的实际的服务器 (通常是承载真实业务的服务器) 进行保活。 1.2.2、故障切换 主要应用在配置了主备的服务器上，使用虚拟路由冗余协议维持主备之间的心跳。 当主服务器出现问题时，由备服务器承载对应的业务，从而在最大限度上减少损失，并提供服务的稳定性。 1.3、VRRP 协议 在现实的网络环境中，主机之间的通信都是通过配置静态路由（默认网关）来完成的。 而主机之间的路由器一旦出现故障，就会通信失败。 因此在这种通信模式下，路由器就会有单点瓶颈问题，为了解决这个问题，引入了 VRRP 协议（虚拟路由冗余协议）。 通过 VRRP 可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。 VRRP 可以将两台或多台物理路由器设备虚拟成一个虚拟路由器，这个虚拟路由器通过虚拟 IP（一个或多个）对外提供服务，而在虚拟路由器内部是多个物理路由器协同工作，VRRP 角色如下： 1.3.1、角色 虚拟路由器：VRRP 组中所有的路由器，拥有虚拟的 IP+MAC (00-00-5e-00-01-VRID) 地址。 主路由器（master）：虚拟路由器内部通常只有一台物理路由器对外提供服务，主路由器是由选举算法产生，对外提供各种网络功能。 备份路由器（backup）：VRRP 组中除主路由器之外的所有路由器，不对外提供任何服务，只接受主路由的通告，当主路由器挂掉之后，重新进行选举算法接替 master 路由器。 master 路由器由选举算法产生，它拥有对外服务的 VIP，提供各种网络服务，如 ARP 请求、数据转发、ICMP 等等，而 backup 路由器不拥有 VIP，也不对外提供网络服务。 当 master 发生故障时，backup 将重新进行选举，产生一个新的 master 继续对外提供服务。 1.3.2、VRRP 工作模式 VRRP 有三种工作状态，分别是： Initialize 状态 Master 状态 Backup 状态 选举机制: 抢占模式：一旦有优先级高的路由器加入，立即成为 Master。 非抢占模式：只要 Master 不挂掉，优先级高的路由器只能等待。 二、Keepalived 原理 keepalived 工作在 TCP/IP 参考模型的第三、四和第五层，也就是网络层、传输层和应用层。 网络层：通过 ICMP 协议向集群每个节点发送一个 ICMP 数据包（类似于 ping 功能），如果某个节点没有返回响应数据包，那么认定此节点发生了故障，Keepalived 将报告此节点失效，并从集群中剔除故障节点。 传输层：通过 TCP 协议的端口连接和扫描技术来判断集群节点是否正常，keepalived 一旦在传输层探测到这些端口没有响应数据返回，就认为这些端口所对应的节点发生故障，从集群中剔除故障节点。 应用层：用户可以通过编写程序脚本来运行 keepalived，keepalived 根据脚本来检测各种程序或者服务是否正常，如果检测到有故障，则把对应的服务从服务器中删除。 2.1、组件架构 我们将整个体系结构分层用户层和内核层： Scheduler I/O Multiplexer I/O 复用分发调用器，负责安排 Keepalived 所有的内部的任务请求 Memory Management 内存管理机制，提供了访问内存的一下通用方法 Keepalived Control Plane 控制面板，实现对配置文件的编译和解析，Keepalived 的配置文件解析比较特殊，它并不是一次解析所有模块的配置，而是只有在用到某模块时才解析相应的配置 Core components Keepalived 的核心组件，包含了一系列功能模块，主要有 watch dog、Checkers、VRRP Stack、IPVS wrapper、Netlink Reflector。 watch dog 一个极为简单又非常有效的检测工…

Prometheus & Grafana
type: item
date: 2024-01-11T13:52:00+00:00
description: 一、Prometheus 入门 Prometheus 受启发于 Google 的 Brogmon 监控系统（相似的 Kubernetes 是从 Google 的 Brog 系统演变而来），从 2012 年开始由前 Google 工程师在 Soundcloud 以开源软件的形式进行研发，并且于 2015 年早期对外发布早期版本。 2016 年 5 月继 Kubernetes 之后成为第二个正式加入 CNCF 基金会的项目，同年 6 月正式发布 1.0 版本。2017 年底发布了基于全新存储层的 2.0 版本，能更好地与容器平台、云平台配合。 Prometheus 作为新一代的云原生监控系统，目前已经有超过 650 + 位贡献者参与到 Prometheus 的研发工作上，并且超过 120 + 项的第三方集成。 1.1、Prometheus 的特点 Prometheus 是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型。 相比于传统监控系统，Prometheus 具有以下优点： 1.1.1、易于管理 Prometheus 核心部分只有一个单独的二进制文件，不存在任何的第三方依赖 (数据库，缓存等等)。唯一需要的就是本地磁盘，因此不会有潜在级联故障的风险。 Prometheus 基于 Pull 模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。 对于一些复杂的情况，还可以使用 Prometheus 服务发现 (Service Discovery) 的能力动态管理监控目标 1.1.2、监控服务的内部运行状态 Pometheus 鼓励用户监控服务的内部状态，基于 Prometheus 丰富的 Client 库，用户可以轻松的在应用程序中添加对 Prometheus 的支持，从而让用户可以获取服务和应用内部真正的运行状态。 1.1.3、强大的数据模型 所有采集的监控数据均以指标 (metric) 的形式保存在内置的时间序列数据库当中 (TSDB)。所有的样本除了基本的指标名称以外，还包含一组用于描述该样本特征的标签。 http_request_status {code='200',content_path='/api/path',environment='produment'} => [value1@timestamp1,value2@timestamp2...] http_request_status {code='200',content_path='/api/path2',environment='produment'} => [value1@timestamp1,value2@timestamp2...] 每一条时间序列由指标名称 (Metrics Name) 以及一组标签 (Labels) 唯一标识。每条时间序列按照时间的先后顺序存储一系列的样本值。 http_request_status：指标名称 (Metrics Name) {code='200',content_path='/api/path',environment='produment'}：表示维度的标签，基于这些 Labels 我们可以方便地对监控数据进行聚合，过滤，裁剪。 [value1@timestamp1,value2@timestamp2...]：按照时间的先后顺序存储的样本值。 1.1.4、强大的查询语言 PromQL Prometheus 内置了一个强大的数据查询语言 PromQL。 通过 PromQL 可以实现对监控数据的查询、聚合。同时 PromQL 也被应用于数据可视化 (如 Grafana) 以及告警当中。 通过 PromQL 可以轻松回答类似于以下问题： 在过去一段时间中 95% 应用延迟时间的分布范围？ 预测在 4 小时后，磁盘空间占用大致会是什么情况？ CPU 占用率前 5 位的服务有哪些？(过滤) 1.1.5、高效 对于监控系统而言，大量的监控任务必然导致有大量的数据产生。而 Prometheus 可以高效地处理这些数据，对于单一 Prometheus Server 实例而言它可以处理： 数以百万的监控指标 每秒处理数十万的数据点 1.1.6、可扩展 可以在每个数据中心、每个团队运行独立的 Prometheus Sevrer。Prometheus 对于联邦集群的支持，可以让多个 Prometheus 实例产生一个逻辑集群，当单实例 PrometheusServer 处理的任务量过大时，通过使用功能分区 (sharding)+ 联邦集群 (federation) 可以对其进行扩展。 1.1.7、易于集成 使用 Prometheus…