Prometheus

VictoriaMetrics vmalert 说明

旧街凉风 提交于 2020-08-04 18:07:09
vmalert 可以执行一系列给定的rule(基于metricsql),然后发送报警到Alertmanager 特性 集成VictoriaMetrics TSDB MetricsQL 表达式校验 prometheus 报警规则格式支持 集成Alertmanager 轻量级没有额外的依赖 使用 构建 目前需要自己构建,很简单 make vmalert 就可以了 启动 依赖一系列的规则(promql&&metricssql),数据源地址,通知地址Alertmanager地址,方便处理,聚合报警以及发送通知 命令: . / bin / vmalert - rule = alert. rules \ - datasource. url = http: //localhost:8428 \ - notifier. url = http: //localhost:9093 一个参考规则 groups: - name: groupGorSingleAlert rules: - alert: VMRows for: 10 s expr: vm_rows > 0 labels: label: bar host: "{{ $labels.instance }}" annotations: summary: "{{ $value|humanize }}" description: "{{$labels}

聊聊dubbo-go的PrometheusReporter

*爱你&永不变心* 提交于 2020-08-04 09:39:41
序 本文主要研究一下dubbo-go的PrometheusReporter PrometheusReporter dubbo-go-v1.4.2/metrics/prometheus/reporter.go const ( reporterName = "prometheus" serviceKey = constant.SERVICE_KEY groupKey = constant.GROUP_KEY versionKey = constant.VERSION_KEY methodKey = constant.METHOD_KEY timeoutKey = constant.TIMEOUT_KEY providerKey = "provider" consumerKey = "consumer" // to identify the metric's type histogramSuffix = "_histogram" // to identify the metric's type summarySuffix = "_summary" ) var ( labelNames = []string{serviceKey, groupKey, versionKey, methodKey, timeoutKey} namespace = config

How to get overall uptime of a server with prometheus and node_exporter

为君一笑 提交于 2020-08-03 05:43:54
问题 I'm looking for a query to get the average uptime of the server on which prometheus runs over the last week. It should be about 15h/week, so about 8-10 %. I'm using Prometheus 2.5.0 with node_exporter on CentOS 7.6.1810. My most promising experiments would be: 1 - avg_over_time(up{job="prometheus"}[7d]) This is what I've found when looking for ways to get average uptimes, but it gives me exactly 1. (My guess is it ignores the times in which no scrapes happened?) 2 - sum_over_time(up{job=

How to get overall uptime of a server with prometheus and node_exporter

浪尽此生 提交于 2020-08-03 05:42:07
问题 I'm looking for a query to get the average uptime of the server on which prometheus runs over the last week. It should be about 15h/week, so about 8-10 %. I'm using Prometheus 2.5.0 with node_exporter on CentOS 7.6.1810. My most promising experiments would be: 1 - avg_over_time(up{job="prometheus"}[7d]) This is what I've found when looking for ways to get average uptimes, but it gives me exactly 1. (My guess is it ignores the times in which no scrapes happened?) 2 - sum_over_time(up{job=

VictoriaMetrics vmagent的一些介绍

早过忘川 提交于 2020-07-29 10:39:02
以前有简单说明过vmagent,实际上vmagent可以替代我们做好多事情.以下是一个说明 vmagent的作用 主要目的是实现metrics 的收集然后存储到VictoriaMetrics以及prometheus兼容的存储系统(主要支持remote_write 协议即可,有好多实现) 同时一个好处是实现了metrics 的push,而不是prometheus 的pull(比如无法pull 的场景) 参考架构图 特性 替换prometheus 的scraping target(比如node export) 基于prometheus relabeling 的模式添加,移除,修改labels ,可以方便在数据发送到远端存储之前进行数据的过滤 支持多种数据协议,influx line 协议,grapgite 文本协议,opentsdb 协议,prometheus remote write 协议,json lines协议,csv 数据 支持收集数据的同时,并复制到多种远端存储系统 支持不可靠远端存储(通过本地存储 -remoteWrite.tmpDataPath ),同时支持最大磁盘占用 相比prometheus使用较少的内存,cpu,磁盘io,以及网络带宽 启动模式 参考命令 /path/ to / vmagent - promscrape. config = /path/ to /

一步步教你用Prometheus搭建实时监控系统系列(一)——上帝之火,普罗米修斯的崛起

∥☆過路亽.° 提交于 2020-07-29 10:32:16
上帝之火 本系列讲述的是开源实时监控告警解决方案 Prometheus ,这个单词很牛逼。每次我都能联想到带来上帝之火的希腊之神,普罗米修斯。而这个开源的logo也是火,个人挺喜欢这个logo的设计。 本系列着重介绍 Prometheus 以及如何用它和其周边的生态来搭建一套属于自己的实时监控告警平台。 本系列受众对象为初次接触 Prometheus 的用户,大神勿喷,偏重于操作和实战,但是重要的概念也会精炼出提及下。系列主要分为以下几块 Prometheus 各个概念介绍和搭建,如何抓取数据(本次分享内容) 如何推送数据至 Prometheus ,推送和拉取分别用于什么样的场景 Prometheus 数据的结构以及查询语言 PromQL 的使用 Java应用如何和 Prometheus 集成,如何启用服务发现,如果自定义业务指标 Prometheus 如何和 Grafana 可视化套件进行集成和设置告警 教你如何手写一个集成了监控Dubbo各个指标的java套件 实际案例分享,如何做各个业务端和系统端的监控大盘 Prometheus以及时序数据库的基本概念 Prometheus 现在在 Github 有3w多的star,基本上过万星的开源工具,可以认为是社区里绝对的主流,社区也相当活跃,可以有大量的经验可以借鉴。在企业级系统中,可以放心的使用。 Prometheus 是由

k8s记录-prometheus部署

痞子三分冷 提交于 2020-07-29 09:15:22
prometheus 安装 官网:https://prometheus.io/download/ wget https://github.com/prometheus/prometheus/releases/download/v2.10.0/prometheus-2.10.0.linux-amd64.tar.gz tar xvf prometheus-2.10.0.linux-amd64.tar.gz mv prometheus-2.10.0.linux-amd64 /usr/local/prometheus cd /usr/local/prometheus vim prometheus.yml scrape_configs: - job_name: 'prometheus' static_configs: # 监控本地及端口 - targets: ['xiangsikai:9090'] 注:Prometheus从目标机上通过http方式拉取采样点数据, 它也可以拉取自身服务数据并监控自身的健康状况。 启动服务 ./prometheus --config.file=prometheus.yml # 指定配置文件 --config.file="prometheus.yml" # 指定监听地址端口 --web.listen-address="0.0.0.0:9090" # 最大连接数

VictoriaMetrics vmauth 说明

亡梦爱人 提交于 2020-07-29 09:07:35
VictoriaMetrics 的auth 组件是为了增强安全的,基于golang 的 httputil.ReverseProxy ,当前支持的模式比较简单(基于配置文件) 包含的命令 vmauth - 20200511 - 085829 - heads - cluster - 0 - g6c88e352 Usage of . / vmauth: - auth. config string Path to auth config. See https: //github.com/VictoriaMetrics/VictoriaMetrics/blob/master/app/vmauth/README.md for details on the format of this auth config - enableTCP6 Whether to enable IPv6 for listening and dialing. By default only IPv4 TCP is used - http. disableResponseCompression Disable compression of HTTP responses for saving CPU resources. By default compression is enabled to save network

GitLabRunner和流水线的数据采集与监控

妖精的绣舞 提交于 2020-07-29 08:59:15
本文主要阐述如何配置GitLabRunner和GitLabCI/CD流水线的数据采集与监控。 1.1 配置GitLab Runner监控 GitLab Runner本地具有Prometheus指标,可以访问嵌入式HTTP服务器,通过 /metrics 路径公开。该服务器(如果已启用)可以被Prometheus监视系统抓取,或通过任何其他HTTP客户端进行访问。 公开的信息包括: Runner业务逻辑指标(例如,当前正在运行的作业数) Go特定的流程指标(垃圾收集统计信息,goroutines,memstats等) 常规指标(内存使用情况,CPU使用情况,文件描述符使用情况等) 这些指标是运维人员监视和了解GitLab Runners的一种方式。例如,您可能会对Runner主机上的平均负载和作业数量感兴趣。 Runner默认是没有开启内置的HTTP服务,可以通过两种方式配置指标HTTP服务器: 在 config.toml 文件中配置全局选项 listen_address 。 在Runner启动的时候添加 --listen-address 命令选项。 在这里我直接修改的 config.toml 文件,内容参考如下: $ cat config.toml listen_address = "[::]:9252" concurrent = 10 check_interval = 30 log

高并发葵花宝典

柔情痞子 提交于 2020-07-29 06:01:13
目录 前言 一、常用指标 响应时间 并发数 QPS TPS 二、夺命三高 高并发 高性能 高可用 三、常见招式 分流 缓存 队列 CDN 池化 扩容 熔断 限流 降级 分层 部署分级 日志监控 查询优化 读写分离 分库分表 前言 冰冻三尺非一日之寒,葵花宝典也不是一天写出来的,系统设计也如此,好的架构是不断演进的。 一般来说能用单块架构解决的问题,尽量不要采用分布式。 分布式虽然可以提高系统的响应能力,也带来了更高的复杂性,如果团队技术人员水平hold不住的话,反而会产生更多问题,例如问题难以定位、系统性能下降、某种业务实现困难或无法实现等问题。 以下内容由伟大的诗人chenqionghe整理,light weight baby~ 一、常用指标 响应时间 直观反应系统快慢,一般控制在200ms以内,超过1s用户已经能感觉到慢了 并发数 同时处理请求的数目 QPS 每秒查询请求数 TPS 每秒执行事务数,着重反应写 二、夺命三高 没错,就是高血压、高血糖和高血脂,开玩笑啦~ 高并发 通过设计让系统能接收更多的用户并发请求,承担更大的流量。 一般考查并发数、QPS和TPS。 示例:庐山百龙霸,并发百龙 高性能 一般指服务响应时间快 用户视角。APP、浏览器上能直观感受快 开发视角。响应延迟低,系统吞吐量大,并发处理能力强 运维视角。基础设施配置高,CPU多核心,内存容量大 示例