Monitor

查询结果删除某些指标 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{}) > ....

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 监控管道分为两个：...

本文使用 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...

背景 目前的 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....

背景 在云原生环境中，特别是基于 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....