K8s: Prometheus 服务结构以及基础抓取数据服务部署

Prometheus 数据采集与 Grafana 可视化实践指南 Prometheus 是一个开源的系统监控和警报工具包,采用拉取(pull)模式从目标收集指标数据。:Prometheus 将所有数据存储为时间序列,每个时间序列由指标名称(metric name)和一组键值对标签(label)唯一标识。 阅读详情

Prometheus

  • 发布应用之后,就有持续运维的事情,就是平台监控
  • Prometheus 是一个云原生的日志监控平台,是一个实时标准的一个技术
  • 它是著名的 cncf 里的一个重要的开源项目
  • 上面整个图片是在云原生应用及K8s应用架构下的一个日志监控的一个标准的解决方案
  • 中间火炬图标就是 Prometheus, 从左向右来看
  • Short-lived jobs, 这里有一个job概念,它能执行这种一次性或者是多次的
  • 定时的导入一些触发一些 metrics 收集的任务, 注意,这是k8s里面的job
  • 可以认为是个定时任务, 然后它通过一个Pushgetaway发送一些pull的请求
  • 这个请求去拉什么数据呢?在下面Prometheus 配置文件里,会有一些Jobs, 这里是Prometheus的Jobs
  • 还有这个exporter,也就是我们的日志导出器,也是非常关键的一个组件
  • 它能够在K8s的worker node上去导出一些CPU的这个数据,这个叫Prometheus的一些目标
  • 然后通过这个拉取的方式,这些数据会被拉取到 Prometheus server
  • 这些数据不仅是在 work node 上的数据,也可以是 K8s 应用中的数据
  • 拉取数据库后存储在 TSDB (时序数据库中) 中,所以时序数据库和关系性数据库的区别是什么呢?
    • 关系性数据库,像mysql这样的数据库
    • 它比较适合存这个数据这种有关联关系的这种复杂查询的这种依赖关系的这种数据
    • 像一些监控的数据,它往往是按照一定的时序发生的,所以它叫时序数据库
  • 正因为它是时序时序数据库,所以它的每个K8s集群里面的时序的时间保持一致,需要安装NTP这个server服务器
  • 这个时序数据库存在咱们的这个node上,当然Prometheus本身也是运行在K8s平台上的
  • 收集数据后,它就已经有了K8s集群的一些字段和数据了,或者是应用的一些数据都可以存在这里
  • 有了数据之后,可以做展示,展示的方式呢,它是通过 PromQL 查询语言去从这个数据库里面查询数据
  • 之后展示在 Prometheus 自身的 web UI 里面,同时也可以把这些数据展示到
  • Grafana 这个更专业的做数据可视化的这么一个平台,当然也可以通过接口把数据转到你们自己的web平台里面去
  • 还有push alerts 告警,比如说出现了一些事件之后,通过 Alertmanager 发邮件
  • 这就是一个非常经典的云原生的一个日志监控的一个解决方案
  • 目前业界所有的互联网大公司都会基于这么一套流程去实现日志的收集
  • 我们会从K8s这个node上收取日志,然后展示在Grafana里面
  • 会在K8s上的应用程序,加上一些日志收集的插件,把数据吐到这个Prometheus服务器
  • 这样,在这个监控平台上可以看到这个应用的日志,主要关注:系统集群日志和应用日志
  • Prometheus 比传统监控方案的什么好处
    • 具有由 metric 名称和键/值对标识的时间序列数据的多维数据模型
    • 有一个灵活的查询语言,不用写很复杂的代码即可查询,输入key value
    • 不依赖分布式存储,只和本地磁盘有关
    • 通过 HTTP 的服务拉取时间序列数据
    • 也支持推送的方式来添加时间序列数据
    • 还支持通过服务发现或静态配置发现目标
    • 多种图形和仪表板支持
  • 对比ELK写elastic的语法会比较复杂,但是Prometheus相对来讲更简单

安装时间同步工具

  • 集群都是有很多数据,要实现监控,需要知道监控的指标: 比如,磁盘CPU内存,还有网络的一些异常情况

  • 在这种情况下就需要部署一些能够采集到监控指标的一些服务,我们使用 Node Exporter 来进行集群的任务

  • 我们要实现集群的系统时间同步,这个是非常重要,在每个node节点不管是master还是work node上都要执行

  • 安装

    • 在Centos 8 以下版本执行
      • $ yum -y install ntp
      • $ systemctl enable ntpd
      • $ ntpdate time1.aliyun.com
    • 在 Centos 9 安装
      • $ sudo dnf install chrony
      • $ sudo systemctl start chronyd
      • $ sudo systemctl enable chronyd
      • $ sudo vi /etc/chrony.conf
        server ntp1.aliyun.com iburst
        
      • $ sudo systemctl restart chronyd
      • 之后检查时间和时区
        • $ timedatectl 查看是否是 Time zone: Asia/Shanghai (CST, +0800),如果不是,执行下面
        • $ timedatectl set-timezone Asia/Shanghai
  • 注意,我们用的是时序数据库,时间一定要同步,不同步时间,数据会有问题

部署基础服务抓取数据


1 )概述

  • node-exporter用于提供*NIX内核的硬件以及系统指标
  • 采集服务器层面的运行指标,包括机器的 loadavg、filesystem、meminfo等

2 )说明

  • 此次部署大概分为几个部分
    • namespace 命名空间
      • 所有服务都会安装在这个命名空间之内
      • 保证集群在运行时不会占用其他命名空间的资源
    • node-exporter
      • daemonset 它是一个后台服务 :9100/metrics 部署在9100端口 能够采集到很多数据
      • service 创建了一个 service
    • kube-state-metrics
      • serviceAccount 这里有 clusterrole, serviceaccount, clusterrolebinding
        • clusterrole 通过定义一个集群的角色告诉大家能访问K8s中的什么资源
        • serviceaccount 就是账户名称
        • clusterrolebinding 就是把角色和账户绑定在一起,也就是这个账户具备这个角色的所有权限
      • deploy 这是专门收集日志的组件
      • service 部署服务,暴露端口
      • 备注
        • K8s本质是跑在node节点上的一堆容器组成的服务,本身也要被监控
    • node disk monitor
      • 监视Node的磁盘占用情况
      • 镜像:
        • giantswarm/tiny-tools:latest 工具类,从 work node 抓取变量
        • dockermuenster/caddy:0.9.3
      • 类型是daemonset,每个node上都会部署一份

3 )一键部署

apiVersion: v1
kind: Namespace
metadata:
  name: monitoring
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: prometheus-node-exporter
  namespace: monitoring
  labels:
    app: prometheus
    component: node-exporter
spec:
  selector:
    matchLabels:
      app: prometheus
      component: node-exporter
  template:
    metadata:
      name: prometheus-node-exporter
      labels:
        app: prometheus
        component: node-exporter
    spec:
      containers:
      - image: prom/node-exporter:v0.14.0
        name: prometheus-node-exporter
        ports:
        - name: prom-node-exp
          #^ must be an IANA_SVC_NAME (at most 15 characters, ..)
          containerPort: 9100
          hostPort: 9100
      hostNetwork: true
      hostPID: true
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: 'true'
  name: prometheus-node-exporter
  namespace: monitoring
  labels:
    app: prometheus
    component: node-exporter
spec:
  clusterIP: None
  ports:
    - name: prometheus-node-exporter
      port: 9100
      protocol: TCP
  selector:
    app: prometheus
    component: node-exporter
  type: ClusterIP
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kube-state-metrics
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kube-state-metrics
subjects:
- kind: ServiceAccount
  name: kube-state-metrics
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kube-state-metrics
rules:
- apiGroups: [""]
  resources:
  - nodes
  - pods
  - services
  - resourcequotas
  - replicationcontrollers
  - limitranges
  verbs: ["list", "watch"]
- apiGroups: ["apps"]
  resources:
  - daemonsets
  - deployments
  - replicasets
  verbs: ["list", "watch"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube-state-metrics
  namespace: monitoring
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-state-metrics
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kube-state-metrics
  template:
    metadata:
      labels:
        app: kube-state-metrics
    spec:
      serviceAccountName: kube-state-metrics
      containers:
      - name: kube-state-metrics
#       image: gcr.io/google_containers/kube-state-metrics:v0.5.0
        image: registry.cn-beijing.aliyuncs.com/qua-io-coreos/kube-state-metrics:v1.3.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: 'true'
  name: kube-state-metrics
  namespace: monitoring
  labels:
    app: kube-state-metrics
spec:
  ports:
  - name: kube-state-metrics
    port: 8080
    protocol: TCP
  selector:
    app: kube-state-metrics
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-directory-size-metrics
  namespace: monitoring
  annotations:
    description: |
      This `DaemonSet` provides metrics in Prometheus format about disk usage on the nodes.
      The container `read-du` reads in sizes of all directories below /mnt and writes that to `/tmp/metrics`. It only reports directories larger then `100M` for now.
      The other container `caddy` just hands out the contents of that file on request via `http` on `/metrics` at port `9102` which are the defaults for Prometheus.
      These are scheduled on every node in the Kubernetes cluster.
      To choose directories from the node to check, just mount them on the `read-du` container below `/mnt`.
spec:
  selector:
    matchLabels:
      app: node-directory-size-metrics
  template:
    metadata:
      labels:
        app: node-directory-size-metrics
      annotations:
        prometheus.io/scrape: 'true'
        prometheus.io/port: '9102'
        description: |
          This `Pod` provides metrics in Prometheus format about disk usage on the node.
          The container `read-du` reads in sizes of all directories below /mnt and writes that to `/tmp/metrics`. It only reports directories larger then `100M` for now.
          The other container `caddy` just hands out the contents of that file on request on `/metrics` at port `9102` which are the defaults for Prometheus.
          This `Pod` is scheduled on every node in the Kubernetes cluster.
          To choose directories from the node to check just mount them on `read-du` below `/mnt`.
    spec:
      containers:
      - name: read-du
        image: giantswarm/tiny-tools:latest
        imagePullPolicy: IfNotPresent
        command:
        - fish
        - --command
        - |
          touch /tmp/metrics-temp
          while true
            for directory in (du --bytes --separate-dirs --threshold=100M /mnt)
              echo $directory | read size path
              echo "node_directory_size_bytes{path=\"$path\"} $size" \
                >> /tmp/metrics-temp
            end
            mv /tmp/metrics-temp /tmp/metrics
            sleep 300
          end
        volumeMounts:
        - name: host-fs-var
          mountPath: /mnt/var
          readOnly: true
        - name: metrics
          mountPath: /tmp
      - name: caddy
        image: dockermuenster/caddy:0.9.3
        command:
        - "caddy"
        - "-port=9102"
        - "-root=/var/www"
        ports:
        - containerPort: 9102
        volumeMounts:
        - name: metrics
          mountPath: /var/www
      volumes:
      - name: host-fs-var
        hostPath:
          path: /var
      - name: metrics
        emptyDir:
          medium: Memory
Kubernetes精讲之prometheus Prometheus是一个开源的服务监控系统和时序数据库其提供了通用的数据模型和快捷数据采集、存储和查询接口它的核心组件Prometheus服务器定期从静态配置的监控目标或者基于服务发现自动配置的目标中进行拉取数据新拉取到啊的 数据大于配置的内存缓存区时,数据就会持久化到存储设备当中。 阅读详情

相关推荐

kubernetes部署prometheus监控

kubernetes部署prometheus监控

2302_81167603的博客 1705

K8S-Helm和相关组件(Dashboard、Prometheus、EFK)

在没使用 helm 之前,向 kubernetes 部署应用,我们要依次部署 deployment、svc 等,步骤较繁琐。况且随着很多项目微服务化,复杂的应用在容器中部署以及管理显得较为复杂,helm 通过打包的方式,支持发布的版本管理和控制,很大程度上简化了 Kubernetes 应用的部署和管理。Helm 本质就是让 K8s 的应用管理(Deployment,Service 等 ) 可配置,能动态生成。通过动态生成 K8s 资源清单文件然后调用 Kubectl 自动执行 K8s 资源部署。...

迷雾总会解 1291

k8s部署Prometheus抓取pods的metrics

1.暴露pods给Prometheus抓取 spec: replicas: __app_replicas__ template: metadata: annotations: prometheus.io/scrape: 'true' prometheus.io/path: '/metrics' prometheus.io/port: '9146' 2.部署Prometheus --- apiVersion: rbac.author

yhd723948277的博客 2654

Prometheus监控实战之Prometheus监控K8S

Prometheus监控K8S

sre救赎之路 1万+

Prometheus监控k8s环境构建

node-exporter + prometheus + grafana 是一套非常流行的 Kubernetes 监控方案。node-exporter:节点级指标导出工具,可以监控节点的 CPU、内存、磁盘、网络等指标,并暴露Metrics 接口。Prometheus:时间序列数据库和监控报警工具,可以抓取 Cadvisor 和 node-exporter 暴露的Metrics 接口,存储时序数据,并提供 PromQL 查询语言进行监控分析和报警。

henanchenxuyuan的博客 5074

K8S部署Prometheus

前言:zabbix与prometheus的区别 和Zabbix类似,Prometheus也是一个近年比较火的开源监控框架,和Zabbix不同之处在于Prometheus相对更灵活点,模块间比较解耦,比如告警模块、代理模块等等都可以选择性配置。服务端和客户端都是开箱即用,不需要进行安装。zabbix则是一套安装把所有东西都弄好,很庞大也很繁杂。 zabbix的客户端agent可以比较方便的通过脚...

mcl914的博客 3262

Kubernetes运维之使用Prometheus全方位监控K8S

目录: Prometheus架构 K8S监控指标及实现思路 在K8S平台部署Prometheus 基于K8S服务发现的配置解析 在K8S平台部署Grafana 监控K8S集群中Pod、Node、资源对象 使用Grafana可视化展示Prometheus监控数据 告警规则与告警通知 说在前面的话,现在监控首选的话,肯定是Prometheus+Grafana,也就是很多大型公司也都在用,像RBM,360,网易,基本都是使用这一套监控系统。 一、Prometheus 是什么? Prometheu

Vic的博客 2万+

《kubernetes》Prometheus监控

本文介绍了在Kubernetes集群中部署Prometheus+Grafana监控系统的完整方案。主要内容包括:1)Prometheus监控系统架构及组件解析,包括server、node_exporter等;2)详细部署步骤:创建Prometheus Deployment/Service/ConfigMap/RBAC,部署Node_exporter DaemonSet,安装Grafana可视化组件;3)配置验证,通过NodePort访问Prometheus(9090端口)和Grafana(3000端口);

2301_80348933的博客 1217

K8S部署kube-state-metrics + CAdvisor 并使用 Prometheus 监控 Kubernetes 指标

摘要 本文介绍了使用Prometheus监控Kubernetes集群的方案及架构设计,主要包括容器资源监控(cAdvisor)、宿主机监控(Node Exporter)和集群对象监控(kube-state-metrics)三个层面。通过部署这些组件,Prometheus可以采集K8s集群、节点和Pod的各项指标,并存储到时序数据库(TSDB)中,最终通过Grafana进行可视化展示,结合Alertmanager实现告警功能。 文章详细列出了K8S集群层面和Pod层面的监控指标,并提供了各监控组件的对照表。部

liu_chen_yang的博客 1万+

k8s部署 普罗米修斯(Prometheus)监控

Prometheus是一个开源的服务监控系统和时序数据库其提供了通用的数据模型和快捷数据采集、存储和查询接口它的核心组件Prometheus服务器定期从静态配置的监控目标或者基于服务发现自动配置的目标中进行拉 取数据新拉取到啊的 数据大于配置的内存缓存区时,数据就会持久化到存储设备当中。

D2961953033的博客 3856

(k8s)Kubernetes部署Promehteus

在1.8版本以后heapster由metrics-server替代;从k8s的v1.11版本开始已经全面转向以Prometheus为核心的新监控体系架构;kube-prometheus 中包含了 prometheus 监控所用到的所有组件,当然也包含 prometheus-operator。

Richardlygo的博客 1779

Prometheus监控K8S

Prometheus监控K8S,此文章附带yam文件

礁之的博客 1万+

k8s 结合 Prometheus 构建企业级监控告警系统

k8s 结合 Prometheus 构建企业级监控告警系统

高飞的博客 26万+

进阶之路:从零到一在k8s上部署高可用prometheus —— prometheus

目录导航前言 导航 进阶之路:从零到一在k8s上部署高可用prometheus —— 总览 前言 在进行了一系列准备工作后,终于可以开始部署整个架构的基础 —— prometheus了。

ary的博客 2401

Prometheus 采集rabbitmq监控数据

rabbitmq_exporter 是一个用于将 RabbitMQ(一种开源的消息中间件)指标暴露给 Prometheus 的开源软件。它充当一个代理,运行在与 RabbitMQ 实例相同的主机上,并通过查询 RabbitMQ 的管理 API 来获取有关队列、交换机、连接等方面的信息。rabbitmq_exporter 从 RabbitMQ 收集各种与消息中间件相关的指标,如队列消息数量、消费者数量、发布速率、内存使用量、网络连接数等,并将这些指标数据转换成 Prometheus 可以理解的格式。

极致,细节 2804

【Prometheus】k8s集群内部署的prometheus如何监控kubernetes集群

在前面的章节中,我们已经介绍了 Prometheus 的核心功能,并展示了如何使用二进制部署的Prometheus来监控 Kubernetes 的 APIServer。 但在实际的生产环境中,我们通常是将 Prometheus 部署在 Kubernetes 集群内部,来监控整个集群的资源及状态。

景天科技苑 6万+

K8S 部署Prometheus

1.为了能够方便的管理配置文件,这里将 prometheus.yml 文件用 ConfigMap的形式进行管理: 创建configMap并将配置文件内容写在data字段中: # cat pro_cm.yaml apiVersion: v1 kind: ConfigMap metadata: name: prometheus-config namespace: kube-mon data: prometheus.yml: | global: scrape_interval

lovely_nn的博客 1万+

01-FreeSWITCH 的安装、部署、配置以及可能遇到的问题和解决方法

一文让您了解从FreeSWITCH 的安装、部署、配置、可能遇到的问题及解决方法。一切从实际项目出发,以工程应用为目的。

秋风的博客 2128

Prometheus - 服务发现深度解析:Consul / K8s 自动发现配置

Consul 是 HashiCorp 推出的服务网格解决方案,提供服务发现、健康检查、KV 存储、多数据中心等能力。其服务注册模型简单直观:服务实例启动时向 Consul Agent 注册自身信息(名称、IP、端口、健康检查等),Prometheus 则通过 Consul HTTP API 查询这些信息。Prometheus 的服务发现机制是其适应云原生环境的核心能力。通过与Consul和Kubernetes✅动态目标管理:自动感知实例变化;✅零配置扩展:新服务上线即被监控;✅环境隔离。

千淘万漉虽辛苦,吹尽狂沙始到金 2万+

机械臂视觉抓取避坑指南:如何正确计算手眼标定矩阵(附Numpy代码)

本文详细解析了机械臂视觉抓取中手眼标定矩阵的计算方法,特别针对'眼在手上'配置下的常见错误提供了解决方案。通过Numpy代码示例和坐标转换原理,帮助开发者避免矩阵计算错误和坐标转换偏差,提升工业自动化系统的精度和效率。

weixin_29081703的博客 243

语音识别(ASR)-- Kaldi 学习笔记

语音识别(ASR)-- Kaldi学习笔记语音识别简介GMM-HMM基本原理DNN-HMM(基于神经网络)KaldiKaldi架构简介Kaldi在Windows下的安装工具准备编译OpenFST配置PortAudio配置KaldiKaldi目录说明 语音识别简介 语音识别(Speech Recognition)技术,也被称为自动语音识别(Automatic Speech Recognition, ASR)、计算机语音识别(Computer Speech Recognition)或是语音转文本识别(Spee

qq_43318971的博客 4849
上一篇: K8s: Helm包管理工具的应用以及项目分环境部署
下一篇: K8s: Prometheus 监控主机 和 K8s 集群
Wang's Blog
博客等级 码龄12年 7433粉丝 2421原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Wang's Blog

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值