Prometheus 监控 Kubernetes 集群

最新推荐文章于 2024-09-18 12:35:08 发布
最新推荐文章于 2024-09-18 12:35:08 发布
阅读量788 收藏 1
点赞数
分类专栏： Kubernetes Prometheus 文章标签： prometheus kubernetes kube-prometheus jsonnet
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ni_new_sm_new/article/details/114041941
版权

Prometheus介绍

首先看到Prometheus官方架构图：

download_image

exporter和pushgatway

数据通过exporter和pushgatway收集存储起来，再由Prometheus服务进行拉取操作。这样的设计把数据压力分摊到了各个收集节点，不会导致收集节点过多而Prometheus承受不住数据冲击而宕机。

对于收集的方式通过exporter或pushgatway暴露http/https端口地址进行采集，也就是除了官方提供的exporter之外，我们可以很好的进行定制exporter，只需满足Prometheus的数据格式，在暴露到地址即可。具体细节可以查看 开发自己的exporter。pushgatway 用于不方便去提供一个采集接口时，Prometheus提供的官方接口，可以直接把数据发到pushgatway中，这样也可以收集到发送到数据。但是pushgatway不保证数据的生命周期在你的管控之中，因为pushgatway的控制权在Prometheus，如果pushgatway宕机了，你发的数据就会丢失。所以官方推荐短期任务可以借助pushgatway，而不自己开发exporter。

Prometheus Server

在使用Prometheus监控时，需要有一个念头：Prometheus监控指标，而不能详细到具体数据。而指标不是百分百精确，它有大概的趋势，来帮助我们发现和预判问题。如果需要详细的问题调查体系，则需要日志收集框架和链路追踪框架支撑。所以查看问题的顺序是这样子的：指标监控->日志查询->链路追踪查询，获得的信息逐渐增多，但是所要做的事也增多了。

了解了上面的信息，还需要注意的是：Prometheus认为只有最近的监控数据才有查询的需要，所有Prometheus本地存储的设计初衷只是保存短期（如一个月）的数据，不会针对大量的历史数据进行存储。也就是说，数据保留可能不会太久（长久的数据价值可能远超保留它的代价）。如果需要存储，则需要其他的扩展方案。在图中可以看到，对于存储Prometheus使用自带的TSDB进行存储，对于采集节点服务发现和Kubernetes集成，这也是很关键的一点。

数据展示、报警

Prometheus收集数据存储到本地，这些数据可以配置成rule、alert两种聚合数据，rule会被Grafana收集进行展示、alert会被Alertmanager进行收集报警。这两个组件的灵活度都特别的高，但是不是本节重点，继续往后看。

使用

在之前开发流程是这样的，下载Prometheus、Exporter、Grafana、Alertmanager。之后在Prometheus中配置对应的exporter信息，rule、alert。当然这些都可以通过Docker或者Kubernetes的配置文件一件部署，在kubernetes下则可能是这样子的：

5e2cf43a-079b-4b7f-8bac-b184bcb404a7

可以看到Prometheus连接着其他的组件。当然，连接会通过Service组件连接，防止exporter或组件宕机、升级在集群中重新调度时的ip丢失。但是如果需要添加组件，如新的采集节点，则需要手动修改配置文件。这样维护起来在大集群里可能成本比较高。于是之后就出现了Prometheus-Operator。

Prometheus-Operator是在Kubernetes中的一组CRD，所以它所有的操作都是依赖于Kubernetes的。通过Kubernetes平台优化了上面的问题和添加功能，先看看架构图：

5e180075-bdc8-4845-9776-bad212dd4a2b

可以看到在Prometheus和组件的连接中又抽象了一层ServiceMonitor，ServiceMonitor通过label进行选择组件的连接，和Kubernetes中的一样，我们通过操作类似label选择器的机制去管理组件。除了和Prometheus的连接管理之外，Operator还管理着Grafana和Alertmanager，它们各自的配置文件都可以动态进行更新，此外还抽象出了rule组件，这样rule、alert都可以进行动态更新和管理。

上面所有的管理工作都是由Operator组件完成，它通过prometheus对应reload的http接口/-/reload，如果Operator监听到了配置的变化，就对调用此接口进行配置动态更新。具体细节可能会更加复杂一点。

Kube-Prometheus介绍

有了Kube-Prometheus之后，虽然知道它扩展很方便，但是我们还是希望有一个通用的配置，之后我们在通过修改配置去定制自己的监控集群。原因是一套完整的监控架构需要写的配置文件还是挺多的。😦

于是就有了Kube-Prometheus项目，Kube-Prometheus项目可以通过一些配置快速的生成一套适应你集群的配置文件，之后你在修改生成的配置去适应你的集群，这样就节省了很多时间了。下面就介绍它是如何实现的。

  • 使用官方推荐的Kube-Prometheus进行部署，原理是使用Jasonnet工具生成配置文件。
  • 使用Helm社区维护的Chart部署

使用哪一种方法好？

  • jsonnet本质是类似模版语言工具进行生成配置文件， helm 从某种程度上来说也是做这件事的，由于 Prometheus 相关社区(Grafana、Prometheus-Operator、 Kube-prometheus) 都使用 Jsonnet 做配置管理, 应该有它的理由。
  • Helm维护的配置文件没有Jsonnet来的完备、及时。（官方亲儿子）
  • Json格式上的优势，它不需要考虑空格锁进问题。

我们这里就选择Jsonnet方式进行生成配置然后部署，在开始前先简单介绍jsonnet。

Jsonnet介绍

Jsonnet是一个模版语言工具，语法酷似Python，所以上手起来还是满快的。下面通过例子快速了解下它能做到什么，具体细节和语法推荐到官方上学习。jsonnet官网

下面你可以跟着做，然后观察它的输出。当然，安装jsonnet是必须的，如果你还要使用Kube-Prometheus的话。

最后的引用库文件代码会生成一个库文件，除此之外不会有其他输出文件。

# 安装 Jsonnet(C 实现)
brew install jsonnet

# 也可以安装 Go 实现
go get github.com/google/go-jsonnet/cmd/jsonnet

# 基本用法: 解释运行一个 jsonnet 源码文件
echo "{hello: 'world'}" > test.jsonnet
jsonnet test.jsonnet

# 对于简单的代码也可以使用 -e 直接运行
jsonnet -e '{hello: "world"}'

# 字段可以不加引号 自动格式化
jsonnet -e '{key: 1+2, hello: "world"}'

# 类比: Jsonnet 支持与主流语言类似的四则运算, 条件语句, 字符串拼接, 
# 字符串格式化, 数组拼接, 数组切片以及 python 风格的列表生成式
jsonnet - <<EOF
{
  array: [1, 2] + [3],
  math: (4 + 5) / 3 * 2,
  format: 'Hello, %s' % 'world',
  concat: 'Hello, ' + 'world',
  slice: [1,2,3,4][1:3],
  'list': [x * x for x in [1,2,3,4]],
  condition:
    if 2 > 1 then
    'true'
    else
    'false',
}
EOF

# 使用变量:
#   使用 :: 定义的字段是隐藏的(不会被输出到最后的 JSON 结果中), 
#   这些字段可以作为内部变量使用(非常常用)

#   使用 local 关键字也可以定义变量
#   JSON 的值中可以引用字段或变量, 引用方式:
#     变量名
#     self 关键字: 指向当前对象
#     $ 关键字: 指向根对象
jsonnet - <<EOF
{
  local hello = 'hello',
  world:: 'world',
  message: {
    hello: hello,
    world: $.world,
    _hello: self.world,
  }
}
EOF

# 使用函数:
# 定义与引用方式与变量相同, 函数语法类似 python
jsonnet - <<EOF
{
  local hello(name) = 'hello %s' % name,
  sum(x, y):: x + y,
  newObj(name='hello', age=23):: {
    name: name,
    age: age
  },
  call_sum: $.sum(1, 2),
  call_hello: hello('world'),
  me: $.newObj(age=24),
}
EOF

# Jsonnet 使用组合来实现面向对象的特性(类似 Go)
#   Json Object 就是 Jsonnet 中的对象
#   使用 + 运算符来组合两个对象, 假如有字段冲突, 
#   使用右侧对象(子对象)中的字段

#   子对象中使用 super 关键字可以引用父对象, 
#   用这个办法可以访问父对象中被覆盖掉的字段
jsonnet - <<EOF
local base = {
  o: 'hello world',
  no: {
      hello: 'world'
  }
};
base + {
  o: 'hello zhangsan',
  # +: 组合而非覆盖
  no+: {
      nihao: 'zhangsan'
  },
  super_o: super.o
}
EOF

# 库与 import:
#  jsonnet 共享库复用方式其实就是将库里的代码整合到当前文件中来,
#  引用方式也很暴力, 使用 -J 参数指定 lib 文件夹, 再在代码里 import 即可
#  jsonnet 约定库文件的后缀名为 .libsonnet
cat > hello.libsonnet <<EOF
{
  helloObj(hello='world', name):: {
    hello: hello,
    names: [], #声明数组
    sayhello(name):: self + {
      names +: [name],
    },
  }
}
EOF

#import调用
jsonnet -J . - <<EOF
local helloPackage = import './hello.libsonnet';
helloPackage.helloObj(name='world')
  .sayhello('zhangsan')
  .sayhello('lisi')
EOF

Kube-Prometheus安装、配置

有了上面的知识之后，就可以着手定制自己的配置文件了。我会逐一介绍，按照官方的配置的定制流程。

首先看生成脚本

#!/usr/bin/env bash

# This script uses arg $1 (name of *.jsonnet file to use) to generate the manifests/*.yaml files.

set -e
set -x
# only exit with zero if all commands of the pipeline exit successfully
set -o pipefail

# Make sure to use project tooling
#PATH="$(pwd)/tmp/bin:${PATH}"

# Make sure to start with a clean 'manifests' dir
rm -rf manifests
mkdir -p manifests/setup

# 执行jsonnet生成定制的文件，引入的包为vendor，配置文件为脚本传入（默认为example.jsonnet）之后gojsontoyaml将json转化为yaml格式，最后输出到文件里
jsonnet -J vendor -m manifests "${1-example.jsonnet}" | xargs -I{} sh -c 'cat {} | gojsontoyaml > {}.yaml' -- {}

# Make sure to remove json files
find manifests -type f ! -name '*.yaml' -delete
rm -f kustomization

了解到安装方式之后，只要下载项目中的 vendor 包就可以了。之后创建一个定制的配置文件。安装完成之后的目录是这样的：

.
├── build.sh #生成配置文件的脚本
├── jsonnetfile.json #版本信息
├── jsonnetfile.lock.json
├── monitor.jsonnet # 手动创建脚本的配置信息
└── vendor
    ├──...jsonnet依赖的包

之后编写定制文件：

local kp =
  (import 'kube-prometheus/kube-prometheus.libsonnet') + //基本配置
  // (import 'kube-prometheus/kube-prometheus-kube-aws.libsonnet') + //Aws集群特殊配置
  // (import 'kube-prometheus/kube-prometheus-strip-limits.libsonnet') +
  // Uncomment the following imports to enable its patches
  // (import 'kube-prometheus/kube-prometheus-anti-affinity.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-managed-cluster.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-node-ports.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-static-etcd.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-thanos-sidecar.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-custom-metrics.libsonnet') +
  // (import 'kube-prometheus/kube-prometheus-external-metrics.libsonnet') //+
  // 配置全局或提供的动态配置，这里只设置了全局的命名空间  
  {
    _config+:: {
      namespace: 'monitoring'
    }
  };

{ ['setup/0namespace-' + name]: kp.kubePrometheus[name] for name in std.objectFields(kp.kubePrometheus) } +
{
  ['setup/prometheus-operator-' + name]: kp.prometheusOperator[name]
  for name in std.filter((function(name) name != 'serviceMonitor'), std.objectFields(kp.prometheusOperator))
} +
// 如果要添加更多的export 在这里添加
// serviceMonitor is separated so that it can be created after the CRDs are ready
{ 'prometheus-operator-serviceMonitor': kp.prometheusOperator.serviceMonitor } +
{ ['node-exporter-' + name]: kp.nodeExporter[name] for name in std.objectFields(kp.nodeExporter) } +
//{ ['blackbox-exporter-' + name]: kp.blackboxExporter[name] for name in std.objectFields(kp.blackboxExporter) } + #如果需要黑盒则放开
{ ['kube-state-metrics-' + name]: kp.kubeStateMetrics[name] for name in std.objectFields(kp.kubeStateMetrics) } +
{ ['alertmanager-' + name]: kp.alertmanager[name] for name in std.objectFields(kp.alertmanager) } +
{ ['prometheus-' + name]: kp.prometheus[name] for name in std.objectFields(kp.prometheus) } +
{ ['prometheus-adapter-' + name]: kp.prometheusAdapter[name] for name in std.objectFields(kp.prometheusAdapter) } +
{ ['grafana-' + name]: kp.grafana[name] for name in std.objectFields(kp.grafana) }

AWS集群由于kube-system中组件的label可能丢失，导致监控丢失。所以会帮我们自动生成service文件。这里只要记住如果是aws管理的集群添加这个是保险的。

运行脚本

./build.sh monitor.jsonnet

脚本会生成监控相关的所有配置文件，CRD文件存放在./manifests/setup中，资源文件存放在./manifests中。查看manifests的文件如下。现在就可以开始修改一些配置信息，来满足你的需要了。接下来挑几个重要的文件，并添加常用的一些配置提供参考。

manifests
# alertmanager相关配置
├── alertmanager-alertmanager.yaml
├── alertmanager-secret.yaml # 告警配置
├── alertmanager-service.yaml
├── alertmanager-serviceAccount.yaml
├── alertmanager-serviceMonitor.yaml
# grafana相关配置
├── grafana-dashboardDatasources.yaml
├── grafana-dashboardDefinitions.yaml
├── grafana-dashboardSources.yaml
├── grafana-deployment.yaml
├── grafana-service.yaml
├── grafana-serviceAccount.yaml
├── grafana-serviceMonitor.yaml
# kubernetes集群指标监控
├── kube-state-metrics-clusterRole.yaml
├── kube-state-metrics-clusterRoleBinding.yaml
├── kube-state-metrics-deployment.yaml
├── kube-state-metrics-service.yaml
├── kube-state-metrics-serviceAccount.yaml
├── kube-state-metrics-serviceMonitor.yaml
# 各个几点指标监控
├── node-exporter-clusterRole.yaml
├── node-exporter-clusterRoleBinding.yaml
├── node-exporter-daemonset.yaml
├── node-exporter-service.yaml
├── node-exporter-serviceAccount.yaml
├── node-exporter-serviceMonitor.yaml
# kubernetes hpa相关适配器
├── prometheus-adapter-apiService.yaml
├── prometheus-adapter-clusterRole.yaml
├── prometheus-adapter-clusterRoleAggregatedMetricsReader.yaml
├── prometheus-adapter-clusterRoleBinding.yaml
├── prometheus-adapter-clusterRoleBindingDelegator.yaml
├── prometheus-adapter-clusterRoleServerResources.yaml
├── prometheus-adapter-configMap.yaml
├── prometheus-adapter-deployment.yaml
├── prometheus-adapter-roleBindingAuthReader.yaml
├── prometheus-adapter-service.yaml
├── prometheus-adapter-serviceAccount.yaml
├── prometheus-adapter-serviceMonitor.yaml
# prometheus相关配置
├── prometheus-clusterRole.yaml
├── prometheus-clusterRoleBinding.yaml
├── prometheus-kubeControllerManagerPrometheusDiscoveryService.yaml
├── prometheus-kubeSchedulerPrometheusDiscoveryService.yaml
├── prometheus-operator-serviceMonitor.yaml
├── prometheus-prometheus.yaml # 监控配置
├── prometheus-roleBindingConfig.yaml
├── prometheus-roleBindingSpecificNamespaces.yaml
├── prometheus-roleConfig.yaml
├── prometheus-roleSpecificNamespaces.yaml
├── prometheus-rules.yaml # 默认监控项
├── prometheus-service.yaml
├── prometheus-serviceAccount.yaml
# serviceMonitor相关配置
├── prometheus-serviceMonitor.yaml
├── prometheus-serviceMonitorApiserver.yaml
├── prometheus-serviceMonitorCoreDNS.yaml
├── prometheus-serviceMonitorKubeControllerManager.yaml
├── prometheus-serviceMonitorKubeScheduler.yaml
├── prometheus-serviceMonitorKubelet.yaml
└── setup # CRD文件
    ├── 0namespace-namespace.yaml
    ├── prometheus-operator-0alertmanagerConfigCustomResourceDefinition.yaml
    ├── prometheus-operator-0alertmanagerCustomResourceDefinition.yaml
    ├── prometheus-operator-0podmonitorCustomResourceDefinition.yaml
    ├── prometheus-operator-0probeCustomResourceDefinition.yaml
    ├── prometheus-operator-0prometheusCustomResourceDefinition.yaml
    ├── prometheus-operator-0prometheusruleCustomResourceDefinition.yaml
    ├── prometheus-operator-0servicemonitorCustomResourceDefinition.yaml
    ├── prometheus-operator-0thanosrulerCustomResourceDefinition.yaml
    ├── prometheus-operator-clusterRole.yaml
    ├── prometheus-operator-clusterRoleBinding.yaml
    ├── prometheus-operator-deployment.yaml
    ├── prometheus-operator-service.yaml
    └── prometheus-operator-serviceAccount.yaml

prometheus配置

查看 prometheus-prometheus.yaml 文件

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  labels:
    prometheus: k8s
  name: k8s
  namespace: monitoring
spec:
  alerting:
    alertmanagers:
    - name: alertmanager-main
      namespace: monitoring
      port: web
  image: quay.io/prometheus/prometheus:v2.22.1
  nodeSelector:
    kubernetes.io/os: linux
  podMonitorNamespaceSelector: {}
  podMonitorSelector: {}
  probeNamespaceSelector: {}
  probeSelector: {}
  replicas: 2 # 设置副本数
  retention: 15d # 添加数据保留期限
  # 如果需要添加集群外部数据采集， 在这里添加配置文件
  #additionalScrapeConfigs:
    #name: additional-scrape-configs
    #key: prometheus-additional.yaml
  #添加sc
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: xxx
        resources:
          requests:
            storage: 50Gi
  resources:
    requests:
      memory: 400Mi
  ruleSelector:
    matchLabels:
      prometheus: k8s
      role: alert-rules
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: prometheus-k8s
  serviceMonitorNamespaceSelector: {}
  serviceMonitorSelector: {}
  version: v2.22.1

如果配置了外部采集节点，创建 prometheus-additional-secret.yaml：

# prometheus-additional-secret.yaml
apiVersion: v1
data: {}
kind: Secret
metadata:
  name: additional-scrape-configs
  namespace: monitoring
stringData:
  prometheus-additional.yaml: |-
    - job_name: "prometheus-demo"
      metrics_path: "metrics"
      static_configs:
      - targets: ["xxx:8080"]
type: Opaque

prometheus-rule配置

查看 prometheus-rules.yaml 文件

53b217e9-b50c-49c2-ae25-e2afd8864921

可以看到该项目内置了很多告警项，可以根据自己需要删减。过多的rule可能会影响性能和消耗更多的内存，所以还是根据自己的需要来配置。当然这些rule对于后面Grafana展示都是有用到的。Grafana中的图表也是根据这些规则配置好了的，两者是相关联的。

alertmanager-secret.yaml配置

创建 alertmanager-secret.yaml文件。具体需要的配置看 alertmanager config。

apiVersion: v1
data: {}
kind: Secret
metadata:
  name: alertmanager-main
  namespace: monitoring
stringData:
  alertmanager.yaml: |-
    global:
      resolve_timeout: 2h

      smtp_smarthost: 'smtp.qq.com:465'
      smtp_from: 'xxx@xx.com'
      smtp_auth_username: 'xxx@xx.com'
      smtp_auth_password: 'xxx'
      smtp_require_tls: false
    route:
      group_by: ['alertname']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      receiver: default
      routes:
      - receiver: 'email-receiver'
        group_wait: 30s
        match:
          notify: notify
    receivers:
      - name: email-receiver
        email_configs:
        - to: 'xxx@xx.com'
          send_resolved: true
        - to: 'xxx@xx.com'
          send_resolved: true
      - name: 'default'
        webhook_configs:
        - url: 'http://xxx'
          send_resolved: true
type: Opaque

查看监控信息

完成配置定制之后运行

kubectl apply -f manifests/setup
kubectl apply -f manifests/

以下内容为将端口映射到本地主机端口

kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090

访问地址 http://localhost:9090

kubectl --namespace monitoring port-forward svc/grafana 3000

访问地址 http://localhost:3000 用户名和密码为 admin:admin

kubectl --namespace monitoring port-forward svc/alertmanager-main 9093

访问地址 http://localhost:9093

扩展

Grafana仪表盘图

参考 https://grafana.com/grafana/dashboards

更多监控报警规则参考 https://awesome-prometheus-alerts.grep.to/rules

遇到的问题

manifests/prometheus-rules.yaml 部署失败

Error from server (InternalError): error when creating “manifests/prometheus-rules.yaml”: Internal error occurred: failed calling webhook “prometheusrulemutate.monitoring.coreos.com”: Post https://kube-prometheus-stack-1607-operator.default.svc:443/admission-prometheusrules/mutate?timeout=10s: service “kube-prometheus-stack-1607-operator” not found

具体问题查看 https://github.com/helm/charts/issues/21080

解决：

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io
#do 删除 kube-prometheus..资源

kubectl get MutatingWebhookConfiguration
#do 删除 kube-prometheus..资源

#重新载入
kubectl apply -f manifests/prometheus-rules.yaml
两个监控任务没有对应的目标

访问 Prometheus

img

遇到这种情况一般是你下载的版本和你的Kubernetes集群版本不匹配，导致label丢失，所以ServiceMonitor找不到对应的Service。

解决思路

  • 查看 ServiceMonitor 对应的服务端口是否存在
  • 服务端口是否匹配到正确到po（查看po是否含有匹配标签）
  • 通信协议是否正确（http/https）
_changeme
关注
专栏目录
自动化部署Prometheus监控Kubernetes集群实战
悦分享
08-23 290
prometheus是非常流行的监控服务，但是对于k8s的监控需要做很多接口，这导致了prometheus监控K8s比较复杂，官方就出了kube-prometheus这么一个项目，它是Prometheus operator的定制版，如果我们想获取完整的k8s服务监控指标，推荐采用kube-prometheus的方式。安装manifest目录下的所有yaml文件，kube-prometheus默认安装在monitoring命名空间中，安装过程是非常缓慢的，有些镜像在国外，还会因为拉取不到而安装失败。
手工部署Prometheus监控Kubernetes集群实战
悦分享
08-24 306
Prometheus的数据指标是通过一个公开的HTTP(S)数据接口获取到的，对于一些普通的HTTP服务，我们添加一个/metrics接口暴露给Prometheus即可，现在很多服务从一开始就内置了一个/metrics接口，比如Kubernetes的各个组件都直接提供了数据指标接口，有一些服务即使没有原生集成该接口，也完全可以使用一些exporter来获取到指标数据，比如mysqld_exporter、node_exporter等。这就是Prometheus里面非常重要的服务发现功能了。
Prometheus：监控与告警：14: 与Kubernetes集成的方式
知行合一 止于至善
01-30 1914
在前一篇文章中介绍了Prometheus下的服务发现的机制，比如基于文件的服务发现(file_sd_configs)以及基于Consul的服务发现机制（consul_sd_configs），而Kubernetes也提供了类似的机制以便于和Prometheus的集成（kubernetes_sd_configs）。我们将在这篇文章中对于kubernetes_sd_configs的使用方式进行说明。
kube-prometheus离线安装-服务发现以及监控集群外主机
weixin_42323357的博客
11-05 315
有空再来
Prometheus监控k8s环境构建
最新发布
henanchenxuyuan的博客
09-18 2465
node-exporter + prometheus + grafana 是一套非常流行的 Kubernetes 监控方案。node-exporter:节点级指标导出工具,可以监控节点的 CPU、内存、磁盘、网络等指标,并暴露Metrics 接口。Prometheus:时间序列数据库和监控报警工具,可以抓取 Cadvisor 和 node-exporter 暴露的Metrics 接口,存储时序数据,并提供 PromQL 查询语言进行监控分析和报警。
kubernetes监控prometheus配置项解读
weixin_30954607的博客
07-18 227
前言 文中解决两个问题： 1. kubernetes官方推荐的监控 prometheus 的配置文件, 各项是什么含义 2. 配置好面板之后, 如换去配置 grafana 面板 当然这两个问题网上都有很多完整的模板，可以直接套用，这里我分享一下如换去理解这些内容 准备环境： 1.需要一个 kubernetes 集群 2. grafana 部署文件 3. pro...
Prometheus监控实践：Kubernetes集群监控
01-27
基础设施层：监控各个主机服务器资源(包括Kubernetes的Node和非Kubernetes的Node)，如CPU,内存,网络吞吐和带宽占用,磁盘I/O和磁盘使用等指标。中间件层：监控独立部署于Kubernetes集群之外的中间件，例如：MySQL、Redis、RabbitMQ、ElasticSearch、Nginx等。Kubernetes集群：监控Kubernetes集群本身的关键指标Kubernetes集群上部署的应用：监控部署在Kubernetes集群上的应用其中基础设施层监控指标的拉取肯定是来在Prometheus的node_exporter，因为我们要监控的服务器节点既包含Kube
Prometheus+Grafana监控Kubernetes-配套yaml.zip
05-22
Prometheus+Grafana监控Kubernetes-配套yaml.zip grafana.yaml、Kubernetes Pod Resources.json、namespace.yaml、node-exporter.yaml、prometheus.yaml
如何使用Prometheus监控Kubernetes集群_prometheus 监控 kubernetes
2401_84247341的博客
04-19 810
带有所有 Prometheus 刮削配置和警报规则的配置映射被挂载到 /etc/prometheus 位置中的Prometheus 容器中，作为 prometheus.yaml 和 prometheus.rules 文件。在此配置中，我们将Prometheus配置映射作为文件挂载到 /etc/prometheus 中，如前一节所述。通过将 Prometheus 配置外部化到 Kubernetes 配置映射，你不必在需要添加或删除配置时构建Prometheus 映像。Prometheus 的所有配置在。
基于Prometheus监控Kubernetes集群
时间的博客
08-17 690
Prometheus性能也足够支撑上万台规模的集群。Kubeadm 通过初始化安装是不包括网络插件的，也就是说初始化之后是不具备相关网络功能的，比如 k8s-master 节点上查看节点信息都是“Not Ready”状态、Pod 的 CoreDNS无法提供服务等。-rw-rw-r--. 1 root root 1114 11月 17 2020 prometheus.deploy.yml。-rw-rw-r--. 1 root root 237 1月 7 2019 prometheus.svc.yml。
Prometheus本地存储和VictoriaMetrics远端存储
梵修
02-26 3566
Prometheus的本地存储被称为Prometheus TSDB，目前是V3版本，根据官方介绍其有着非常高效的时间序列数据存储方法，每个采样数据仅占3.5byte左右空间，上百万条时间序列，30s间隔，保存60天，仅占200多G空间默认情况下，Prometheus将采集到的数据保存在本地的TSDB数据库中，默认目录为Prometheus安装目录下的data目录。
kubernetes部署prometheus
认知 行动 坚持
06-22 2121
Prometheus是一款由SoundCloud开发的开源监控系统，它提供了实时监测和报警功能。使用kubernetes来部署prometheus服务，prometheus数据持久化到NFS。亲测可用。
kubernetes-prometheus
jfcjjg的博客
03-24 2108
部署 查询数据 例：可以取到一些对应指标
VictoriaMetrics
qq_51384368的博客
05-14 2777
VictoriaMetrics，是一个快速高效、经济并且可扩展的监控解决方案和时序数据库本文均用VM简称VictoriaMetric。
kube-prometheus部署
Student_xx的博客
05-21 1989
其中最重要的是上面 labels 和 selector 部分，labels 区域的配置必须和我们上面的 ServiceMonitor 对象中的 selector 保持一致，selector 下面配置的是。这两个标签，而前面这个标签具有更唯一的特性，所以使用前面这个标签较好，这样上面创建的 Service 就可以和这个 Pod 进行关联了。，更改后 kube-scheduler 会自动重启，重启完成后再去查看 Prometheus 上面的采集目标就正常了。2、对kube-Scheduler的监控。
kubernetes报错Error from server (AlreadyExists): error when creating "kubernetes-dashboard.yaml": serv
热门推荐
汐银的博客
11-12 2万+
在执行： kubectl apply -f kubernetes-dashboard.yaml 报错 Error from server (AlreadyExists): error when creating "kubernetes-dashboard.yaml": services "kubernetes-dashboard" already exist 初步判断是存在dashboa...
Prometheus配置远程写入数据到victoriametrics
一个行走江湖的人
12-06 1073
【代码】Prometheus配置远程写入数据到victoriametrics。
Victoriametrics单机版本地安装搭配Prometheus和grafana使用教程
shnu_cdk的博客
02-20 1787
准备：安装Prometheus和grafana的教程请参考本人之前写过的文章。
运维开发实践 - Kubernetes - 部署Prometheus
Yuan_xii的博客
11-08 1004
prometheus部署
Prometheus监控kubernetes集群有几种方法
03-25
A：在Kubernetes中，有多种方法可以监控整个集群，其中包括以下几种方法： 1. 使用Kubernetes原生的监控工具：Kubernetes提供了一组原生的监控工具，包括Kubelet、kube-state-metrics和Heapster等，可以监控集群的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值