rancher

转自: https://blog.fleeto.us/post/k8s-faster-services-no-cpu-limits/ 配合站内最大最小内存设置为一致文章一起阅读 Kubernetes：移除 CPU 限制，服务运行更快我们（Buffer）早在 2016 年就开始使用 Kubernetes 了。我们使用 kops 对 Kubernetes 集群进行管理，其中包含了大约 60 个运行在 AWS 的节点，运行着 1500 个左右的容器。我们的微服务迁移之路充满坎坷。在和 Kubernetes 相处多年以后，我们还是会时不时遭到它的毒打。本文接下来要讨论的案例就是这样——CPU Limit 是一头披着狼皮的羊。 CPU 限制和流控Google 等公司强烈建议设置 CPU 限制。如果不进行这一限制，节点上的容器可能会耗尽所有 CPU 资源，这可能会引发多种意料之外的事故——例如导致 Kubernetes 关键进程（比如说 kubelet）停止响应。因此理论上为容器设置 CPU 限制能够很好的对节点进行保护。 该特性能限制一个容器在给定周期内（缺省为 100 毫秒）能够消耗...

导入集群 进入之后选择导入已有集群,随后进入此页面,点击创建 对于自签证书选择第二项,复制,然后在k3s-server节点执行 问题error: no objects passed to apply 这里的问题主要是无法连接到部署Rancher的主机，无法获取yaml文件导致的。可以将yaml文件直接下载到k3s-server，再手动执行kubectl apply -f {xxx}.yaml (针对配置了--tls-san参数 - 自签证书)可能会执行失败,提示域名rancher.k3s.cn 不识别(前面的证书域名以及对应ip) 更新资源的字段 1234567891011121314151617181920212223242526272829303132333435(because the cert was made by myself,so i need configured the hosts, otherwise it does not know my cert's domain name,unless you used ip in...

前言随着 Prometheus 监控的组件、数量、指标越来越多，Prometheus 对计算性能的要求会越来越高，资源占用也会越来越高。 在这种情况下，要优化 Prometheus 性能, 优化存储占用. 第一时间想到的可能是各种 Prometheus 的兼容存储方案, 如 Thanos 或 VM、Mimir 等。但是实际上虽然集中存储、长期存储、存储降采样及存储压缩可以一定程度解决相关问题，但是治标不治本。 真正的本，还是在于指标量（series）过于庞大。 治本之法，应该是减少指标量。有 2 种办法： 解决高基数问题 根据实际使用情况，只保留（keep）展示（Grafana Dashboards）和告警（prometheus rules）会用到的指标。 高基数问题什么是基数(Cardinality)?基数的 基本定义 是指一个给定集合中的元素的数量。 在Prometheus中指代series 的基数 (High Cardinality) 在 Prometheus 和可观察性的世界里，标签基数 是非常重要的，因为它影响到你的监控系统的性能和资源使用。 下面这张...

我在第二章中有介绍使用koa整合Prometheus自定义指标，这里记录下整合Springboot和Prometheus实现自定义指标 要在Spring Boot中使用Micrometer-registry-prometheus记录QPS和响应时间，可以按照以下步骤操作 Spring-boot-starter-actuatorSpringBoot中的spring-boot-starter-actuator依赖已经集成了对Micrometer的支持，其中的metrics端点的很多功能就是通过Micrometer实现的，prometheus端点默认也是开启支持的，实际上actuator依赖的spring-boot-actuator-autoconfigure中集成了对很多框架的开箱即用的API，其中prometheus包中集成了对Prometheus的支持，使得使用了actuator可以轻易地让项目暴露出prometheus端点，使得应用作为Prometheus收集数据的客户端，Prometheus（服务端软件）可以通过此端点收集应用中Micrometer的度量数据。 整合M...

介绍Grafana 是一款采用 go 语言编写的开源应用，可以从Elasticsearch，Prometheus，Graphite，InfluxDB等各种数据源中获取数据，并通过精美的图形将其可视化。 除了Prometheus的AlertManager 可以发送报警，Grafana 同时也支持告警。Grafana 可以无缝定义告警在数据中的位置，可视化的定义阈值，并可以通过钉钉、email等平台获取告警通知。最重要的是可直观的定义告警规则，不断的评估并发送通知。 由于Grafana alert告警比较弱，大部分告警都是通过Prometheus Alertmanager进行告警. 安装见：https://github.com/behappy-project/behappy-docker-application/tree/master/grafana 图表配置 在时序图表配置场景下，我们需要核心关注配置的有: Metrics: promQL查询语句【注：当使用rancher部署方式时，此处编写会有乱码情况，解决办法是在PrometheusUI中编写粘贴到这里】 Legen...

介绍Prometheus是一套成熟且流行的系统和服务监控系统，它几乎满足了监控的所有能力。 Grafana, 它和Prometheus相比更侧重的是图形化展示，有强大、灵活的仪表盘体系，我们会把基于Prometheus收集的数据作为数据源导入到Grafana。 监控模式目前，监控系统采集指标有两种方式，一种是『推』，另一种就是『拉』： 推的代表有 ElasticSearch，InfluxDB，OpenTSDB 等，需要你从程序中将指标使用 TCP，UDP 等方式推送至相关监控应用，只是使用 TCP 的话，一旦监控应用挂掉或存在瓶颈，容易对应用本身产生影响，而使用 UDP 的话，虽然不用担心监控应用，但是容易丢数据。 拉的代表，主要代表就是 Prometheus，让我们不用担心监控应用本身的状态。而且可以利用 DNS-SRV 或者 Consul 等服务发现功能就可以自动添加监控。 如何监控Prometheus 监控应用的方式非常简单，只需要进程暴露了一个用于获取当前监控样本数据的 HTTP 访问地址。这样的一个程序称为Exporter，Exporter 的实例称为一个 Target...

介绍 在Kubernetes中，Prometheus Operator可以通过两种方式自动发现监控目标：PodMonitor和ServiceMonitor。PodMonitor用于监控由单个Pod定义的服务，而ServiceMonitor用于监控Kubernetes Service中的所有Pod。 要使用PodMonitor和ServiceMonitor，需要在Kubernetes中定义它们，然后Prometheus Operator将从这些定义中自动发现和创建监控目标。 在Kubernetes中，Prometheus Operator可以通过两种方式自动发现监控目标：PodMonitor和ServiceMonitor。PodMonitor用于监控由单个Pod定义的服务，而ServiceMonitor用于监控Kubernetes Service中的所有Pod。 要使用PodMonitor和ServiceMonitor，需要在Kubernetes中定义它们，然后Prometheus Operator将从这些定义中自动发现和创建监控目标。 以下是如何使用PodMonitor和Ser...

摘自：https://juejin.cn/post/7097166804044218405 安装运行Prometheus(docker版)Grafana是一个开源的功能丰富的数据可视化平台，通常用于时序数据的可视化。它内置了多种数据源的支持 下载镜像包123docker pull prom/node-exporterdocker pull prom/prometheusdocker pull grafana/grafana 启动node-exporter12345docker run -d -p 9100:9100 \ -v "/proc:/host/proc:ro" \ -v "/sys:/host/sys:ro" \ -v "/:/rootfs:ro" \ prom/node-exporter 访问url： http://127.0.0.1:9100/metrics 效果如下: 这些都是收集到的数据，有了它就可以做数据展示了。 启动prometheus新建目录 prometheus，编辑配置文件p...

AlertManager 中的几个容易混淆的参数首先在 Prometheus 中有两个全局的参数 scrape_interval 和 evaluation_interval 。 scrape_interval 参数表示的是 Prometheus 从各种 metrics 接口抓取指标数据的时间间隔 evaluation_interval 参数表示的是 Prometheus 对报警规则进行评估计算的时间间隔。 group_by 为了避免连续发送类似的告警通知，可以将相关告警分到同一组中进行告警。分组机制可以将详细的告警信息合并成一个通知，在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知： 1group_by: ['alertname', 'job'] group_wait 当一个新的报警分组被创建后，需要等待至少 group_wait 时间来初始化告警。 这样实际上就缓冲了从 Prometheus 发送到 AlertManager 的告警，...

摘自: https://blog.csdn.net/qq_35952638/article/details/108077895 本文使用 Prometheus v2.18.1 ，Alertmanager v0.20.0本文主要分析 Alertmanager 什么情况下会发送告警消息，避免对用户造成消息轰炸。 Alertmanager 的一般工作流程 Prometheus 每隔 interval 时长执行一次 alert rule 。如果执行结果包含 n 个时间序列，则认为存在 n 个警报，通过 HTTP 通信发送 alerting 状态的消息给 Alertmanager 。 Alertmanager 收到之后， 先根据 route 判断它属于哪个 group 、应该发送给哪个 receiver 。 再判断该 group 当前是否处于冷却阶段、是否被 Silence 静音、是否被 Inhibit 抑制。如果都没有，则立即发送告警消息给用户。 如果 Prometheus 再次执行 alert rule 时，发现执行结果为空，则认为警报已解决，立即产生 resolved 状态的...