https://www.161616.top/tags/monitor/ Recent content in Monitor on Cylon's Collection Hugo -- 0.125.7 zh Sat, 14 Sep 2024 23:00:36 +0800 https://www.161616.top/promql-advanced/ Wed, 17 Jul 2024 00:00:00 +0000 https://www.161616.top/promql-advanced/ 查询结果删除某些指标 without without 属于聚合查询的子句，必须在聚合查询中使用 语法： bash 1 <aggr-op> [without|by (<label list>)] ([parameter,] <vector expression>) 可以看到属于 <aggr-op> 例如 text 1 sum without(instance) (http_requests_total) ignoring ignoring 属于 “向量匹配” (Vector matching) 关键词，可以在 一对多，和多对多查询中使用 语法 bash 1 <vector expr> <bin-op> ignoring(<label list>) <vector expr> 例如 bash 1 method_code:http_errors:rate5m{code="500"} / ignoring(code) method:http_requests:rate5m 与查询 可以查询满足多个条件的指标，例如下列是查询 jvm 内存 $\frac{used}{committed} > 80%$ 并且 Pod WSS 使用大于 80% 的指标 promql 1 2 3 4 5 6 sum by(pod) (jvm_memory_used_bytes{}) / sum by(pod) (jvm_memory_committed_bytes{}) > . https://www.161616.top/prometheus-adapter-intro/ Fri, 31 May 2024 00:00:00 +0000 https://www.161616.top/prometheus-adapter-intro/ Kubernetes监控架构设计 k8s监控设计背景说明 根据 Kubernetes监控架构 1，Kubernetes 集群中的 metrcis 可以分为 系统指标 (Core Metrics) 和 服务指标 (service metrics) ; 系统指标(System metrics) 是通用的指标，通常可以从每一个被监控的实体中获得（例如，容器和节点的CPU和内存使用情况）。服务指标(Service metrics) 是在应用程序代码中显式定义并暴露的 (例如，API Server 处理的 500 错误数量)。 Kubernetes将系统指标分为两部分： 核心指标 (core metrics) 是 Kubernetes 理解和用于其内部组件和核心工具操作的指标，例如：用于调度的指标 (包括资源估算算法的输入, 初始资源/VPA (vertical autoscaling)，集群自动扩缩 (cluster autoscaling)，水平Pod自动扩缩 (horizontal pod autoscaling ) 除自定义指标之外的指标)；Kube Dashboard 使用的指标，以及 “kubectl top” 命令使用的指标。 非核心指标 (non-core metrics) 是指不被 Kubernetes 解释的指标。我们一般假设这些指标包含核心指标 (但不一定是 Kubernetes 可理解的格式)，以及其他额外的指标。 所以，kubernetes monitoring 的架构被设计拥有如下特点： 通过标准的主 API (当前为主监控 API) 提供关于Node, Pod 和容器的核心系统指标，使得核心 Kubernetes 功能不依赖于非核心组件 kubelet 只导出有限的指标集，即核心 Kubernetes 组件正常运行所需的指标。 … 监控管道 Kubernetes 监控管道分为两个： https://www.161616.top/grafana-keycloak/ Tue, 19 Dec 2023 00:00:00 +0000 https://www.161616.top/grafana-keycloak/ 本文使用 helm 方式部署 grafana 9 并同样将 keycloak 部署在 kubernetes 集群之上；接下来使用 keycloak 作为 grafana authentication，并实现 oauth2 的用户权限管理。 在Kubernetes 集群之上使用helm部署keycloak 在 kubernetes 集群安装 keycloak 有两种方式： bitnami helm offical 下面使用 offical 提供的方式进行部署 bash 1 kubectl create -f https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/latest/kubernetes/keycloak.yaml helm 部署完成后默认密码是存储在 secret 中，上面方式安装的密码默认为 admin/admin Keycloak configuration 创建realm Realm 管理这一组用户(users), 凭据(credentials), 角色(roles) 和 组(groups)，realm之间是相互隔离，一个用户属于并登录到某个 realm，只能管理和验证其控制的用户。 下面为 grafana 创建一个 realm，如果你的环境已经存在通用的 realm，则可以使用这个 realm，默认 keycloak 的 realm 是 master，超级管理员属于这个 realm。 创建 client Client 是可以请求Keycloak对用户进行身份验证的实体。最常见用途是希望使用Keycloak来保护自己并提供单点登录(SSO)解决方案的应用程序和服务。客户端也可以是只希望请求身份信息或访问令牌的实体，以便它们可以安全地调用由 Keycloak 保护的网络上的其他服务。因此，我们需要为 grafana 创建一个 client https://www.161616.top/kubernetes-node-label-dashboard/ Sat, 19 Aug 2023 00:00:00 +0000 https://www.161616.top/kubernetes-node-label-dashboard/ 背景 目前的 Kubernetes 集群资源面板是基于集群的使用资源，因为是多集群，业务同时运行字啊不同集群上，如果通过 label 来划分业务使用的资源情况，这个才是真的和每个集群的每个业务使用的资源有关。 对于这种场景的划分，Kubernetes 中有一个专门的名词是 Pod 的拓扑域；基于这些需要做的事情就如下步骤 首先确定node label可以搜集到，如果不存在需要收集 当收集到node label 时，需要根据对应的 label 将一个域中的 根据域（label）做变量注入到 对应的查询语句中以生成图表 收集 node label 在使用 kube-prometheus-stack 中收集 kubernetes 的 node label 需要手动启动参数 - --metric-labels-allowlist=nodes=[*] 才可以收集到 node label，手动给Node 打上标签，test 拓扑域 为 aaaa bbbb两个 在 helm 中直接增加如下： bash 1 - nodes=[*] 查看 label bash 1 2 3 4 $ kubectl get node --show-labels NAME STATUS ROLES AGE VERSION LABELS node01 Ready <none> 13d v1.16.10 beta. https://www.161616.top/blackbox_exporter-in-k8s/ Wed, 12 Jul 2023 00:00:00 +0000 https://www.161616.top/blackbox_exporter-in-k8s/ 背景 在云原生环境中，特别是基于 Kubernetes，集群中的 “服务” 在与外部交互时，例如，一个外部的第三方 Web 服务/API 等，而监控这些不同的 endpoint 诊断服务可用性的一个关键点，这里将阐述基于 Kube-prometheus-stacks 如果做到可以监控外部 IP/URL，例如，HTTP/TCP/ICMP 等。 blackbox_exporter 是 Prometheus 官方维护的 exporter之一，是提供一种用于检测 HTTP/S、DNS、TCP 和 ICMP 端点的可用性。 基于 kube-prometheus-stack 安装 blackbox 本文使用了 helm 安装的 prometheus-community/prometheus-blackbox-exporter ，在安装前，需要自行修改要启动的 prober，与是否开启默认的 servicemonitor yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 secretConfig: false config: modules: ping: prober: icmp timeout: 5s icmp: preferred_ip_protocol: "ip4" http_2xx: prober: http timeout: 5s http: valid_http_versions: ["HTTP/1.1", "HTTP/2. https://www.161616.top/using-thanos-improve-prometheus.md/ Sun, 02 Jul 2023 00:00:00 +0000 https://www.161616.top/using-thanos-improve-prometheus.md/ 背景 Prometheus 是目前云原生架构中监控解决方案中的基石，而对于 “metrics”，“traces” 和 “logs” 是组成云原生架构中“可观测性”的一个基础，当在扩展 Prometheus，那么 Prometheus 提供的基础架构是无法满足需求的（高可用性和可扩展性）， 而高可用性与可扩展性是满足不断增长基础设施的一个基本条件。而 Prometheus 本身并没有提供“弹性”的集群配置，也就是说，多个副本的 Prometheus 实例，对于分布在每个 Pod 上的数据也会不一致，这时也需要保证指标的归档问题。 并且在一定的集群规模下，问题的出现远远大于 Prometheus 本身的能力，例如： 如何经济且搞笑的存储历史数据（TB, PB）？如何快速的查询历史数据？ 如何合并 Promehtues 多个实例收集来的副本数据？ 以及多集群间的监控？ 由于 TSDB 的块同步，Prometheus 严重依赖内存，使得 Prometheus 监控项的扩展将导致集群中的CPU/MEM 的使用加大 .. 解决 Thanos 是一款可以使 Prometheus 获得 ”长期存储“，并具体有”高可用性“ 的 Prometheus 的功能扩展，“Thanos” 源自希腊语“ Athanasios”，英文意思是”不朽“。这也正是 ”Thanos“ 提供的功能：”无限制的对象存储“，并与原生 Prometheus API 高度兼容，你可以理解为 Thanos API 就是 Prometheus API。 Cortexmetrics 与 Thanos 类似，是用通过将 Prometheus 实例的”存储“和”查询“等功能分离到独立的组件中，实现水平扩展。它使用对象存储来持久化历史指标，块存储（TSDB）是他的存储后端；此外，Cortex 还提供了多租户与多租户隔离等功能 联邦集群，联邦集群是 Prometheus 官方提供的一个概念，使用了联邦将允许 Prometheus 从另一个 Prometheus 中抓取选定的指标。可以使用的一些模型如下： 分层联邦：大规模的集群中，Prometheus 部署模型如一个”树形“，高级别的从多个低级实例中抓取指标，并存储聚合 跨服务联邦：Prometheus 从另一个 Prometheus 只抓取指定的数据 图：Prometheus 联邦 Source：https://www. https://www.161616.top/impove-prometheus-performance/ Wed, 14 Jun 2023 00:00:00 +0000 https://www.161616.top/impove-prometheus-performance/ 背景 对于整个 Kubernetes 集群来说，随着业务不断地打磨，新增指标，那么对于 Prometheus 特性来说，那么内存 与 存储的使用势必是增加。这是对于存储压力是很重的，通常情况下，使用 Prometheus，都会是用于 Kubernetes 集群中，而 应用于 Kubernetes 集中的存储势必是 PVC 之类的网络存储。 这种场景中，我将尝试拆解如何分析和配置 Prometheus 以显著的减少其资源使用并解决高基数问题 高基数 基数 (cardinality) 通俗来说是一个集合中的元素数量 [1] 基数的来源通常为： label 的数量 series(指标) 的数量 时间：label 或者 series 随时间而流失或增加，通常是增加 那么这么看来高基数就是，label, series, 时间这三个集合的笛卡尔积，那么高基数的情况就很正常了。 而高基数带来的则是 Prometheus 资源使用，以及监控的性能。下图是 Grafana Lab 提到的一张图，很好的阐述了高基数这个问题 图：Prometheus中的基数 Source：https://grafana.com/blog/2022/02/15/what-are-cardinality-spikes-and-why-do-they-matter 如图所示：一个指标 server_responses 他的 label 存在两个 status_code 与 environment ，这代表了一个集合，那他的 label value 是 1~5xx，这个指标的笛卡尔积就是10。 那么此时存在一个问题，如何能定位 基数高不高，Grafana Lab 给出了下面的数据 [1]，但是我不清楚具体的来源或者如何得到的这些值。也就是 label:value 低基数：1: 5 标准基数：1: 80 高基数：1: 10000 为什么指标会指数级增长 在以 Kubernetes 为基础的架构中，随着抽象级别的提高（通常为Pod, Label, 以及更多抽象的拓扑），指标的时间序列也越来越多。因为在这种基础架构中，在传统架构中运行的一个应用的单个裸机，被许多运行分散在许多不同节点上的许多不同微服务的 Pod 所取代。在这些抽象层中的每一个都需要一个标签，以便可以唯一地标识它们，并且这些组件中的每一个都会生成自己的指标，从而创建其独特的时间序列集。 https://www.161616.top/grafana-8.0/ Fri, 17 Dec 2021 00:00:00 +0000 https://www.161616.top/grafana-8.0/ Select panel title → Inspect → Panel JSON Set “type” to “table-old” Apply The visualization should now appear as Table (old) and in the right side will appear Column Styles Column Styles → Options → Name pattern set the name of the column to hide Type → Hidden Reference：Hide column in table in v8.0 https://www.161616.top/prometheus-operator/ Mon, 02 Nov 2020 00:00:00 +0000 https://www.161616.top/prometheus-operator/ 什么是 Operator？ Operator是由CoreOS公司开发的，用来扩展kubernetes APi的特定的应用程序控制器，Operator基于Kubernetes的资源和控制器概念之上构建，但同时又包含了对相应应用程序特定的一些专业知识。创建operator的关键是 CRD（CustomResourceDefinition）的设计。 Prometheus Operator Prometheus Operator 是CoreOS公司提供的基于Prometheus及其相关监视组件对Kubernetes集群组件的管理，该Operator目的是简化和自动化针对Kubernetes集群的基于Prometheus的管理及配置。 Prometheus Operator架构组件 Operator：作为Prometheus Operator的核心组件，也即是自定义的控制器，用来监视和部署管理Prometheus Operator CRD资源对象，监控并维持CRD资源状态。 Prometheus Server：Operator 根据自定义资源 Prometheus 类型中定义的内容而部署的Prometheus Cluster Prometheus Operator CRD： Prometheus：以CRD资源提供给Operator的类似于Pod资源清单定位的资源。 ServiceMonitor：声明定义对Kubernetes Services资源进行监控，使用标签选择器来选择所需配置的监控，后端是Service的Endpoint，通过Service标签选择器获取EndPoint对象。 PodMonitor：使用标签选择器，选择对匹配Pod进行监控 Alertmanager：声明定义了Alertmanager在Kubernetes中运行所提供的配置。 PrometheusRule: 声明定义了Prometheus在Kubernetes中运行所需的Rule配置。 reference Prometheus-Operator-design Prometheus Operator监控二进制kubernetes 查看兼容性列表选择对应的版本来下载，此处kubernetes集群为1.8.10 。 对应地址为 https://github.com/prometheus-operator/kube-prometheus.git ，可以在域名后添加.cnpmjs.org 访问中国的github加速。 bash 1 git clone https://github.com.cnpmjs.org/prometheus-operator/kube-prometheus.git 资源清单在项目目录 manifests CRD在 manifests/setup 需要先安装CRD 和 Operator 对象 kube-controller-manager 和 kube-scheduler 无监控数据 二进制部署的Kubernetes集群中部署Prometheus Operator，会发现在prometheus server的页面上发现kube-controller和kube-schedule的target为0/0。匹配不到节点信息，这是因为serviceMonitor是根据label去选取svc的。此处svc并没有kube-controller和kube-schedule 需要手动创建。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 apiVersion: v1 kind: Service metadata: namespace: kube-system name: kube-controller-manager labels: k8s-app: kube-controller-manager component: kube-controller-manager spec: selector: k8s-app: kube-controller-manager component: kube-controller-manager ports: - name: https-metrics port: 10252 targetPort: 10252 --- apiVersion: v1 kind: Endpoints metadata: namespace: kube-system name: kube-controller-manager labels: k8s-app: kube-controller-manager component: kube-controller-manager subsets: - addresses: - ip: "10. https://www.161616.top/telegram-bot-send-post-json/ Mon, 02 Sep 2019 00:00:00 +0000 https://www.161616.top/telegram-bot-send-post-json/ text 1 2 3 4 5 6 7 8 9 10 11 curl -XPOST https://api.telegram.org/bot977657989:AAF0QE88WhxRIdpFLOYO_9ldLun5VtpfCWw/getUpdates curl -X POST \ -H 'Content-Type: application/json' \ -d '{"chat_id": "850233746", "text": "This is a test from curl", "disable_notification": true}' \ https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage curl -X POST \ -H 'Content-Type: application/json' \ -d '{"chat_id": "850233746", "text": "This is a test from curl", "disable_notification": true}' \ https://api.telegram.org/bot1009139816:AAGTmFsJDkH9H3E0OVoFi4GyvYp0uMctvcE/sendMessage https://api.telegram.org/bot721202655:AAG_kN1IHP93Wmnd90RRaJC-dK9tKQHddRA/sendMessage json 1 2 3 4 5 { "chat_id": "-383641009", "text": "This is a test from curl", "disable_notification": true } alertmanager发送的消息类型如下： https://www.161616.top/prome-nginx-module-vts/ Tue, 02 Jul 2019 00:00:00 +0000 https://www.161616.top/prome-nginx-module-vts/ prometheus 监控nginx的模块 nginx-module-vts 下载后配置 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 http{ vhost_traffic_status_zone; vhost_traffic_status_zone shared:vhost_traffic_status:32m; # 设置共享内存大小 server { vhost_traffic_status_filter_by_set_key $status $server_name; # 计算详细的http状态代码的流量 location /status { vhost_traffic_status_display; # 设置了该指令，则可以访问如下： vhost_traffic_status_display_format html; vhost_traffic_status off; ## 启用或禁用模块工作 } } } 不想统计流量的server区域禁用vhost_traffic_statu off 例： 计算upstream后端响应时间 nginx_upstream_responseMsec{upstream=“group1”} 一个完整的配置文件：nginx.conf 关于GEO相关：GeoIP.dat file format #162 ngx如何配置GEO：GeoIP discontinuation; Upgrade to GeoIP2 with nginx on CentOS 删除所zone内存中的数据 bash 1 curl localhost/status/control? https://www.161616.top/prometheus-golang_client/ Sun, 02 Jun 2019 00:00:00 +0000 https://www.161616.top/prometheus-golang_client/ exporter是一个独立运行的采集程序，其中的功能需要有这三部分 自身是HTTP服务器，可以相应从外部发过来的HTTP GET请求。 自身需要运行在后台，并可以定期触发抓取本地的监控数据。 返回给prometheus_server的内容是要符合prometheus规定的metrics类型的key-Value promethes监控中对于采集过来的数据统一称为metrice数据 Metrics，为某个系统某个服务做监控、做统计，就需要用到Metrics. metrics是一种对采样数掘的总称（metrics并不代表某一种具体的数据格式是一种对于度星计算单位的抽象） metrics的几种主要的类型 METRIC TYPES prometheus客户端库提供4中metric类型 counter 计数器，累加指标 gauge 测量指标 summary 概略 histogram 直方图 counter Counter计数器，累加的指标数据，随时间逐步增加，如程序运行次数、运行错误发生总数。如网卡流量，代表持续增加的数据包或者传输字节的累加值 比如对用户访问量的采样数据 我们的产品被用户访问一次就是1过了10分钟后积累到100 过一天后累积到20000 一周后积累到100000-150000 go 1 2 3 4 5 6 7 8 test = prometheus.NewSummaryVec( prometheus.SummaryOpts{ Name: "zhangsan", Help: "username", Objectives: map[float64]float64{0.5: 0.05, 0.9: 0.01, 0.99: 0.001}, }, []string{"service"}, ) text 1 2 3 4 5 6 7 # HELP zhangsan username # TYPE zhangsan summary zhangsan{service="aaa",quantile="0.5"} 0. https://www.161616.top/prometheus-install/ Tue, 02 Apr 2019 00:00:00 +0000 https://www.161616.top/prometheus-install/ 全局配置选项 text 1 2 3 4 5 6 7 scrape_interval: 采集生命周期 scrape_timeout: 采集超时时间 evaluation_interval: 告警评估周期 rule_files 监控告警规则 scrape_config: 被监控端 altering 检查配置文件语法 text 1 2 3 $ promtool check config \etc\prometheus.yml Checking \etc\prometheus.yml SUCCESS: 0 rule files found 100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) \ node_memory_MemTotal_bytes * 100 计算剩余空间 node_filesystem_free_bytes{mountpoint="",fstype=~“ext4|xfs”} \ node_filesystem_size_bytes{mountpoint="",fstype=~“ext4|xfs”} * 100 查看使用的百分比 100-node_filesystem_free_bytes{mountpoint="",fstype=~“ext4|xfs”} \ node_filesystem_size_bytes{mountpoint="",fstype=~“ext4|xfs”} * 100 prometheus使用influxdb [Prometheus endpoints support in InfluxDB | InfluxData Documentation](https:\docs.influxdata.com\influxdb\v1.7\supported_protocols\prometheus) [Configuration | Prometheus](https:\prometheus.io\docs\prometheus\latest\configuration\configuration) 配置文件参考 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 global: alerting: alertmanagers: - static_configs: - targets: rule_files: scrape_configs: - job_name: 'prometheus1' file_sd_configs: - files: ['\data\sd_config\test.