Prometheus

SQL Server 简介SQL Server 是什么？Microsoft SQL Server 是 Microsoft 推出的关系型数据库解决方案，反对企业 IT 环境中的各种事务处理、商业智能和剖析应用程序。Microsoft SQL Server 是市场当先的数据库技术之一。 SQL Server 特点稳固：针对企业的利用需要，制订出适应环境的解决方案，保障了企业的数据安全和顺利运行。易用：提供了丰盛的图形化管理工具，不便用户疾速搭建数据库系统。兼容：原生适配 Windows 零碎，提供丰盛的 API 拜访。性能：多种数据库引擎优化算法，反对大量数据查问存储。SQL Server 外围概念 关系引擎：关系引擎管制存储引擎对数据的解决，并提供 SQL Server 组件来精确确定应如何执行查问。关系引擎由三个次要局部组成。CMD 解析器（parser）次要负责辨认和打消语义和语法错误，并生成查问树。优化器（Optimizer）通过打消冗余工作和寻找最优打算，确保所申请的查问响应尽可能高效。查问执行器（Query Executoe）会生成数据获取逻辑的行为。 存储引擎：当数据由存储引擎存储时，会从存储系统（例如 SAN 或磁盘）检索数据。存储引擎中存在三种类型的文件：主文件、辅助文件和日志文件。拜访办法（Access Method）负责在缓存管理器和事务日志之间替换数据。缓存管理器（Buffer Manager）缓存以后的执行打算和页。事务管理器（Transaction Manager）应用日志和锁管理器对事务进行治理。 协定层：该层反对客户端-服务器架构以及流。协定层反对 3 种类型的客户端服务器架构：共享内存、TCP/IP、命名管道。 次要实用场景Microsoft SQL Server 凭借其可视化界面及其所具备的选项和工具，非常适合在关系数据库中存储所有所需的信息，以及轻松治理此类数据。 事务处理：SQL Server 反对事务处理，通过应用事务，用户能够将一系列数据库操作组合在一起，并确保它们要么全副胜利执行，要么全副回滚到初始状态。这对于解决银行交易、在线购物和库存治理等须要保证数据一致性的应用程序十分要害。通过大数据集群对所有数据进行智能剖析：SQL Server 提供了弱小的数据仓库和商业智能性能。用户能够应用 SSIS 将数据从不同的数据源中提取、转换和加载到数据仓库中。而后，您能够应用 SSAS 创立多维数据模型和立方体，以反对简单的数据分析和报表需要。此外，SQL Server还提供了数据挖掘和预测剖析性能，帮忙组织发现数据中暗藏的模式和趋势。可扩展性：SQL Server 提供了宽泛的开发和编程性能，以反对应用程序开发人员。SQL Server 还反对程度和垂直扩大，用户能够在须要时减少服务器硬件资源或在多个服务器之间进行数据分区和散布，以解决大规模数据和高并发负载。SQL Server 容许用户轻松地将数据库管理系统与任何设施和 Azure 服务集成，以取得更好的数据性能和剖析能力。次要版本介绍SQL Server 2022：平安、性能、可用性等增强；查问存储和智能查询处理 SQL Server 2019：数据虚拟化和大数据群集；智能数据库、智能查问；内存数据库 SQL Server 2017：图形数据库性能、动静治理视图、内存优化等 ...

阐明：prometheus、alertmanager、grafana、dingtalk 、node_exporter 均应用k8s部署k8s版本：v1.20.15所有利用部署形式：docker启动，且都能失常应用 一、yaml 筹备alertmanager-all-in-one.yamlapiVersion: v1data: config.yml: | global: resolve_timeout: 30s route: group_by: ['docker', 'node', 'prometheus', 'instance'] group_interval: 30s group_wait: 5m repeat_interval: 1h receiver: webhook routes: - match: severity: 'Critical' receiver: 'webhook' - match_re: severity: ^(Warning|Disaster)$ receiver: 'webhook' receivers: - name: 'webhook' webhook_configs: - url: http://dingtalk.prom-test.svc.cluster.local:8060/dingtalk/webhook/send send_resolved: truekind: ConfigMapmetadata: name: alertmanager namespace: prom-test ---apiVersion: apps/v1kind: Deploymentmetadata: name: alertmanager namespace: prom-test labels: app: alertmanagerspec: selector: matchLabels: app: alertmanager template: metadata: labels: app: alertmanager spec: nodeName: node-5 volumes: - name: config configMap: name: alertmanager containers: - name: alertmanager image: prom/alertmanager imagePullPolicy: IfNotPresent args: - "--config.file=/etc/alertmanager/config.yml" - "--log.level=debug" ports: - containerPort: 9093 name: http volumeMounts: - mountPath: "/etc/alertmanager" name: config resources: requests: cpu: 100m memory: 256Mi limits: cpu: 2 memory: 2Gi ---apiVersion: v1kind: Servicemetadata: name: alertmanager namespace: prom-testspec: type: NodePort ports: - name: web port: 9093 targetPort: http nodePort: 30333 selector: app: alertmanagerprometheus-all-in-one.yamlapiVersion: v1kind: ConfigMapmetadata: name: prometheus-config namespace: prom-testdata: prometheus.yml: | global: scrape_interval: 15s evaluation_interval: 15s # alertmanager alerting: alertmanagers: - static_configs: - targets: - alertmanager:9093 # 告警规定门路,相对路径 rule_files: - "*-rule.yml" scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] - job_name: 'coredns' static_configs: - targets: ['10.96.0.10:9153'] - job_name: 'kubernetes-apiserver' static_configs: - targets: ['10.96.0.1'] scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token - job_name: 'kubernetes-sd-node-exporter' kubernetes_sd_configs: - role: node relabel_configs: - source_labels: [__address__] regex: '(.*):10250' replacement: '${1}:9100' target_label: __address__ action: replace - source_labels: [__address__] regex: '(.*):(9.*)' replacement: '$1' target_label: ip action: replace - job_name: 'kubernetes-sd-cadvisor' kubernetes_sd_configs: - role: node scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - target_label: __address__ replacement: 10.96.0.1 - source_labels: [__meta_kubernetes_node_name] regex: (.+) target_label: __metrics_path__ replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor - job_name: "huaweicloud-linux" static_configs: - targets: ["xxx.xxx.xx.xx:9100","xxx.xxx.xx.xx:9100"] - job_name: "icmp_ping" metrics_path: /probe params: module: [icmp] # 应用icmp模块 static_configs: - targets: ["xxx.xxx.xx.xx"] relabel_configs: - source_labels: [__address__] regex: (.*)(:80)? target_label: __param_target replacement: ${1} - source_labels: [__param_target] target_label: instance - source_labels: [__param_target] regex: (.*) target_label: ping replacement: ${1} - source_labels: [] regex: .* target_label: __address__ replacement: xxx.xxx.xx.xx:9115 - job_name: "http_get_status" metrics_path: /probe params: module: [http_2xx] # Look for a HTTP 200 response. static_configs: - targets: - "https://xxx.xxx.com.cn:{port}" relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: "xxx.xxx.x.xx:9115" # 指向理论的Blackbox exporter. - target_label: region replacement: "xxx.xxx.x.xx:9115" - job_name: 'tcp_port_status' metrics_path: /probe params: module: [tcp_connect] static_configs: - targets: ["https://xxx.xxx.com.cn:8090","xxx.xxx.xx.xx:{port}","xxx.xxx.xx.xx:{port}"] labels: instance: 'port_status' group: 'tcp' relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: xxx.xxx.xx.xx:9115 - job_name: "nacos-server" metrics_path: '/nacos/actuator/prometheus' static_configs: - targets: ["xxx.xxx.xx.xx:8848"] - job_name: 'Rabbitmq' scrape_interval: 5s static_configs: - targets: - xxx.xxx.xx.xx:9419 labels: instance: RabbitMQ-xxx.xxx.xx.xx - job_name: 'redis' static_configs: - targets: ['xxx.xxx.xx.xx:9121'] - job_name: 'mysql-service' static_configs: - targets: ["xxx.xxx.xx.xx:9104"] node-rule.yml: | groups: - name: node rules: - alert: CPU_High expr: floor((1 - (sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by (instance) / sum(increase(node_cpu_seconds_total[1m])) by (instance))) * 100) > 1 for: 3s labels: status: Critical annotations: summary: "in prometheus {{ $labels.instance }}: High CPU usage" description: "{{ $labels.instance }} of job {{ $labels.job }} CPU usage is {{ $value }}%" - alert: Free_High expr: floor(100 - (node_memory_MemFree_bytes + node_memory_Cached_bytes + node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100) > 0 for: 3s labels: status: Critical annotations: summary: "in prometheus {{ $labels.instance }}: High Free usage" description: "{{ $labels.instance }} of job {{ $labels.job }} Free usage is {{ $value }}%" ---apiVersion: apps/v1kind: Deploymentmetadata: name: prometheus namespace: prom-test labels: app: prometheusspec: selector: matchLabels: app: prometheus template: metadata: labels: app: prometheus spec: serviceAccountName: prometheus # 援用这个servicecount initContainers: - name: "change-permission-of-directory" image: swr.cn-north-1.myhuaweicloud.com/htsd/busybox:latest command: ["/bin/sh"] args: ["-c", "chown -R 65534:65534 /prometheus"] securityContext: privileged: true volumeMounts: - mountPath: "/etc/prometheus" name: config-volume - mountPath: "/prometheus" # 挂载到容器的门路,挂载点 name: data containers: - image: swr.cn-north-1.myhuaweicloud.com/htsd/prometheus:v2.33.2 name: prometheus args: - "--config.file=/etc/prometheus/prometheus.yml" - "--storage.tsdb.path=/prometheus" # 指定tsdb数据门路 - "--web.enable-lifecycle" # 反对热更新，间接执行localhost:9090/-/reload立刻失效 - "--web.console.libraries=/usr/share/prometheus/console_libraries" - "--web.console.templates=/usr/share/prometheus/consoles" ports: - containerPort: 9090 name: http volumeMounts: - mountPath: "/etc/prometheus" name: config-volume - mountPath: "/prometheus" name: data resources: requests: cpu: 200m memory: 512Mi limits: cpu: 4 memory: 4Gi volumes: - name: data persistentVolumeClaim: claimName: prometheus-pvc - configMap: name: prometheus-config name: config-volume ---apiVersion: v1kind: ServiceAccountmetadata: name: prometheus namespace: prom-test---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: prometheusrules:- apiGroups: - "" resources: - nodes - services - endpoints - pods - nodes/proxy verbs: - get - list - watch- apiGroups: - "extensions" resources: - ingresses verbs: - get - list - watch- apiGroups: - "" resources: - configmaps - nodes/metrics verbs: - get- nonResourceURLs: # 非资源类型的URL,这里就是用于抓取指标采集的接口. - /metrics verbs: - get---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: prometheusroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: prometheussubjects:- kind: ServiceAccount name: prometheus namespace: prom-test ---apiVersion: v1kind: Servicemetadata: name: prometheus namespace: prom-test labels: app: prometheusspec: selector: app: prometheus type: NodePort ports: - name: web port: 9090 targetPort: http nodePort: 30650 ---apiVersion: v1kind: PersistentVolumeClaimmetadata: name: prometheus-pvc namespace: prom-test #annotations: #volume.beta.kubernetes.io/storage-class: "nfs"spec: storageClassName: huaweicloud-nfs # 这肯定要写明是关联的哪个storageclass accessModes: - ReadWriteMany resources: requests: storage: 10Gi # 依据理论状况批改grafana-all-in-one.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: grafana namespace: prom-testspec: selector: matchLabels: app: grafana template: metadata: labels: app: grafana spec: volumes: - name: storage persistentVolumeClaim: claimName: grafana-pvc securityContext: runAsUser: 0 containers: - name: grafana image: swr.cn-north-1.myhuaweicloud.com/htsd/grafana:8.5.0 imagePullPolicy: IfNotPresent ports: - containerPort: 3000 name: grafana env: - name: GF_SECURITY_ADMIN_USER value: admin - name: GF_SECURITY_ADMIN_PASSWORD value: admin@123 readinessProbe: failureThreshold: 10 httpGet: path: /api/health port: 3000 scheme: HTTP initialDelaySeconds: 60 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 30# livenessProbe:# failureThreshold: 3# httpGet:# path: /api/health# port: 3000# scheme: HTTP# periodSeconds: 10# successThreshold: 1# timeoutSeconds: 1 resources: limits: cpu: 500m memory: 512Mi requests: cpu: 150m memory: 512Mi volumeMounts: - mountPath: /var/lib/grafana name: storage---apiVersion: v1kind: Servicemetadata: name: grafana namespace: prom-testspec: type: ClusterIP ports: - port: 3000 selector: app: grafana ---apiVersion: v1kind: PersistentVolumeClaimmetadata: name: grafana-pvc namespace: prom-test #annotations: #volume.beta.kubernetes.io/storage-class: "nfs"spec: storageClassName: huaweicloud-nfs accessModes: - ReadWriteMany resources: requests: storage: 10Gidingtalk-all-in-one.yamlapiVersion: v1kind: ConfigMapmetadata: name: dingtalk-config namespace: prom-testdata: config.yml: |- templates: - /etc/prometheus-webhook-dingtalk/dingding.tmpl targets: webhook: # 钉钉上创立机器人给的token, 须要改成本人的 url: https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxx mention: all: true dingding.tmpl: |- {{ define "dingtalk.to.message" }} {{- if gt (len .Alerts.Firing) 0 -}} {{- range $index, $alert := .Alerts -}} ========= **监控告警** ========= **告警集群:** k8s **告警类型:** {{ $alert.Labels.alertname }} **告警级别:** {{ $alert.Labels.severity }} **告警状态:** {{ .Status }} **故障主机:** {{ $alert.Labels.instance }} {{ $alert.Labels.device }} **告警主题:** {{ .Annotations.summary }} **告警详情:** {{ $alert.Annotations.message }}{{ $alert.Annotations.description}} **主机标签:** {{ range .Labels.SortedPairs }} </br> [{{ .Name }}: {{ .Value | markdown | html }} ] {{- end }} </br> **故障工夫:** {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }} ========= = **end** = ========= {{- end }} {{- end }} {{- if gt (len .Alerts.Resolved) 0 -}} {{- range $index, $alert := .Alerts -}} ========= **故障复原** ========= **告警集群:** k8s **告警主题:** {{ $alert.Annotations.summary }} **告警主机:** {{ .Labels.instance }} **告警类型:** {{ .Labels.alertname }} **告警级别:** {{ $alert.Labels.severity }} **告警状态:** {{ .Status }} **告警详情:** {{ $alert.Annotations.message }}{{ $alert.Annotations.description}} **故障工夫:** {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }} **复原工夫:** {{ ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }} ========= = **end** = ========= {{- end }} {{- end }} {{- end }} ---apiVersion: apps/v1kind: Deploymentmetadata: name: dingtalk namespace: prom-testspec: replicas: 1 selector: matchLabels: app: dingtalk template: metadata: name: dingtalk labels: app: dingtalk spec: nodeName: node-5 containers: - name: dingtalk image: timonwong/prometheus-webhook-dingtalk imagePullPolicy: IfNotPresent ports: - containerPort: 8060 volumeMounts: - name: config mountPath: /etc/prometheus-webhook-dingtalk volumes: - name: config configMap: name: dingtalk-config ---apiVersion: v1kind: Servicemetadata: name: dingtalk namespace: prom-test labels: app: dingtalk annotations: prometheus.io/scrape: 'false'spec: selector: app: dingtalk ports: - name: dingtalk port: 8060 protocol: TCP targetPort: 8060node-exporter.yamlapiVersion: apps/v1kind: DaemonSetmetadata: name: node-exporter namespace: prom-test labels: app: node-exporterspec: selector: matchLabels: app: node-exporter template: metadata: labels: app: node-exporter spec: hostPID: true hostIPC: true hostNetwork: true nodeSelector: kubernetes.io/os: linux containers: - name: node-exporter image: swr.cn-north-1.myhuaweicloud.com/htsd/node-exporter:v1.3.0 # 因的containerd配置文件写的state = "/data/containerd/run", 故排除data/containerd/ # docker默认的为/var/lib/docker/ args: - --web.listen-address=$(HOSTIP):9100 - --path.procfs=/host/proc - --path.sysfs=/host/sys - --path.rootfs=/host/root - --collector.filesystem.mount-points-exclude==^/(dev|proc|sys|data/containerd/|var/lib/docker/.+)($|/) - --collector.filesystem.fs-types-exclude=^(autofs|binfmt_misc|cgroup|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|sysfs|tracefs)$ ports: - containerPort: 9100 env: - name: HOSTIP valueFrom: fieldRef: fieldPath: status.hostIP resources: requests: cpu: 500m memory: 200Mi limits: cpu: 500m memory: 200Mi securityContext: runAsNonRoot: true runAsUser: 65534 volumeMounts: - name: proc mountPath: /host/proc - name: sys mountPath: /host/sys - name: root mountPath: /host/root mountPropagation: HostToContainer readOnly: true # master节点都有污点,然而master节点也须要被监控,退出容忍污点,也就能够在master上部署一个客户端 tolerations: - operator: "Exists" volumes: - name: proc hostPath: path: /proc - name: dev hostPath: path: /dev - name: sys hostPath: path: /sys - name: root hostPath: path: /二、部署阐明：prometheus的configmap外面配置了除k8s集群之外的监控（mysql、redis等等），dingtalk的configmap外面配置webhook url也须要改成本人的，在这里咱们先能够将prometheus、alertmanager、grafana、dingtalk、node_exporter先部署起来，前面再依据本人的需要进行配置。这里咱们将所有的yaml放在同一目录上面。 ...

背景新增两台物理机用于压测，为了监控服务器状况，现须要对服务器进行监控，所有须要装置prometheus+grafana来监控服务。 筹备机器： 机器1机器2192.168.1.103192.168.1.102mock服务，压测脚本业务服务prometheus+ grafana+node-exporter+cadvisornode-exporter+cadvisor阐明： cadvisor: 用于收集容器的信息 node-exporter: 用于收集机器主机的信息 prometheus:别离把node-exporter和cadivsor的数据对立汇合 grafana: 页面web展现同步工夫因为物理机是新装的centos7.9的零碎，本地工夫和windows的工夫不统一，会导致后续的grafana不能拉取到数据no data. 同步网络工夫很重要。 date 查看工夫敞开防火墙或者凋谢相应的端口 systemctl status firewalld 查看防火墙状况机器的网口名要统一 目前我的两台机器网口名一个是:p2p1, 一个是:enp3s0. 导致grafana页面填写收集的表达式device不能对立，很麻烦。node_network_receive_bytes_total{instance=~'$node', device="enp3s0", job="host"} ifconfig 查看网口名装置ntpdyum install -y ntpd systemctl enable ntpdsystemctl start ntpd systemctl status ntpd 同步工夫ntpdate -u ntp.sjtu.edu.cn 开始部署node-exporterdocker run -v "/proc:/host/proc" -v "/sys:/host/sys" -v "/:/rootfs" --net=host --restart=always --name node-exporter prom/node-exporter --path.procfs /host/proc --path.sysfs /host/sys --collector.filesystem.ignored-mount-points "^/(sys|proc|dev|host|etc)($|/)"阐明: node-exporter肯定要以host模式装置，bridge模式，不能收集到网口的数据。 cadvisor docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys/sys:ro --volume=/home/docker-file/:/var/lib/docker:ro --volume=/dev/disk:/dev/disk:ro --net=host --detach=true --name=cadvisor --restart=always google/cadvisor:latest阐明： --volume=/home/docker-file:/var/lib/docker 这个指向的是本地docker服务运行的门路，我这里是指向了/home/docker-file门路，如果没有改变的话就是/var/lib/docker。df -h 能够查看门路。 ...

n9e=nightingale n9e监控告警框架，提供了监控绘图、监控告警以及告诉等一体的监控运维体系，在云原生时代，能够认为是Open-falcon的升级版。 一. 告警的数据流指标存储：应用push模式 categraf采集后push给n9e-server；n9e-server将指标值push给时序库prometheus；指标告警：应用pull模式 由n9e-server应用PromQL向prometheus进行查问；若查问到后果，示意告警被触发； 二. 告警实例的高可用告警配置被存储在MySQL中，n9e-server从MySQL中读出，而后查问其中的PromQL，断定告警是否被触发。 1. 问题相似于prometheus，当部署多个n9e-server实例后，若每个n9e-server都进行下面的告警断定过程，会导致每个n9e-server上都有告警产生。 prometheus是通过alertmanager进行告警去重的，那n9e-server是如何实现的呢？ 2. 解决n9e-server通过heartbeat+一致性hash，对告警规定进行分片，每个n9e-server只负责本人实例的告警规定的断定。 当n9e-server有实例退出时，已有的n9e-server实例会进行rehash，让新节点负责一部分告警规定；当n9e-server有实例退出时，所有的n9e-server实例会进行rehash，退出节点的告警规定被分给存活的节点；Heartbeat: n9e-server实例启动一个heartbeat线程，定期的上报本人的状态并存储在MySQL中；若发现过程内保留的实例列表与MySQL的实例列表不同，阐明产生了节点变动，则进行rehash；一致性hash: 对某个datasource，比方prometheus-a1，有N个n9e-server注册进来，则将N个n9e-server组成一致性hash环；对某个告警规定，应用rule.id进行一致性hash，命中到哪个n9e-server实例，就由其进行告警断定； 三. 源码剖析实现代码次要在alert/naming/*.go。 在做告警断定时，对每个告警规定： 若rule不归本节点负责，则跳过；// alert/eval/alert_rule.gofunc (s *Scheduler) syncAlertRules() { ids := s.alertRuleCache.GetRuleIds() alertRuleWorkers := make(map[string]*AlertRuleWorker) externalRuleWorkers := make(map[string]*process.Processor) for _, id := range ids { rule := s.alertRuleCache.Get(id) if rule == nil { continue } if rule.IsPrometheusRule() { datasourceIds := s.promClients.Hit(rule.DatasourceIdsJson) for _, dsId := range datasourceIds { // 断定rule是否归本节点负责 if !naming.DatasourceHashRing.IsHit(dsId, fmt.Sprintf("%d", rule.Id), s.aconf.Heartbeat.Endpoint) { continue } ... } } ... } ...}1. 一致性hash一致性hash的key=rule.id，依据key判断该rule是否归本节点负责： ...

prometheus中的指标timestamp有两个： prometheus拉取时刻的timestamp，即服务端的工夫：time.Now()；exporter的/metrics接口，除了返回metric，value，还返回timestamp；# HELP container_cpu_user_seconds_total Cumulative user cpu time consumed in seconds.# TYPE container_cpu_user_seconds_total countercontainer_cpu_user_seconds_total{container="",id="/",image="",name="",namespace="",pod=""} 788250.59 1692241058502container_cpu_user_seconds_total{container="",id="/kubepods.slice",image="",name="",namespace="",pod=""} 378238.54 1692241058529一. prometheus的配置对下面的两个timestamp，prometheus通过上面的配置决定抉择哪一个。 1. 配置# honor_timestamps controls whether Prometheus respects the timestamps present# in scraped data.## If honor_timestamps is set to "true", the timestamps of the metrics exposed# by the target will be used.## If honor_timestamps is set to "false", the timestamps of the metrics exposed# by the target will be ignored.[ honor_timestamps: <boolean> | default = true ]应用honor_timestamps配置拉取指标的工夫： ...

在应用 Prometheus 时，文档中提供的指标和标签约定并不是必须的，但能够作为款式指南和最佳实际的汇合。不同的组织能够对某些实际办法（例如命名约定）采取不同的形式。 指标名称指标名称应该合乎以下特色： 必须合乎数据模型中无效字符的要求。应该应用与指标所属畛域相干的（单词）应用程序前缀。前缀有时被客户端库称为命名空间。对于特定应用程序的指标，前缀通常是应用程序名称自身。然而，有时指标更通用，例如由客户端库导出的标准化指标。例子： prometheus_notifications_total（特定于 Prometheus 服务器）process_cpu_seconds_total（由许多客户端库导出）http_request_duration_seconds（用于所有 HTTP 申请）必须具备单个单位（即不要将秒[seconds]与毫秒[milliseconds]混用，或将秒[seconds]与字节[bytes]混用）。应该应用根本单位（例如秒[seconds]、字节[bytes]、米[meters] - 而不是毫秒[milliseconds]、兆字节[megabytes]、千米[kilometers]）。最初有一个根本单位的列表。应该有一个以复数模式形容单位的后缀。留神，累积计数器在单位实用的状况下，除了单位外还有 total 作为后缀。 http_request_duration_secondsnode_memory_usage_byteshttp_requests_total（无单位的 counter 计数器）process_cpu_seconds_total（带有单位的 counter 计数器）foobar_build_info（提供无关运行二进制文件的元数据的伪指标）data_pipeline_last_record_processed_timestamp_seconds（用于跟踪数据处理流水线中最新记录解决工夫的工夫戳）应该在所有标签维度上示意雷同的逻辑测量对象。 申请持续时间数据传输字节数刹时资源使用率的百分比作为一个教训法令，给定指标的所有维度的 sum() 或 avg() 应该是有意义的（不论有没有用）。如果没有意义，则应该将数据拆分成多个指标。例如，在一个指标中混合队列的容量和队列中以后元素数量是不好的，而将各种队列的容量放在一个指标中是能够的。 标签应用标签来辨别被测量对象的个性： api_http_requests_total - 辨别申请类型：operation="create|update|delete"api_request_duration_seconds - 辨别申请阶段：stage="extract|transform|load"不要将标签名称放在指标名称中，这会导致冗余，并且如果相应的标签被聚合掉，将会引起混同。 留神：每个惟一的键-值标签对的组合示意一个新的工夫序列，这可能会大大增加存储的数据量。不要应用具备高基数（不能枚举的，许多不同标签值）的标签来存储维度，例如用户ID、电子邮件地址或其余无边界的汇合。 根本单位Prometheus 没有任何硬编码的单位。为了更好的兼容性，应应用根本单位。以下是一些指标家族及其根本单位的列表。该列表并不详尽。 家族根本单位备注Timeseconds Temperaturecelsius摄氏度出于理论起因而被优先选择，开尔文（绝对温度）则保留给须要绝对温度值或准确温度差的专门状况应用Lengthmeters Bytesbytes Bitsbytes为了防止混同不同度量规范，即便比特看起来更常见，也应始终应用字节。Percentratio数值范畴为0-1（而不是0-100）。ratio只用作像disk_usage_ratio这样的名称的后缀。通常的度量规范名称遵循A_per_B的模式。Voltagevolts Electric currentamperes Energyjoules Power 倡议导出以焦耳计量的计数器(counter)，这样应用 rate(joules[5m])能够失去以瓦特为单位的功率。Massgrams为了防止应用千（kilo）前缀时可能呈现的问题，倡议应用克而不是千克。伪指标（pseudo-metric）在Prometheus中是指提供对于运行二进制文件的元数据或其余附加信息的指标。它们通常不参加度量或监控理论的业务指标，而是用于提供无关零碎或应用程序状态的描述性信息。例如，"foobar_build_info" 能够是一个伪指标，它提供无关正在运行的二进制文件的版本号、构建工夫、构建者等信息。这些信息对于运行时的调试、故障排查和版本追踪十分有用，但不间接与业务指标相干。伪指标能够通过在指标命名中应用 "_info" 或其余相似的后缀来辨别。这样能够与其余实在的度量指标进行辨别，并且在查问和可视化时能够独自解决。

grafana[root@vm5 ~]# wget https://dl.grafana.com/oss/release/grafana-10.0.0.linux-amd64.tar.gz [root@vm5 ~]# tar -xf grafana-10.0.0.linux-amd64.tar.gz[root@vm5 ~]# mv grafana-10.0.0 /home/grafana[root@vm5 ~]# cat /usr/lib/systemd/system/grafana.service[Unit]Description=Grafana ServerAfter=network-online.target[Service]Restart=on-failureExecStart=/home/grafana/bin/grafana-server -config /home/grafana/conf/defaults.ini -homepath /home/grafana[Install]WantedBy=multi-user.target[root@vm5 ~]# systemctl daemon-reload[root@vm5 ~]# systemctl start grafana[root@vm5 ~]# systemctl enable grafanaprometheushttps://prometheus.io/download/[root@vm11 ~]# tar -xf prometheus-2.44.0.linux-amd64.tar.gz[root@vm11 ~]# mv prometheus-2.44.0 /opt/prometheus[root@vm11 ~]# cat /usr/lib/systemd/system/prometheus.service[Unit]Description=Prometheus server DaemonAfter=network.target[Service]Type=simpleUser=rootGroup=rootExecStart=/opt/prometheus/prometheus --web.listen-address=0.0.0.0:37090 --config.file=/opt/prometheus/prometheus.yml --storage.tsdb.path=/opt/data/prometheus --storage.tsdb.retention=15d --web.enable-lifecycleRestart = on-failure[Install]WantedBy=multi-user.target[root@vm5 ~]# systemctl daemon-reload[root@vm5 ~]# systemctl start prometheus[root@vm5 ~]# systemctl enable prometheusalertmanagerwget https://github.com/prometheus/alertmanager/releases/download/v0.24.0/alertmanager-0.24.0.linux-amd64.tar.gztar -xf alertmanager-0.25.0.linux-amd64.tar.gz mv alertmanager-0.25.0.linux-amd64 /opt/alertmanagervim /etc/systemd/system/alertmanager.service[Unit]Description=AlertManager ServiceAfter=network.target[Service]Restart=alwaysExecStart=/opt/alertmanager/alertmanager --config.file=/opt/alertmanager/alertmanager.yml --web.listen-address=0.0.0.0:33093Type=simpleUser=rootGroup=root[Install]WantedBy=multi-user.targetsystemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager

node_exporter installwget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gzcat /usr/lib/systemd/system/node_export.service[Unit]Description=node_exporterDocumentation=https://prometheus.io/After=network.target [Service]Type=simpleUser=rootExecStart=/usr/local/bin/node_exporter --web.listen-address=0.0.0.0:39100 --collector.systemd --collector.systemd.unit-whitelist=(docker|sshd).service --collector.textfile.directory /var/lib/node_exporter/textfile_collector/Restart=on-failure [Install]WantedBy=multi-user.targetmv /usr/lib/systemd/system/node_export.service /usr/lib/systemd/system/node_exporter.servicesystemctl daemon-reloadsystemctl enable node_exporterCreated symlink from /etc/systemd/system/multi-user.target.wants/node_exporter.service to /usr/lib/systemd/system/node_exporter.service.systemctl start node_exporternetstat -tnplActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1079/sshd tcp6 0 0 :::22 :::* LISTEN 1079/sshd tcp6 0 0 ::1:25 :::* LISTEN 1399/master tcp6 0 0 :::39100 :::* LISTEN 6735/node_exporter tcp6 0 0 :::39104 :::* LISTEN 4456/mysqld_exporte ...

install mysql exporterwget https://github.com/prometheus/mysqld_exporter/releases/download/v${VER}/mysqld_exporter-${VER}.linux-amd64.tar.gztar -xf mysqld_exporter-0.15.0-rc.0.linux-amd64.tar.gzmv mysqld_exporter-0.15.0-rc.0.linux-amd64 [root@vm1 ~]# cat /usr/local/mysqld_exporter/mysql.cnf [client]user=readpassword=m!maport=6333add service[root@vm1 home]# vim /usr/lib/systemd/system/mysqld_exporter.service[Unit]Description=mysqld_exporterDocumentation=https://prometheus.ioWants=network-online.targetAfter=network.target[Service]Type=simpleUser=rootExecStart=/usr/local/mysqld_exporter/mysqld_exporter --config.my-cnf=/usr/local/mysqld_exporter/mysql.cnf --web.listen-address=0.0.0.0:39104Restart=on-failure[Install]WantedBy=multi-user.target[root@vm1 home]# systemctl daemon-reload[root@vm1 home]# systemctl restart mysqld_exporter[root@vm1 home]# systemctl enable mysqld_exporterCreated symlink from /etc/systemd/system/multi-user.target.wants/mysqld_exporter.service to /usr/lib/systemd/system/mysqld_exporter.service.[root@vm1 home]# netstat -tnlpActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1399/master tcp6 0 0 :::39104 :::* LISTEN 4456/mysqld_exporte

JVM 默认会通过 JMX 的形式裸露根底指标，很多中间件也会通过 JMX 的形式裸露业务指标，比方 Kafka、Zookeeper、ActiveMQ、Cassandra、Spark、Tomcat、Flink 等等。把握了 JMX 监控形式，就把握了一批程序的监控形式。本节介绍 JMX-Exporter 的应用，利用 JMX-Exporter 把 JMX 监控数据裸露为 Prometheus 可辨认的格局。JMXJMX（Java Management Extensions）是 Java 治理扩大的简称，是一种为 Java 应用程序植入治理性能的框架。Java 类程序常常应用 JMX 裸露监控指标数据，也能够通过 JMX 来管制 Java 类程序，典型的比方通过 JMX 触发程序 GC。 Java 程序里，某个类如果实现了 MBean 接口，那么这个类就能够通过 JMX 来读取和批改这个类的属性，也能够调用这个类的办法。JMX 通过 MBeanServer 来治理 MBean，MBeanServer 是一个管理器，它能够治理多个 MBean，每个 MBean 都有一个 ObjectName，用来惟一标识这个 MBean。 更新信息能够参考 JMX Specification。非本文重点。 JMX-Exporter 简介JMX-Exporter 是 Prometheus 社区提供的一个工具，用来把 JMX 裸露的监控指标数据转换为 Prometheus 可辨认的格局。JMX-Exporter 通过 HTTP 服务的形式裸露监控指标数据，Prometheus 通过 HTTP 协定来拉取监控指标数据。 JMX-Exporter 就是个 jar 包，以 javaagent（何为 javaagent，须要读者自行 Google） 的形式运行，和业务 Java（或 Scala） 程序运行在一个 JVM 虚拟机里。有了 JMX-Exporter，业务程序无需裸露 JMX 端口了，JMX-Exporter 会把 JMX 裸露的监控指标数据转换为 Prometheus 可辨认的格局，而后通过 HTTP 只读形式裸露进来，也更为平安。 ...

背景：过程是这样的，须要与合作方数据进行交互（必定是不容许间接连对方数据源的），对方提供了两台server，后端共事在server下面作了proxy搭建了桥接的利用（两台server没有公网ip，通过一个超级难用的堡垒机明御进行治理）。两台server挂在在了负载平衡slb上对外提供http服务（环境为阿里云环境）。我的项目马上要上线了，而后就面临一个问题，如何监控这个桥接程序的衰弱状态呢？想到了几种形式：1 .云商的拨测服务：比方腾讯云的云拨测（Cloud Automated Testing，CAT）2.还搜到了开源的我的项目Uptime Kuma。3.当然了还找到了能够与prometheus联合应用的blackbox\_exporter(Prometheus 社区提供的官网黑盒监控解决方案)集体的prometheus集群是kube-prometheus,搭建形式参照：Kubernetes 1.20.5 装置Prometheus-Oprator。上面次要基于腾讯云的云拨测和blackbox\_exporter的形式实现一下对近程web服务的拨测： 对近程http服务的拨测体验云拨测CAT配置以及体验关上腾讯云可观测平台：https://console.cloud.tencent.com/monitor/overview2,点击左侧边栏云拨测服务：能够看到上方云拨测的利用场景： 网络品质 页面性能 文件传输(上传/下载) 端口性能 音视频体验。我这里的场景次要应用了端口性能！当然了点击云拨测的时候还呈现了这404的页面，疏忽这该死的体验感！新建工作参照：新建自定义拨测，我这里应用了新建端口性能工作：拨测的频率最低这里只能反对到五分钟......（试用版，传输类型，挪动端不反对一分钟粒度），拨测点配置试用版只反对6 个拨测点，我这里顺手点了五个，而后创立了工作：点击查看剖析剖析页面初始是空白的须要期待一会能力呈现相干数据大略期待五分钟左右（拨测粒度工夫）然而吐槽一下 这里有默认的 502也会显示失常 100%，因为这里没有做statuscode验证，点击工作，进行编辑增加验证形式：这里简略批改了一下工作设置拨测参数配置，验证形式 验证statusCode 200恩这样就能够了，非200默认为失败，当然了这里失常应该依据理论需要来设置，我这里就是探测源站存活，没有针对uri进行更具体的探测！接下来是报警：很恶心连贯性很差 佛系设置了。这里吐槽一下正确率不应该设置默认的小于号吗？另外这种的云拨测的 能弹性伸缩....伸缩能够带来什么呢？告警模板能够依据本人需要创立：参照：告警接管 短信报警大略就是这个样子： 对此产品的不满价格问题参照：https://cloud.tencent.com/document/product/280/79416。我想创立一个探测工作一个月须要1299？如果我对一个网站做网络品质 页面性能 文件传输(上传/下载) 端口性能 音视频体验，貌似须要1299*6（工作外面上传下载是离开的）？如果我对一个网站的100个接口进行拨测呢？那这是多少工作？怎么免费.....对于我集体来说，我宁愿国内搭建七个节点的边缘集群，本人去做探测了....... 页面的连贯，一致性眼神好的应该看到下面截图的差异了，可观测平台外面的云拨测与云拨测这里的题目根本分类都有点不统一了？另外对于拨测增加告警监控，在工作下面设置是不是更好？我做了工作了不能顺畅的创立监控告警，如果在观测平台须要跳转到告警治理这里配置.... 告警模板告警模板也很刺激...操作这里居然没有批改？要点击告警模板的链接进入能力批改告警策略？另外集体用cls日志服务较多，日志服务中监控告警跟可观测平台没有交融在所有，且cls日志中监控告警的告诉渠道组是不是就是实践上告警治理这里的告诉模板呢？居然也没有买通....齐全是孤岛........ Blackbox简略应用对于Blackbox参照github:https://github.com/prometheus/blackbox_exporter.The blackbox exporter allows blackbox probing of endpoints over HTTP, HTTPS, DNS, TCP, ICMP and gRPC(blackbox exporter容许通过 HTTP、HTTPS、DNS、TCP、ICMP 和 gRPC 对端点进行黑盒探测)这里的blackbox exporter曾经默认装置了：Kubernetes 1.20.5 装置Prometheus-Oprator kubectl get pods -n monitoringblackbox-exporter为对应pod服务！这里演示只进行简略的http code 200检测！ 批改配置文件想查看一下monitoring命名空间下的configmap kubectl get cm -n monitoring通过名字能够看出blackbox-exporter-configuration为blackbox-exporter的配置文件，查看一下此配置文件内容： kubectl get cm blackbox-exporter-configuration -n monitoring -o yaml略微批改了一下下http\_2xx： ...

注：图片起源百度，侵删 参考官网文档：https://prometheus.io/docs/prometheus/latest/querying/functions1 1. 了解rate函数rate函数是用于计算工夫序列数据的速率（rate）的函数之一。rate函数的公式为： rate(metric[range-vector])其中metric是一个指标名称，range-vector是一个时间段范畴，例如[5m]示意5分钟的工夫范畴。该函数返回的是在指定工夫范畴内，每秒钟平均值的变化率。 例如，假如咱们有一个名为http_requests_total的指标，示意每秒钟HTTP申请的数量。如果咱们想要计算过来5分钟中的HTTP申请速率，则能够应用以下查问： rate(http_requests_total[5m])这将返回过来5分钟内HTTP申请的均匀速率，单位为每秒。在理论利用中，rate函数通常与其余函数联合应用，例如sum或avg，以便计算多个工夫序列的速率或均匀速率。例如，如果咱们想要计算所有Web服务器的HTTP申请速率，则能够应用以下查问： sum(rate(http_requests_total[5m])) by (instance)这将返回每个Web服务器的HTTP申请速率总和，单位为每秒。 2. 了解sum函数sum函数是用于计算工夫序列数据总和的函数之一。sum函数的公式为： sum(metric[by-label-list])其中metric是一个指标名称，by-label-list是一个可选的标签列表，用于指定要对哪些标签进行求和。如果未指定标签，则将对所有标签进行求和。 例如，假如咱们有一个名为http_requests_total的指标，示意每个Web服务器上的HTTP申请总数。如果咱们想要计算所有Web服务器上的HTTP申请总数，则能够应用以下查问： sum(http_requests_total)如果咱们想按实例（instance）标签对HTTP申请总数进行求和，则能够应用以下查问： sum(http_requests_total) by (instance)在理论利用中，sum函数通常与其余函数联合应用，例如rate或avg，以便计算多个工夫序列的总和或平均值。例如，如果咱们想要计算所有Web服务器的HTTP申请速率总和，则能够应用以下查问： sum(rate(http_requests_total[5m])) by (instance)这将返回每个Web服务器的HTTP申请速率总和，单位为每秒。 3. 了解histogram_quantile函数histogram_quantile函数是用于计算分位数（quantile）的函数之一。分位数是指将一组数据按升序排序后，第p分位数是这组数据中最小的元素到第p×100%的元素的范畴。histogram_quantile函数的公式为： histogram_quantile(, bucket_selector(metric_name[by_label_list], ≤ bucket))其中，是分位数，metric_name是一个指标名称，bucket是一个桶的边界值，by_label_list是可选的标签列表。 该函数返回指定分位数的值，能够用于剖析指标散布的特色。 例如，假如咱们有一个名为http_request_duration_seconds的指标，示意HTTP申请的响应工夫。咱们能够应用histogram类型来收集数据，并将其分为不同的桶，每个桶示意不同范畴的响应工夫。 如果咱们想要计算95%的HTTP申请的响应工夫，则能够应用以下查问： histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))该查问将计算过来5分钟内HTTP申请响应工夫在95%分位数处的值。其中，http_request_duration_seconds_bucket是用于存储分段数据的指标名称，le是用于标识桶边界的标签。在理论利用中，能够将histogram_quantile函数与其余函数联合应用，例如sum或avg，以便计算多个工夫序列的分位数或平均分位数。 例如，如果咱们想要计算所有Web服务器的HTTP申请响应工夫的中位数，则能够应用以下查问： histogram_quantile(0.5, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, instance))这将返回每个Web服务器的HTTP申请响应工夫中位数，单位为秒。在此查问中，咱们按instance标签对HTTP申请响应工夫进行分组，以便计算每个Web服务器的中位数。 4. 了解irate函数irate函数用于计算工夫序列数据的刹时变化率。与rate函数不同，irate函数会思考数据的最近两个工夫点之间的差别，并将其视为刹时速率。irate函数的公式为： irate(metric[range-vector])其中metric是一个指标名称，range-vector是一个时间段范畴，例如[5m]示意5分钟的工夫范畴。该函数返回的是在指定工夫范畴内，最近两个数据点之间的变化率。 当应用irate函数时，Prometheus会依据最近两个数据点之间的工夫距离计算变化率，而不思考工夫范畴内的其余数据点。这使得irate函数更实用于测量刹时速率，特地是在数据采集距离较大或数据点不均匀分布的状况下。 例如，假如咱们有一个名为http_requests_total的指标，示意每秒的HTTP申请数量。如果咱们想要计算过来5分钟内的HTTP申请数量的刹时变化率，则能够应用以下查问： irate(http_requests_total[5m])这将返回过来5分钟内HTTP申请数量的刹时变化率，单位为每秒。在理论利用中，irate函数通常与其余函数联合应用，例如sum或avg，以计算多个工夫序列的刹时变化率或均匀刹时变化率。 例如，如果咱们想要计算所有Web服务器的HTTP申请数量的刹时变化率总和，则能够应用以下查问： sum(irate(http_requests_total[5m])) by (instance)这将返回每个Web服务器的HTTP申请数量的刹时变化率总和，单位为每秒。 5. 了解round函数round函数用于将工夫序列数据的值舍入到指定的精度。它能够用于对数据进行舍入，以便更好地适应可视化或聚合需要。round函数的公式为： round(metric, precision)其中metric是一个指标名称或表达式，precision是要舍入到的小数位数。该函数返回的后果是将指定的指标或表达式中的值舍入到指定精度后的后果。 例如，假如咱们有一个名为cpu_usage的指标，示意CPU使用率。如果咱们心愿将CPU使用率的值舍入到小数点后两位，则能够应用以下查问： round(cpu_usage, 0.01) 这将返回将cpu_usage指标的值舍入到小数点后两位的后果。在理论利用中，round函数通常与其余函数或表达式联合应用，以便进行更简单的计算或数据处理。 例如，如果咱们心愿计算所有Web服务器的均匀CPU使用率，并将后果舍入到小数点后两位，则能够应用以下查问： round(avg(cpu_usage) by (instance), 0.01) 这将返回将每个Web服务器的CPU使用率取均匀后的后果，并将其舍入到小数点后两位。在此查问中，咱们应用avg函数计算每个实例的均匀CPU使用率，而后应用round函数将后果舍入到指定精度。 6. 了解metric type在Prometheus指标采集中，有几种常见的指标类型，包含Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）和Summary（摘要）。这些类型用于示意不同类型的数据和度量规范，提供了在监控和剖析零碎性能时须要的不同维度和粒度。 以下是对这些指标类型的解释： ...

对于Prometheus部署计划的抉择在以往的分享中，有分享过应用Prometheus Operator来治理Prometheus。但，在此同时，又抛出了个问题：是手工将Prometheus部署到 Kubernetes 比拟好还是应用Prometheus Operator来部署比拟好？对于技术的选型，往往是没有规定死是要用哪一项技术的，而是须要联合业务的需要、运维场景、本身对某项技术的把握水平、以及其它更多的考量因素来独特决定的： 如果对 Kubernetes 中的 Prometheus 的自动化部署、治理和配置不是很相熟，或者须要部署 Prometheus 集群和实现高可用性，那么应用 Prometheus Operator 是更好的抉择。Prometheus Operator 提供了简化 Prometheus 在 Kubernetes 中部署的性能，能够主动解决很多繁琐的工作，如主动部署 Prometheus 和 Alertmanager、主动创立监控指标和规定等。这样能够显著升高部署和保护 Prometheus 的难度和工作量，并加强 Prometheus 在 Kubernetes 中的可靠性和可用性。如果有丰盛的 Kubernetes 和 Prometheus 的教训，并且须要更加个性化的定制和管制，那么手工将 Prometheus 部署到 Kubernetes 中也是一个不错的抉择。手工部署尽管绝对更简单，然而也能够充分发挥 Kubernetes 的灵活性和可定制性，例如自定义 Kubernetes Service 和 Endpoints、更加粗疏的治理数据存储和备份等。这样能够满足更加个性化和定制化的需要，同时减少对 Prometheus 零碎的深度了解和把握。所以，抉择手工部署还是 Prometheus Operator，应该基于具体场景和需要进行综合思考，以便更好地满足业务和运维的要求。分享手工将Prometheus部署到K8S（供参考）上面分享手工将Prometheus部署到 Kubernetes 的yaml，对于应用Prometheus Operator部署可参考我之前的分享或者参考官网文档即可。 提醒：本案例中应用Prometheus的数据目录所在的后端存储是rook-ceph，可将其批改为您已有的后端存储，如原生的ceph、nfs等等。 apiVersion: v1kind: Namespacemetadata:  name: monitor---apiVersion: v1kind: ConfigMapmetadata:  name: prometheus-config  namespace: monitordata:  prometheus.yml: |    global:      scrape_interval: 15s      evaluation_interval: 15s    alerting:      alertmanagers:        - static_configs:            - targets:              # - alertmanager:9093    rule_files:      # - "first_rules.yml"      # - "second_rules.yml"    scrape_configs:      - job_name: "prometheus"        static_configs:          - targets: ["localhost:9090"]---apiVersion: v1kind: PersistentVolumeClaimmetadata:  name: prometheus-pvc  namespace: monitorspec:  accessModes:    - ReadWriteOnce  resources:    requests:      storage: 100Gi  storageClassName: rook-ceph-block---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: prometheus  name: prometheus  namespace: monitorspec:  replicas: 1  selector:    matchLabels:      app: prometheus  template:    metadata:      labels:        app: prometheus    spec:      initContainers:      - name: "change-prometheus-data-dir-perm"        image: busybox        command: ["/bin/sh"]        args: ["-c", "chown -R 65534:65534 /prometheus"]        securityContext:          privileged: true        volumeMounts:          - name: prometheus-storage            mountPath: /prometheus      containers:      - image: prom/prometheus:latest        name: prometheus        ports:        - containerPort: 9090          protocol: TCP        volumeMounts:        - name: prometheus-storage          mountPath: /prometheus        - name: prometheus-config          mountPath: /etc/prometheus          readOnly: true      volumes:        - name: prometheus-config          configMap:             name: prometheus-config        - name: prometheus-storage          persistentVolumeClaim:            claimName: prometheus-pvc---apiVersion: v1kind: Servicemetadata:  labels:    app: prometheus  name: prometheus  namespace: monitorspec:  ports:  - name: http-port    nodePort: 30090    port: 9090    protocol: TCP    targetPort: 9090  selector:    app: prometheus  type: NodePort留神：在下面的yaml中，initContainers 的作用是确保 /prometheus 目录以及其子目录的权限正确，因为 Prometheus 过程通常须要以非特权用户运行。同时，因为该 initContainers 是以特权模式运行的，因而能够确保 Prometheus 容器可能以正确的形式拜访挂载的卷，而不会因为权限问题导致运行异样。本文转载于WX公众号：不背锅运维（喜爱的盆友关注咱们）：https://mp.weixin.qq.com/s/JlCgx1mkHqcF2e_ZqkafEw

简介最近我有一个工作，须要跟踪、搞定 series 基数问题，并显著缩小 Prometheus 的资源应用。为了做到这一点，我首先须要剖析零碎。在本文中，我将解释如何应用 mimirtool 来辨认平台上应用哪些指标以及哪些没有被应用。 先决条件本文中形容的所有内容都是在 Kubernetes 环境中应用 kube-prometheus-stack 实现的。如果您的 Prometheus 部署形式与我不同，您可能须要进行调整，但如果您同时领有 Prometheus 和 Grafana 的至多一个实例，那么您应该能够持续应用。 依据 Grafana 的官网： Mimirtool 是一个 CLI 工具，可用于波及 Grafana Mimir 或 Grafana Cloud Metrics 的 Prometheus 兼容工作的各种操作。要重现示例，您须要： # Archlinuxpacman -Sy kubectl mimir jq# MacOSbrew install kubectl mimirtool jq如果您的 Prometheus 和 Grafana 实例也在 Kubernetes 上运行，如果您心愿可能复制和粘贴示例，则能够在上面的变量中复制它们的 pod 名称： # kubectl get pod -n monitoring | grep -E 'prometheus|grafana'my_grafana_pod="kube-prometheus-stack-grafana-6b7fc54bd9-q2fdj"my_prometheus_pod="prometheus-kube-prometheus-stack-prometheus-0"剖析你的 Prometheus 的 metrics 应用状况咱们须要做的第一件事是确定咱们应用的指标和咱们领有的指标。我过来曾应用 grep 手动实现此操作，但 mimirtool 使它变得非常简单！ ...

本篇要分享的内容这里假如你曾经实现了kube-prometheus的部署。假如有个需要：须要将node-exporter的指标裸露到k8s集群内部。如果要搞清楚这个问题，并实现这个需要，须要对通过operator部署的资源、外部链路有肯定的理解才能够。所以，本篇要做这方面的一个分享。 对于在manifests下的清单这里假如你曾经对prometheus-operator和kube-prometheus有了肯定的理解和应用教训。在 kube-prometheus 仓库下的 manifests 中，曾经有了用于装置和部署 Prometheus Operator、Alertmanager、Node Exporter、kube-state-metrics 和 Grafana 等组件的 Kubernetes 部署清单。这些清单能够用来在 Kubernetes 集群中部署这些组件，以便能够开始监控集群中的各种指标。不仅如此，它还蕴含了其它资源清单，如 Service、ConfigMap、Role、ClusterRole 等。这些清单文件一起提供了一个残缺的 Prometheus 监控解决方案。 它为什么无奈在内部拿到指标看看部署形式nodeExporter-daemonset.yaml apiVersion: apps/v1kind: DaemonSet......在k8s中， DaemonSet 是一种用于在 K8S 集群中部署守护过程的控制器，它确保每个节点上都运行一个 Pod 的正本，这使得在整个集群中运行守护过程变得非常容易。DaemonSet 的工作原理是，在每个节点上主动创立 Pod，并且这些 Pod 将始终运行，直到 DaemonSet 被删除或更新为止。 如果一个新节点退出集群，DaemonSet 会在该节点上主动创立 Pod。反之，如果节点被删除，它将主动删除对应的 Pod。DaemonSet 罕用于运行一些零碎级别的服务，例如监控代理、日志收集代理等，这些服务须要在每个节点上运行。所以，node-exporter 以 DaemonSet 控制器部署是十分适合的一个解决方案。 查看节点上主动创立的Pod[root@k8s-a-master manifests-prometheus-operator]# kubectl get pod -n monitoring -o wide | grep node-exporternode-exporter-2wgf7                    2/2     Running   0             3m14s   192.168.11.19    k8s-a-node09   <none>           <none>node-exporter-65fb9                    2/2     Running   0             3m14s   192.168.11.20    k8s-a-node10   <none>           <none>node-exporter-6p2ll                    2/2     Running   0             3m14s   192.168.11.16    k8s-a-node06   <none>           <none>node-exporter-9jnml                    2/2     Running   0             3m14s   192.168.11.12    k8s-a-node02   <none>           <none>node-exporter-cjsr6                    2/2     Running   0             3m14s   192.168.11.17    k8s-a-node07   <none>           <none>node-exporter-d9lqf                    2/2     Running   0             3m14s   192.168.11.13    k8s-a-node03   <none>           <none>node-exporter-gcrx4                    2/2     Running   0             3m14s   192.168.11.10    k8s-a-master   <none>           <none>因为这里应用了DaemonSet控制器部署node-exporter，因而每个节点上都会运行一个该容器的实例。这意味着每个节点上都会有一个监听9100端口的node-exporter实例，而这些实例都会向Prometheus提供监控数据，使得Prometheus可能集中管理和剖析这些数据。持续往下看，监听端口的局部。 咱们来看一下端口局部...ports:- containerPort: 9100    hostPort: 9100    name: https...“name”指定了一个名为“https”的端口，“containerPort”指定了Pod中容器的端口号，即9100。而“hostPort”指定了宿主机节点上的端口号，也是9100。这意味着在任何宿主机节点上，都能够通过拜访9100端口来拜访Pod中的容器。 在页面上查看targets，node-exporter的job已主动增加在外部，走的是https协定。 内部不给浏览器间接拜访![图片]() 咱们在集群节点外部用curl试试[root@k8s-a-node06 ~]# curl https://192.168.11.16:9100/metricscurl: (60) Peer's certificate issuer has been marked as not trusted by the user.More details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.[root@k8s-a-node06 ~]# curl http://192.168.11.16:9100/metricsClient sent an HTTP request to an HTTPS server.[root@k8s-a-node06 ~]# [root@k8s-a-node06 ~]# curl http://127.0.0.1:9100/metrics# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.# TYPE go_gc_duration_seconds summarygo_gc_duration_seconds{quantile="0"} 2.2247e-05go_gc_duration_seconds{quantile="0.25"} 3.0408e-05go_gc_duration_seconds{quantile="0.5"} 3.2917e-05...process_cpu_seconds_total 2.77# HELP process_max_fds Maximum number of open file descriptors.# TYPE process_max_fds gaugeprocess_max_fds 1.048576e+06# HELP process_open_fds Number of open file descriptors.# TYPE process_open_fds gaugeprocess_open_fds 10# HELP process_resident_memory_bytes Resident memory size in bytes.# TYPE process_resident_memory_bytes gauge...发现在集群外部应用http协定拜访127.0.0.1是能够拿到指标的，并且没有提醒任何对于证书的问题。也就有可能说，只有让其走http就能够在内部拿到指标了？咱们持续往下看。nodeExporter yaml清单先理解每个yaml的用处 [root@k8s-a-master manifests-prometheus-operator]# ls -l nodeExporter-*-rw-r--r-- 1 root root   468 Apr 11 10:30 nodeExporter-clusterRoleBinding.yaml-rw-r--r-- 1 root root   485 Apr 11 10:30 nodeExporter-clusterRole.yaml-rw-r--r-- 1 root root  3640 Apr 27 21:46 nodeExporter-daemonset.yaml-rw-r--r-- 1 root root   671 Apr 11 10:30 nodeExporter-networkPolicy.yaml-rw-r--r-- 1 root root 15214 Apr 11 10:30 nodeExporter-prometheusRule.yaml-rw-r--r-- 1 root root   306 Apr 11 10:30 nodeExporter-serviceAccount.yaml-rw-r--r-- 1 root root   850 Apr 27 21:46 nodeExporter-serviceMonitor.yaml-rw-r--r-- 1 root root   492 Apr 27 21:46 nodeExporter-service.yamlnodeExporter-clusterRoleBinding.yaml：这个文件定义了一个 ClusterRoleBinding（集群角色绑定）对象，用于受权一个指定的服务帐户（在 nodeExporter-serviceAccount.yaml 文件中定义）拜访与 Node Exporter 相干的资源。nodeExporter-clusterRole.yaml：这个文件定义了一个 ClusterRole（集群角色）对象，用于授予一组权限，容许 Prometheus Server 拜访 Node Exporter 的指标数据。nodeExporter-daemonset.yaml：这个文件定义了一个 DaemonSet（守护过程集）对象，用于在 Kubernetes 集群中每个节点上运行一个 Node Exporter 的正本，以便从每个节点收集指标数据。nodeExporter-networkPolicy.yaml：这个文件定义了一个 NetworkPolicy（网络策略）对象，用于限度从 Prometheus Server 到 Node Exporter 的网络流量，以确保只有来自 Prometheus Server 的流量可能达到 Node Exporter。nodeExporter-prometheusRule.yaml：这个文件定义了一组 PrometheusRule（Prometheus 规定）对象，用于查看 Node Exporter 的指标数据并生成相应的警报。这些规定定义了要查看的指标及其阈值。nodeExporter-serviceAccount.yaml：这个文件定义了一个 ServiceAccount（服务帐户）对象，用于受权 Node Exporter 拜访 Kubernetes API。这个服务帐户将被绑定到下面提到的 ClusterRole。nodeExporter-serviceMonitor.yaml：这个文件定义了一个 ServiceMonitor（服务监控）对象，用于通知 Prometheus Server 如何收集来自 Node Exporter 的指标数据。这个对象定义了 Node Exporter 的服务名称和端口号等信息。nodeExporter-service.yaml：这个文件定义了一个 Service（服务）对象，用于将 Node Exporter 的网络服务裸露到 Kubernetes 集群中。这个服务将被 nodeExporter-serviceMonitor.yaml 文件中定义的 ServiceMonitor 监控。同样的，其它grafana、alertmanager、blackboxExporter、kubeStateMetrics等，它们的资源清单也是这样的。https链路剖析之前曾经晓得了在外部走的是https协定，并且当初曾经搞清楚了清单里的每个yaml的作用后，置信大脑里曾经产生了上面的一个逻辑图： ...

在 Gartner 公布的《2023 年十大策略技术趋势》[1]报告中,「利用可观测性」再次成为热门趋势。用户须要建设可观测体系来兼顾、整合企业数字化所产生的指标数据，并以此为根底进行反馈并制订决策，这对于进步组织决策有效性和及时性，将是最强有力的撑持。 新需要带来新反动，Prometheus 产品应运而生，引领新一轮可观测技术反动。得益于良好的产品设计，Prometheus 部署与轻度应用体验十分晦涩：敲两三个命令就能运行起来，配置几行 yaml 就能收集数据，编辑一个规定就能触发告警，再配合上 Grafana，写一句 PromQL 就能画出趋势图表。所有简略而美妙，好像SRE光明的将来正向咱们招手，这所有来的太忽然，它真的如此轻易么？ 当然不是。Prometheus 用良好的用户接口覆盖了外部简单实现。深刻其中，咱们会看到时序数据存储、大规模数据采集、工夫线高基数、数据搅动、长周期查问、历史数据归档等等。像潜藏在平静湖面下磨牙吮血的鳄鱼，静待不小心掉进坑中的 SRE 们。**残缺内容请点击下方链接查看：** https://developer.aliyun.com/article/1151103 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

筹备工作1、创立用户和配置环境参数(1)、创立用户和创立所需目录[root@centos ~]# groupadd prometheus[root@centos ~]# useradd -d /home/prometheus -g prometheus -m prometheus[root@centos ~]# chmod 755 /home/prometheus[root@centos ~]# mkdir -p /home/prometheus/software[root@centos ~]# mkdir -p /home/prometheus/yunwei[root@centos ~]# chown -R prometheus:prometheus /home/prometheus[root@centos ~]# mkdir -p /data/prometheus[root@centos ~]# chown -R prometheus:prometheus /data/prometheus(2)、下载https://github.com/prometheus/prometheus/releases/download/v2.42.0/prometheus-2.42.0.linux-amd64.tar.gz部署计划1、部署(1)、敞开防火墙[root@centos ~]# systemctl stop firewalld[root@centos ~]# systemctl disable firewalldRemoved symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.[root@centos ~]# setenforce 0[root@centos ~]# getenforce Permissive[root@centos ~]# vi /etc/sysconfig/selinux # This file controls the state of SELinux on the system.# SELINUX= can take one of these three values:# enforcing - SELinux security policy is enforced.# permissive - SELinux prints warnings instead of enforcing.# disabled - No SELinux policy is loaded.SELINUX=disabled# SELINUXTYPE= can take one of three values:# targeted - Targeted processes are protected,# minimum - Modification of targeted policy. Only selected processes are protected.# mls - Multi Level Security protection.SELINUXTYPE=targeted(2)、解压安装包并备份配置文件[prometheus@centos ~]$ tar zxf $HOME/software/prometheus-2.42.0.linux-amd64.tar.gz -C $HOME[prometheus@centos ~]$ mv prometheus-2.42.0.linux-amd64 prometheus-2.42.0[prometheus@centos ~]$ cp prometheus-2.42.0/prometheus.yml prometheus-2.42.0/prometheus.yml_init(3)、创立所需目录[prometheus@centos ~]$ mkdir -p /data/prometheus/prometheus-2.42.0/logs[prometheus@centos ~]$ mkdir -p /data/prometheus/prometheus-2.42.0/data2、调整配置文件[prometheus@centos ~]$ vi $HOME/prometheus-2.42.0/prometheus.yml# my global configglobal: scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. # scrape_timeout is set to the global default (10s).# Alertmanager configurationalerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.rule_files: # - "first_rules.yml" # - "second_rules.yml"# A scrape configuration containing exactly one endpoint to scrape:# Here it's Prometheus itself.scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: "prometheus" # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: ["192.168.19.149:9090"]3、启停服务与创立脚本(1)、查看prometheus版本信息# 查看版本信息[prometheus@centos ~]$ $HOME/prometheus-2.42.0/prometheus --versionprometheus, version 2.42.0 (branch: HEAD, revision: 225c61122d88b01d1f0eaaee0e05b6f3e0567ac0) build user: root@c67d48967507 build date: 20230201-07:53:32 go version: go1.19.5 platform: linux/amd64(2)、失常启动命令及参数抉择# 启动服务[prometheus@centos ~]$ $HOME/prometheus-2.42.0/prometheus --config.file=prometheus.yml# 指定配置文件--config.file="prometheus.yml"# 默认指定监听地址端口，可批改端口--web.listen-address="0.0.0.0:9090"# 开启API服务（为管理控制操作启用API端点。）--web.enable-admin-api# 最大连接数--web.max-connections=512# tsdb数据存储的目录，默认以后data/--storage.tsdb.path="data/"# premetheus 存储数据的工夫，默认保留15天--storage.tsdb.retention.time=365d#通过命令热加载无需重启 curl -XPOST 192.168.19.149:9090/-/reload--web.enable-lifecycle# 能够启用 TLS或身份验证 的配置文件的门路--web.config.file=""# 启动选项理解:[prometheus@centos ~]$ $HOME/prometheus-2.42.0/prometheus --help(3)、启动脚本配置[prometheus@centos ~]$ vi $HOME/yunwei/prometheus-2.42.0_start.sh#!/bin/bash#cd $HOME/prometheus-2.42.0nohup ./prometheus --config.file="prometheus.yml" --web.max-connections=512 --storage.tsdb.path="/data/prometheus/prometheus-2.42.0/data/" --storage.tsdb.retention.time=365d --web.enable-lifecycle --web.enable-admin-api >> /data/prometheus/prometheus-2.42.0/logs/prometheus-2.42.0.log 2>&1 &tail -f /data/prometheus/prometheus-2.42.0/logs/prometheus-2.42.0.log(4)、进行脚本配置[prometheus@centos ~]$ vi $HOME/yunwei/prometheus-2.42.0_stop.sh#!/bin/bash#prom_pid=`ps -ef|grep prometheus|grep storage.tsdb.retention.time|grep -v grep|awk '{print $2}'`kill -9 $prom_pid(5)、热加载重启配置[prometheus@centos ~]$ vi $HOME/yunwei/prometheus-2.42.0_reload.sh#!/bin/bash#curl -XPOST 192.168.19.149:9090/-/reload治理配置1、创立目录[prometheus@centos ~]$ mkdir $HOME/exporter[prometheus@centos ~]$ mkdir -p $HOME/yunwei/exporter/node[prometheus@centos ~]$ mkdir -p /data/prometheus/exporter/node_exporter_1.5.0/logs2、下载https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-amd64.tar.gz3、部署node_exporter[prometheus@centos ~]$ tar zxf $HOME/software/node_exporter-1.5.0.linux-amd64.tar.gz -C $HOME/exporter[prometheus@centos ~]$ mv $HOME/exporter/node_exporter-1.5.0.linux-amd64 $HOME/exporter/node_exporter4、查看node_exporter版本及参数# 查看版本[prometheus@centos node_exporter]$ $HOME/exporter/node_exporter/node_exporter --versionnode_exporter, version 1.5.0 (branch: HEAD, revision: 1b48970ffcf5630534fb00bb0687d73c66d1c959) build user: root@6e7732a7b81b build date: 20221129-18:59:09 go version: go1.19.3 platform: linux/amd64# 查看相干参数[prometheus@centos ~]$ $HOME/node_exporter --help# 申请URL门路地址--web.telemetry-path="/metrics"# 最大申请数量--web.max-requests=40# web监听端口地址--web.listen-address=:9100# 指定配置文件--web.config.file=""5、配置prometheus.yml[prometheus@centos ~]$ vi prometheus-2.42.0/prometheus.yml# my global configglobal: scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. # scrape_timeout is set to the global default (10s).# Alertmanager configurationalerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.rule_files: # - "first_rules.yml" # - "second_rules.yml"# A scrape configuration containing exactly one endpoint to scrape:# Here it's Prometheus itself.scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: "prometheus" # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: ["192.168.19.149:9090"] # 新增job_name并增加治理主机参数 - job_name: "node_exporter" static_configs: - targets: ['192.168.19.149:9100'] labels: host_ip: 192.168.19.1496、脚本配置(1)、启动脚本[prometheus@centos ~]$ vi $HOME/yunwei/exporter/node/node_exporter_1.5.0_start.sh#!/bin/bash#cd $HOME/exporter/node_exporter./node_exporter --web.listen-address=:9100 >> /data/prometheus/exporter/node_exporter_1.5.0/logs/node_exporter.log &(2)、进行脚本[prometheus@centos ~]$ vi $HOME/yunwei/exporter/node/node_exporter_1.5.0_stop.sh#!/bin/bash#node_exp_pid=`ps -ef|grep node_exporter|grep 9100|awk '{print $2}'`kill -9 $node_exp_pid

一.启动参数prometheus-adapter的pod启动参数，重点关注： metrics-relist-interval: series的查问距离，adapter在内存中保护了集群以后的series，并定期查问prometheus进行更新；prometheus-url: 查问prometheus的url；containers: - args: - --cert-dir=/var/run/serving-cert - --config=/etc/adapter/config.yaml - --logtostderr=true - --metrics-relist-interval=1m - --prometheus-url=http://prometheus-k8s.monitoring.svc.cluster.local:9090/ - --secure-port=6443 image: bitnami.io/prometheus-adapter:v0.7.0....prometheus-adapter的配置文件config.yaml，次要蕴含： rules: 用于custom.metrics.k8s.io，自定义指标；resourceRules: 用于metrics.k8s.io，kubectl top的cpu/mem指标；rules:- seriesQuery: 'http_requests_total' resources: template: <<.Resource>> name: matches: 'http_requests_total‘ as: "http_requests" metricsQuery: sum(rate(http_requests_total{<<.LabelMatchers>>}[5m])) by (<<.GroupBy>>)"resourceRules": "cpu": "containerLabel": "container" "containerQuery": "sum(irate(container_cpu_usage_seconds_total{<<.LabelMatchers>>,container!=\"POD\",container!=\"\",pod!=\"\"}[5m])) by (<<.GroupBy>>)" "nodeQuery": "sum(1 - irate(node_cpu_seconds_total{mode=\"idle\"}[5m]) * on(namespace, pod) group_left(node) node_namespace_pod:kube_pod_info:{<<.LabelMatchers>>}) by (<<.GroupBy>>)" "resources": "overrides": "namespace": "resource": "namespace" "node": "resource": "node" "pod": "resource": "pod" "memory": "containerLabel": "container" "containerQuery": "sum(container_memory_working_set_bytes{<<.LabelMatchers>>,container!=\"POD\",container!=\"\",pod!=\"\"}) by (<<.GroupBy>>)" "nodeQuery": "sum(node_memory_MemTotal_bytes{job=\"node-exporter\",<<.LabelMatchers>>} - node_memory_MemAvailable_bytes{job=\"node-exporter\",<<.LabelMatchers>>}) by (<<.GroupBy>>)" "resources": "overrides": "instance": "resource": "node" "namespace": "resource": "namespace" "pod": "resource": "pod"二.resourceRules与resourceProviderresourceRule用于metrics.k8s.io，能够通过kubectl top nodes/pods，查看资源的cpu/mem，这部分性能与metrics-server是雷同的。 ...

adapter的配置以configmap的模式，被挂载到adapter的pod中： # kubectl get cm adapter-config -n monitoringNAME DATA AGEadapter-config 1 2d一.配置文件的构造整个配置蕴含2个重要的局部： rules局部：用于custom.metrics.k8s.io，用以自定义指标的HPA伸缩；resourceRule局部：用于metrics.k8s.io，用以cpu、mem指标的HPA伸缩；rules: - seriesQuery: '{__name__=~"^container_.*",container_name!="POD",namespace!="",pod!=""}' seriesFilters: [] resources: overrides: namespace: resource: namespace pod: resource: pods name: matches: ^container_(.*)_seconds_total$ as: "" metricsQuery: sum(rate(<<.Series>>{<<.LabelMatchers>>,container_name!="POD"}[1m])) by (<<.GroupBy>>)---resourceRules: cpu: containerQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>}[1m])) by (<<.GroupBy>>) nodeQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>, id='/'}[1m])) by (<<.GroupBy>>) resources: overrides: instance: resource: nodes namespace: resource: namespace pod: resource: pods containerLabel: container_name 二. rules配置的构造rules:- seriesQuery: '{__name__=~"^container_.*",container!="POD",namespace!="",pod!="”}' seriesFilters: [] resources: overrides: namespace: {resource: "namespace"}, pod: {resource: "pod"}, name: matches: "^container_(.*)_seconds_total$" metricsQuery: "sum(rate(<<.Series>>{<<.LabelMatchers>>,container!="POD"}[2m])) by (<<.GroupBy>>)"每个rule通常由4局部形成： ...

简介Prometheus OperatorPrometheus Operator: 在 Kubernetes 上治理 Prometheus 集群。该项目标目标是简化和自动化基于 Prometheus 的 Kubernetes 集群监控堆栈的配置。 kube-prometheus最简略的办法是将 Prometheus Operator 作为 kube-prometheus 的一部分进行部署。kube-prometheus 部署了 Prometheus Operator，并且曾经安顿了一个名为 prometheus-k8s 的 prometheus，默认带有警报和规定，并且带有其余 prometheus 须要的组件，如： Grafanakube-state-metricsprometheus adapternode exporter...Prometheus Operator vs. kube-prometheus vs. community helm chartPrometheus OperatorPrometheus Operator 应用 Kubernetes 自定义资源，简化了 Prometheus、Alertmanager 和相干监控组件的部署和配置。 kube-prometheuskube-prometheus 提供了一个基于 Prometheus 和 Prometheus Operator 的残缺集群监控堆栈的示例配置。这包含部署多个 Prometheus 和 Alertmanager 实例、用于收集节点指标的指标导出器（如 node_exporters)、将 Prometheus 链接到各种指标端点的指标配置，以及用于告诉集群中潜在问题的示例警报规定。 helm chartprometheus-community/kube-prometheus-stack helm chart 提供了与 kube-prometheus 类似的个性集。这张 chart 是由 prometheus 社区保护的。 Prometheus Operator 性能CRDPrometheus Operator 的一个外围个性是 watch Kubernetes API 服务器对特定对象的更改，并确保以后 Prometheus 部署与这些对象匹配。Operator 对以下自定义资源定义 (crd) 进行操作： ...

一.概述prometheus拉取exporter中的指标进行解析时，对于labels，若label value=""，则会将该label去掉； 也就是说，对于label value=""，不会存储到tsdb，通过prom API也查问不到该label。 二.源码剖析1.原理scape当前，会通过两次删除，将value=""的Label删掉： 第一次：对拉取的text进行label解析后，在增加target的label时，删除value=""的label；第二次：将解析后的labels、t/v数据，存储到head时，删除value=""的label；// scrape/scrape.gofunc (sl *scrapeLoop) append(app storage.Appender, b []byte, contentType string, ts time.Time) (total, added, seriesAdded int, err error) { ... for { var ( et textparse.Entry sampleAdded bool ) if et, err = p.Next(); err != nil { if err == io.EOF { err = nil } break } ... met, tp, v := p.Series() ce, ok := sl.cache.get(yoloString(met)) // 查找cache if !ok { var lset labels.Labels mets := p.Metric(&lset) // 解析原始labels，保留到lset lset = sl.sampleMutator(lset) // 增加target的label，含第一次删除的逻辑 ... ref, err = app.Add(lset, t, v) // 增加到head，含第二次删除的逻辑 } } ...}2.第一次删除：解析labelsscrape当前，会进行拉取对象的文本解析；解析label时，会增加target的label，此时会删除value=""的label； ...

简略网络管理协定SNMP（Simple Network Management Protocol）用于网络设备的治理。网络设备品种多种多样、不同厂商提供的治理接口（如命令行接口）又不雷同，这使得网络管理变得愈发简单。为解决这一问题，SNMP应运而生。SNMP作为广泛应用于TCP/IP网络的规范网络管理协定，提供了对立的接口，从而实现了不同品种和厂商的网络设备之间的对立治理。通过SNMP数据的监测数据，用户能够及时关注到网络设备的状态和异样变动。 SNMP 简介随着网络技术飞速发展，网络设备数量成几何级数减少，使得网络管理员对设施的治理变得越来越艰难；同时，网络作为简单的分布式系统，其笼罩地区不断扩大，也使得对这些设施进行实时监控和故障排查变得极为艰难。网络设备品种多种多样，不同设施厂商提供的治理接口（如命令行接口）各不相同，这使得网络管理变得愈发简单。 为了应答这一场景，SNMP利用而生。作为广泛应用于TCP/IP网络的网络管理标准协议，SNMP反对网络管理系统，以监测连贯到网络上的设施是否有须要运维关注的状况。同时，SNMP采纳轮询机制，提供最根本的功能集，适宜小型、疾速、低价格的环境应用，而且SNMP以用户数据报协定（UDP）报文为承载，因此受到绝大多数设施的反对，同时保障治理信息在任意两点传送，便于管理员在网络上的任何节点检索信息，进行故障排查。 随着技术演进，SNMP协定相继衍生出三个版本：SNMPv1、SNMPv2c和SNMPv3。 SNMPv1作为SNMP协定的最后版本，提供最小限度的网络管理性能。SNMPv1基于个人名认证，安全性较差，且返回报文的错误码也较少。 SNMPv2c采纳个人名（community）认证，在SNMPv1版本的根底上引入了GetBulk和Inform操作，反对更多的规范错误码信息，反对更多的数据类型（Counter64、Counter32）。 SNMPv3在安全性方面进行加强，提供了基于USM（User Security Module）的认证加密和基于VACM（View-based Access Control Model）的访问控制。SNMPv3版本反对的操作和SNMPv2c版本反对的操作一样。 目前，v1版本应用较少，个别应用v2c版本，如果对平安认证有需要，能够应用v3版本。 SNMP零碎组成SNMP根本组件包含网络管理系统NMS（Network Management System）、代理过程（Agent）、被管对象（Managed Object）和治理信息库MIB（Management Information Base）。如图所示他们独特形成SNMP的治理模型，在SNMP的体系结构中都起着至关重要的作用。 NMSNetwork Management System，网络管理系统，个别是各种网管软件，能够向agent查问/批改各种信息，也能够承受agent的被动推送，在咱们的场景中，就是snmp exporter，仅对agent做信息查问。 Agent被治理设施上的一个代理过程，收集被治理设施的信息并汇报给NMS。 MIBManagement Information Base，是一个数据库，列出了被治理设施能够提供的各项数据，每项数据都对应一个惟一的OID。 Device设施，理论的网络设备，包含交换机、路由器、防火墙、UPS、AP、软路由等等，只有反对SNMP，都能够视为一个网络设备。 Managed Object被治理对象，一个设施蕴含至多一个被治理对象，可能是设施自身，也可能是某个硬件（一个网口），也可能是一些参数合集。 OIDObject ID，对象标识符，用于定位一个数据项。OID是一串数字，比方1.3.6.1.2.1.1示意system，数字是树形构造，左侧为根，右侧为叶，后面一截是由IANA调配的厂商标识符，前面就是各个厂商自定的，所以不同厂商设施的OID树差异很大。OID树结构参见下图。 MODULE因为SNMP能够监控的设施和厂商多种多样，所以SNMP exporter中划分了很多module，比方网络设备的if_mib，软路由的ddwrt，paloalto_fw防火墙等等，一共有十几种，最罕用的就是if_mib。 SNMP ExporterSNMP协定中用不同的OID辨别不同的状态数据，所以OID十分相似于Prometheus中的指标的概念，SNMP Exporter通过从Agent查问指定的OID数据，同时将数据映射到可读的指标上，实现SNMP数据到Prometheus指标的转换。SNMP Exporter就默认提供了十分丰盛的转换配置，大部分场景下用户无需额定配置即可将OID转换为可读的指标数据。 SNMP Metric 监控参考模型SNMP Metrics采集SNMP 能够帮忙运维人员以极为简略而无效的形式管理网络。首先，SNMP 帮忙运维人员收集网络上不同设施带宽使用量的信息。在进行故障排除的同时，更加疾速找出网络性能趋势或问题。SNMP采集到的数据都是来自设施提供，不同厂商的设施能够提供的数据不尽一致，SNMP Exporter尽可能多的提供兼容，默认配置中曾经蕴含了常见的各个厂商的OID映射，涵盖了市面上次要的厂家及其网络产品，可能满足绝大多数场景需要，详见Prometheus开源社区的相干文档。在以后版本中，咱们反对if_mibmodule的指标数据采集，更多module反对将依据需要状况陆续凋谢。 文档链接：https://github.com/prometheus/snmp_exporter/blob/main/snmp.ym这里咱们常见的以思科16口交换机为例，次要指标包含： SNMP监控大盘咱们默认提供了SNMP Status和SNMP Interface Detail两个大盘，次要针对if_mib场景，监控网络流量等信息。 SNMP Status次要展现设施的总体状态，包含设施运行时长，以后的流入/流出流量、出入流量总计、各个端口的的实时流量信息、流量变化趋势等。 SNMP Interface Detail展现各个端口工作详情。包含端口状态、端口是否连贯、端口速率、MTU配置等，以及各种流量（单播/组播/多播等）的速率/包数量变动状况。 须要留神的是，SNMP Interface Detail大盘应用前，须要在Variable 中配置须要查看的DataSource。 SNMP告警规定参考后面对各项次要指标的介绍，针对SNMP能够配置一下告警项： ...

discovery反对文件、http、consul等主动发现targets，targets会被发送到scrape模块进行拉取。 一.整体框架discovery组件通过Manager对象治理所有的逻辑，当有数据变动时，通过syncChannel将数据发送给scrape组件。 discovery组件会为每个Job_name创立一个provider对象，它蕴含Discover对象： Discover对象会主动发现target；当有targets变动时： 首先，通过updateGroup()更新Manager中的targets对象；而后，向Manager的triggerSend channel发送音讯，通知Manager要更新；最初，Manager收到triggerSend channel中的音讯，将Manager中的所有targets发送给syncChannel；scrape组件接管syncChannel中的数据，而后应用reload()进行抓取对象更新： 若有新job，则创立scrapePool并启动它；若有新target，则创立scrapeLoop并启动它；若有隐没的target，则进行其scrapeLoop； 二.discovery组件的代码入口先创立provider和dicover对象；再启动provider；// discovery/manager.gofunc (m *Manager) ApplyConfig(cfg map[string]sd_config.ServiceDiscoveryConfig) error { ....... m.targets = make(map[poolKey]map[string]*targetgroup.Group) //依据配置创立provider和discover对象 for name, scfg := range cfg { failedCount += m.registerProviders(scfg, name) } //启动provder for _, prov := range m.providers { m.startProvider(m.ctx, prov) } return nil}三.provider和discover对象的初始化provider对象的初始化在Manager.registerProviders(): 对主动发现的配置，为其每个配置创立provider和discover对象；将provider对象退出m.providers;// discovery/manager.go// registerProviders returns a number of failed SD config.func (m *Manager) registerProviders(cfg sd_config.ServiceDiscoveryConfig, setName string) int { add := func(cfg interface{}, newDiscoverer func() (Discoverer, error)) { t := reflect.TypeOf(cfg).String() //创立Discover对象 d, err := newDiscoverer() //结构provider对象 provider := provider{ name: fmt.Sprintf("%s/%d", t, len(m.providers)), d: d, config: cfg, subs: []string{setName}, } //退出m.providers m.providers = append(m.providers, &provider) } // 对file_sd_configs中的每个配置，创立provider和discover for _, c := range cfg.FileSDConfigs { add(c, func() (Discoverer, error) { return file.NewDiscovery(c, log.With(m.logger, "discovery", "file")), nil }) } ...... for _, c := range cfg.KubernetesSDConfigs { add(c, func() (Discoverer, error) { return kubernetes.New(log.With(m.logger, "discovery", "k8s"), c) }) } ………}discover对象的创立，以file_sd.Discover为例： ...

wal.watcher利用在remote_write的流程中： wal.watcher会实时读取wal最新的数据；而后将其Apppend给QueueManager；最初由QueueManager发送给remote storage。一.整体框架wal.watcher在启动时，记录wal.startTimestamp = now()； wal.watcher先读checkpoint目录下的segment，调用readSegment()读取wal中的数据；wal.watcher再读wal目录下的segment，调用readSegment()读取wal中的数据；因为wal目录中的数据是实时追加，wal.watcher会实时读取其中的数据。 readSegment()读取wal中数据的流程： 若遇到record.Series，则将其增加到QueueManager的series缓存中；若遇到reocrd.Samples，查看其工夫 > wal.startTimeStamp，若是，则将其Append到QueueMananger； 二.流程代码入口是QueueManager.Start(): // storage/remote/queue_manager.gofunc (t *QueueManager) Start() { ...... t.watcher.Start() ......}其次要工作在w.loop()中： // tsdb/wal/watcher.gofunc (w *Watcher) Start() { w.setMetrics() level.Info(w.logger).Log("msg", "Starting WAL watcher", "queue", w.name) go w.loop()}w.loop()保障除非退出，否则会始终执行w.Run()： // tsdb/wal/watcher.gofunc (w *Watcher) loop() { defer close(w.done) // We may encounter failures processing the WAL; we should wait and retry. for !isClosed(w.quit) { w.SetStartTime(time.Now()) // 设置w.startTimestamp if err := w.Run(); err != nil { level.Error(w.logger).Log("msg", "error tailing WAL", "err", err) } select { case <-w.quit: return case <-time.After(5 * time.Second): } }}w.Run()是具体的执行流程： ...

背景最近接手保护了公司的指标监控零碎，之后踩到坑就没站起来过。。 本次问题的起因是咱们配置了一些指标的删除策略没有失效： - action: drop_metrics regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum"与这两个容易引起误会的配置relabel_configs/metric_relabel_configs无关。 他们都是对抓取的数据进行重命名、过滤、新增、删除等操作，但利用场景却齐全不同。 咱们应用了 VictoriaMetrics 替换了 Prometheus，VM 齐全兼容 Prometheus ，所以本文也对 Prometheus 同样实用。了解谬误1但这里其实是有一个谬误了解的，我是通过 VM 的服务发现页面的指标响应页面查问指标的，关上之后的确能搜到须要被删除的相干指标。 但其实即使是真的删除了数据这个页面也会有数据存在，删除的数据只是不会写入 VM 的时序数据库中。 这一点是在后续查源码时才发现；前面我配置对了仍然在这里查看数据，发现还是没有删除，这个谬误了解节约了不少工夫。了解谬误2为了解决问题，通过 drop metrics 这类关键字在 VM 的官网文档中查问，最终找到一篇文章。https://www.robustperception.io/dropping-metrics-at-scrape-time-with-prometheus/ 依照这里的介绍，将删除的配置退出到 metric_relabel_configs 配置下，通过测试的确无效。 不过为啥将同样的配置： relabel_configs: - action: drop_metrics regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum"退出到 relabel_configs 未能失效呢？ 预计的确容易令人误导，在文档中也找到了相干的解释：https://www.robustperception.io/relabel_configs-vs-metric_relabel_configs/这篇文章次要是表白几个重点： relabel_configs 用于配置哪个指标须要被抓取，产生在指标抓取之前。metric_relabel_configs 产生在指标抓取之后，写入存储之前。如果其中一个没失效，就换一个（这句话很容易让人犯迷糊）但说实话过后我看到这里还是一脸懵，为了彻底理解两则的区别还是看源码来的间接。 浏览源码了解实质起因metric_relabel_configs metric_relabel_configs: - action: drop_metrics regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum"首先看下metric_relabel_configs配置失效的起因。 metric_relabel_configs 配置的整体流程如上图： 启动 VM 时加载配置到内存依据配置的抓取间隔时间(scrape_interval)抓取数据，拿到的每一条数据都须要通过 metric_relabel_configs 的利用。针对于这里的 drop_metrics 来说，就是判断是否须要删除掉所有的 Label。如果能够匹配删除，那就不会写入存储。其中的要害代码如下： 这里还有一个小细节，源码里判断的 action 是 drop，而咱们配置的是 drop_metrics，其实 drop_metrics 也是 drop 的一个封装而已。 ...

一.整体框架fanoutStorage被传入scrapeLoop；scrapeLoop在抓取结束后，调用fanoutAppender去add/addFast/commit时序数据； add/addFast是写入缓存；commit是写wal + 写入head chunk；批量数据commit进步了写入效率； 二.fanoutStorage被传入scrapeLoop1)fanoutStorage被传入scrape.Manager// cmd/prometheus/main.go// fanoutStorage被传入scrape.ManagerscrapeManager = scrape.NewManager(log.With(logger, "component", "scrape manager"), fanoutStorage)// scrape/manager.go// NewManager is the Manager constructorfunc NewManager(logger log.Logger, app storage.Appendable) *Manager { m := &Manager{ append: app, ...... } return m}2)fanoutStorage被传入scrape.Pool// scrape/manager.go func (m *Manager) reload() { var wg sync.WaitGroup for setName, groups := range m.targetSets { if _, ok := m.scrapePools[setName]; !ok { scrapeConfig, ok := m.scrapeConfigs[setName] // 创立scrape.Pool, m.append=fanoutStorage sp, err := newScrapePool(scrapeConfig, m.append, m.jitterSeed, log.With(m.logger, "scrape_pool", setName)) m.scrapePools[setName] = sp } wg.Add(1) // Run the sync in parallel as these take a while and at high load can't catch up. go func(sp *scrapePool, groups []*targetgroup.Group) { sp.Sync(groups) wg.Done() }(m.scrapePools[setName], groups) } m.mtxScrape.Unlock() wg.Wait()} 3)fanoutAppender被传入scrapeLoop//scrape/scrape.gofunc newScrapePool(cfg *config.ScrapeConfig, app storage.Appendable, jitterSeed uint64, logger log.Logger) (*scrapePool, error) { sp := &scrapePool{ appendable: app, ...... } sp.newLoop = func(opts scrapeLoopOptions) loop { ...... return newScrapeLoop( ...... // fanoutAppender被传入scrapeLoop func() storage.Appender { return appender(app.Appender(), opts.limit) }, ..... ) } return sp, nil}三.scrapeLoop应用fanoutAppender写入时序数据首先，执行scrape；而后，scrapeLoop应用fanoutAppender，将数据写入headAppender的缓存；最初，scrapeLoop应用fanoutAppender.Commit()将缓存的数据提交，包含； ...

为什么要compact? 待删除的数据未被真正删除，仅记录在tombstone文件中；相邻block的index文件个别状况是雷同，compact能够缩小disk usage；当查问的后果波及N个block时，blocks数据的合并会消耗大量资源；compact不会无止境的运行，prometheus中限度单个block最长的时间跨度=31d(744hour)，或者1/10的retentionTime，两者取最小值。 { // Max block size settings. if cfg.tsdb.MaxBlockDuration == 0 { maxBlockDuration, err := model.ParseDuration("31d") // When the time retention is set and not too big use to define the max block duration. if cfg.tsdb.RetentionDuration != 0 && cfg.tsdb.RetentionDuration/10 < maxBlockDuration { maxBlockDuration = cfg.tsdb.RetentionDuration / 10 } cfg.tsdb.MaxBlockDuration = maxBlockDuration }}compact的过程中，波及到基于retention的数据删除，能够基于sizeRetention 或 timeRetention。 一.整体框架prometheus中启动1个goroutine执行db.run()。在db.run()中执行了1min的loop循环： 查看Head block是否须要compact，若是，则先将head block compact 成 disk block；而后compact disk block： 首先，生成compact打算，即找出能够compact的blocks；而后，将找进去的blocks执行compact过程；最初，删除掉过期的blocks； 二.compact的整体逻辑代码代码入口： ...

应用prometheus client_go为应用程序增加监控指标时，通常为http注册一个client_go默认的handler，这样就能够通过/metrics接口，拉取应用程序的metrics指标了： http.Handle("/metrics", promhttp.Handler())然而，该默认的handler会主动引入go的指标和proc的指标： go的指标： go_gc_duration_secondsgo_goroutinesgo_info....proc的指标 process_start_time_secondsprocess_cpu_seconds_total....默认handler为啥会引入go指标和proc指标，如果不须要要，能够去掉它们吗？ 一. 起因从源码中找起因，http handler： http.Handle("/metrics", promhttp.Handler())client_go中该handler的实现： // prometheus/client_golang/prometheus/promhttp/http.gofunc Handler() http.Handler { return InstrumentMetricHandler( prometheus.DefaultRegisterer, HandlerFor(prometheus.DefaultGatherer, HandlerOpts{}), )}其中DefaultRegister、DefaultGather指向同一个Registry对象，即defaultRegistry： // prometheus/client_golang/prometheus/registry.govar ( defaultRegistry = NewRegistry() DefaultRegisterer Registerer = defaultRegistry DefaultGatherer Gatherer = defaultRegistry)func init() { MustRegister(NewProcessCollector(ProcessCollectorOpts{})) // 采集Proc指标 MustRegister(NewGoCollector()) // 采集Go指标}func MustRegister(cs ...Collector) { DefaultRegisterer.MustRegister(cs...)}该Registry对象在init()中，被注入了： NewProcessCollector:采集过程的指标信息；NewGoCollector: 采集go runtime的指标信息；二. 去掉Proc和Go指标在实现本人的exporter或为应用程序增加指标时，若不须要Proc/Go指标，能够： 不应用 defaultRegister，本人 NewRegister，自定义应用哪些collector，即可去掉 Proc/Go 指标；import ( "net/http" "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promhttp")func main() { // 创立一个自定义的注册表 registry := prometheus.NewRegistry() // 可选: 增加 process 和 Go 运行时指标到咱们自定义的注册表中 registry.MustRegister(prometheus.NewProcessCollector(prometheus.ProcessCollectorOpts{})) registry.MustRegister(prometheus.NewGoCollector()) // 创立一个简略的 gauge 指标。 temp := prometheus.NewGauge(prometheus.GaugeOpts{ Name: "home_temperature_celsius", Help: "The current temperature in degrees Celsius.", }) // 应用咱们自定义的注册表注册 gauge registry.MustRegister(temp) // 设置 gague 的值为 39 temp.Set(39) // 裸露自定义指标 http.Handle("/metrics", promhttp.HandlerFor(registry, promhttp.HandlerOpts{Registry: registry})) http.ListenAndServe(":8080", nil)}其中： ...

prometheus-operator提供了一个Probe CRD对象，能够用来进行黑盒监控，具体的探测性能由Blackbox-exporter实现。 blackbox-exporter是prometheus社区提供的黑盒监控解决方案，反对用户通过HTTP、HTTPS、TCP、ICMP等形式对target进行网络探测。 一. 整体架构具体应用时： 首先，用户创立一个Probe CRD对象，对象中指定探测形式、探测指标等参数；而后，prometheus-operator watch到Probe对象创立，而后生成对应的prometheus拉取配置，reload到prometheus中；最初，prometheus应用url=/probe?target={探测指标}&module={探测形式}，拉取blackbox-exporter，此时blackbox-exporter会对指标进行探测，并以metrics格局返回探测后果； 二. 部署prometheus-operator应用kube-prometheus部署prometheus-operator。 # git clone -b release-0.8 git@github.com:prometheus-operator/kube-prometheus.git# cd kube-prometheus首先，部署CRD： # kubectl apply -f manifests/setup# kubectl get crd |grep coreosalertmanagerconfigs.monitoring.coreos.com 2022-05-19T06:44:00Zalertmanagers.monitoring.coreos.com 2022-05-19T06:44:01Zpodmonitors.monitoring.coreos.com 2022-05-19T06:44:01Zprobes.monitoring.coreos.com 2022-05-19T06:44:01Zprometheuses.monitoring.coreos.com 2022-05-19T06:45:04Zprometheusrules.monitoring.coreos.com 2022-05-19T06:44:01Zservicemonitors.monitoring.coreos.com 2022-05-19T06:44:01Zthanosrulers.monitoring.coreos.com 2022-05-19T06:44:02Z能够看到，部署了probes.monitoring.coreos.com这个CRD. 而后，部署prometheus-operator: # kubectl apply -f manifests/# kubectl get pods -n monitoringNAME READY STATUS RESTARTS AGEalertmanager-main-0 2/2 Running 0 46malertmanager-main-1 2/2 Running 0 46malertmanager-main-2 2/2 Running 0 46mblackbox-exporter-5cb5d7479d-mznws 3/3 Running 0 49mgrafana-d595885ff-cf49m 1/1 Running 0 49mkube-state-metrics-685d769786-tkv7l 3/3 Running 0 22mnode-exporter-4d6mq 2/2 Running 0 49mnode-exporter-8cr4v 2/2 Running 0 49mnode-exporter-krr2h 2/2 Running 0 49mprometheus-adapter-6fd94587c9-6tsgb 0/1 Running 0 3sprometheus-adapter-6fd94587c9-8zm2l 1/1 Running 4 (13m ago) 13mprometheus-k8s-0 2/2 Running 0 46mprometheus-k8s-1 2/2 Running 0 46mprometheus-operator-7684989c7-qt2sp 2/2 Running 0 49m部署实现后，给service: prometheus-k8s配置NodePort，以便拜访Prometheus UI。 ...

Sginoz是一个开源的APM(Application Performance Management)，它是利用可观测性的一个实际，应用OpenTelemetry协定，将traces/metrics/log交融在一起。 SigNoz is an open-source APM. It helps developers monitor their applications & troubleshoot problems, an open-source alternative to DataDog, NewRelic, etc.本文重点关注traces和metrics方面的实现。 一. 整体架构app应用opentelmetry-sdk编写代码(反对java/golang/python等)；app配置将metrics和tracing发送至otel-collector；otel-collector定制实现了: clickhouse-metrics-exporter: 将metrics发送至clickhouse；clickhouse-trace-exporter：将trace发送至clickhouse:query-server负责从clickhouse中查问metrics和trace信息，并提供前端API； 二. otel-collector1. app将metrics和trace发送至otel-collectorapp中引入opentelemetry: go.opentelemetry.io/otel若应用gin作为http框架： import "go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin"r := gin.Default()r.Use(otelgin.Middleware(serviceName))app在运行时，指定ServiceName和collector地址： # SERVICE_NAME=goApp INSECURE_MODE=true OTEL_EXPORTER_OTLP_ENDPOINT=192.168.0.1:4317 go run main.go2. otel-collector的配置otel-collector的配置，分为receivers、processors、exporters，而后由service通过pipeline组织成残缺的性能。 receivers: opencensus: endpoint: 0.0.0.0:55678 otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 jaeger: protocols: grpc: endpoint: 0.0.0.0:14250 thrift_http: endpoint: 0.0.0.0:14268processors: batch: send_batch_size: 10000 send_batch_max_size: 11000 timeout: 10sexporters: clickhousetraces: datasource: tcp://clickhouse:9000/?database=signoz_traces clickhousemetricswrite: endpoint: tcp://clickhouse:9000/?database=signoz_metrics resource_to_telemetry_conversion: enabled: trueservice: telemetry: metrics: address: 0.0.0.0:8888 extensions: - health_check - zpages - pprof pipelines: traces: receivers: [jaeger, otlp] processors: [signozspanmetrics/prometheus, batch] exporters: [clickhousetraces] metrics: receivers: [otlp] processors: [batch] exporters: [clickhousemetricswrite]3. otel-collector实现clickhouse的exporterotel-collector将metrics和traces保留至clickhouse，为此，signoz在otel-collector中，实现了： ...

一. exemplar是什么exemplar译为“样本”、“范例”。 exemplar最早被用在Google的StackDriver中，前面成为了 OpenMetrics 规范的一部分，即: 能够为metrics额定减少属性。 典型利用是为metrics增加trace信息，这样metrics和tracing就能够关联起来。 OpenMetrics introduces the ability for scrape targets to add exemplars to certain metrics. Exemplars are references to data outside of the MetricSet. A common use case are IDs of program traces.指标对象通过 /metrics 接口裸露metrics 和 exemplar信息，prometheus在 pull 时，会一起拉取并保留。 prometehus反对对exemplar的采集和存储，启动时须要额定减少参数： --enable-feature=exemplar-storageprometheus中exemplar对象的定义： 跟一般的metrics相似，由t/v、labels组成；// Exemplar is easier to use, user-facing representation of *dto.Exemplar.type Exemplar struct { Value float64 Labels Labels // Optional. // Default value (time.Time{}) indicates its empty, which should be // understood as time.Now() time at the moment of creation of metric. Timestamp time.Time}二. client侧暴漏metrics和exemplar对于metrics，个别应用prometheus/client_go减少本人的指标； ...

一.honor_labels的应用- job_name: monitoring/kubelet/0 honor_labels: true scrape_interval: 30s scrape_timeout: 5s metrics_path: /metrics scheme: httpshonor_labels用于解决 <scrape的指标label> 与 <target的label> 的抵触，比方job、instance等： honor_labels=true时，当labelKey抵触时，间接应用scrape的指标label，不顾及target的label； 通常用于联邦集群或pushgateway的场景，因为该状况下，所有原始的labels须要保留；honor_labels=false时，当labelKey抵触时，将scrape的label批改为：exported_labelKey—>lableValue；默认honor_labels=false；honor_labels controls how Prometheus handles conflicts between labels that arealready present in scraped data and labels that Prometheus would attachserver-side ("job" and "instance" labels, manually configured targetlabels, and labels generated by service discovery implementations). If honor_labels is set to "true", label conflicts are resolved by keeping labelvalues from the scraped data and ignoring the conflicting server-side labels. ...

prometheus配置了remote-read之后，能够读近程的tsdb存储； remote_read: - url: "http://storage01:9090/api/v1/read" read_recent: true - url: "http://storage02:9090/api/v1/read" read_recent: trueprometheus在执行查问时，本地tsdb和近程tsdb是如何取舍的呢？ 论断： 首先，查看remote-read的readRecent配置，默认=false；若remote-read.readRecent=true，则本地tsdb + 近程tsdb同时查问，而后将后果merge返回client；若remote-read.readRecent=false，则： 若Prometheus已有block生成，则对于4hour之后的查问，仅查问本地tsdb，不查问近程tsdb；否则，对于其它状况，须要同时查问本地tsdb和近程tsdb，最初将后果merge返回client；也就是说，prometheus运行一段时间后，为减小API查问提早，做了肯定的优化，对于本地能够笼罩的数据，尽量从本地tsdb中的查问。 一.remote read配置加载为每个remote-read配置，创立1个SampleAndChunkQueryableClient，蕴含1个Http client: // storage/remote/storage.gofunc (s *Storage) ApplyConfig(conf *config.Config) error { ... readHashes := make(map[string]struct{}) queryables := make([]storage.SampleAndChunkQueryable, 0, len(conf.RemoteReadConfigs)) for _, rrConf := range conf.RemoteReadConfigs { hash, err := toHash(rrConf) ... readHashes[hash] = struct{}{} ... name := hash[:6] // httpclient c, err := newReadClient(name, &ClientConfig{ URL: rrConf.URL, Timeout: rrConf.RemoteTimeout, HTTPClientConfig: rrConf.HTTPClientConfig, }) ... queryables = append(queryables, NewSampleAndChunkQueryableClient( c, conf.GlobalConfig.ExternalLabels, labelsToEqualityMatchers(rrConf.RequiredMatchers), rrConf.ReadRecent, // readRecent参数 s.localStartTimeCallback, )) } s.queryables = queryables return nil}二.preferLocalStorage的逻辑remote查问是通过sampleAndChunkQueryableClient.Querier()返回的对象进行的； ...

一.Prometheus agent模式Prometheus agent是v2.32.0开始提供的一项性能： 应用起来很简略，间接在启动参数中减少--enable-feature=agent即可： usage: prometheus [<flags>]The Prometheus monitoring serverFlags: -h, --help Show context-sensitive help (also try --help-long and --help-man). (... other flags) --storage.tsdb.path="data/" Base path for metrics storage. Use with server mode only. --storage.agent.path="data-agent/" Base path for metrics storage. Use with agent mode only. (... other flags) --enable-feature= ... Comma separated feature names to enable. Valid options: agent, exemplar-storage, expand-external-labels, memory-snapshot-on-shutdown, promql-at-modifier, promql-negative-offset, remote-write-receiver, extra-scrape-metrics, new-service-discovery-manager. See https://prometheus.io/docs/prometheus/latest/feature_flags/ for more details.若Prometheus过程启用agent模式，原Prometheus的残缺性能，被精简为只有： ...

一.Pushgateway是什么pushgatway是prometheus社区推出的一个推送指标的组件，次要利用在： 短生命周期(short-lived)或者批工作(batch jobs)的资源/作业的指标；prometheus无奈拉取到(网络起因)的target的指标； 作业工作能够将指标通过HTTP API推送给pushgateway，而后由prometheus拉取pushgateway的指标。 二.Pushgateway如何应用1.装置启动pushgateway# wget https://github.com/prometheus/pushgateway/releases/download/v1.2.0/pushgateway-1.2.0.linux-amd64.tar.gz# ./pushgateway --web.listen-address=":9099"2.配置pushgateway被prometheus拉取scrape_configs： - job_name: 'pushgateway' static_configs: - targets: ['127.0.0.1:9099']3.向pushgateway发送数据这里通过shell，调用pushgateway的HTTP接口，发送数据： #!/bin/bashinstance_name=`hostname -f | cut -d'.' -f1`if [ $instance_name == "localhost" ];then echo "Must FQDN hostname" exit 1fi# For waitting connectionslabel="count_netstat_wait_connections"count_netstat_wait_connections=`netstat -an | grep -i wait | wc -l`cat <<EOF | curl --data-binary @- http://127.0.0.1:9099/metrics/job/pushgateway/instance/$instance_name# TYPE $label gauge# HELP $label current connection in wait state$label $count_netstat_wait_connectionsEOF查问本机中处于wait状态的网络连接数，而后发送给pushgateway: # ./net_exporter_shell.sh4.prometheus UI验证数据正确接管&拉取首先，看一下pushgateway的/metrics是否有咱们定义的指标： # curl http://127.0.0.1:9099/metrics# HELP count_netstat_wait_connections current connection in wait state# TYPE count_netstat_wait_connections gaugecount_netstat_wait_connections{instance="dev",job="pushgateway"} 0...而后，再看prometheus UI上是否能够查问到该指标： ...

一、环境介绍相干软件版本：kubernetets：v1.22.2kube-prometheus:release 0.9 二、开始部署在部署之前留神先去官网查看kube-prometheus与k8s集群的兼容性。kube-prometheus官网：kube-prometheus 在 master 节点下载相干软件包。 root@master01:~/monitor# git clone https://github.com/prometheus-operator/kube-prometheus.gitCloning into 'kube-prometheus'...remote: Enumerating objects: 17447, done.remote: Counting objects: 100% (353/353), done.remote: Compressing objects: 100% (129/129), done.remote: Total 17447 (delta 262), reused 279 (delta 211), pack-reused 17094Receiving objects: 100% (17447/17447), 9.12 MiB | 5.59 MiB/s, done.Resolving deltas: 100% (11455/11455), done.root@master01:~/monitor# lskube-prometheuskube-prometheus部署：留神manifests/setup/文件夹的资源在部署的时候必须用create不能用apply，否则会提醒“The CustomResourceDefinition "prometheuses.monitoring.coreos.com" is invalid: metadata.annotations: Too long: must have at most 262144 bytes”，manifests文件夹中的内容能够用apply创立。 root@master01:~/monitor# lskube-prometheusroot@master01:~/monitor/kube-prometheus# kubectl create -f manifests/setup/customresourcedefinition.apiextensions.k8s.io/alertmanagerconfigs.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/alertmanagers.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/podmonitors.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/probes.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/prometheuses.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/prometheusrules.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/servicemonitors.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/thanosrulers.monitoring.coreos.com creatednamespace/monitoring createdroot@master01:~/monitor/kube-prometheus# kubectl apply -f manifests/alertmanager.monitoring.coreos.com/main creatednetworkpolicy.networking.k8s.io/alertmanager-main createdpoddisruptionbudget.policy/alertmanager-main createdprometheusrule.monitoring.coreos.com/alertmanager-main-rules createdsecret/alertmanager-main createdservice/alertmanager-main createdserviceaccount/alertmanager-main createdservicemonitor.monitoring.coreos.com/alertmanager-main createdclusterrole.rbac.authorization.k8s.io/blackbox-exporter createdclusterrolebinding.rbac.authorization.k8s.io/blackbox-exporter createdconfigmap/blackbox-exporter-configuration createddeployment.apps/blackbox-exporter creatednetworkpolicy.networking.k8s.io/blackbox-exporter createdservice/blackbox-exporter createdserviceaccount/blackbox-exporter createdservicemonitor.monitoring.coreos.com/blackbox-exporter createdsecret/grafana-config createdsecret/grafana-datasources createdconfigmap/grafana-dashboard-alertmanager-overview createdconfigmap/grafana-dashboard-apiserver createdconfigmap/grafana-dashboard-cluster-total createdconfigmap/grafana-dashboard-controller-manager createdconfigmap/grafana-dashboard-grafana-overview createdconfigmap/grafana-dashboard-k8s-resources-cluster createdconfigmap/grafana-dashboard-k8s-resources-namespace createdconfigmap/grafana-dashboard-k8s-resources-node createdconfigmap/grafana-dashboard-k8s-resources-pod createdconfigmap/grafana-dashboard-k8s-resources-workload createdconfigmap/grafana-dashboard-k8s-resources-workloads-namespace createdconfigmap/grafana-dashboard-kubelet createdconfigmap/grafana-dashboard-namespace-by-pod createdconfigmap/grafana-dashboard-namespace-by-workload createdconfigmap/grafana-dashboard-node-cluster-rsrc-use createdconfigmap/grafana-dashboard-node-rsrc-use createdconfigmap/grafana-dashboard-nodes-darwin createdconfigmap/grafana-dashboard-nodes createdconfigmap/grafana-dashboard-persistentvolumesusage createdconfigmap/grafana-dashboard-pod-total createdconfigmap/grafana-dashboard-prometheus-remote-write createdconfigmap/grafana-dashboard-prometheus createdconfigmap/grafana-dashboard-proxy createdconfigmap/grafana-dashboard-scheduler createdconfigmap/grafana-dashboard-workload-total createdconfigmap/grafana-dashboards createddeployment.apps/grafana creatednetworkpolicy.networking.k8s.io/grafana createdprometheusrule.monitoring.coreos.com/grafana-rules createdservice/grafana createdserviceaccount/grafana createdservicemonitor.monitoring.coreos.com/grafana createdprometheusrule.monitoring.coreos.com/kube-prometheus-rules createdclusterrole.rbac.authorization.k8s.io/kube-state-metrics createdclusterrolebinding.rbac.authorization.k8s.io/kube-state-metrics createddeployment.apps/kube-state-metrics creatednetworkpolicy.networking.k8s.io/kube-state-metrics createdprometheusrule.monitoring.coreos.com/kube-state-metrics-rules createdservice/kube-state-metrics createdserviceaccount/kube-state-metrics createdservicemonitor.monitoring.coreos.com/kube-state-metrics createdprometheusrule.monitoring.coreos.com/kubernetes-monitoring-rules createdservicemonitor.monitoring.coreos.com/kube-apiserver createdservicemonitor.monitoring.coreos.com/coredns createdservicemonitor.monitoring.coreos.com/kube-controller-manager createdservicemonitor.monitoring.coreos.com/kube-scheduler createdservicemonitor.monitoring.coreos.com/kubelet createdclusterrole.rbac.authorization.k8s.io/node-exporter createdclusterrolebinding.rbac.authorization.k8s.io/node-exporter createddaemonset.apps/node-exporter creatednetworkpolicy.networking.k8s.io/node-exporter createdprometheusrule.monitoring.coreos.com/node-exporter-rules createdservice/node-exporter createdserviceaccount/node-exporter createdservicemonitor.monitoring.coreos.com/node-exporter createdclusterrole.rbac.authorization.k8s.io/prometheus-k8s createdclusterrolebinding.rbac.authorization.k8s.io/prometheus-k8s creatednetworkpolicy.networking.k8s.io/prometheus-k8s createdpoddisruptionbudget.policy/prometheus-k8s createdprometheus.monitoring.coreos.com/k8s createdprometheusrule.monitoring.coreos.com/prometheus-k8s-prometheus-rules createdrolebinding.rbac.authorization.k8s.io/prometheus-k8s-config createdrolebinding.rbac.authorization.k8s.io/prometheus-k8s createdrolebinding.rbac.authorization.k8s.io/prometheus-k8s createdrolebinding.rbac.authorization.k8s.io/prometheus-k8s createdrole.rbac.authorization.k8s.io/prometheus-k8s-config createdrole.rbac.authorization.k8s.io/prometheus-k8s createdrole.rbac.authorization.k8s.io/prometheus-k8s createdrole.rbac.authorization.k8s.io/prometheus-k8s createdservice/prometheus-k8s createdserviceaccount/prometheus-k8s createdservicemonitor.monitoring.coreos.com/prometheus-k8s createdapiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io createdclusterrole.rbac.authorization.k8s.io/prometheus-adapter createdclusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader createdclusterrolebinding.rbac.authorization.k8s.io/prometheus-adapter createdclusterrolebinding.rbac.authorization.k8s.io/resource-metrics:system:auth-delegator createdclusterrole.rbac.authorization.k8s.io/resource-metrics-server-resources createdconfigmap/adapter-config createddeployment.apps/prometheus-adapter creatednetworkpolicy.networking.k8s.io/prometheus-adapter createdpoddisruptionbudget.policy/prometheus-adapter createdrolebinding.rbac.authorization.k8s.io/resource-metrics-auth-reader createdservice/prometheus-adapter createdserviceaccount/prometheus-adapter createdservicemonitor.monitoring.coreos.com/prometheus-adapter createdclusterrole.rbac.authorization.k8s.io/prometheus-operator createdclusterrolebinding.rbac.authorization.k8s.io/prometheus-operator createddeployment.apps/prometheus-operator creatednetworkpolicy.networking.k8s.io/prometheus-operator createdprometheusrule.monitoring.coreos.com/prometheus-operator-rules createdservice/prometheus-operator createdserviceaccount/prometheus-operator createdservicemonitor.monitoring.coreos.com/prometheus-operator created部署后果验证，能够看到新创建的monitoring名称空间中的POD全副失常启动，相干资源失常被创立。 ...

前言无论是对外提供 IaaS PaaS SaaS 的云公司，还是提供信息技术服务的乙方公司，亦或是金融 制作等各行各业的数据中心、运维部门，咱们的一个十分重要的合同承诺或考核评估指标就是：SLA（即：Service-Level Agreement 服务等级协定）。 而真正落地实现 SLA 的精确测量，最广为人知的就是 Google 的 SRE 实践。 Google SRE SLO & SLA在 Google，会明确辨别 SLO 和服务等级协定 （SLA）。SLA 通常波及向服务用户承诺，即服务可用性 SLO 应在特定时间段内达到特定级别。如果不这样做，就会导致某种惩办。这可能是客户为该期间领取的服务订阅费的局部退款，或者收费增加的额定订阅工夫。SLO 不达标会挫伤到服务团队，因而他们将致力留在 SLO 内。如果您要向客户收取费用，则可能须要 SLA。 SLA 中的可用性 SLO 通常比外部可用性 SLO 更宽松。这能够用可用性数字示意：例如，一个月内可用性 SLO 为 99.9%，外部可用性 SLO 为 99.95%。或者，SLA 可能仅指定形成外部 SLO 的指标的子集。 如果 SLA 中的 SLO 与外部 SLO 不同（简直总是如此），则监控必须显式测量 SLO 达标状况。您心愿可能查看零碎在 SLA 日程期间的可用性，并疾速查看它是否仿佛有脱离 SLO 的危险。 您还须要对合规性进行精确测量，通常来自 Metrics、Tracing、Logging 剖析。因为咱们对付费客户有一组额定的任务（如 SLA 中所述），因而咱们须要将从他们那里收到的查问与其余查问离开进行度量。这是建设 SLA 的另一个益处 — 这是确定流量优先级的明确办法。 定义 SLA 的可用性 SLO 时，请留神将哪些查问视为非法查问。例如，如果客户因为公布了其挪动客户端的谬误版本而超出配额，则能够思考从 SLA 中排除所有"超出配额"的响应代码。 ...

简介之前笔者有间断 2 篇文章： Prometheus 性能调优 - 什么是高基数问题以及如何解决？如何精简 Prometheus 的指标和存储占用陆续介绍了一些 Prometheus 的性能调优技巧，包含高基数问题的解决以及精简 Prometheus 的指标和存储占用。 明天再介绍一个新的调优思路：程度分片。 程度分片如果你正在面临的不是因为 label 导致的高基数问题，而是因为监控规模的急剧扩张导致须要被监控的 instance 十分宏大时，能够通过 Prometheus 的hashmod relabel action 来优化性能。通过这种方法，面对成千上万的 instance 时，一台 Prometheus 只须要监控其中的所有各种各样实例的一部分 instance。 Notes： Prometheus 也有垂直分片，垂直分片要简略很多，说白了就是配置不同的 job 监控不同的组件即可。程度分片绝对还有些技术含量。 程度分片配置具体配置如下，应用一台 Prometheus 抓取 targets 的一部分： global: external_labels: env: prod scraper: 2scrape_configs: - job_name: my_job ... relabel_configs: - source_labels: [__address__] modulus: 4 target_label: __tmp_hash action: hashmod - source_labels: [__tmp_hash] regex: 2 action: keep在 modulus 里，配置了 4 为基数。每个 Prometheus 只抓取 1/4，比方下面的配置就只抓取 hashmod 后 __temp_hash 为 2 的 targets。 ...

指标类型1： Counter（计数器） 一种只增不减的数据指标。例如：申请数、已实现的工作数、谬误产生的次数 #PromQL中反对的一些示例//通过rate()函数获取HTTP申请量的增长率rate(http_requests_total[5m])//查问以后零碎中，访问量前10的HTTP地址topk(10, http_requests_total)客户端参考 2：Guage（仪表盘） 样本数据能够任意变动的指标，即可增可减 客户端参考 3：Histogram（直方图） 客户端参考 4：Summary（摘要） 客户端参考 参考https://www.infoq.cn/article/...

极狐GitLab Runner 从 1.8.0 引入了对 Prometheus metrics 的原生反对。Runner 目前对外输入的信息有： Runner 的业务逻辑指标（诸如以后运行 Job 的数量）Go 相干的过程指标（诸如 gc、goroutines、memstats 等）通用的过程指标（比方 memory usage、 CPU usage、file descriptor usage 等）构建的版本信息上面应用 Prometheus + Grafana来实现 Runner 指标的监控。 前提条件处于运行状态的 Runner一个 Prometheus 实例一个 Grafana 实例Runner 的装置Runner 的装置有多种办法，papckage、docker、helm 等，具体的装置应用能够查看 Runner 的花式玩法。 本文用 docker 的形式拉起了一个 Runner 实例，为了获取 metrics，同步开启了 9252 端口： $ docker run -d --name gitlab-runner-docker \ --restart always -v $PWD:/etc/gitlab-runner \ -p 9252:9252 -v /var/run/docker.sock:/var/run/docker.sock \ gitlab/gitlab-runner:latest为了测试用，应用 gitlab-runenr register 注册了 6 次： $ gitlab-runner listRuntime platform arch=amd64 os=linux pid=353 revision=43b2dc3d version=15.4.0Listing configured runners ConfigFile=/etc/gitlab-runner/config.tomlrunner-1 Executor=docker Token=rGSszVLSiYxQzcpVm8ud URL=https://jihulab.com/runner-2 Executor=docker Token=7r8bfWJRVaeMsCCQ3R2m URL=https://jihulab.com/runner-3 Executor=docker Token=3xqRCdMdo9VYuwb92Gfr URL=https://jihulab.com/runner-4 Executor=docker Token=jAeBYLSNCCkaspAbmTsA URL=https://jihulab.com/runner-5 Executor=docker Token=DAGXrJoNHYKNuwwNUVD5 URL=https://jihulab.com/runner-6 Executor=docker Token=V_sAUz2C-fVba5CfQxjA URL=https://jihulab.com/在极狐GitLab 的我的项目 → 设置 → CI/CD → Runner 外面能够看到 6 个 Runner 处于 active 状态： ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。大家好，我是张晋涛。 因为上周在假期，所以没有推送新的文章。大家的假期过的如何呢？ 我有一个托管在 Pipedream 上的 workflow ，该 workflow 订阅了我博客的 RSS， 当有新文章公布后，会调用 Bitly 生成短网址，而后主动发推。失常状况下，它会放弃 RSS 的解决状态，仅解决增量数据。 然而在两周前某天早上醒来，我收到一堆的告警和音讯揭示，发现该 workflow 工作异样了，它将我的很多历史博客都推送了一遍。（事实上，幸好触发了 Bitly 的申请限度，否则它的确会把我的所有博客都推一遍） 通过与该司的 Co-founder 沟通，问题呈现的起因是该平台呈现了一些故障，导致 RSS 解决的状态数据失落了。所以会将 RSS 的工作从新进行解决。 问题呈现的起因和影响面这和我关系不大，晓得在个论断曾经足够了。简略说下如何防止后续再呈现这种状况。 该平台提供了一个 Data Stores 的服务，用于进行一些长久化数据的存储。所以后续的解决方法就是抉择了 guid 作为惟一值，存储在该服务中。该平台首选反对的语言是 NodeJS，所以也比较简单，如下配置即可。 export default defineComponent({ props: { db: { type: "data_store", label: "RSS item keys", } }, async run({ steps, $ }) { const { guid } = steps.trigger.event // Exit early if no GUID found if (!guid) return $.flow.exit("No GUID found") // Exit early if key is found const key = await this.db.get(guid) if (key) return $.flow.exit("GUID already found") // Else set and continue await this.db.set(guid, true) },})另外为了避免再反复推送，所以在复原 workflow 运行前，我创立了一个新的 workflow，应用了 RSS 和上述的解决步骤，对数据做了下预热，确保曾经都存储到了 Data Stores，并且能按预期工作。 ...

0、索引go-zero docker-compose 搭建课件服务（一）：编写服务api和proto go-zero docker-compose 搭建课件服务（二）：编写courseware rpc服务 go-zero docker-compose 搭建课件服务（三）：编写courseware api服务 go-zero docker-compose 搭建课件服务（四）：生成Dockerfile并在docker-compose中启动 go-zero docker-compose 搭建课件服务（五）：欠缺user服务 go-zero docker-compose 搭建课件服务（六）：欠缺jwt鉴权和返回构造 go-zero docker-compose 搭建课件服务（七）：prometheus+grafana服务监控 0.1源码地址https://github.com/liuyuede123/go-zero-courseware 1、什么是prometheusPrometheus是一个开源的系统监控和警报工具包。自2012年启动以来，许多公司和组织都采纳了Prometheus，该我的项目领有十分沉闷的开发人员和用户社区。它当初是一个独立的开源我的项目，独立于任何公司进行保护。Prometheus于2016年退出云原生计算基金会，成为继Kubernetes之后的第二个托管我的项目。 个性： 一个多维数据模型，蕴含由指标名称和键/值对（Tag）标识的工夫序列数据PromQL是一种灵便的查问语音，用于查问并利用这些维度数据不依赖分布式存储，单个服务器节点是自治的工夫序列收集是通过HTTP上的pull模型进行的（反对Pull）推送工夫序列是通过一个两头网关来反对的（也反对Push）指标是通过服务发现或动态配置发现的多种模式的图形和仪表盘反对2、什么是grafanagrafana是用于可视化大型测量数据的开源程序，他提供了弱小和优雅的形式去创立、共享、浏览数据。dashboard中显示了你不同metric数据源中的数据。 Grafana是一个开源的，领有丰盛dashboard和图表编辑的指标剖析平台，和Kibana不同的是Grafana专一于时序类图表剖析，而且反对多种数据源，如Prometheus、Graphite、InfluxDB、Elasticsearch、Mysql、K8s、Zabbix等。 3、prometheus部署根目录下减少prometheus的Dockerfile FROM bitnami/prometheus:latestLABEL maintainer="liuyuede123 <liufutianoppo@163.com>"减少prometheus配置 # my global configglobal: scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. # scrape_timeout is set to the global default (10s).# Alertmanager configurationalerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.rule_files:# - "first_rules.yml"# - "second_rules.yml"# A scrape configuration containing exactly one endpoint to scrape:# Here it's Prometheus itself.scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: 'file_ds' file_sd_configs: - files: - targets.json[ { "targets": ["user-api:9081"], "labels": { "job": "user-api", "app": "user-api", "env": "test", "instance": "user-api:8300" } }, { "targets": ["user-rpc:9091"], "labels": { "job": "user-rpc", "app": "user-rpc", "env": "test", "instance": "user-api:9300" } }, { "targets": ["courseware-api:9082"], "labels": { "job": "courseware-api", "app": "courseware-api", "env": "test", "instance": "courseware-api:8400" } }, { "targets": ["courseware-rpc:9092"], "labels": { "job": "courseware-rpc", "app": "courseware-rpc", "env": "test", "instance": "courseware-rpc:9400" } }]文件构造如下 ...

前言PrometheusPrometheus 是有 SoundCloud 开发的开源监控零碎和时序数据库，基于 Go 语言开发。通过基于 HTTP 的 pull 形式采集时序数据，通过服务发现或动态配置去获取要采集的指标服务器，反对多节点工作，反对多种可视化图表及仪表盘。贴一下官网提供的架构图： Pormetheus 几个次要模块有，Server，Exporters，Pushgateway，PromQL，Alertmanager，WebUI等，次要逻辑如下： Prometheus server 定期从动态配置的 targets 或者服务发现的 targets 拉取数据。当新拉取的数据大于配置内存缓存区时，Prometheus 会将数据长久化到磁盘（如果应用 remote storage 将长久化到云端）。Prometheus 配置 rules，而后定时查问数据，当条件触发时，会将 alert 推送到配置的 Alertmanager。Alertmanager 收到正告时，会依据配置，聚合、去重、降噪等操作，最初发送正告。能够应用 API，Prometheus Console 或者 Grafana 查问和聚合数据。GrafanaGrafana 是一个开源的度量剖析及可视化套件。通过拜访数据库（如InfluxDB、Prometheus），展现自定义图表。 ExporterExporter 是 Prometheus 推出的针对服务器状态监控的 Metrics 工具。目前开发中常见的组件都有对应的 exporter 能够间接应用。常见的有两大类，一种是社区提供的，蕴含数据库，音讯队列，存储，HTTP服务，日志等，比方 node_exporter，mysqld_exporter等；还有一种是用户自定义的 exporter，能够基于官网提供的 Client Library 创立本人的 exporter 程序。每个 exporter 的一个实例被称为 target，Prometheus 通过轮询的形式定期从这些 target 中获取样本数据。 原理简介 装置数据收集器 node-exporter装置 node-exportercd /optwget https://github.com/prometheus/node_exporter/releases/download/v1.4.0-rc.0/node_exporter-1.4.0-rc.0.linux-amd64.tar.gztar xvf node_exporter-1.4.0-rc.0.linux-amd64.tar.gzmv node_exporter-1.4.0-rc.0.linux-amd64 node_exportermv node_exporter /usr/local/运行如下命令测试 node-exporter 收集器启动状况，失常状况下会输入服务端口。 ...

一、介绍Operator是CoreOS公司开发，用于扩大kubernetes API或特定应用程序的控制器，它用来创立、配置、治理简单的有状态利用，例如数据库，监控零碎。其中Prometheus-Operator就是其中一个重要的我的项目。其架构图如下： 其中外围局部是Operator，它会去创立Prometheus、ServiceMonitor、AlertManager、PrometheusRule这4个CRD对象，而后会始终监控并保护这4个对象的状态。 Prometheus：作为Prometheus Server的形象ServiceMonitor：就是exporter的各种形象AlertManager：作为Prometheus AlertManager的形象PrometheusRule：实现报警规定的文件 上图中的 Service 和 ServiceMonitor 都是 Kubernetes 的资源，一个 ServiceMonitor 能够通过 labelSelector 的形式去匹配一类 Service，Prometheus 也能够通过 labelSelector 去匹配多个ServiceMonitor。二、装置 留神集群版本的坑，本人先到Github上下载对应的版本。 咱们应用源码来装置，首先克隆源码到本地： git clone https://github.com/coreos/kub...复制代码咱们进入kube-prometheus/manifests/setup，就能够间接创立CRD对象： cd kube-prometheus/manifests/setupkubectl apply -f .复制代码而后在下层目录创立资源清单： cd kube-prometheus/manifestskubectl apply -f .复制代码能够看到创立如下的CRD对象： kubectl get crd | grep coreosalertmanagers.monitoring.coreos.com 2019-12-02T03:03:37Zpodmonitors.monitoring.coreos.com 2019-12-02T03:03:37Zprometheuses.monitoring.coreos.com 2019-12-02T03:03:37Zprometheusrules.monitoring.coreos.com 2019-12-02T03:03:37Zservicemonitors.monitoring.coreos.com 2019-12-02T03:03:37Z复制代码查看创立的pod： kubectl get pod -n monitoringNAME READY STATUS RESTARTS AGEalertmanager-main-0 2/2 Running 0 2m37salertmanager-main-1 2/2 Running 0 2m37salertmanager-main-2 2/2 Running 0 2m37sgrafana-77978cbbdc-886cc 1/1 Running 0 2m46skube-state-metrics-7f6d7b46b4-vrs8t 3/3 Running 0 2m45snode-exporter-5552n 2/2 Running 0 2m45snode-exporter-6snb7 2/2 Running 0 2m45sprometheus-adapter-68698bc948-6s5f2 1/1 Running 0 2m45sprometheus-k8s-0 3/3 Running 1 2m27sprometheus-k8s-1 3/3 Running 1 2m27sprometheus-operator-6685db5c6-4tdhp 1/1 Running 0 2m52s复制代码查看创立的Service： ...

Addcurl '10.26.5x.3x:9093/api/v2/silences' \-H 'Content-Type: application/json' \ --data '{"matchers":[{"name":"alertname","value":"Host_磁盘监控告警_linux_high>85%","isRegex":false}],"startsAt":"2022-08-22T09:10:45.446Z","endsAt":"2022-09-17T09:44:45.446Z","createdBy":"test","comment":"tmp","id":null}' \ --compressed \ --insecur Updatecurl '10.26.5x.3x:9093/api/v2/silences' \-H 'Content-Type: application/json' \ --data '{"matchers":[{"name":"alertname","value":"Host_磁盘监控告警_linux_high>85%","isRegex":false}],"startsAt":"2022-08-22T09:10:45.446Z","endsAt":"2022-09-17T09:44:45.446Z","createdBy":"test","comment":"tmp111111111111111111111","id":"199514ee-9e60-4d0e-8c32-8b98a48c1953"}' \ --compressed \ --insecure

写在开篇基于上次的 oracledb_exporter监控Oracle，一个入侵性极低的监控计划 文章中，本篇持续解说如下内容：依据理论业务需要编写自定义监控指标，让其真正能够在生产上玩起来oracledb_exporter的备机拉取master配置再次坚固下计划本篇讲的是下图中的红色框局部 红色框局部，是oracledb_exporter的主备计划，联合上次的设计，这个图是残缺的监控架构了。 oracledb_exporter的主备方案设计思路是跟Prometheus主备的设计思路大同小异的，架构不论如何设计，都是为了在生产环境上不要存在单点。 再次坚固笔者的环境规划用处主备角色物理IPVIP接管VIP地址oracledb_exporterMaster192.168.11.20接管192.168.11.200oracledb_exporterBackup192.168.11.21待接管192.168.11.200自定义指标的标准什么是自定义指标如果oracledb_exporter默认的监控指标没有你想要的，怎么办？非常简单！oracledb_exporter反对自定义指标，依照它的标准格局进行编写相应的指标，将自定义指标编写在文件格式以.toml结尾的配置文件里（指标文件），那oracledb_exporter如何应用这个自定义的指标文件？有两种形式，如下： 应用--custom.metrics参数，前面指定指标文件设置全局或部分环境变量，如下： export CUSTOM_METRICS=my-custom-metrics.toml自定义指标文件格式和标准编写自定义指标文件，必须依照它的标准进行编写，咱们拿官网的小栗子来解释解释，解剖解剖，官网小栗子如下： [[metric]]context = "test"request = "SELECT 1 as value_1, 2 as value_2 FROM DUAL"metricsdesc = { value_1 = "Simple example returning always 1.", value_2 = "Same but returning always 2." }依据下面的小栗子，能够晓得，必须蕴含的元素有如下： 一个或多个指标，就须要一个或多个[[metric]]局部，也就是一个指标，就对应一个[[metric]]局部对于每个[[metric]]局部，最起码要有上面的字段：context：指标名称（有意义的）request：编写自定义sqlmetricsdesc：对指标的形容自定义指标实战上面咱们通过一个更贴合理论的案例来实战一下，假如要获取IOPS指标，这个指标是须要计算的。特地要留神，在编写自定义指标之前，肯定要先把sql写好，且要调试好。笔者写好的获取iops的sql如下： select sum(decode(name,'physical read IO requests',value,'physical write IO requests',value,0)) as iops, sum(decode(name,'physical read bytes',value,'physical write bytes',value,0)) / 1024 / 1024 as mbps from v$sysstat where name in ('physical read IO requests','physical write IO requests','physical read bytes','physical read total bytes', 'physical write bytes','physical write total bytes','physical read total IO requests','physical write total IO requests');通过plsql工具连贯到oracle进行执行和调试，看看后果是否达到预期，成果如下： ...

PromQL是Prometheus自定义的一套弱小的数据查询语言，除了应用监控指标作为查问关键字认为，还内置了大量的函数，帮忙用户进一步对时序数据进行解决。例如应用rate()函数，能够计算在单位工夫内样本数据的变动状况即增长率，因而通过该函数咱们能够近似的通过CPU应用工夫计算CPU的利用率 能够应用关键字node_load1能够查问出Prometheus采集到的主机负载的样本数据，这些样本数据依照工夫先后顺序展现，造成了主机负载随工夫变动的趋势图表。 这时如果要疏忽是哪一个CPU的，只须要应用without表达式，将标签CPU去除后聚合数据即可。 那如果须要计算零碎CPU的总体使用率，通过排除零碎闲置的CPU使用率即可取得。 通过PromQL咱们能够十分不便的对数据进行查问，过滤，以及聚合，计算等操作。通过这些丰盛的表白书语句，监控指标不再是一个独自存在的个体，而是一个个可能表白出正式业务含意的语言。 （这部分是重点，未完待续。。。 参考：

想要让Prometheus server从node exporter获取监控数据须要： 编辑prometheus.yml 在scrape_configs节点上面增加： scrape_configs:- job_name: 'prometheus' static_configs: - targets: ['localhost:9090']# 采集node exporter监控数据- job_name: 'node' static_configs: - targets: ['localhost:9100']重启Prometheus Server 拜访http://localhost:9090/ 在 奇怪这里阻塞了一下，为什么up{instance="localhost:9090",job="prometheus"} 1up{instance="localhost:9100",job="node"} 1这只有1个未完待续。。 参考： https://yunlzheng.gitbook.io/...

在mac下载安装prometheus在https://prometheus.io/download/下载prometheus放到自定义的地位。解压压缩包创立data文件夹mkdir -p datamac下装置Node Exporter（NodeExporter是Prometheus提供的一个能够采集到主机信息的应用程序，它能采集到机器的 CPU、内存、磁盘等信息） cd到目标目录,而后用命令下载二进制包 curl -OL https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.darwin-amd64.tar.gz解压这个二进制包 tar -xzf node_exporter-1.3.1.darwin-amd64.tar.gz进入&运行node exporter cd node_exporter-1.3.1.darwin-amd64cd ..cp node_exporter-1.3.1.darwin-amd64/node_exporter /usr/local/bin/node_exporter运行 cd ...cd /usr/local/bin./node_exporter拜访http://localhost:9100/看到 点击http://localhost:9100/metrics进去能够看到 # HELP node_cpu Seconds the cpus spent in each mode.# TYPE node_cpu counternode_cpu{cpu="cpu0",mode="idle"} 362812.7890625# HELP node_load1 1m load average.# TYPE node_load1 gaugenode_load1 3.0703125数据阐明： HELP 解释以后指标的含意TYPE 阐明以后指标的数据类型node_cpu的正文表明以后指标是cpu0上idle过程占用CPU的总工夫CPU占用工夫是一个只增不减的度量指标，从类型中也能够看出node_cpu的数据类型是计数器(counter)node_load1 该指标反映了以后主机在最近一分钟以内的负载状况 指标类型为仪表盘(gauge)参考：https://yunlzheng.gitbook.io/...

写在开篇Oracle怎么做监控？用Zabbix？能够呀，但！本篇讲的内容是基于上次设计的Prometheus主备计划的根底上进行的， 上篇的文章是《重磅！DIY的Prometheus主备计划，全网惟一。生产未上，测试后行。》，顺便再附上该篇文章的链接：https://mp.weixin.qq.com/s?__...计划阐明本篇讲的是下图中的红色框局部 红色框局部，是oracledb_exporter的主备计划，联合上次的设计，这个图是残缺的监控架构了。 oracledb_exporter的主备方案设计思路是跟Prometheus主备的设计思路大同小异的，架构不论如何设计，都是为了在生产环境上不要存在单点。 环境规划用处主备角色物理IPVIP接管VIP地址oracledb_exporterMaster192.168.11.20接管192.168.11.200oracledb_exporterBackup192.168.11.21待接管192.168.11.200装置keepalived下载keepalived wget https://www.keepalived.org/software/keepalived-2.2.7.tar.gz编译和装置 mkdir -p /usr/local/keepalivedtar -zxf keepalived-2.2.7.tar.gzcd keepalived-2.2.7./configure --prefix=/usr/local/keepalived/ && make && make install配置master和backup的keepalived.conf 配置非抢占模式master global_defs { router_id lb01}vrrp_instance VI_1 { state BACKUP interface ens32 virtual_router_id 80 priority 150 nopreempt advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.11.200/24 dev ens32 label ens32:1 }}backup global_defs { router_id lb02}vrrp_instance VI_1 { state BACKUP interface ens32 virtual_router_id 80 priority 100 nopreempt advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.11.200/24 dev ens32 label ens32:1 }}启动keepalived ...

周日不报警(probe_success{devicetype="ipadreservation",monitortype="icmp"} == 0) and (day_of_week(timestamp(up)) != 0 )没思考utc工夫本人想方法在工夫戳+8个小时 23点当前不报警(probe_success{devicetype="ipadreservation",monitortype="icmp"} == 0) and ((hour(timestamp(up)) + 8) < 23) 0-23 小时 0是周日

写在开篇对于prometheus的高可用计划，通过笔者一直的钻研、比照、和搜寻，发现不论是官网、还是各大搜索引擎搜寻进去的计划，都不合乎笔者的需要。因而，笔者本人设计了一套prometheus主备的计划。该计划是一个很low的计划，但通过一直的实际、验证，最初发现还挺实用。对于本计划，笔者当前还会找机会用go或者python开发一个带UI界面的prometheus主备管理器，让它的性能更加欠缺，做到更自动化和智能化。Prometheus是监控畛域的新启之秀，后劲十分大，K8S内置对它间接反对，间接有提供exporter，而K8S又是将来基础架构的主力军。而监控方面，prometheus成为将来的主力军是胜券在握，把它玩透了你相对不吃亏。好了，前戏有点多了。敬请大家的关注、点赞、转发。上面的正式进入主题！！！DIY的prometheus主备计划架构图 计划阐明 两台主机（master和slave）别离部署keepalived，让master主机接管VIP，留神：keepalived倡议配置成非抢占模式之所以采纳VIP的起因如下：为了不便日常拜访Prometheus页面和Alertmanager页面，在主备切换时，可无需更换拜访ip。下层可视化利用（如grafana）通过VIP来对接Prometheus的数据源，当主备切换时，无需在grafana上批改对应的数据源。日常由master主机处于工作状态，在master中，启动Promethues和Alertmanager组件，启动webhook脚本（告警音讯推送脚本，用于将告警推送到其余平台）。slave主机备用状态，在slave中，须要启动Promethues组件（用于拉取指标数据），启动Alertmanager组件（用于接管警报音讯），这里留神，webhook脚本需处于进行状态（不进行告警推送到其余平台）。这样做是为了躲避推送反复告警的问题，尽管Alertmanager有本身的去重告警性能，但这样的设计基本就没有告警反复，曾经将反复扼杀在摇篮里了。在接入监控对象时（部署对应的exporter），切记，仅须要在master上做配置即可， slave定期从master拉取配置文件（包含主配置文件、警报规定文件等），定期和master放弃配置同步。master和slave的配置放弃同步，意味着两边都会拉取被监控对象的监控指标数据。监控指标的拉取、警报的触发两台均一起工作，但告警的推送只有master在负责，slave不负责告警的推送，如果master不可用了，就须要将slave上的webhook脚本手动拉起来，由slave上的webhook脚本接管告警推送的工作。配置文件同步的做法是采纳最原始、最简略、最粗犷的方法，master和slave的配置文件同步计划如下：Master主机： master提供配置文件下载服务，由python自带的SimpleHTTPServer模块实现，且须要在prometheus或alertmanager标准装置门路下（如/usr/local/prometheus）进行SimpleHTTPServer模块的启动，拉起后，默认的监听端口是8000。master检测配置文件变动状况，如达到条件则触发备份和打包新的配置目录。在master上，设计了一个保留告诉动作的文件notice_slave.action，配置发生变化写入1，配置没有发生变化写入0。同时，该检测脚本作为常驻过程在后盾运行。Slave主机： slave从master下载告诉动作的文件notice_slave.action，依据状态码（1和0）来决定接下来的动作，如果是1，则：从master下载配置压缩包、备份原有配置目录、解压新下载后的配置压缩包、热重启相干组件（prometheus、alertmanger），如果是0则什么都不做。对于配置文件的同步，也是有两种实现形式的，要么是推，要么是拉，笔者的这个计划里是后者，笔者目前之所以折腾零散的shell脚本来去做高可用的治理，是为了能疾速解决需要，因而才做了这个简陋的计划，笔者的准则是：艰难的事件简略做，简略的事件咱不做（开玩笑哈！！！）。 当然，笔者当前会通过Go或者Python打造一个治理Promtheus主备的工具，且是带UI的管理工具，敬请期待推出！我不造车，我只造整机。一、布局和标准1. 设施布局（本示例为测试环境）角色物理IPVIP装置组件告警推送形式master192.168.11.146192.168.11.203（以后接管）prometheus、alertmanager（均拉起）webhook形式，脚本拉起slave192.168.11.147 prometheus、alertmanager（均拉起）webhook形式，脚本不拉起（备用）2. 对立装置门路标准master和slave主机的规范装置门路均为：/usr/local/，笔者装置组件后的环境如下:/usr/local/keepalived （留神：倡议keepalived配置成非抢占模式）/usr/local/prometheus/usr/local/alertmanager至于装置门路的标准，请自行依据理论状况敲定。3. prometheus组件配置文件和目录标准所有配置文件统一标准门路：/usr/local/prometheus/conf/prometheus主配置文件：/usr/local/prometheus/conf/prometheus.yml按业务粒度，一个业务对应一个目录，业务下不同的监控对象都放在对应的业务目录下：/usr/local/prometheus/conf/business特地阐明1：请自行在prometheus组件的装置目录下创立conf目录，并将默认的prometheus.yml配置文件挪动进去 特地阐明2：请自行在prometheus组件的配置文件统一标准门路（./conf）下创立业务目录business 特地阐明3：业务目录下，又蕴含两个目录：job和rule，job用于寄存监控拉取配置文件，rule用于寄存警报规定配置文件 配置文件目录和业务目录布局示范，如下: /usr/local/prometheus/ # 这是标准的装置门路/usr/local/prometheus/conf/ # 这是标准的配置目录/usr/local/prometheus/conf/prometheus.yml # 这是主配置文件/usr/local/prometheus/conf/business 这是按业务粒度布局的业务根目录# 如下是业务A的布局案例：/usr/local/prometheus/conf/business/a_business/ 这是业务a的目录/usr/local/prometheus/conf/business/a_business/job/oracle.yml 这是业务a下拉取oracle监控配置数据的yml配置文件/usr/local/prometheus/conf/business/a_business/rule/oracle.rules 这是业务a下oracle的警报规定rules配置文件特地阐明：上述对业务A的配置文件布局案例十分重要，请务必参照此标准。4. alertmanager组件配置文件和目录标准对于Alertmanager组件的配置文件，相对来说没prometheus那么简单，次要的布局还是在prometeus中alertmanager的主配置文件统一标准门路放在prometeheus的conf中：/usr/local/prometheus/conf/alertmanager.yml5. 备份门路标准在master主机上，会主动备份原有的conf配置文件目录 Prometheus组件 对立备份门路为：/usr/local/prometheus/backup/Alertmanager组件 不波及到备份6. 日志目录标准在master主机和slave主机上运行的脚本日志均对立寄存在指定目录 Prometheus组件 对立日志目录：/usr/local/prometheus/logs/AlertManager组件 对立日志目录：/usr/local/alertmanager/logs/二、组件装置部署留神：master和slave均须要装置如下组件keepalived高可用组件prometheus监控组件alertmanager警报组件因组件的装置部署不是本文的主题，所以笔者在这里就不再撰写装置步骤，在此省略了哈，请自行装置好即可。三、prometheus配置文件目录同步部署阐明1：均须要在master和slave上部署文件同步相干脚本 阐明2：以下的每一步操作，请均进入到“/usr/local/prometheus/”目录下进行操作（此目录是之前曾经定为装置标准的目录），如您的标准目录和笔者的不同，请进入到您本人的标准目录下。 阐明3：以下波及的脚本，波及的目录：conf、backup、logs、cfmd5，请自行在标准的目录下进行创立即可。 1. master部署配置文件下载服务通过python拉起简略的Http服务，默认监听端口为8000，创立脚本startPromconfSyncApi.shstartPromconfSyncApi.sh脚本内容如下： #!/bin/shnohup /usr/bin/python -m SimpleHTTPServer > /dev/null &运行配置文件下载服务的脚本 sh startPromconfSyncApi.sh拉起http服务脚本后查看端口 [root@prosvr-master prometheus]# netstat -tulnp | grep 8000tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 1293/python [root@prosvr-master prometheus]# 创立配置文件变动查看脚本startTarPackConf.sh 留神，请在标准的装置门路/usr/local/prometheus/上面创立startTarPackConf.sh脚本，以及创立目录cfmd5startTarPackConf.sh脚本内容： #!/bin/shtime_log=`date "+%Y-%m-%d %H:%M:%S"`echo "${time_log} 配置查看器启动"task_wait_sec=4find ./conf -type f -print0 | xargs -0 md5sum > ./cfmd5/cfmd5.listwhile truedo time_bak=`date "+%Y%m%d%H%M%S"` time_log=`date "+%Y-%m-%d %H:%M:%S"` md5sum -c ./cfmd5/cfmd5.list > ./cfmd5/check_cfmd5.log md5ret=`cat ./cfmd5/check_cfmd5.log | grep "FAILED" | wc -l` while true do if [ ${md5ret} -gt 0 ] then echo "${time_log} 配置文件发生变化，触发备份和打包压缩" mv ./conf.tar.gz ./backup/conf.tar.gz_bak_${time_bak} tar -zcf conf.tar.gz conf/ echo 1 > ./notice_slave.action curl -X POST http://127.0.0.1:9090/-/reload break else echo 0 > ./notice_slave.action break fi done find ./conf -type f -print0 | xargs -0 md5sum > ./cfmd5/cfmd5.list sleep ${task_wait_sec}done脚本实现阐明：很简略，就是递归搜寻conf目录下的所有配置文件且生成md5值保留在./cfmd5/cfmd5.list，并应用md5sum -c实时查看./cfmd5/cfmd5.list中的文件md5值是否有变动，且将后果输入到./cfmd5/check_cfmd5.log，再通过cat ./cfmd5/check_cfmd5.log进行过滤"FAILED"并统计，只有呈现有"FAILED"，就认为配置文件有产生过变动，要么是减少了，要么是现有的配置文件做了批改。统计的后果保留在md5ret变量，判断条件就是md5ret后果大于0就触发南方和打包压缩配置目录，同时master中的配置文件发生变化后，也会主动触发热重启。接着将状态码1写入到./notice_slave.action文件中，如果没有变动，将状态码就是0。notice_slave.action文件是存储状态变动的（在这里就罗唆叫告诉文件吧！）。 ...

import os, json, requests, timedef get_disk_peak(ip): # 拼接URL pre_url = 'http://10.xx.5.3x:90x0' + '/api/v1/query?query=' expr = '(node_filesystem_size_bytes{fstype!~"apfs",mountpoint="/",instancehost="ip17"} - node_filesystem_free_bytes{fstype!~"apfs",mountpoint="/",instancehost="ip17"}) / node_filesystem_size_bytes{fstype!~"apfs",mountpoint="/",instancehost="ip17"} * 100'.replace('ip17', ip) url = pre_url + expr result = {} # 申请URL后将Json数据转为字典对象 res = json.loads(requests.post(url=url).content.decode('utf8', 'ignore')) print("###json:", res) # 循环取出字典里每个IP的values，排序取最高值，最初存入result字典 result_list = res.get('data').get('result') print(result_list) result_dict = result_list[0] result_value = result_dict['value'] return result_value[1]def get_rule_recovery(ip, recovery_expr): # 拼接URL pre_url = 'http://10.xx.5.3x:9xx0' + '/api/v1/query?query=' expr = recovery_expr.replace('ip17', ip) url = pre_url + expr # 申请URL后将Json数据转为字典对象 res = json.loads(requests.post(url=url).content.decode('utf8', 'ignore')) print("###json:", res) result_list = res.get('data').get('result') print(result_list) result_dict = result_list[0] result_value = result_dict['value'] return result_value[1]ww = '(node_filesystem_size_bytes{fstype!~"apfs",mountpoint="/",instancehost="ip17"} - node_filesystem_free_bytes{fstype!~"apfs",mountpoint="/",instancehost="ip17"}) / node_filesystem_size_bytes{fstype!~"apfs",mountpoint="/",instancehost="ip17"} * 100'print(get_rule_recovery(ip='10.31.140.24', recovery_expr=ww)) ...

k8s教程阐明k8s底层原理和源码解说之精髓篇k8s底层原理和源码解说之进阶篇k8s纯源码解读课程，助力你变成k8s专家k8s-operator和crd实战开发 助你成为k8s专家tekton全流水线实战和pipeline运行原理源码解读prometheus全组件的教程01_prometheus全组件配置应用、底层原理解析、高可用实战02_prometheus-thanos应用和源码解读03_kube-prometheus和prometheus-operator实战和原理介绍04_prometheus源码解说和二次开发go语言课程golang根底课程golang运维平台实战，服务树,日志监控，工作执行，分布式探测问题形容比方对于1个构建的流水线指标 pipeline_step_duration ，会设置1个标签是step每次流水线蕴含的step可能不雷同 # 比方 流水线a 第1次的step 蕴含clone 和buildpipeline_step_duration{step="clone"}pipeline_step_duration{step="build"}# 第2次 的step 蕴含 build 和pushpipeline_step_duration{step="build"}pipeline_step_duration{step="push"}那么问题来了：第2次的pipeline_step_duration{step="build"} 要不要删掉？其实在这个场景外面是要删掉的，因为曾经不蕴含clone了问题能够总结成：之前采集的标签曾经不存在了，数据要及时清理掉 --问题是如何清理？探讨这个问题前做个试验：比照两种常见的自打点形式对于不沉闷指标的删除解决试验伎俩：prometheus client-go sdk启动1个rand_metrics蕴含rand_key，每次key都不一样，测试申请metrics接口的后果 var ( T1 = prometheus.NewGaugeVec(prometheus.GaugeOpts{ Name: "rand_metrics", Help: "rand_metrics", }, []string{"rand_key"}))实现形式01 业务代码中间接实现打点：不实现Collector接口代码如下，模仿极其状况，每0.1秒生成随机key 和value设置metrics package mainimport ( "fmt" "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promhttp" "math/rand" "net/http" "time")var ( T1 = prometheus.NewGaugeVec(prometheus.GaugeOpts{ Name: "rand_metrics", Help: "rand_metrics", }, []string{"rand_key"}))func init() { prometheus.DefaultRegisterer.MustRegister(T1)}func RandStr(length int) string { str := "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" bytes := []byte(str) result := []byte{} rand.Seed(time.Now().UnixNano() + int64(rand.Intn(100))) for i := 0; i < length; i++ { result = append(result, bytes[rand.Intn(len(bytes))]) } return string(result)}func push() { for { randKey := RandStr(10) rand.Seed(time.Now().UnixNano() + int64(rand.Intn(100))) T1.With(prometheus.Labels{"rand_key": randKey}).Set(rand.Float64()) time.Sleep(100 * time.Millisecond) }}func main() { go push() addr := ":8081" http.Handle("/metrics", promhttp.Handler()) srv := http.Server{Addr: addr} err := srv.ListenAndServe() fmt.Println(err)}启动服务之后申请 :8081/metrics接口发现 过期的 rand_key还会保留，不会清理 ...

写在开篇对于prometheus的高可用计划，通过笔者一直的钻研、比照、和搜寻，发现不论是官网、还是各大搜索引擎搜寻进去的计划，都不合乎笔者的需要。因而，笔者本人设计了一套prometheus主备的计划。该计划是一个很low的计划，但通过一直的实际、验证，最初发现还挺实用。对于本计划，笔者当前还会找机会用go或者python开发一个带UI界面的prometheus主备管理器，让它的性能更加欠缺，做到更自动化和智能化。Prometheus是监控畛域的新启之秀，后劲十分大，K8S内置对它间接反对，间接有提供exporter，而K8S又是将来基础架构的主力军。而监控方面，prometheus成为将来的主力军是胜券在握，把它玩透了你相对不吃亏。好了，前戏有点多了。敬请大家的关注、点赞、转发。上面的正式进入主题！！！DIY的prometheus主备计划架构图计划阐明 两台主机（master和slave）别离部署keepalived，让master主机接管VIP，留神：keepalived倡议配置成非抢占模式之所以采纳VIP的起因如下：为了不便日常拜访Prometheus页面和Alertmanager页面，在主备切换时，可无需更换拜访ip。下层可视化利用（如grafana）通过VIP来对接Prometheus的数据源，当主备切换时，无需在grafana上批改对应的数据源。日常由master主机处于工作状态，在master中，启动Promethues和Alertmanager组件，启动webhook脚本（告警音讯推送脚本，用于将告警推送到其余平台）。slave主机备用状态，在slave中，须要启动Promethues组件（用于拉取指标数据），启动Alertmanager组件（用于接管警报音讯），这里留神，webhook脚本需处于进行状态（不进行告警推送到其余平台）。这样做是为了躲避推送反复告警的问题，尽管Alertmanager有本身的去重告警性能，但这样的设计基本就没有告警反复，曾经将反复扼杀在摇篮里了。在接入监控对象时（部署对应的exporter），切记，仅须要在master上做配置即可， slave定期从master拉取配置文件（包含主配置文件、警报规定文件等），定期和master放弃配置同步。master和slave的配置放弃同步，意味着两边都会拉取被监控对象的监控指标数据。监控指标的拉取、警报的触发两台均一起工作，但告警的推送只有master在负责，slave不负责告警的推送，如果master不可用了，就须要将slave上的webhook脚本手动拉起来，由slave上的webhook脚本接管告警推送的工作。配置文件同步的做法是采纳最原始、最简略、最粗犷的方法，master和slave的配置文件同步计划如下：Master主机： master提供配置文件下载服务，由python自带的SimpleHTTPServer模块实现，且须要在prometheus或alertmanager标准装置门路下（如/usr/local/prometheus）进行SimpleHTTPServer模块的启动，拉起后，默认的监听端口是8000。master检测配置文件变动状况，如达到条件则触发备份和打包新的配置目录。在master上，设计了一个保留告诉动作的文件notice_slave.action，配置发生变化写入1，配置没有发生变化写入0。同时，该检测脚本作为常驻过程在后盾运行。Slave主机： slave从master下载告诉动作的文件notice_slave.action，依据状态码（1和0）来决定接下来的动作，如果是1，则：从master下载配置压缩包、备份原有配置目录、解压新下载后的配置压缩包、热重启相干组件（prometheus、alertmanger），如果是0则什么都不做。 对于配置文件的同步，也是有两种实现形式的，要么是推，要么是拉，笔者的这个计划里是后者，笔者目前之所以折腾零散的shell脚本来去做高可用的治理，是为了能疾速解决需要，因而才做了这个简陋的计划，笔者的准则是：艰难的事件简略做，简略的事件咱不做（开玩笑哈！！！）。 当然，笔者当前会通过Go或者Python打造一个治理Promtheus主备的工具，且是带UI的管理工具，敬请期待推出！我不造车，我只造整机。一、布局和标准1. 设施布局（本示例为测试环境）角色物理IPVIP装置组件告警推送形式master192.168.11.146192.168.11.203（以后接管）prometheus、alertmanager（均拉起）webhook形式，脚本拉起slave192.168.11.147 prometheus、alertmanager（均拉起）webhook形式，脚本不拉起（备用）2. 对立装置门路标准master和slave主机的规范装置门路均为：/usr/local/，笔者装置组件后的环境如下:/usr/local/keepalived （留神：倡议keepalived配置成非抢占模式）/usr/local/prometheus/usr/local/alertmanager至于装置门路的标准，请自行依据理论状况敲定。3. prometheus组件配置文件和目录标准所有配置文件统一标准门路：/usr/local/prometheus/conf/prometheus主配置文件：/usr/local/prometheus/conf/prometheus.yml按业务粒度，一个业务对应一个目录，业务下不同的监控对象都放在对应的业务目录下：/usr/local/prometheus/conf/business特地阐明1：请自行在prometheus组件的装置目录下创立conf目录，并将默认的prometheus.yml配置文件挪动进去 特地阐明2：请自行在prometheus组件的配置文件统一标准门路（./conf）下创立业务目录business 特地阐明3：业务目录下，又蕴含两个目录：job和rule，job用于寄存监控拉取配置文件，rule用于寄存警报规定配置文件 配置文件目录和业务目录布局示范，如下: /usr/local/prometheus/ # 这是标准的装置门路/usr/local/prometheus/conf/ # 这是标准的配置目录/usr/local/prometheus/conf/prometheus.yml # 这是主配置文件/usr/local/prometheus/conf/business 这是按业务粒度布局的业务根目录# 如下是业务A的布局案例：/usr/local/prometheus/conf/business/a_business/ 这是业务a的目录/usr/local/prometheus/conf/business/a_business/job/oracle.yml 这是业务a下拉取oracle监控配置数据的yml配置文件/usr/local/prometheus/conf/business/a_business/rule/oracle.rules 这是业务a下oracle的警报规定rules配置文件特地阐明：上述对业务A的配置文件布局案例十分重要，请务必参照此标准。4. alertmanager组件配置文件和目录标准对于Alertmanager组件的配置文件，相对来说没prometheus那么简单，次要的布局还是在prometeus中alertmanager的主配置文件统一标准门路放在prometeheus的conf中：/usr/local/prometheus/conf/alertmanager.yml5. 备份门路标准在master主机上，会主动备份原有的conf配置文件目录 Prometheus组件 对立备份门路为：/usr/local/prometheus/backup/Alertmanager组件 不波及到备份6. 日志目录标准在master主机和slave主机上运行的脚本日志均对立寄存在指定目录 Prometheus组件 对立日志目录：/usr/local/prometheus/logs/AlertManager组件 对立日志目录：/usr/local/alertmanager/logs/二、组件装置部署留神：master和slave均须要装置如下组件keepalived高可用组件prometheus监控组件alertmanager警报组件因组件的装置部署不是本文的主题，所以笔者在这里就不再撰写装置步骤，在此省略了哈，请自行装置好即可。三、prometheus配置文件目录同步部署阐明1：均须要在master和slave上部署文件同步相干脚本 阐明2：以下的每一步操作，请均进入到“/usr/local/prometheus/”目录下进行操作（此目录是之前曾经定为装置标准的目录），如您的标准目录和笔者的不同，请进入到您本人的标准目录下。 阐明3：以下波及的脚本，波及的目录：conf、backup、logs、cfmd5，请自行在标准的目录下进行创立即可。 1. master部署配置文件下载服务通过python拉起简略的Http服务，默认监听端口为8000，创立脚本startPromconfSyncApi.shstartPromconfSyncApi.sh脚本内容如下： #!/bin/shnohup /usr/bin/python -m SimpleHTTPServer > /dev/null &运行配置文件下载服务的脚本 sh startPromconfSyncApi.sh拉起http服务脚本后查看端口 [root@prosvr-master prometheus]# netstat -tulnp | grep 8000tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 1293/python [root@prosvr-master prometheus]# 创立配置文件变动查看脚本startTarPackConf.sh 留神，请在标准的装置门路/usr/local/prometheus/上面创立startTarPackConf.sh脚本，以及创立目录cfmd5startTarPackConf.sh脚本内容： #!/bin/shtime_log=`date "+%Y-%m-%d %H:%M:%S"`echo "${time_log} 配置查看器启动"task_wait_sec=4find ./conf -type f -print0 | xargs -0 md5sum > ./cfmd5/cfmd5.listwhile truedo time_bak=`date "+%Y%m%d%H%M%S"` time_log=`date "+%Y-%m-%d %H:%M:%S"` md5sum -c ./cfmd5/cfmd5.list > ./cfmd5/check_cfmd5.log md5ret=`cat ./cfmd5/check_cfmd5.log | grep "FAILED" | wc -l` while true do if [ ${md5ret} -gt 0 ] then echo "${time_log} 配置文件发生变化，触发备份和打包压缩" mv ./conf.tar.gz ./backup/conf.tar.gz_bak_${time_bak} tar -zcf conf.tar.gz conf/ echo 1 > ./notice_slave.action curl -X POST http://127.0.0.1:9090/-/reload break else echo 0 > ./notice_slave.action break fi done find ./conf -type f -print0 | xargs -0 md5sum > ./cfmd5/cfmd5.list sleep ${task_wait_sec}done脚本实现阐明：很简略，就是递归搜寻conf目录下的所有配置文件且生成md5值保留在./cfmd5/cfmd5.list，并应用md5sum -c实时查看./cfmd5/cfmd5.list中的文件md5值是否有变动，且将后果输入到./cfmd5/check_cfmd5.log，再通过cat ./cfmd5/check_cfmd5.log进行过滤"FAILED"并统计，只有呈现有"FAILED"，就认为配置文件有产生过变动，要么是减少了，要么是现有的配置文件做了批改。统计的后果保留在md5ret变量，判断条件就是md5ret后果大于0就触发南方和打包压缩配置目录，同时master中的配置文件发生变化后，也会主动触发热重启。接着将状态码1写入到./notice_slave.action文件中，如果没有变动，将状态码就是0。notice_slave.action文件是存储状态变动的（在这里就罗唆叫告诉文件吧！）。 ...

背景形容如图 想要取到 url get申请的值，应用prometheus blackbox 无奈获取，所以思考应用flask自定义exporter 获取 install 库 pip install prometheus_client flaskfrom atexit import registerimport mimetypesimport requestsfrom prometheus_client.core import CollectorRegistryfrom prometheus_client import Gauge, Counter, Info, Enum, generate_latest, start_http_serverfrom flask import Response, Flaskmeeting_useroom_url = 'http://10.31.140.24:9000/meeting_use_count/2'json_meeting_count = requests.get(meeting_useroom_url)dic_meeting_count = json_meeting_count.json()meeting_totalroom_url = 'http://10.31.140.24:9000/meeting_rooms'json_totalroom_count = requests.get(meeting_totalroom_url)dic_totalroom_count = json_totalroom_count.json()meeting_totalpersion_url = 'http://10.31.140.24:9000/meeting_persions'json_totalpersion_count = requests.get(meeting_totalpersion_url)dic_totalpersion_count = json_totalpersion_count.json()# 获取源数据，数据源能够是任意接口、数据库、文件等def get_qcloud_data(): data = { 'meeting_count': int(dic_meeting_count), 'room_count': int(dic_totalroom_count), 'persion_count': int(dic_totalpersion_count), 'cbs': 2, 'clb': 3 } return data# 设置metrics# Prometheus提供4种类型Metrics：Counter, Gauge, Summary和Histogram# Counter 累加器，只有inc办法,定义方法指标名，形容，默认增长值是1# Gauge 可任意设置，比方cpu、内存、磁盘等指标，定义方法，指标名，形容，标签# Histogram 分桶统计，对每个桶的数据进行统计# Summary 分位统计，对每个值进行统计registry = CollectorRegistry(auto_describe=False)product_meeting_count = Gauge('product_meeting_count', 'product_usage_meeting_count', ['product'], registry=registry)product_room_count = Gauge('product_room_count', 'product_usage_room_count', ['product'], registry=registry)product_persion_count = Gauge('product_persion_count', 'product_usage_persion_count', ['product'], registry=registry)product_cbs = Gauge('product_cbs', 'product_usage_cbs', ['product'], registry=registry)product_clb = Gauge('product_clb', 'product_usage_clb', ['product'], registry=registry)app = Flask(__name__)@app.route("/metrics")def main(): data = get_qcloud_data() for key, value in data.items(): if key == 'meeting_count': product_meeting_count.labels(product=key).set(value) elif key == 'room_count': product_room_count.labels(product=key).set(value) elif key == 'persion_count': product_persion_count.labels(product=key).set(value) elif key == 'cbs': product_cbs.labels(product=key).set(value) elif key == 'clb': product_clb.labels(product=key).set(value) return Response(generate_latest(registry), mimetype="text/plain")@app.route('/')def index(): print(dic_meeting_count, dic_totalpersion_count, dic_totalroom_count) return "welecome to qcloud export"if __name__ == "__main__": app.run(host="0.0.0.0", port=9117) ...

统计形式：avg_over_time, max_over_time, min_over_time,sum_over_time汇聚函数：avg by, sum by, max by, min by表达式语言数据类型instant vector 刹时向量 - 它是指在同一时刻，抓取的所有度量指标数据。这些度量指标数据的 key 都是雷同的，也即雷同的工夫戳。range vector 范畴向量 - 它是指在任何一个工夫范畴内，抓取的所有度量指标数据。scalar 标量 - 一个简略的浮点值string 字符串 - 一个以后没有被应用的简略字符串 刹时向量选择器刹时向量选择器能够只指定度量名称来获取该度量名的所有的即时向量。 以kong网关抓取各个服务的http状态码为例kong_http_status 也能够进行标签筛选，数据埋点的时候咱们会对采集的数据打上不同的 tag 标签 kong_http_status{code="200",service="sky-cmdb"} 能够采纳不匹配的标签值也是能够的，或者用正则表达式不匹配标签。标签匹配操作如下所示： =: 准确地匹配标签给定的值!=: 不等于给定的标签值=~: 正则表白匹配给定的标签值!~: 给定的标签值不合乎正则表达式 范畴向量选择器在刹时向量的根底上加上工夫范畴，具体语法是在向量选择器开端的方括号中填上持续时间，用来指定每个后果范畴向量元素提取多长时间值。 持续时间指定为数字，紧接着是以下单位之一：s - secondsm - minutesh - hoursd - daysw - weeksy - years kong_http_status{code="200",service="sky-cmdb"}[5m] 偏移修饰符这个 offset 偏移修饰符容许在查问中扭转单个刹时向量和范畴向量中的工夫偏移 这将返回一周前的刹时向量： kong_http_status{code="200",service="sky-cmdb"} offset 1w内置函数prometheus 内置了许多函数提供咱们调用 abs()abs(v instant-vector) 返回输出向量，所有样本值都转换为其绝对值。 ceil()ceil(v instant-vector) 将 v 中所有元素的样本值舍入到最靠近的整数。 ...

一.VictoriaMetrics概述VictoriaMetrics是一个疾速、高效和可扩大的时序数据库，可作为prometheus的长期存储(long-term storage)。 VictoriaMetrics反对PromQL查询语言，也反对Influxdb行协定，对以后支流的时序协定反对比拟好。 本文重点关注其集群架构。 单实例的victoriametric只有一个过程。 集群版的victoriametrics有3类过程，即3类微服务组成： vmstorage: 数据存储节点，负责存储时序数据；vmselect: 数据查问节点，负责接管用户查问申请，向vmstorage查问时序数据；vminsert: 数据插入节点，负责接管用户插入申请，向vmstorage写入时序数据；在部署时能够依照需要，不同的微服务部署不同的正本，以应答业务需要： 若数据量比拟大，部署较多的vmstorage正本；若查问申请比拟多，部署较多的vmselect正本；若插入申请比拟多，部署较多的vminsert正本；二.VictoriaMetrics集群实现集群中vmselect、vminsert节点都是无状态的，惟一有状态的是vmstorage。 vmstorage的多节点采纳shared noting architecture，各节点间不共享数据，也不晓得彼此的存在。 vmstorage nodes don't know about each other, don't communicate with each other and don't share any data. This is shared nothing architecture. It increases cluster availability, simplifies cluster maintenance and cluster scaling.为保障时序数据的可用性，采纳复制的办法，即每份数据存入N个不同的节点，在查问时，同时查问多个节点，去重后返回给client。 若设置--replicationFactor=2，即数据正本=2： 在写入数据时： 对输出数据进行一致性hash计算，将写入storageIndex节点；因为配置写入2正本，它同时要写入storageIndex+1节点；在查问数据时： 向所有的vmstorage发动查问；将查问后果合并、去重后，返回给client；依据vmstorage正确响应的节点和replica的个数，判断返回数据isPartial/OK；三.VictoriaMetrics写入数据以InfluxDB行协定插入数据为例，联合源码剖析victoriametrics集群版本写入数据的流程。 写入数据在vminsert服务中解决，假如--replicationFactor=2，即数据正本=2： 插入时： 对每条时序数据，依照其label计算一致性hash值，作为它存入的指标节点，假如为storageNodeA；对于该条时序数据，因为正本=2，它将被写入storageNodeA和storageNodeA +1两个vmstorage节点；1）API入口API: influx/write // app/vminsert/main.gofunc requestHandler(w http.ResponseWriter, r *http.Request) bool { ...... switch p.Suffix { case "influx/write", "influx/api/v2/write": if err := influx.InsertHandlerForHTTP(at, r); err != nil { httpserver.Errorf(w, r, "%s", err) return true } w.WriteHeader(http.StatusNoContent) return true } ......}API handler: ...

装置docker run --restart=always --name consul -p 8500:8500 -v /home/consul/conf/:/consul/conf/ -v /home/consul/data/:/consul/data/ -d consul agent -server -ui -bind=0.0.0.0 -client=0.0.0.0 -bootstrap-expect=1 add[root@prometheus_sh_01_10_23_1x_174 ~]# curl -X PUT -d '{"id": "node-exporter11-10.31.140.24","name": "node-exporter11-10.31.140.24","address": "10.31.1x.24","port": 9100,"Meta": {"service": "test_consule","instance_host": "10.31.1x.24"},"tags": ["test"],"checks": [{"http": "http://10.31.1x.24:9100/metrics", "interval": "15s"}]}' http://10.100.1x.55:8500/v1/agent/service/register查看[root@prometheus_sh_01_10_23_1x_174 ~]# curl http://10.100.140.55:8500/v1/agent/services{"node-exporter":{"ID":"node-exporter","Service":"node-exporter11-10.23.140.174","Tags":["test"],"Meta":{"instance_host":"10.23.140.174","service":"test_consule"},"Port":9100,"Address":"10.23.140.174","TaggedAddresses":{"lan_ipv4":{"Address":"10.23.140.174","Port":9100},"wan_ipv4":{"Address":"10.23.140.174","Port":9100}},"Weights":{"Passing":1,"Warning":1},"EnableTagOverride":false,"Datacenter":"dc1"},"node-exporter11-10.31.1x.24":{"ID":"node-exporter11-10.31.140.24","Service":"node-exporter11-10.31.1x.24","Tags":["test"],"Meta":{"instance_host":"10.31.1x.24","service":"test_consule"},"Port":9100,"Address":"10.31.140.24","TaggedAddresses":{"lan_ipv4":{"Address":"10.31.1x.24","Port":9100},"wan_ipv4":{"Address":"10.31.1x.24","Port":9100}},"Weights":{"Passing":1,"Warning":1},"EnableTagOverride":false,"Datacenter":"dc1"}}[root@prometheus_sh_01_10_23_1x_174 ~]# [root@prometheus_sh_01_10_23_x40_174 ~]# 删除curl -X PUT http://10.100.1x.55:8500/v1/agent/service/deregister/node-exporter11-10.23.1x.174 vim prometheus.yml - job_name: 'consul-prometheus' consul_sd_configs: - server: '10.100.1x.55:8500' services: [] relabel_configs: - source_labels: ['__meta_consul_tags'] target_label: 'product' - source_labels: ['__meta_consul_dc'] target_label: 'idc' - source_labels: ['__meta_consul_service'] regex: "consul" #匹配为"consul" 的service action: drop # 执行的动作 - source_labels: ['job'] target_label: 'environment' regex: '(.*)job' replacement: '${1}' ...

版本组件版本kubernetes1.23.4prometheus2.34.0node-exporter1.3.1grafana8.4.6参考资料prometheus官网:https://prometheus.io/docs/pr...prometheus官网镜像:https://hub.docker.com/r/prom...prometheus官网示例:https://github.com/prometheus... prometheu部署#生成deploymentkubectl create deployment prometheus --image=prom/prometheus:v2.34.0 --dry-run=client -o yaml > prometheus-deployment.yaml#生成servicekubectl expose deployment prometheus --port=9090 --type=NodePort --target-port=9090 --name=prometheus -o yaml > prometheus-service.yamlgrafana部署#生成deploymentkubectl create deployment grafana --image=grafana/grafana-oss:8.4.6 --dry-run=client -o yaml > grafana-deployment.yaml#生成servicekubectl expose deployment grafana --port=3000 --type=NodePort --target-port=3000 --name=grafana --dry-run=client -o yaml > grafana-service.yamlnode-exporter部署#生成deploymentkubectl create deployment node-exporter --image=prom/node-exporter:v1.3.1 --dry-run=client -o yaml > node-exporter-deployment.yaml#生成servicekubectl expose deployment node-exporter --port=9100 --type=NodePort --target-port=9100 --name=grafana --dry-run=client -o yaml > node-exporter-service.yaml

前言软件的开发不仅仅在于解决业务，它还须要程序尽可能的运行上来，这就波及到了服务的稳定性。稳定性波及很多因素，硬件软件都须要保障。为了能让这些条件更加短缺，咱们须要一直的收集数据，剖析数据，监控数据，进而优化能优化的点。Prometheus 在这方面就为咱们提供了很好的监控计划。 什么是 Prometheus？Prometheus 是一个开源的监控和报警零碎，它将咱们关怀的指标值通过 PULL 的形式获取并存储为工夫序列数据。如果单从它的收集性能来讲，咱们也能够通过 mysql、redis 等形式实现。然而，这些数据是在每时每刻产生的，其宏大的规模须要咱们好好的思考其存储形式。另外，这些监控数据大多数时候是跟统计相干的，比方数据与工夫的散布状况等，这须要有业余的度量常识。而这些正是 Prometheus 的善于所在。 因为 Prometheus 的关注重点在于指标值以及工夫点这两个因素，所以内部程序对它的接入老本十分的低。这种易用性能够让咱们对数据进行多维度、多角度的察看和剖析，使得监控的成果更加具体化，例如内存耗费、网络利用率、申请连接数等。 除此之外，Prometheus 还具备了操作简略、可拓展的数据收集和弱小的查询语言等个性，这些个性能帮忙咱们在问题呈现的时候，疾速告警并定位谬误。所以当初很多微服务基础设施都会抉择接入 Prometheus，像 k8s、云原生等。 Prometheus 的整体架构Prometheus 为了保障它的拓展性、可靠性，在除了提供外围的 server 外还提供了很多生态组件，为了不减少了解的复杂度，咱们先从上帝视角，看看它的外围 Prometheus server： 能够看到，Prometheus server 的解决链路很清晰，其实就是数据收集-数据存储-数据查问。当然，一个欠缺的零碎必定会衍生出许多组件来撑持它的个性。所以咱们会看到，在 Prometheus 架构里还存在着其余的组件，例如： Pushgateway：为监控节点提供 Push 性能，再由 Prometheus server 到 Pushgateway 集中 Pull 数据。Targets Discover：依据服务发现获取监控节点的地址。PromQL：针对指标数据查问的语言，相似 SQL。Alertmanager：依据配置规定以及指标剖析，提供告警服务。最初，Prometheus 的整体架构如下： 指标(Metrics)下面提到 Prometheus 的外围关注点在于指标（Metrics），指标咱们能够简略的了解为一个度量值，这个值能够是 CPU 负载、内存应用、申请连接数等。它们来源于操作系统、应用服务、设施数据等，会随着工夫的变动而有所不同。为了能让这些指标更好的体现出度量外延，Prometheus 提供了四种指标类型： Counter（计数器）：只增不减的计数器Gauge（仪表盘）：可增可减，任意变动的仪表盘Histogram（直方图）：将指标进行量化均匀，失去相似在 0~10ms 之间的申请数有多少，而 10~20ms 之间的申请数又有多少的直方图Summary（摘要）：histogram 在客户端是简略的分桶和分桶计数，因为 prometheus 服务端基于这么无限的数据做百分位估算，不是很精确，summary 就是解决百分位精确的问题而来的。实际上，在 Prometheus 里指标的组成有几局部：指标名、labels、指标值。 （labels 就是咱们常常提到的维度）。例如，上面就是一个对于 http 的计数器类型指标数据： # HELP prometheus_http_requests_total Counter of HTTP requests.# TYPE prometheus_http_requests_total counterprometheus_http_requests_total{code="200",handler="/api/v1/label/:name/values"} 7prometheus_http_requests_total{code="200",handler="/api/v1/query"} 19prometheus_http_requests_total{code="200",handler="/api/v1/query_range"} 27prometheus_http_requests_total{code="200",handler="/graph"} 11prometheus_http_requests_total{code="200",handler="/metrics"} 8929prometheus_http_requests_total{code="200",handler="/static/*filepath"} 52prometheus_http_requests_total{code="302",handler="/"} 1prometheus_http_requests_total{code="400",handler="/api/v1/query_range"} 6须要留神的是，Prometheus 须要收集的数据是随着工夫的增长而增长的，所以它个别不倡议保留长期的指标数据，默认保留 15 天。如果监控的数据发现问题，那么须要咱们配置告警发现，疾速解决。 ...

PromQL（Prometheus Query Language）为Prometheus tsdb的查询语言。是联合grafana进行数据展现和告警规定的配置的要害局部。 本文默认您已理解Prometheus的四种指标类型： counter（计数器）gauge （仪表类型）histogram（直方图类型）summary （摘要类型）便于读者实际，本文大部分样本数据target： Prometheusnode_exporter表达式数据类型PromQL查问语句即表达式，实现的四种数据类型： Instant vector Instance vector（刹时向量）示意一个工夫序列的汇合，然而每个时序只有最近的一个点，而不是线。 Range vector Range vector（范畴向量）示意一段时间范畴里的时序，每个时序可蕴含多个点 sources：Understanding Prometheus Range Vectors Scalar Scalar（标量）通常为数值，能够将只有一个时序的Instance vector转换成Scalar。 String 简略字符串值，目前未被应用。 选择器标签选择器查问Prometheus http状态码为400的申请数量。 prometheus_http_requests_total{code="400"} 标签匹配运算符: =：与字符串匹配!=：与字符串不匹配=~：与正则匹配!~：与正则不匹配查问Prometheus http状态码为4xx或5xx并且handler为/api/v1/query的申请数量 prometheus_http_requests_total{code=~"4.*|5.*",handler="/api/v1/query"}外部标签__name__用来匹配指标名称，上面的表达式与上一条等价 {code=~"4.*|5.*",handler="/api/v1/query",__name__="prometheus_http_requests_total"}范畴选择器查问过来5分钟Prometheus健康检查的采样记录。 prometheus_http_requests_total{code="200",handler="/-/healthy"}[5m] 单位：ms、s、m、h、d、w、y 工夫串联：[1h5m]一小时5分钟 工夫偏移通过offset通过offset将工夫倒退5分钟，即查问5分钟之前的数据。 prometheus_http_requests_total{code="200"} offset 5m 同样反对查问range vector prometheus_http_requests_total{code="200"}[3m] offset 5m@修饰符还能够通过@ 间接跳转到某个uinx工夫戳，需开启启动参数--enable-feature=promql-at-modifier prometheus_http_requests_total{code="200"} @ 1646089826运算符Prometheus中的运算符与各类编程语言中的基本一致。 数学运算符Prometheus 中存在以下数学运算符： +（加法）-（减法）*（乘法）/（除法）%（取模）^（幂）两个标量之间的计算 10/3 刹时向量与标量计算，因为计算后值意义与原指标名有差别，Prometheus很贴心的帮咱们移除了指标名称。 prometheus_http_response_size_bytes_sum / 1024 两个刹时向量间的计算，如下计算node的内存使用率 (1 -node_memory_MemAvailable_bytes{job="node",instance="localhost:9100"} / node_memory_MemTotal_bytes{job="node",instance="localhost:9100"})* 100 如果两个刹时向量标签不统一可通过ignoring疏忽多余标签 输出示例： method_code:http_errors:rate5m{method="get", code="500"} 24method_code:http_errors:rate5m{method="post", code="500"} 6method:http_requests:rate5m{method="get"} 600method:http_requests:rate5m{method="post"} 120查问示例： ...

一言难尽的Prometheus监控实际说到TiDB的监控，大家第一工夫想到的就是Prometheus和Grafana，这两个曾经是十分成熟的监控产品了，置信大家都有肯定的理解。那么这里对于Prometheus 和 Grafana 不做过多的介绍，大略就是Prometheus会收集TiDB集群信息，Grafana会调用这些信息生成可视化图标来进行展现。 而作为一名DBA，为TiDB集群保驾护航之时，就少不了这两大工具，无论是日常巡检还是问题排查，咱们都须要关上Grafana看看集群状态，钻研各种指标，一一排查问题所在。 本文次要介绍一次理论我的项目中的Prometheus应用和踩的一些坑，那是真的是坑！如果你尝试对TiDB的Prometheus进自定义开发或是对接其余监控告警零碎等，那么读完这篇文章会对你有很大的帮忙！ 我的项目背景首先谈谈我的项目背景，这次我的项目次要是搭建了一套TiDB的集群，节点十分多，而后对于TiDB集群的监控，公司有本人的要求，因为整个公司不止有一套TiDB集群，还有其余的MySQL，Oracle集群，为了不便公司的数据库治理，对于所有的数据库集群的监控和告警都心愿集成到同一个监控平台和告警平台。 简略的说就是开发了一套自有的监控和告警平台，来治理所有的数据库集群，那么对于TiDB集群，咱们的设计是，依然应用TiDB自带的Prometheus作为集群信息的收集者，而后在自有的监控告警平台上，通过应用PQL来查问Prometheus的数据，进行展现和对接到相应的告警零碎。你能够简略了解成从新开发了一个Grafana和AlertManage。 Prometheus集成到自定义平台TiDB的Prometheus自身就自带一系列告警规定，这些告警规定根本就涵盖了TiDB集群的方方面面，所以咱们能够将这些告警规定间接搬过去。在Prometheus的部署目录，conf文件上面能够找到。 在这些规定中，咱们能够提取出本人想要的一些规定集成到咱们本人的平台上，具体的集成办法能够参考一下： 首先到rule.yaml中找到本人想要集成监控告警项（比方TiDB_server_panic_total，含意是TiDB Server 呈现panic谬误超过一次则告警）获取到PQL，也就是Expr 前面的这一段:，表达式非常容易了解，在5分钟内，如果tidb过程的启动工夫呈现变动，就代表TiDB服务重启过。拜访Prometheus的Api，通过PQL获取到数据，拜访形式就是 http://prometheus_address/api... response = requests.get('http://%s/api/v1/query' % prometheus_address, params={'query': query})获取到的查问后果后，就能够自行对后果进行解决，解决后输入到本人的监控告警平台下面。对于PQL能够通过 http://prometheus_address/graph 先进行调试，对于PQL的语法也比较简单，只有晓得相应的TiDB指标和PQL的根本函数，就能够轻松的查问想要的后果。如果你感觉比拟麻烦，我倡议还是间接应用rule.yaml外面的expr的表达式，而后做一些小的批改就能满足绝大部分场景。 将Prometheus集成到自定义监控告警零碎大略就这么简略，获取后果后如何施展，就看大家本人的业务逻辑和设计了。 一言难尽的那些坑其实整个过程实现难度并不大，最大的难度，可能也只是在于你怎么解决从Prometheus获取到的数据。然而就这么简略的过程中，你也会遇到大量的坑去踩，坑的次要起源在于文档和版本。 我大抵形容一下：咱们都晓得 TiDB 的版本更新是十分快的，所以对于 TiDB 的一些监控指标会随着版本发生变化，然而，TiDB版本的更新速度和监控规定相干代码的跟新速度是不一样的，这里就呈现了两个变动因素，这个时候，咱们就须要查问各种文档，来进行对立，比方TiDB 集群报警规定 | PingCAP Docs，问题又来了，TiDB告警的文档更新的更慢，并且存在一些问题，这个时候你是不是就傻眼了？ 当有三个因素都在变动的时候，想要确认某一件事件堪称是纠结万分，例如我举一个列子tikv_batch_request_snapshot_nums 这个指标。 在文档中，这个指标意思是某个TiKV 的 Coprocessor CPU 使用率超过了 90%，然而当你如果去掉超过90%的条件，单纯想要获取到Coprocessor CPU使用率的时候，你会发现PQL无奈从Prometheus中查问到任何的数据。 起因很简略，因为该PQL中 tikv_thread_cpu_seconds_total 这个指标外面基本就没有name 为 cop 结尾的，也就是你无奈通过这个指标获取到 Coprocessor 的 CPU 使用率，而且不仅仅是文档，就连 Prometheus 外面 rule.yaml 也呈现了同样的谬误，所以在某些版本TiDB集群里的Grafana中你会发现你的 Coprocessor CPU 面板是没有数据的，如下： 那么根本原因是什么？我剖析的是因为在TiDB新版本中，引入了 UnifyReadPool 的概念，也就是将Coprocessor 线程池与 Storage Read Pool 合并起来，那么 Coprocessor CPU 的使用率指标也就同样放到了 UnifyReadPool 外面去了，不在做独自的监控指标。当然，有问题的监控指标还有很多，比方一些弃用了的指标，还有一些改名了的指标，合并或是拆解的指标，大家在应用的过程中，肯定要多进行测试，不然到时候集群出了问题，监控和告警没反馈那就很危险了。 ...

这个问题，如果确定端口是能够telnet通的话，可能是主机名的起因导致的监测失败 wgcloud的agent监测端口机制，默认应用的是： telnet localhost 3306 3306是轻易写的端口号，如果不通，那么可能是localhost无奈应用 咱们在agent配置文件agent/config/application.properties中批改下配置项，如下，把默认的localhost改成agent主机的IP： #端口检测规定，telnet localhost或ip 端口号telnetIp=localhost改好后，重启下agent，察看5分钟，看是否无效

介绍在这篇文章中，我将展现常见基础设施的 Prometheus exporters 列表，这些指标采集器在咱们创立监控时十分有用。我还将提供指向可用于出现数据的 Grafana 仪表盘的链接。 零碎根本信息Linux ServersExporterhttps://github.com/prometheus... Dashboardhttps://grafana.com/grafana/d... Windows ServersExporterhttps://github.com/prometheus... Dashboardhttps://grafana.com/grafana/d... web端服务器Nginx Server收集无关 NGINX 或 NGINX Plus 的信息 Exporterhttps://github.com/nginxinc/n... Dashboardhttps://grafana.com/grafana/d... Apache Server收集无关 Apache 服务相干信息 Exporterhttps://github.com/Lusitaniae... Dashboardhttps://grafana.com/grafana/d... BlackBox Exporter收集HTTP、TCP等信息，有利于监控Web服务的生命周期。 Exporterhttps://github.com/prometheus... Dashboardhttps://grafana.com/grafana/d... SSL info Exporter发送无关用于 Web 服务器的 SSL 证书的信息。实用于监控 SSL 证书的到期日期。 Exporterhttps://github.com/ribbybibby... Dashboardhttps://grafana.com/grafana/d... 数据库服务器MySQL Server收集 MySQL 服务器信息 Exporterhttps://github.com/prometheus... Dashboardhttps://grafana.com/grafana/d... PostgreSQL Server收集 PostgreSQL 服务器信息 Exporterhttps://github.com/prometheus... Dashboardhttps://grafana.com/grafana/d... REDIS收集 REDIS 服务器信息 ...

prometheus的rule有两类： AlertingRule: 告警规定；RecordingRule: 表达式规定，用于产生新的指标；1.整体框架prometheus的rule治理次要在代码目录prometheus/rules/中: rules.Manager在运行时的时候，会读取rules/*.yaml文件，读取出所有的分组rules.Group；为每个rules.Group调配1个goroutine，周期性的执行group下所有的rules；对每个Rule： 若是AlertingRule，则进行eval，若触发告警，则sendAlerts进来；若是RecordingRule，则进行eval，将后果写入TSDB； 如果rules/xxx.yaml文件内容如下： groups:- name: test rules: - expr: | 100 - avg without (cpu, mode) ( rate(node_cpu_seconds_total{job="node-exporter", mode="idle"}[1m]) )*100 record: instance:node_cpu_used_percent:rate1m labels: __type__: "gauge" - alert: Too_Many_Goroutine expr: | go_goroutines > 100 labels: serverity: high annotations: summary: too many goroutines- name: cpu_used rules: - expr: | node_cpu_seconds_total{mode="user", cpu="0"} record: cpu_used_percent labels: cpu: "0"那么，它将产生2个group： group: test，内含1个recodingRule和1个alertingRule；group: cpu_used，内含1个recordingRule；2.规定加载的代码逻辑manager.Update加载规定，并为每个group启动1个goroutine运行规定： // rules/manager.gofunc (m *Manager) Update(interval time.Duration, files []string, externalLabels labels.Labels) error { // 加载规定 groups, errs := m.LoadGroups(interval, externalLabels, files...) var wg sync.WaitGroup for _, newg := range groups { ...... wg.Add(1) go func(newg *Group) { ... go func() { ...... // 运行group内的规定 newg.run(m.opts.Context) }() wg.Done() }(newg) } ...... wg.Wait() m.groups = groups return nil}读取规定的逻辑： ...

scrape模块代码位于prometheus/scrape目录下，负责监控对象的指标拉取。 1.整体框架整体代码框架： 由scrape.Manager治理所有的抓取对象；所有的抓取对象按group分组，每个group是一个job_name；每个group下含多个scrapeTarget，即具体的抓取指标endpoint；对每个指标endpoint，启动一个抓取goroutine，依照interval距离循环的抓取对象的指标； 如果prometheus.yaml中的抓取配置为： scrape_configs: - job_name: "monitor" static_configs: - targets: ['192.168.101.9:11504'] - job_name: 'node-exporter' static_configs: - targets: ['10.21.1.74:9100', '192.168.101.9:9100']那么，抓取对象将按如下构造分组： { "monitor": [ { "Targets": [ { "__address__": "192.168.101.9:11504" } ], "Labels": null, "Source": "0" } ], "node-exporter": [ { "Targets": [ { "__address__": "10.21.1.74:9100" }, { "__address__": "192.168.101.9:9100" } ], "Labels": null, "Source": "0" } ]}2.scrape.Manager的代码逻辑代码入口，其中函数参数中的map[string][]*targetgroup.Group由discover组件传入： // scrape.manager.gofunc (m *Manager) Run(tsets <-chan map[string][]*targetgroup.Group) error { go m.reloader() for { select { case ts := <-tsets: m.updateTsets(ts) select { case m.triggerReload <- struct{}{}: //发送数据到channel: m.triggerReload default: } case <-m.graceShut: return nil } }}// 期待channel:m.triggerReload上的数据，而后进行reload// 热加载func (m *Manager) reloader() { ticker := time.NewTicker(5 * time.Second) defer ticker.Stop() for { select { case <-m.graceShut: return case <-ticker.C: select { case <-m.triggerReload: m.reload() case <-m.graceShut: return } } }}具体的初始化动作在reload()中，对每个targetGroup： ...

prometheus中的指标t/v数据保留在block/chunks下，label数据保留在block/index下。 对于t/v数据，prometheus采纳Facebook Gorilla论文的压缩形式： timestamp: delta-of-delta形式压缩时序点的工夫值；value: xor形式压缩时序点的value值；依照上述压缩形式，能够将一个16byte的时序点压缩成1.37byte，压缩率十分高。 时序点t/v的压缩1)timestamp压缩在时序上，相邻两个点的工夫戳的差值个别是固定的，若隔60s pull一次，那么timestamp差值个别都是60s，比方 p1: 10:00:00，p2: 10:01:00，p3: 10:01:59，p4：10:03:00，p5：10:04:00，p6：10:05:00工夫戳的差值为：60s，59s，61s，60s，60s；Gorilla论文采纳delta-of-delta形式压缩timestamp： 第一个时序点的工夫戳t0，被残缺存储起来；第二个时序点的工夫戳t1，存储delta=t1-t0；对后续的工夫戳tn，首先计算dod值：delta=(tn - tn-1) - (tn-1 - tn-2)； 如果dod=0，则应用1bit=“0”存储该工夫戳；如果dod=[-8191, 8192]，则先存入“10”作为标识，再用14bit存储该dod值；如果dod=[-65535, 65536]，则先存入“110”作为标识，再用17bit存储该dod值；如果dod=[-524287, 524288]，则先存入“1110”作为标识，再用20bit存储该dod值；如果dod>524288，则先存入“1111”作为标识，再用64bit存储该dod值；在实践中发现，95%的timestamp可能依照dod=0的情景进行存储。 2)value压缩Gorilla论文对时序点value的压缩基于： 相邻时序点的value值不会产生显著变动；value大多是浮点数，当两个value十分靠近的时候，这两个浮点数的符号位、指数位和尾数局部的前几bit都是雷同的；value值的压缩算法： 第一个时序点的value值不压缩，间接保留；从第二个点开始，将其value与上一个value进行XOR运算； 若XOR运算后果为“0”，则示意前后两个value雷同，仅存入1bit的“0”值即可；否则，存入1bit值“1”； 若XOR后果中非0的局部蕴含在前一个XOR后果中，那么再写入1bit值“0”，而后存入XOR中非0的局部；否则，写入1bit值“1”，用5bit存入XOR中前值0的个数，6bit存入两头非0的长度，最初再存入两头的非0位；数据显示，大概有60%的value值仅用1bit存储，有30%的value值落入“10”范畴，残余10%的value值落入“11”范畴。 3)压缩示例输出时序序列值 10:00:00 3.110:01:01 3.210:02:00 3.010:02:59 3.210:03:00 3.1那么将存入 10:00:00 3.161 3.2 xor 3.1-2(59-61) 3.0 xor 3.20(59-59) 3.2 xor 3.02(61-59) 3.1 xor 3.2写入t/v的源码剖析xorAppender负责写入t/v的值，t=int64，v=float64 // tsdb/chunkenc/xor.gofunc (a *xorAppender) Append(t int64, v float64) { var tDelta uint64 num := binary.BigEndian.Uint16(a.b.bytes()) //第一个点，残缺记录t1和v1的值 if num == 0 { buf := make([]byte, binary.MaxVarintLen64) for _, b := range buf[:binary.PutVarint(buf, t)] { a.b.writeByte(b) //写入t1的值 } a.b.writeBits(math.Float64bits(v), 64) //写入v1的值 } else if num == 1 { //第二个点 tDelta = uint64(t - a.t) buf := make([]byte, binary.MaxVarintLen64) for _, b := range buf[:binary.PutUvarint(buf, tDelta)] { a.b.writeByte(b) //写入tDeleta=t2-t1 } a.writeVDelta(v) //写入v2^v1的值 } else { //第三个点及当前的点 tDelta = uint64(t - a.t) dod := int64(tDelta - a.tDelta) //计算dod // Gorilla has a max resolution of seconds, Prometheus milliseconds. // Thus we use higher value range steps with larger bit size. switch { case dod == 0: a.b.writeBit(zero) //写入0 case bitRange(dod, 14): //dod=[-8191,8192],先存入10作为标识，再用14bit存储dod的值 a.b.writeBits(0x02, 2) // '10' a.b.writeBits(uint64(dod), 14) case bitRange(dod, 17): //dod=[-65535,65536],先存入110作为标识，再用17bit存储该dod的值 a.b.writeBits(0x06, 3) // '110' a.b.writeBits(uint64(dod), 17) case bitRange(dod, 20): //dod=[-524287,524288],先存入1110作为标识，再用20bit存储该dod的值 a.b.writeBits(0x0e, 4) // '1110' a.b.writeBits(uint64(dod), 20) default: //dod>524288,先存入1111作为标识，再用64bit存储该dod的值 a.b.writeBits(0x0f, 4) // '1111' a.b.writeBits(uint64(dod), 64) } a.writeVDelta(v) //写入vn^vn-1 } a.t = t //写入的最初一个t a.v = v //写入的最初一个v binary.BigEndian.PutUint16(a.b.bytes(), num+1) a.tDelta = tDelta //写入的最初一个tDelta}再看一下应用xor写入VDelta的源码： ...

倒排索引prometheus tsdb中的index以倒排索引的形式组织： 给每个series调配1个id 用seriesId查问series，这是前向索引，查问工夫复杂度=O(1);结构label的索引 若seriesId={2,5,10,29}都含有label: app='nginx';那么，对于app='nginx", {2,5,10,29}就是它的倒排索引；举例来说，对于seriesId=5： // seriesId=5{ __name__ = "request_total", pod="nginx-1", path="/api/v1/status", status="200", method="GET"}那么，对于： status="200": 它的倒排索引={1,2,5,......}method="GET": 它的倒排索引={2,3,4,5,6,9,......}整体源码框架内存中，应用headIndexReader，将内存block中的label组织成倒排索引；block中，应用blockIndexReader，读取block目录中的index文件，将其中的label组织倒排索引；headIndexReader和blockIndexReader均继承自indexReader，提供了： LabelNames(): 查问所有的Label key；LabelValues(name)：查问label key对应的values；Postings()：查问label key/value对应的[]seriesId；blockQuerier依据不同的block，结构不同的indexReader来读取Label索引；blockQuerier应用Postings()失去[]seriesId后，再应用chunkReader最终读取到时序数据(t/v)。 内存中的倒排索引数据结构： // tsdb/index/postings.gotype MemPostings struct { mtx sync.RWMutex // label key --> []labelValue values map[string]stringset // Label names to possible values. // map[labelName]map[labelValue]postingsList // labelName --> labelValue --> []posting m map[string]map[string][]uint64 ordered bool}// tsdb/head.go// Head handles reads and writes of time series data within a time window.type Head struct { ...... postings *index.MemPostings // Postings lists for terms.}1-内存倒排索引的插入入口是插入时序数据: ...

什么是Head block?v2.19之前，最近2hour的指标数据存储在memory。v2.19引入Head block，最近的指标数据存储在memory，当head block满时，将数据存储到disk并通过mmap援用它。Head block由若干个chunk组成，head chunk是memChunk，接管时序写入。 写入时序数据时，当写入head chunk和wal后，就返回写入胜利。 什么是mmap?一般文件的读写： 文件先读入kernal space；文件内容被copy值user space；用户操作文件内容； mmap形式下文件的读写： 文件被map到kernal space后，用户空间就能够读写；相比一般文件读写，缩小了一次零碎调用和一次文件copy；在多过程以只读形式共享同一个文件的场景下，将节俭大量的内存； Head block的生命周期1）初始状态时序数据被写入head chunk和wal后，返回写入胜利。 2）head chunk被写满headChunk对每个series，保留最近的120个点的数据； const samplesPerChunk = 120若scrape interval=15s的话，headChunk会存储30min的指标数据；head chunk被写满后，生成新的head chunk承受指标写入，如下图所示： 同时，原head chunk被flush到disk，并mmap援用它： 3）mmap的chunks满mmap的chunks达到chunkRange(2hour)的3/2时，如下图所示： mmap中chunkRange(2hour)的数据将被长久化到block，同时生成checkpoint & 清理wal日志。 Head block的源码剖析 每个memSeries构造，蕴含一个headChunk，其保留1个series在mem中的数据： // prometheus/tsdb/head.go// memSeries is the in-memory representation of a series.type memSeries struct { ... ref uint64 lset labels.Labels ... headChunk *memChunk}type memChunk struct { chunk chunkenc.Chunk minTime, maxTime int64}向memSeries增加指标数据： ...

一、参考时序数据库学习系列目录 ——更新ing 实战 Prometheus 搭建监控零碎

node_exporter以Pod模式部署，它监控宿主机的CPU、Mem、Disk等监控指标。Pod隔离的运行环境，会对宿主机的监控造成烦扰，故尽量与宿主机share namespace，通常配置 hostNetwork: truehostPID: true这里重点关注监控宿主机Disk分区使用率的过程。 node_exporter运行的用户Dockerfile中，以USER指定运行用户，若未指定，则为root；能够看出，node_exporter默认的用户为: nobody，其用户Id=65534 ......COPY ./node_exporter /bin/node_exporterEXPOSE 9100USER nobodyENTRYPOINT [ "/bin/node_exporter" ]node_exporter的daemonset.yaml中，配置的securityContext为： ...... hostNetwork: true hostPID: true securityContext: runAsNonRoot: true runAsUser: 65534......这里runAsNonRoot的配置： 若runAsNonRoot未配置，则应用镜像内的默认用户；若配置了runAsNonRoot，则应用指定的用户执行容器过程；# kubectl explain daemonset.spec.template.spec.securityContext.runAsNonRootKIND: DaemonSetVERSION: apps/v1FIELD: runAsNonRoot <boolean>DESCRIPTION: Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.能够看出，node_exporter指定以非root用户(nobody)执行node_exporter。 ...

龙芯CPU的架构有Mips架构和loong64架构(如龙芯3C5000L)。 对于Mips架构，能够应用golang的穿插编译，指定GOARCH=mips64le编译出prometheus的可执行文件。 对于loong64架构，golang的穿插编译尚不反对，通常须要在龙芯的OS上装置golang，而后将prometheus的git repoc拷贝过来，而后本机编译。 # go versiongo version go1.15.6 linux/loong64本文探讨loong64架构下，prometheus二进制编译和镜像构建的办法。 GOPROXY龙芯loong64提供了GOPROXY，外面蕴含了罕用的依赖，然而不全： go env -w GOPROXY=http://goproxy.loongnix.cn:3000,direct配置direct后，当GOPROXY没有找到依赖时，会间接去源地址拉取。 编译办法在开发机器中，应用go mod vendor，将依赖搁置vendor目录，而后将整个prometheus我的项目(含vendor)拷贝至龙芯机器，再到龙芯机器上应用vendor进行本地编译(go build -mod vendor)。 在编译过程中，通常会报vendor目录下golang.org/x/sys、golang.org/x/net库失败，此时须要将龙芯机器本地的golang.org/x/sys和golang.org/x/net包替换到vendor目录即可。 prometheus编译过程prometheus二进制构建，依赖构建工具promu，故要先build进去promu。 promu构建过程： 开发机器：git clone github.com/prometheus/promu开发机器：go mod vendor将我的项目目录promu拷贝至龙芯机器；龙芯机器：make build生成promuprometheus构建过程： 开发机器：git clone github.com/prometheus/prometheus开发机器：go mod vendor将我的项目目录prometheus拷贝至龙芯机器；龙芯机器：将/root/go/pkg/mod/golang.org/x/sys和x/net，替换vendor目录下的golang.org/x/sys和x/net；将上一步构建进去的promu可执行文件，拷贝至prometheus我的项目根目录；龙芯机器：批改Dockerfile.common，应用本地的promu工具 ...$(PROMU): #$(eval PROMU_TMP := $(shell mktemp -d)) #curl -s -L $(PROMU_URL) | tar -xvzf - -C $(PROMU_TMP) #mkdir -p $(FIRST_GOPATH)/bin #cp $(PROMU_TMP)/promu-$(PROMU_VERSION).$(GO_BUILD_PLATFORM)/promu $(FIRST_GOPATH)/bin/promu #rm -r $(PROMU_TMP) cp ./promu $(FIRST_GOPATH)/bin/promu...龙芯机器： vendor/github.com/prometheus/procfs目录，减少cpuinfo_loong64.go文件// +build linuxpackage procfsvar parseCPUInfo = parseCPUInfoLoong64vendor/github.com/prometheus/procfs目录，批改cpuinfo.go文件，减少上面的内容 scanner := bufio.NewScanner(bytes.NewReader(info)) // find the first "processor" line firstLine := firstNonEmptyLine(scanner) if !strings.HasPrefix(firstLine, "system type") || !strings.Contains(firstLine, ":") { return nil, errors.New("invalid cpuinfo file: " + firstLine) } field := strings.SplitN(firstLine, ": ", 2) cpuinfo := []CPUInfo{} systemType := field[1] for scanner.Scan() { line := scanner.Text() if strings.TrimSpace(line) == "" { break } } i := 0 for scanner.Scan() { line := scanner.Text() if !strings.Contains(line, ":") { continue } field := strings.SplitN(line, ": ", 2) switch strings.TrimSpace(field[0]) { case "processor": v, err := strconv.ParseUint(field[1], 0, 32) if err != nil { return nil, err } i = int(v) cpuinfo = append(cpuinfo, CPUInfo{}) // start of the next processor cpuinfo[i].Processor = uint(v) cpuinfo[i].VendorID = systemType case "cpu family": cpuinfo[i].CPUFamily = field[1] case "BogoMIPS": v, err := strconv.ParseFloat(field[1], 64) if err != nil { return nil, err } cpuinfo[i].BogoMips = v } } return cpuinfo, nil}龙芯机器：在prometheus我的项目根目录，执行make build，编译出prometheu二进制文件prometheus镜像Dockfile中根底镜像为quay.io/prometheus/busybox，须要替换为龙芯下的busybox: harbor.loongnix.cn/mirrorloongsoncontainers/busybox，龙芯harbor的拜访办法参考2。 ...

什么是checkpoint?checkout是wal中一个目录： # ls -alh-rw-r--r-- 1 root root 11M 12月 14 17:00 00000999-rw-r--r-- 1 root root 11M 12月 14 19:00 00001000-rw-r--r-- 1 root root 2.1M 12月 14 19:22 00001001drwxr-xr-x 2 root root 22 12月 14 19:00 checkpoint.00000998# ls -alh checkpoint.00000998/-rw-r--r-- 1 root root 384K 12月 14 19:00 00000000prometheus写入指标时，将指标写入内存和wal，而后返回写入胜利。wal保障了prometheus crash-free的能力。 prometheus内存中缓存了最近2hour的指标数据，而后2hour的数据被压缩成block，存储在硬盘上；此时这2hour的WAL数据就能够被删除了。 checkpoint就是用来清理wal日志的。 当2hour的内存数据被压缩成block存储至硬盘时： 该工夫之前的wal日志就能够删除了；因为曾经长久化到硬盘了，即便prometheus实例宕掉，也不会丢数据；此时，prometheus生成一个checkpoint，进行wal日志的清理；checkpoint的整体流程假如之前checkpoint为checkpoint.m，在segment n处，进行block的存储，此时checkpoint的流程如下： 读取文件： checkpoint.m目录下所有文件segment m+1~n之间的所有文件遍历文件内容，将block之后的series和samples数据，写入checkpoint.n目录； checkpoint生成之后，会删除以下文件： 删除segment.n之前的segment；删除之前的checkpoint：< n（如checkpoint.m）；checkpoint的代码剖析入口代码： // tsdb/head.go// Truncate removes old data before mint from the head.func (h *Head) Truncate(mint int64) (err error) { .... // 生成新的checkpoint wal.Checkpoint(h.logger, h.wal, first, last, keep, mint) // 将segment.n之前的segment删掉 err := h.wal.Truncate(last + 1) // 将之前的checkpoint删掉: < last err := wal.DeleteCheckpoints(h.wal.Dir(), last)}checkpoint的过程代码： ...

prometheus-operator v0.43之前我的项目中应用的prometheus-operator始终是v0.40.0版本，部署进去的prometheus pod有3个container: prometheus: v2.20.0config-reloader: v0.40.0，sidecar，负责config文件的自动更新；rule-reloader: v0.0.1，sidecar，负责rules文件的自动更新；prometheus-operator的配置自动更新原理，参考之前的文章： https://segmentfault.com/a/11...https://segmentfault.com/a/11...https://segmentfault.com/a/11...prometheus-operator v0.43(含)之后部署进去的prometheus pod只有2个container: prometheus: v2.××.×config_reloader: v0.4×.×，sidecar，负责config和rules文件的自动更新；之前版本的rule-reloader由https://github.com/jimmidyson...实现，本次更新中将其废除，对立由config_reloader实现。 参考：1.https://github.com/prometheus...

label_replace和label_join是PromQL的预置函数，反对将label的value进行截取和拼接，生成新的label。值得注意的是，它们不扭转源label的name及value，仅生成新label。 label_replace反对对某个label的值进行正则匹配，截取出某些值，生成新的label。 label_replace(v instant-vector, dst_label string, replacement string, src_label string, regex string)原始指标： node_network_transmit_bytes_total{container="kube-rbac-proxy",device="eth0",endpoint="https",instance="k8s-v22-1",job="node-exporter",namespace="monitoring",pod="node-exporter-nvj7r",service="node-exporter"} 9457895219通过label_replace将device==>iface label_replace(node_network_transmit_bytes_total{job="node-exporter", device="eth0"}, "iface", "$1", "device", "(.+)")后果： node_network_transmit_bytes_total{container="kube-rbac-proxy",device="eth0",endpoint="https",iface="eth0",instance="k8s-v22-1",job="node-exporter",namespace="monitoring",pod="node-exporter-nvj7r",service="node-exporter"} 9465702581label_join反对将某些label拼接起来，生成新的label。 label_join(v instant-vector, dst_label string, separator string, src_label_1 string, src_label_2 string, ...)原始指标： kubelet_node_name{endpoint="https-metrics",instance="178.104.163.63:10250",job="kubelet",metrics_path="/metrics",namespace="kube-system",node="k8s-v22-1",service="kubelet"} 1通过label_join将instance和metrics_path拼接起来，生成新label: metrics_url label_join(kubelet_node_name, "metrics_url", "", "instance", "metrics_path")后果： kubelet_node_name{endpoint="https-metrics",instance="178.104.163.63:10250",job="kubelet",metrics_path="/metrics",metrics_url="178.104.163.63:10250/metrics",namespace="kube-system",node="k8s-v22-1",service="kubelet"} 1参考1.prometheus-book

大家好，我是张晋涛。 Prometheus 简直曾经成为了云原生时代下监控选型的事实标准，它也是第二个从 CNCF 毕业的我的项目。 以后，Prometheus 简直能够满足各种场景/服务的监控需要。我之前有写过一些文章介绍过 Prometheus 及其生态，本篇咱们将聚焦于 Prometheus 最新版本中公布的 Agent 模式，对于与此主题无关的一些概念或者用法，我会粗略带过。 拉模式（Pull）和 推模式（Push）家喻户晓，Prometheus 是一种拉模式（Pull）的监控零碎，这不同于传统的基于推模式（Push）的监控零碎。 什么是拉模式（Pull）呢？ 待监控的服务本身或者通过一些 exporter 裸露进去一些 metrics 指标的接口，由 Prometheus 去被动的定时进行抓取/采集，这就是拉模式（Pull）。即由监控零碎被动的去拉（Pull）指标的 metrics。 与之绝对应的就是推模式（Push）了。 由应用程序被动将本身的一些 metrics 指标进行上报，监控零碎再进行绝对应的解决。如果对于某些应用程序的监控想要应用推模式（Push），比方：不易实现 metrics 接口等起因，能够思考应用 Pushgateway 来实现。 对于拉模式（Pull）和推模式（Push）到底哪种更好的探讨始终都在持续，有趣味的小伙伴能够自行搜寻下。 这里次要是聚焦于单个 Prometheus 和应用服务之间交互的手形式。本篇咱们从更下层的角度或者全局角度来看看以后 Prometheus 是如何做 HA、 长久化和集群的。 Prometheus HA/长久化/集群的计划在大规模生产环境中应用时，很少有零碎中仅有一个单实例 Prometheus 存在的状况呈现。无论从高可用、数据长久化还是从为用户提供更易用的全局视图来思考，运行多个 Prometheus 实例的状况就很常见了。 目前 Prometheus 次要有三种方法来将多个 Prometheus 实例的数据进行聚合，并给用户提供一个对立的全局视图。 联邦（Federation）：是最晚期的 Prometheus 内置的数据聚合计划。这种计划下，能够应用某个核心 Prometheus 实例从叶子 Prometheus 实例上进行指标的抓取。这种计划下能够保留 metrics 本来的工夫戳，整体也比较简单；Prometheus Remote Read（近程读）：能够反对从近程的存储中读取原始 metrics，留神：这里的近程存储能够有多种抉择。当读取完数据后，便可对它们进行聚合，并展示给用户了；Prometheus Remote Write（近程写）：能够反对将 Prometheus 采集到 metrics 等写到近程存储中。用户在应用的时候，间接从远端存储中读取数据，并提供全局视图等；Prometheus Agent 模式Prometheus Agent 是自 Prometheus v2.32.0 开始将会提供的一项性能，它次要是采纳上文中提到的 Prometheus Remote Write 的形式，将启用了 Agent 模式的 Prometheus 实例的数据写入到近程存储中。并借助近程存储来提供一个全局视图。 ...

sidecar负责定期向近程存储发送本地prometheus的block数据，其运行参数： /bin/thanos sidecar --prometheus.url=http://localhost:9090/ --tsdb.path=/prometheus --grpc-address=[$(POD_IP)]:10901 --http-address=[$(POD_IP)]:10902 --objstore.config=$(OBJSTORE_CONFIG)其中环境变量： Environment: POD_IP: (v1:status.podIP) OBJSTORE_CONFIG: <set to the key 'thanos.yaml' in secret 'thanos-objstore-config'> Optional: falsePOD_IP是downwareAPI拿到的，OBJSTORE_CONFIG是secret保留的thanos.yaml内容，配置了s3近程存储minio： type: s3config: bucket: thanos endpoint: minio.minio.svc.cluster.local:9000 access_key: minio secret_key: minio insecure: true signature_version2: falsesidecar源码入口先找sidecar的入口： func main() { ...... app := extkingpin.NewApp(kingpin.New(filepath.Base(os.Args[0]), "A block storage based long-term storage for Prometheus.").Version(version.Print("thanos"))) registerSidecar(app) ....... var g run.Group ...... if err := g.Run(); err != nil { // Use %+v for github.com/pkg/errors error to print with stack. level.Error(logger).Log("err", fmt.Sprintf("%+v", errors.Wrapf(err, "%s command failed", cmd))) os.Exit(1) }}registerSidecar()注册sidecar服务： ...

随着公司规模的扩充，本来的人工运维，曾经扛不住了，几百台服务器、几十个集群、几十个数据库，曾经不是人工能看的过去了，上线Prometheus+Grafana+AlertManager计划，能做到定点解决问题，不须要再挨个去看，约了很多工夫。 从产品体验的角度来看，原服务，是客户发现问题咱们去解决问题，这样的用户体验是很差的，然而通过Prometheus+Blackbox-exporter+AlertManager计划，咱们能够对代表性接口进行检测，依据接口返回的申请工夫等参数评估，当初服务器的整体状态。 总体来说Prometheus能够解决运维层面很多货色，也是DevOps必须的一项，倡议大家进行深刻理解，学会怎么变懒。 Prometheus介绍 Prometheus是开源系统监控工具包，它会将工夫戳和数据联合为时序数据存储起来，大家联合官网文档进行享受。Prometheus官网文档 联合docker运行 docker run -d -p 9090:9090 --name prometheus prom/prometheus性能介绍 运行实现后，浏览器拜访127.0.0.1:9090拜访Prometheus的后盾Alerts：正告规定Graph：图形界面，输出语法，点击执行，通过图形或输入进行查看 Status->Runtime&Build Info：蕴含了缓存和编译的详细信息Status->Configuration：等同Prometheus下的/etc/prometheus/prometheus.yml里的内容。Status->Rules：告警规定，联合AlertManager应用Status->Targets：指标，展现你在配置文件中要监控的所有指标Status->服务发现留神 1.Prometheus是时序数据，所以对工夫要求很严格，如果Prometheus服务没问题，然而图形死活不出数据，那就要思考所在的服务器工夫是否正确了，Centos配置工夫办法 yum install -y ntpntpdate ntp.api.bzdate

prometheus-operatorCRDs:Prometheus:定义了所需的 Prometheus 部署Alertmanager定义了所需的 Alertmanager 部署ThanosRuler定义了所需的 Thanos Ruler 部署ServiceMonitor以申明形式指定应如何监控 Kubernetes 服务组。Operator 依据 API 服务器中对象的以后状态主动生成 Prometheus 抓取配置Podmonitor以申明形式指定应如何监督 Pod 组。Operator 依据 API 服务器中对象的以后状态主动生成 Prometheus 抓取配置Probe以申明形式指定应如何监督入口组或动态指标组。Operator 依据定义主动生成 Prometheus 抓取配置PrometheusRule定义了一组所需的 Prometheus 警报和/或记录规定。Operator 生成一个规定文件，可供 Prometheus 实例应用AlertmanagerConfig以申明形式指定 Alertmanager 配置的子局部，容许将警报路由到自定义接收器，并设置禁止规定 https://github.com/prometheus... 监控配置对于如何部署,如何根底配置能够查看官网文档 Configuration | Prometheus Kubernetes内利用监控配置利用增加相应metric(波及开发内容不做过多解说,我司我的项目为java开发,采纳micrometer git地址:https://github.com/micrometer...) 次要采纳podmonitor配置主动发现(https://github.com/prometheus...) apiVersion: monitoring.coreos.com/v1kind: PodMonitormetadata: labels: mill-app: appmonitor name: appmonitorspec:## 配置全局namespace监听## 留神:如需配置全namespace监听,须要配置相应RBAC权限 namespaceSelector: any: true podMetricsEndpoints: - interval: 10s relabelings: - action: replace regex: (.+) sourceLabels:## 配置标签解决 - __meta_kubernetes_pod_annotation_prometheus_io_path targetLabel: __metrics_path__ - action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 sourceLabels: - __address__ - __meta_kubernetes_pod_annotation_prometheus_io_port targetLabel: __address__ scheme: http selector: matchLabels: mill-monitor: app# 要害配置须要发现的标签配置利用deployment  ...

问题假如有两个不同的metric，有雷同的tag，须要将它们的值进行sum。 metricA: metricA{__type__="gauge",instance="127.0.0.1:9999",job="my-test",node="node1"} 0metricA{__type__="gauge",instance="127.0.0.1:9999",job="my-test",node="node2"} 0metricA{__type__="gauge",instance="127.0.0.1:9999",job="my-test",node="node3"} 0metricB: metricB{__type__="gauge",instance="127.0.0.1:9999",job="my-test",node="node2"} 33metricB{__type__="gauge",instance="127.0.0.1:9999",job="my-test",node="node3"} 44答案PromQL求和： sum by (node) ({__name__=~"metricA|metricB"})后果： {node="node1"} 0{node="node2"} 33{node="node3"} 44原理PromQL中应用了__name__标签，实际上它也是tag的一部分，比方metricB： metricB{__type__="gauge",instance="127.0.0.1:9999",job="my-test",node="node2"} 33//该序列值等价于{__name__="metricB",__type__="gauge",instance="127.0.0.1:9999",job="my-test",node="node2"} 33 这样metricA和metricB对立变成领有雷同tag的metric，能够对它们进行sum等操作。

本文首发于泊浮目标简书:https://www.jianshu.com/u/204...版本日期备注1.02021.10.19文章首发0. 背景题目来源于InfluxDB对于它们的存储引擎诞生的背景介绍： The workload of time series data is quite different from normal database workloads. There are a number of factors that conspire to make it very difficult to get it to scale and perform well:- Billions of individual data points- High write throughput- High read throughput- Large deletes to free up disk space- Mostly an insert/append workload, very few updatesThe first and most obvious problem is one of scale. In DevOps, for instance, you can collect hundreds of millions or billions of unique data points every day.To prove out the numbers, let’s say we have 200 VMs or servers running, with each server collecting an average of 100 measurements every 10 seconds. Given there are 86,400 seconds in a day, a single measurement will generate 8,640 points in a day, per server. That gives us a total of 200 * 100 * 8,640 = 172,800,000 individual data points per day. We find similar or larger numbers in sensor data use cases.最近负责了产品中一部分的监控事宜。我想到时序数据库的对于RT和IOPS的要求应该很高，因而想看看它外部是怎么实现的——会不会和我意识的Kafka、HBase很像。 ...

创立利用咱们首先从一个最简略的 Go 应用程序开始，在端口 8080 的 /metrics 端点上裸露客户端库的默认注册表，临时还没有跟踪任何其余自定义的监控指标。 先创立一个名为 instrument-demo 的目录，在该目录上面初始化我的项目： $ mkdir instrument-demo && cd instrument-demo $ go mod init github.com/cnych/instrument-demo下面的命令会在 instrument-demo 目录上面生成一个 go.mod 文件，在同目录上面新建一个 main.go 的入口文件，内容如下所示： package mainimport ( "net/http" "github.com/prometheus/client_golang/prometheus/promhttp")func main() { // Serve the default Prometheus metrics registry over HTTP on /metrics. http.Handle("/metrics", promhttp.Handler()) http.ListenAndServe(":8080", nil)}而后执行上面的命令下载 Prometheus 客户端库依赖： $ export GOPROXY="https://goproxy.cn"$ go mod tidygo: finding module for package github.com/prometheus/client_golang/prometheus/promhttpgo: found github.com/prometheus/client_golang/prometheus/promhttp in github.com/prometheus/client_golang v1.11.0go: downloading google.golang.org/protobuf v1.26.0-rc.1而后间接执行 go run 命令启动服务： ...

论断rate与irate都能够计算counter的变化率。区别： rate计算指定工夫范畴内：增量/工夫范畴；irate计算指定工夫范畴内：最近两个点的增量/最近两个点的时间差；场景： irate适宜计算疾速变动的counter，它能够反映出counter的疾速变动；rate适宜计算迟缓变动的counter，它用平均值将峰值削平了(长尾效应)；rate()函数详解计算demo_api_request_duration_seconds_count最近1min的每秒变化率： rate(demo_api_request_duration_seconds_count[1m])计算方法： 取工夫范畴内的firstValue和lastValue；变化率 = (lastValue - firstValue) / Range； 若要计算一段时间内的后果： 对每个数据点，计算(value - valueBeforeRange)/range；最终失去一串数据，绘制变化率图形； 当抓取指标的过程重启时，counter可能会重置为0，rate()认为指标值只有缩小了就认为被重置了，而后它会主动进行调整。 rate()源码剖析//promql/functions.go// FunctionCalls is a list of all functions supported by PromQL, including their types.var FunctionCalls = map[string]FunctionCall{ ...... "rate": funcRate,}// === rate(node parser.ValueTypeMatrix) Vector ===func funcRate(vals []parser.Value, args parser.Expressions, enh *EvalNodeHelper) Vector { return extrapolatedRate(vals, args, enh, true, true)}具体计算过程：(略去了主动调整的逻辑) func extrapolatedRate(vals []parser.Value, args parser.Expressions, enh *EvalNodeHelper, isCounter bool, isRate bool) Vector { ms := args[0].(*parser.MatrixSelector) var ( samples = vals[0].(Matrix)[0] lastValue float64 ) for _, sample := range samples.Points { ...... lastValue = sample.V } resultValue := lastValue - samples.Points[0].V if isRate { resultValue = resultValue / ms.Range.Seconds() } ......}irate()函数详解应用rate计算疾速变动的样本均匀增长率时，容易陷入长尾问题，因为它用平均值将峰值削平了，无奈反映工夫窗口内样本数据的疾速变动。与rate相似，irate同样能够计算counter的均匀增长率，但其反映出的是刹时增长率。irate计算增长率时，应用指定工夫范畴内的最初两个样本数据： ...

prometheus配置告警表达式，定期检查是否触发阈值，若触发阈值，则通过HTTP发送告警给alertManager。 # cat node_alerts.ymlgroups:- name: cpu_alerts rules: - alert: CPUAlert expr: 100 - avg(irate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance) * 100 > 60 for: 3m labels: severity: warning annotations: summary: High Node CPUprometheus告警状态告警有三种状态： 初始触发阈值，生成alert并置alert状态=pending；当该alert在pending维持肯定工夫(如for 3m)，alert状态=Firing；prometheus通过HTTP POST发送alert给alertManager；当alert不再触发阈值，则alert状态=Inactive； prometheus告警断定首先，用告警表达式查问最新的数据，若查问到后果，则阐明触发了阈值，生成新的alert对象。而后，将本次触发阈值的alert与以后active的alert列表进行比对，依据不同的场景治理alert的生命周期。 治理alert生命周期的过程： 原来没有alert，本次合乎阈值： 新建一个alert对象，状态=pending，放入r.active数组；原来有alert=pending，本次合乎阈值： 没有达到holdDuration：放弃不变；达到holdDuration：更新状态=Firing， 触发工夫fireAt=ts；原来有alert=pending，本次不合乎阈值： 将其从r.active中删除；alert状态批改为Inacvie，ResolvedAt=ts:原来有alert=firing，本次合乎阈值： 放弃不变；原来有alert=firing，本次不合乎阈值： alert状态=Inactive，ResolvedAt=ts；若resolveAt已过15min，那么将其从r.active中删除；(便于alertmanager判断其复原)//rules/alerting.gofunc (r *AlertingRule) Eval(ctx context.Context, ts time.Time, query QueryFunc, externalURL *url.URL) (promql.Vector, error) { res, err := query(ctx, r.vector.String(), ts) //用告警表达式去查问数据，若查问到后果，则触发了阈值 // 本次触发的告警lables.hash()汇合 resultFPs := map[uint64]struct{}{} var vec promql.Vector var alerts = make(map[uint64]*Alert, len(res)) for _, smpl := range res { ...... lbs := lb.Labels() h := lbs.Hash() resultFPs[h] = struct{}{} alerts[h] = &Alert{ //生成告警对象 Labels: lbs, Annotations: annotations, ActiveAt: ts, State: StatePending, //触发了pending Value: smpl.V, } } for h, a := range alerts { // 曾经是active，更新value和annotations if alert, ok := r.active[h]; ok && alert.State != StateInactive { alert.Value = a.Value alert.Annotations = a.Annotations continue } r.active[h] = a // []active寄存所有pending&Firing的告警 } // Check if any pending alerts should be removed or fire now. Write out alert timeseries. for fp, a := range r.active { // 针对之前已有的告警，当初不再满足阈值了 if _, ok := resultFPs[fp]; !ok { // If the alert was previously firing, keep it around for a given // retention time so it is reported as resolved to the AlertManager. if a.State == StatePending || (!a.ResolvedAt.IsZero() && ts.Sub(a.ResolvedAt) > resolvedRetention) { // resolvedRetention=15min delete(r.active, fp) } // 不再触发阈值了，将其state批改为Inactive，ResolvedAt有值 if a.State != StateInactive { a.State = StateInactive a.ResolvedAt = ts } continue } // 针对之前的pending，当初holdDuration已到，更新其状态为Firing if a.State == StatePending && ts.Sub(a.ActiveAt) >= r.holdDuration { a.State = StateFiring a.FiredAt = ts } } return vec, nil}这里有个特地的中央：原来Firing的告警，本次不再触发阈值，那么它将变成Inactive，同时alert.ResolvedAt=now()。同时，该alert对象要等resolvedRetention(15min)后，才从r.actvie[]中删除，依照正文的说法： ...

prometheus拉取target的metrics时，都是错开工夫别离拉取的，这样有以下益处： 防止prometheus实例启动太多的goroutine同时拉取；多prometheus实例拉取同一个target时，防止同时拉取对target造成流量压力；单prometheus实例内的不同target单实例内的不同target，不是在某个时刻一起拉取，而是错开工夫别离拉取。比方scrape_interval=30s，不同target的拉取工夫如下： job=prometheus：20秒、50秒拉取；job=node-exporter：04秒、34秒拉取；job=pvc-test：07秒、37秒拉取；> select * from up where job='prometheus' order by time desc limit 5;name: uptime __name__ __type__ instance job value---- -------- -------- -------- --- -----2021-09-24T05:52:20.665Z up gauge localhost:9090 prometheus 12021-09-24T05:51:50.665Z up gauge localhost:9090 prometheus 12021-09-24T05:51:20.665Z up gauge localhost:9090 prometheus 12021-09-24T05:50:50.665Z up gauge localhost:9090 prometheus 12021-09-24T05:50:20.665Z up gauge localhost:9090 prometheus 1>> select * from up where job='node-exporter' order by time desc limit 5;name: uptime __name__ __type__ instance job value---- -------- -------- -------- --- -----2021-09-24T05:52:34.184Z up gauge 10.21.1.74:9100 node-exporter 02021-09-24T05:52:04.183Z up gauge 10.21.1.74:9100 node-exporter 02021-09-24T05:51:34.183Z up gauge 10.21.1.74:9100 node-exporter 02021-09-24T05:51:04.183Z up gauge 10.21.1.74:9100 node-exporter 02021-09-24T05:50:34.183Z up gauge 10.21.1.74:9100 node-exporter 0>> select * from up where job='pvc-test' order by time desc limit 5;name: uptime __name__ __type__ instance job value---- -------- -------- -------- --- -----2021-09-24T05:53:07.315Z up gauge 127.0.0.1:9999 pvc-test 02021-09-24T05:52:37.315Z up gauge 127.0.0.1:9999 pvc-test 02021-09-24T05:52:07.315Z up gauge 127.0.0.1:9999 pvc-test 02021-09-24T05:51:37.315Z up gauge 127.0.0.1:9999 pvc-test 02021-09-24T05:51:07.315Z up gauge 127.0.0.1:9999 pvc-test 0多prometheus实例在HA场景下，不同的prometheus实例可能拉取雷同的target。多个prometheus实例同时启动时，开始拉取的工夫也要随机错开，否则会呈现多个实例同时拉取同一个target的景象。 ...

prometheus中remote-write和remote-read的配置： # store data to influxdbremote_write: - url: "http://10.21.1.74:8086/api/v1/prom/write?db=prometheus"# read data from influxdbremote_read: - url: "http://10.21.1.74:8086/api/v1/prom/read?db=prometheus"remote-read能够让prometheus读取近程存储上的时序数据，扩大了本地存储。 prometheus在应答/query查问申请时，由fanoutStorage解决； fanoutStorage蕴含localStorage(本地TSDB)和remoteStorage(近程存储)，它们均实现了查问接口；localStorage执行本地查问；remoteStorage通过HTTP执行近程查问；将上述2个查问后果进行合并，返回给client； demo演示prometheus配置remote-write和remote-read；运行一段时间后：进行prometheus: stop prometheus；删除本地数据：delete prometheus/data目录；启动prometheus: start promethesu;上述操作模仿：本地存储宕机，应用近程存储的场景。 在prometheus UI上执行查问，能够失去历史数据(近程存储)； remote-read的代码执行近程查问的入口代码：生成query，而后发送HTTP近程查问 // storage/remote/read.gofunc (q *querier) Select(sortSeries bool, hints *storage.SelectHints, matchers ...*labels.Matcher) storage.SeriesSet { if len(q.requiredMatchers) > 0 { requiredMatchers := append([]*labels.Matcher{}, q.requiredMatchers...) for _, m := range matchers { for i, r := range requiredMatchers { if m.Type == labels.MatchEqual && m.Name == r.Name && m.Value == r.Value { // Requirement matched. requiredMatchers = append(requiredMatchers[:i], requiredMatchers[i+1:]...) break } } } } // 加label m, added := q.addExternalLabels(matchers) // 生成查问 query, err := ToQuery(q.mint, q.maxt, m, hints) // HTTP client发动近程查问 res, err := q.client.Read(q.ctx, query) return newSeriesSetFilter(FromQueryResult(sortSeries, res), added)}client对象的结构：每个remote有一个client，应用其配置的URL/HttpConfig结构 ...

prometheus通过HTTP或者HTTPS拉取target的metrics信息。 alertmanager通过HTTP拉取： http://10.233.96.91:9090/metrics//配置scrape_configs:- job_name: monitoring/alertmanager/0 honor_timestamps: true scrape_interval: 30s scrape_timeout: 10s metrics_path: /metrics scheme: http ......kube-state-metrics通过HTTPS拉取： https://10.233.96.90:8443/metrics//配置- job_name: monitoring/kube-state-metrics/0 honor_labels: true honor_timestamps: true scrape_interval: 30s scrape_timeout: 30s metrics_path: /metrics scheme: https bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true能够看到，对于https的target来说，配置： scheme=https;减少了bearer_token_file的配置；减少了tls_config的配置；初始化http client结构client时，应用配置cfg.HTTPClientConfig: //scrape/scrape.gofunc newScrapePool(cfg *config.ScrapeConfig, app storage.Appendable, jitterSeed uint64, logger log.Logger) (*scrapePool, error) { ...... client, err := config_util.NewClientFromConfig(cfg.HTTPClientConfig, cfg.JobName, false) .... sp := &scrapePool{ cancel: cancel, appendable: app, config: cfg, client: client, activeTargets: map[uint64]*Target{}, loops: map[uint64]loop{}, logger: logger, } .....}HTTPClientConfig构造带了bearToken和tlsconfig信息： ...

源码级别教程地址源码级别教程地址thanos我的项目总结sidecar架构图 外围长处总结无需保护存储，存储高可用： 利用便宜的私有云对象存储，高可用长时间存储，数据降采样：利用Compactor降采样齐全适配原生prometheus查问接口：Query实现多级数据缓存配置怎样才能用好thanos须要对prometheus 有很深刻的了解 包含查问的流程查问的接口tsdb存储的问题数据交互的次要流程如果你有很好的prometheus源码接触，再看thanos就瓜熟蒂落了。thanos的重点是理分明thanos每个组件存在的意思是什么每个组件都干了什么 为什么说prometheus的源码了解很重要因为thanos的每个模块都是为了解决prometheus解决不了或者解决不好的问题我看thanos源码的心得因为我对prometheus拿捏的死死的所以thanos每个我的项目我都能猜到要干什么再联合源码一看就清晰了在调优thanos之前请先理解下面的货色根底不牢，只能出一个新组件追一个，然而每个都不晓得在干什么

PromQL中的group_left和group_right的操作函数，别离提供了Many2One和One2Many的语义，让2个不同的指标能够进行join。 残缺的语法模式： <vector expr> <bin-op> ignoring(<label list>) group_left(<label list>) <vector expr><vector expr> <bin-op> ignoring(<label list>) group_right(<label list>) <vector expr><vector expr> <bin-op> on(<label list>) group_left(<label list>) <vector expr><vector expr> <bin-op> on(<label list>) group_right(<label list>) <vector expr>官网的demo比拟难了解，这里提供一个比拟切合实际应用的demo。 2个输出指标： kube_pod_spec_volumes_persistentvolumeclaims_info：标识pvc和pod的挂载信息；kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes：标识pvc的使用量/总量信息；kube_pod_spec_volumes_persistentvolumeclaims_infokube_pod_spec_volumes_persistentvolumeclaims_info{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim",pod="nginx-pv-1"} 1kube_pod_spec_volumes_persistentvolumeclaims_info{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim",pod="nginx-pv-2"} 1kube_pod_spec_volumes_persistentvolumeclaims_info{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim",pod="nginx-pv-3"} 1kube_pod_spec_volumes_persistentvolumeclaims_info{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim--2",pod="busybox-xxx"} 1kube_pod_spec_volumes_persistentvolumeclaims_info{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim--2",pod="busybox-yyy"} 1kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim"} 0.5{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim--2"} 0.25指标： 通过2个指标的join，失去每个pod及其挂载的pvc的使用率；答案： kube_pod_spec_volumes_persistentvolumeclaims_info + on(namespace,persistentvolumeclaim) group_left 100*(kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes)应用group_left实现了Many2One的语义；2个指标join时，以name和persistentvolumeclaim为维度；后果： {__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim",pod="nginx-pv-1"} 50{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim",pod="nginx-pv-2"} 50{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim",pod="nginx-pv-3"} 50{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim--2",pod="busybox-xxx"} 25{__type__="gauge",instance="127.0.0.1:9999",job="pvc-test",namespace="default",persistentvolumeclaim="myclaim--2",pod="busybox-yyy"} 25参考：1.group_left/group_right官网doc：https://prometheus.io/docs/pr...2.prometheus中各种映射关系的实现：https://iximiuz.com/en/posts/...

rules-reloader的源码： https://github.com/jimmidyson... rules-reloader的启动参数： Args: --webhook-url=http://localhost:9090/-/reload --volume-dir=/etc/prometheus/rules/prometheus-k8s-rulefiles-0operator监听到prometheusrule配置变更，会更新configmap(目录prometheus-k8s-rulefiles-0)，rules-reloader监控到prometheus-k8s-rulefiles-0目录有变更，发送reload给prometheus。 1. rules-reloader的源码剖析rules-reloader的源码很简略，应用fsnotify监听--volume-dir，发现变动就发送--webhook-url: // configmap-reload.gofunc main() { flag.Var(&volumeDirs, "volume-dir", "the config map volume directory to watch for updates; may be used multiple times") flag.Var(&webhook, "webhook-url", "the url to send a request to when the specified config map volume directory has been updated") flag.Parse() watcher, err := fsnotify.NewWatcher() go func() { for { select { // 监听到变动 case event := <-watcher.Events: log.Println("config map updated") for _, h := range webhook { begun := time.Now() // HTTP发送webhook req, err := http.NewRequest(*webhookMethod, h.String(), nil) for retries := *webhookRetries; retries != 0; retries-- { resp, err := http.DefaultClient.Do(req) ..... } } case err := <-watcher.Errors: } } }() // 配置监听volumeDirs for _, d := range volumeDirs { log.Printf("Watching directory: %q", d) err = watcher.Add(d) if err != nil { log.Fatal(err) } } ......}rulers-reloader监听的volume是挂载的ConfigMap:prometheus-k8s-rulefiles-0 ...

config-reloader的源码：https://github.com/prometheus... config-reloader的启动参数： prometheus-config-reloader:Image: 178.104.162.39:443/kubernetes/amd64/prometheus-config-reloader:v0.40.0Args: --log-format=logfmt --reload-url=http://localhost:9090/-/reload --config-file=/etc/prometheus/config/prometheus.yaml.gz --config-envsubst-file=/etc/prometheus/config_out/prometheus.env.yamloperator监听到prometheus配置变更，会更新secret(文件prometheus-yaml.gz，应用gz保障<1M)，config-reloader监控到prometheus-yaml.gz文件有变更，将其解压至prometheus-env.yaml，而后发送reload给prometehus。 1. config-reloader内的源码剖析代码中监听了config-file和rules-dir(未应用)的变动： // cmd/promethues-config-reloader/main.gofunc main() { cfgFile := app.Flag("config-file", "config file watched by the reloader").String() cfgSubstFile := app.Flag("config-envsubst-file", "output file for environment variable substituted config file").String() rulesDir := app.Flag("rules-dir", "Rules directory to watch non-recursively").Strings() var g run.Group { ctx, cancel := context.WithCancel(context.Background()) rel := reloader.New(logger, *reloadURL, *cfgFile, *cfgSubstFile, *rulesDir) g.Add(func() error { return rel.Watch(ctx) }, func(error) { cancel() }) } if err := g.Run(); err != nil { fmt.Fprintln(os.Stderr, err) os.Exit(1) }}监听的动作由reloader实现： ...

何为prometheus配置自动更新： prometheus CRD对象变更，导致prometheus的配置文件变更，须要reload prometheus让配置失效；prometheusrule CRD对象变更，导致prometheus的规定文件变更，须要reload prometheus让配置失效；serviceMonitor/podMonitor等CRD对象变更，导致prometheus的配置文件变更，须要reload prometheus让配置失效；prometheus的POD中有3个container，其中蕴含： prometheus: prometheus-server，主容器；config-reloader: sidecar，负责reload prometheus的配置文件；rules-reloader: sidecar，负责reload prometheus的规定文件；operator+prometheus+2个sidecar一起单干，实现了配置的自动更新。 1. sidecar的镜像及启动参数2个sidecar的镜像版本，在operator的启动参数中指定： containers: - args: - --kubelet-service=kube-system/kubelet - --logtostderr=true - --config-reloader-image=178.104.162.39:443/kubernetes/amd64/configmap-reload:v0.0.1 - --config-reloader-memory=50Mi - --prometheus-config-reloader=178.104.162.39:443/kubernetes/amd64/prometheus-config-reloader:v0.40.0 image: 178.104.162.39:443/kubernetes/amd64/prometheus-operator:v0.40.0 imagePullPolicy: IfNotPresent name: prometheus-operator能够看到，rules-reloader的镜像版本v0.0.1，config-reloader的版本v0.40.0，因为config-reloader的代码跟operator的代码放在一起的，所以其版本也跟着operator的走。 2个sidecar的源码地位： config-reloader: 与operator源码在一起，https://github.com/prometheus...rules-reloader: https://github.com/jimmidyson...prometheus及sidecar的启动参数： prometheus:Image: 178.104.162.39:443/kubernetes/amd64/prometheus:v2.20.0Args: --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries --config.file=/etc/prometheus/config_out/prometheus.env.yaml --storage.tsdb.path=/prometheus --storage.tsdb.retention.time=24h --web.enable-lifecycle --storage.tsdb.no-lockfile --web.route-prefix=/prometheus-config-reloader:Image: 178.104.162.39:443/kubernetes/amd64/prometheus-config-reloader:v0.40.0Args: --log-format=logfmt --reload-url=http://localhost:9090/-/reload --config-file=/etc/prometheus/config/prometheus.yaml.gz --config-envsubst-file=/etc/prometheus/config_out/prometheus.env.yamlrules-configmap-reloader:Image: 178.104.162.39:443/kubernetes/amd64/configmap-reload:v0.0.1Args: --webhook-url=http://localhost:9090/-/reload --volume-dir=/etc/prometheus/rules/prometheus-k8s-rulefiles-02. sidecar与volume的挂载关系4个volume别离被3个container挂载： prometheus-k8s-db: 寄存prometheus data的目录，仅被prometheus挂载；prometheus-k8s: 寄存prometheus配置压缩文件prometheus.yaml.gz，仅被config-reloader挂载；config-out: 寄存prometheus配置文件，被prometheus和config-reloader挂载；prometheus-k8s-rulefiles-0: 寄存prometheus的规定文件，被prometheus和rules-reloader挂载； 3. 论断后行论断不难理解，然而外面的细节太多，对细节感兴趣的话能够浏览前面的详解文章。 operator监听到prometheus配置变更，会更新secret(文件prometheus-yaml.gz，应用gz保障<1M)，config-reloader监控到prometheus-yaml.gz文件有变更，将其解压至prometheus-env.yaml，而后发送reload给prometehus；operator监听到prometheusrule配置变更，会更新configmap(目录prometheus-k8s-rulefiles-0)，rules-reloader监控到prometheus-k8s-rulefiles-0目录有变更，发送reload给prometheus；

Operator的整体架构： 次要包含3大组件： Informer: 监听资源对象的变动，将变动转成事件放入WorkQueue；WorkQueue: 保留变动的事件；Control Loop: 生产WorkQueue中的事件，对事件做响应；其中，Informer较为简单： Reflector: 调用apiservier接口，应用List&Watch对指定类型的资源对象进行监控；DeltaFIFO: 增量队列，保留Reflector监控到的change对象；LocalStorage: informer的本地cache，用以查问特定类型的资源对象，以加重apiserver的查问压力；1. Informer源码对于要监控的资源类型，每种类型创立一个Informer，比方prometheus CRD: // 代码入口// cmd/operator/main.gofunc Main() int { ....... r := prometheus.NewRegistry() po, err := prometheuscontroller.New(cfg, log.With(logger, "component", "prometheusoperator"), r) if err != nil { fmt.Fprint(os.Stderr, "instantiating prometheus controller failed: ", err) return 1 } .......}这里能够看到，用prometheuscontroller.New()创立对应的operator，这也是常说的operator=CRD+Controller： // pkg/prometheus/operator.go// New creates a new controller.func New(conf Config, logger log.Logger, r prometheus.Registerer) (*Operator, error) { .... c.promInf = cache.NewSharedIndexInformer( c.metrics.NewInstrumentedListerWatcher( listwatch.MultiNamespaceListerWatcher(c.logger, c.config.Namespaces.PrometheusAllowList, c.config.Namespaces.DenyList, func(namespace string) cache.ListerWatcher { return &cache.ListWatch{ ListFunc: func(options metav1.ListOptions) (runtime.Object, error) { options.LabelSelector = c.config.PromSelector return mclient.MonitoringV1().Prometheuses(namespace).List(context.TODO(), options) }, WatchFunc: func(options metav1.ListOptions) (watch.Interface, error) { options.LabelSelector = c.config.PromSelector return mclient.MonitoringV1().Prometheuses(namespace).Watch(context.TODO(), options) }, } }), ), &monitoringv1.Prometheus{}, resyncPeriod, cache.Indexers{cache.NamespaceIndex: cache.MetaNamespaceIndexFunc}, ) .....}创立了prometheus的Informor: c.promInf，能够看到，它监听对象变更应用的是List&Watch；创立ok后，将该Informer Run起来： ...

指标：估算Prometheus在监控零碎中，采集指标的指标值时，所消耗的存储容量。 统计后果个别以每小时/每天耗费多少GB容量示意，以便于进行容量布局。 PromQL计算样本收集率rate(prometheus_tsdb_head_samples_appended_total[1m])# 后果：2076个/s依据过来1m采集到的tsdb的样本数，计算每秒的样本率。 PromQL计算每个样本占用bytes1) 估算：Prometheus的压缩算法(dod&xor)，每个样本大小1~2bytes，激进依照2bytes计算； 2) 精算： # 每个样本均匀占用的bytesrate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[1h])计算存储用量由上述统计得悉，每秒入TSDB 2076个样本，每个样本2bytes，能够统计出，1hour的存储用量： 3600*2076*2 = 14,947,200 bytes = 15MB 也就是2hour存储用量大略30MB。 到prometheus实例上查看一下理论用量： /prometheus $ ls -alhtotal 24Kdrwxrwsrwx 17 root 2000 4.0K Feb 22 05:00 .drwxr-xr-x 1 root root 28 Feb 2 06:03 ..drwxr-sr-x 3 1000 2000 68 Feb 21 05:00 01EZ1FAVT6VZ7GQ2RKNZRFK47Zdrwxr-sr-x 3 1000 2000 68 Feb 21 07:00 01EZ1P6K16BXJQJDFF008VKVZ1drwxr-sr-x 3 1000 2000 68 Feb 21 09:00 01EZ1X2A9B41NMEPD0T8FH9YH2drwxr-sr-x 3 1000 2000 68 Feb 21 11:00 01EZ23Y1HQQPJZJTGF4NPH944Ydrwxr-sr-x 3 1000 2000 68 Feb 21 13:00 01EZ2ASRS728MQ2TWXC2K6R3G6drwxr-sr-x 3 1000 2000 68 Feb 21 15:00 01EZ2HNG2GSF4GD2JZ25FBJHS3drwxr-sr-x 3 1000 2000 68 Feb 21 17:00 01EZ2RH7A3M9V3RPDHDN4T21FMdrwxr-sr-x 3 1000 2000 68 Feb 21 19:00 01EZ2ZCYJFNG3HYWF326NJKXE3drwxr-sr-x 3 1000 2000 68 Feb 21 21:00 01EZ368NS93N04A6RHDBGFBKJQdrwxr-sr-x 3 1000 2000 68 Feb 21 23:00 01EZ3D4D13YT2HG8QPR4WB1QK0drwxr-sr-x 3 1000 2000 68 Feb 22 01:00 01EZ3M04943Q1WW6SGAGN9ZVWXdrwxr-sr-x 3 1000 2000 68 Feb 22 03:00 01EZ3TVVHKWDFKNN697DPFE7J6drwxr-sr-x 3 1000 2000 68 Feb 22 05:00 01EZ41QJS6YM7SHX18RQHSTV8Hdrwxr-sr-x 2 1000 2000 34 Feb 22 05:00 chunks_head-rw-r--r-- 1 1000 2000 19.5K Feb 22 06:58 queries.activedrwxr-sr-x 3 1000 2000 97 Feb 22 05:00 wal/prometheus $/prometheus $ du -sh 01EZ1FAVT6VZ7GQ2RKNZRFK47Z25.5M 01EZ1FAVT6VZ7GQ2RKNZRFK47Z/prometheus $/prometheus $ du -sh 01EZ1P6K16BXJQJDFF008VKVZ125.4M 01EZ1P6K16BXJQJDFF008VKVZ1/prometheus $能够看到，2hour的存储用量≈26MB，跟咱们之前的评估后果差不多。 ...

prometheus-operator默认部署2个prometheus POD，并且被优先调度到master节点。 2个prometheus实例查看prometheus CRD对象的定义，能够看出，部署了2个实例： # vi prometheus-prometheus.yaml ...... image: "178.104.162.39:443/dev/huayun/amd64/prometheus:v2.20.0" ...... replicas: 2 ......在kubernetes集群中，prometheus以statefulset形式部署： # kubectl get all -n monitoring |grep prometheus-k8spod/prometheus-k8s-0 3/3 Running 1 19dpod/prometheus-k8s-1 3/3 Running 1 19dservice/prometheus-k8s NodePort 10.233.50.253 <none> 9090:32500/TCP 20dstatefulset.apps/prometheus-k8s 2/2 20d2个prometheus实例的关系两个prometheus实例是独立、对等的关系，相互之间并不感知。 scrape对象雷同：prometheus.yaml内容统一；alertmanager的配置雷同：当有告警时，2个prometheus实例同时发送到alertmanager，alertmanager集群会进行告警的去重；若两个实例都配置了remote_write到influxdb，则每份指标会存入influxdb两次，然而会用prometheus_replica辨别是来自哪个实例：

指标：用户启动的service或pod，在annotation中增加label后，能够主动被prometheus发现： annotations: prometheus.io/scrape: "true" prometheus.io/port: "9121"1. secret保留主动发现的配置若要特定的annotation被发现，须要为prometheus减少如下配置： - job_name: 'kubernetes-service-endpoints' kubernetes_sd_configs: - role: endpoints relabel_configs: - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape] action: keep regex: true - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme] action: replace target_label: __scheme__ regex: (https?) - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port] action: replace target_label: __address__ regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 - action: labelmap regex: __meta_kubernetes_service_label_(.+) - source_labels: [__meta_kubernetes_namespace] action: replace target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_service_name] action: replace target_label: kubernetes_name上述配置会筛选endpoints：prometheus.io/scrape=True ...

上文讲到serviceMonitor是service监控对象的形象，本文就以kube-proxy为例，剖析如何应用serviceMonitor对象监控kube-proxy。 1. kube-proxy的部署模式# kubectl get all -A|grep proxykube-system pod/kube-proxy-bn64j 1/1 Running 0 30mkube-system pod/kube-proxy-jcl54 1/1 Running 0 30mkube-system pod/kube-proxy-n44bh 1/1 Running 0 30mkube-system daemonset.apps/kube-proxy 3 3 3 3 3 kubernetes.io/os=linux 217d能够看到，kube-proxy应用daemonset部署，但没有service，部署了3个Pod。 2. 减少kube-proxy的/metrics拜访端口kube-proxy的Pod内含1个container，并且其配置文件中，metrics绑定的ip为127.0.0.1： # kubectl edit ds kube-proxy -n kube-system...... spec: containers: - command: - /usr/local/bin/kube-proxy - --config=/var/lib/kube-proxy/config.conf - --hostname-override=$(NODE_NAME) env: - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName image: 178.104.162.39:443/dev/kubernetes/amd64/kube-proxy:v1.18.0 imagePullPolicy: IfNotPresent name: kube-proxy查看其配置文件/var/lib/kube-proxy/config.conf: # kubectl exec -it kube-proxy-4vxsf /bin/sh -n kube-system# cat /var/lib/kube-proxy/config.confbindAddress: 0.0.0.0......healthzBindAddress: 0.0.0.0:10256......metricsBindAddress: 127.0.0.1:10249能够看到，其绑定的metrics地址：127.0.0.1:10249；要想里面能够拜访/metrics，须要将该端口转发进去，这里应用sidecar：减少1个kube-rbac-proxy container的形式，将proxy container的metrics端口转发进去： ...

prometheus-operator部署模式为deployment，其应用operator框架开发，operator实质上是CRD+controller： CRD: prometheus/prometheusurle/alertmanager/serviceMonitor/podMonitor等；controller: 监听CRD的变动，批改相应的资源配置； prometheus-operator蕴含的CRD： prometheus: 对prometheus-server的形象；serviceMonitor: 对service监控对象的形象；podMonitor: 对pod监控对象的形象；prometheusrule: 对prometheus报警规定的形象；prometheus-operator的应用，根本是如何操作上述的CRD对象。 查看CRD类型： # kubectl get crd |grep coreosalertmanagers.monitoring.coreos.com 2021-05-28T08:02:20Zpodmonitors.monitoring.coreos.com 2021-05-28T08:02:21Zprometheuses.monitoring.coreos.com 2021-05-28T08:02:22Zprometheusrules.monitoring.coreos.com 2021-05-28T08:02:23Zservicemonitors.monitoring.coreos.com 2021-05-28T08:02:24Zthanosrulers.monitoring.coreos.com 2021-05-28T08:02:25Z查看特定CRD类型下的实例： # kubectl get prometheuses -n monitoringNAME VERSION REPLICAS AGEk8s v2.20.0 2 46h# kubectl get servicemonitors -n monitoringNAME AGEalertmanager 46hcoredns 46hetcd-k8s 19hkube-apiserver 46hkube-controller-manager 46hkube-scheduler 46hkube-state-metrics 46hkubelet 46hnode-exporter 46hprometheus 46hprometheus-adapter 46hprometheus-operator 46h参考：1.operator开发/部署：https://www.qikqiak.com/post/k8s-operator-101/

prometheus初始应用min_shards运行，在运行过程中，利用sampleIn/sampleOut等指标计算新的shards，而后更新shards运行。 remote_write中shard的默认配置： min_shards=1;max_shards=1000;按此配置，理论运行的shards值： 初始=min_shards=1;有1个Goroutine依据以后的输入输出状况，定时计算新的desired_shards，而后进行reshard，以此动静调整shard数量；入口入口在上文讲到的QueueManager: // Start the queue manager sending samples to the remote storage.// Does not block.func (t *QueueManager) Start() { .... go t.updateShardsLoop() //计算新的shard go t.reshardLoop() //更新shard}更新shard: reshardLoop()更新shard很简略，stop老的shard，而后start新的shard; func (t *QueueManager) reshardLoop() { defer t.wg.Done() for { select { case numShards := <-t.reshardChan: // We start the newShards after we have stopped (the therefore completely // flushed) the oldShards, to guarantee we only every deliver samples in // order. t.shards.stop() t.shards.start(numShards) case <-t.quit: return } }}计算新shard: updateShardsLoop()计算新shard的过程略微简单一些。外围逻辑在t.calculateDesiredShards()： ...