关于nf_conntrack以及xx of conntrack entries are used问题
Kubernetes 节点将conntrack_max值与节点上的 RAM 大小成比例地设置。高负载应用（尤其是在小型节点上）很容易超过conntrack_max，并导致连接复位和超时。 理论conntrack 是建立在 Netlifier 框架之上的功能。它对于高性能的 Kubernetes 复杂网络至关重要，其中节点需要跟踪数千个 Pod 和服务之间的连接信息。 在 Kubernetes 中, 默认值可以在 prometheus 指标中找到node_nf_conntrack_entries_limit（需要node_exporter） linux系统中可以通过以下指令查看【当然如果未配置过的话，默认值会以下面的公式计算出默认值】：sysctl net.netfilter.nf_conntrack_max conntrack_max值与节点的内存成正比，通常聚合代理类服务会需要持续跟踪大量连接【消耗大量的conntrack...
自定义监控指标开发(六):精简Prometheus指标减少资源占用
前言随着 Prometheus 监控的组件、数量、指标越来越多，Prometheus 对计算性能的要求会越来越高，资源占用也会越来越高。 在这种情况下，要优化 Prometheus 性能, 优化存储占用. 第一时间想到的可能是各种 Prometheus 的兼容存储方案, 如 Thanos 或 VM、Mimir 等。但是实际上虽然集中存储、长期存储、存储降采样及存储压缩可以一定程度解决相关问题，但是治标不治本。 真正的本，还是在于指标量（series）过于庞大。 治本之法，应该是减少指标量。有 2 种办法： 解决高基数问题 根据实际使用情况，只保留（keep）展示（Grafana Dashboards）和告警（prometheus rules）会用到的指标。 高基数问题什么是基数(Cardinality)?基数的 基本定义 是指一个给定集合中的元素的数量。 在Prometheus中指代series 的基数 (High Cardinality) 在 Prometheus 和可观察性的世界里，标签基数...
自定义监控指标开发(五):整合Springboot和Prometheus实现自定义指标
我在第二章中有介绍使用koa整合Prometheus自定义指标，这里记录下整合Springboot和Prometheus实现自定义指标 要在Spring...
自定义监控指标开发(三):Grafana配置及使用
介绍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:...
自定义监控指标开发(二):Prometheus介绍及PromQL的使用
介绍Prometheus是一套成熟且流行的系统和服务监控系统，它几乎满足了监控的所有能力。 Grafana, 它和Prometheus相比更侧重的是图形化展示，有强大、灵活的仪表盘体系，我们会把基于Prometheus收集的数据作为数据源导入到Grafana。 监控模式目前，监控系统采集指标有两种方式，一种是『推』，另一种就是『拉』： 推的代表有 ElasticSearch，InfluxDB，OpenTSDB 等，需要你从程序中将指标使用 TCP，UDP 等方式推送至相关监控应用，只是使用 TCP 的话，一旦监控应用挂掉或存在瓶颈，容易对应用本身产生影响，而使用 UDP 的话，虽然不用担心监控应用，但是容易丢数据。 拉的代表，主要代表就是 Prometheus，让我们不用担心监控应用本身的状态。而且可以利用 DNS-SRV 或者 Consul 等服务发现功能就可以自动添加监控。 如何监控Prometheus 监控应用的方式非常简单，只需要进程暴露了一个用于获取当前监控样本数据的 HTTP 访问地址。这样的一个程序称为Exporter，Exporter 的实例称为一个...
自定义监控指标开发(四):配合K8s收集服务指标信息
介绍 在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...
自定义监控指标开发(一):基于Docker搭建Prometheus+Grafana
摘自：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推送告警记录
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...
分析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...
公告