Prometheus

整体流程 remoteConfigs反对配置多个remoteStorage，每个remoteStorage应用1个QueueManager；wathcer将sample发送给QueueManager;1个QueueManager中治理多个shard，每个shard的容量为capactiy；每个shard会定时(batch_send_deadline)定量(max_samples_per_send)的向remote endpoint发送数据；代码入口入口：storage/remote/write.go次要工作是初始化QueueManager，而后调用start()让其干活。 // 依据配置初始化QueueManager，而后让QueueManager干活func (rws *WriteStorage) ApplyConfig(conf *config.Config) error { ..... newQueues := make(map[string]*QueueManager) newHashes := []string{} for _, rwConf := range conf.RemoteWriteConfigs { hash, err := toHash(rwConf) if err != nil { return err } // Don't allow duplicate remote write configs. if _, ok := newQueues[hash]; ok { return fmt.Errorf("duplicate remote write configs are not allowed, found duplicate for URL: %s", rwConf.URL) } // Set the queue name to the config hash if the user has not set // a name in their remote write config so we can still differentiate // between queues that have the same remote write endpoint. name := hash[:6] if rwConf.Name != "" { name = rwConf.Name } c, err := NewWriteClient(name, &ClientConfig{ URL: rwConf.URL, Timeout: rwConf.RemoteTimeout, HTTPClientConfig: rwConf.HTTPClientConfig, }) if err != nil { return err } queue, ok := rws.queues[hash] ...... endpoint := rwConf.URL.String() newQueues[hash] = NewQueueManager( ##初始化QueueManager newQueueManagerMetrics(rws.reg, name, endpoint), rws.watcherMetrics, rws.liveReaderMetrics, rws.logger, rws.walDir, ##这里是/prometheus，在walwatcher中会被初始化为/prometheus/wal rws.samplesIn, rwConf.QueueConfig, conf.GlobalConfig.ExternalLabels, rwConf.WriteRelabelConfigs, c, rws.flushDeadline, ) // Keep track of which queues are new so we know which to start. newHashes = append(newHashes, hash) } // Anything remaining in rws.queues is a queue who's config has // changed or was removed from the overall remote write config. for _, q := range rws.queues { q.Stop() } for _, hash := range newHashes { ##QueueManager干活 newQueues[hash].Start() } rws.queues = newQueues return nil}具体看一下QueueManager做的事件： ...

prometheus没有提供近程存储，但提供了近程存储的接口: 近程存储只有实现这一接口，即可存储和读取prometheus的数据；这里仅剖析remote-write:笔者的prometheus被prometheus-operator部署在kubernetes中，kubernetes应用prometheus这个CRD治理配置，prometheus-operator监听到配置变动，将新配置apply到prometheus POD上。 prometheus CRD中的remote-write配置：remoteWrite: - url: "https://1.2.3.4/api/monitor/v1/prom/write" tlsConfig: insecureSkipVerify: trueapply当前，prometheus生成如下的配置： remote_write:- url: https://1.2.3.4/api/monitor/v1/prom/write remote_timeout: 30s tls_config: insecure_skip_verify: true queue_config: capacity: 500 max_shards: 1000 min_shards: 1 max_samples_per_send: 100 batch_send_deadline: 5s min_backoff: 30ms max_backoff: 100ms能够看到，它减少了queue_config，即传输过程中的队列配置。假如每个remoteStorage应用1个queue进行传输： queue中的初始shards数=min_shards，最大shards数=max_shards；每个shard的容量=capacity个sample；通过HTTP向remoteStorage发送数据时，若发送失败，则回退min_backoff；再次失败，则回退2*min_backoff，直到max_backoff； prometheus的remote-write数据协定prometheus的samples，通过protobuf的序列化，而后再通过snappy压缩，最初通过HTTP发送给remoteStorage;对应的源代码： // prometheus/storage/remote/queue_manager.gofunc buildWriteRequest(samples []prompb.TimeSeries, buf []byte) ([]byte, int64, error) { var highest int64 for _, ts := range samples { // At the moment we only ever append a TimeSeries with a single sample in it. if ts.Samples[0].Timestamp > highest { highest = ts.Samples[0].Timestamp } } req := &prompb.WriteRequest{ Timeseries: samples, } data, err := proto.Marshal(req) if err != nil { return nil, highest, err } // snappy uses len() to see if it needs to allocate a new slice. Make the // buffer as long as possible. if buf != nil { buf = buf[0:cap(buf)] } compressed := snappy.Encode(buf, data) return compressed, highest, nil}remoteStorage如何实现remote-write协定接口remoteStorage要实现remoteConfigs中定义的HTTP接口，这里次要参考influxdb的实现。HTTP接口： ...

前言mtail是一个Google开发的日志提取工具，相比ELK/EFK/Grafana Loki来说会更轻量。因为我遇到的需要只是为了采集生产日志中的数据，所以采纳更为简略的mtail配合Prometheus和Grafana实现自定义日志数据监控。 更新历史2021年08月04日 - 初稿 浏览原文 - https://wsgzao.github.io/post... 常见的日志监控解决方案开源的业务日志监控，我重点举荐以下3个 值得注意的是ELK目前有被EFK取代的趋势1：ELK-“ELK”是三个开源我的项目的首字母缩写，这三个我的项目别离是：Elasticsearch、Logstash 和 Kibana。 Elasticsearch 是一个搜寻和剖析引擎。 Logstash 是服务器端数据处理管道，可能同时从多个起源采集数据，转换数据，而后将数据发送到诸如 Elasticsearch 等“存储库”中。 Kibana 则能够让用户在 Elasticsearch 中应用图形和图表对数据进行可视化。 2：Loki，Grafana Labs 团队最新的开源我的项目，是一个程度可扩大，高可用性，多租户的日志聚合零碎。 3：mtail :它是一个google开发的日志提取工具，从应用程序日志中提取指标以导出到工夫序列数据库或工夫序列计算器， 用处就是: 实时读取应用程序的日志、 再通过本人编写的脚本进行剖析、 最终生成工夫序列指标。 工具适宜本人的才是最好的，无论是EFK还是Loki都是功能齐全的日志采集零碎，当然它们也有各自的劣势， Blog中记录了一些应用教训大家能够参考Scribe装置应用 - https://wsgzao.github.io/post... 应用ELK(Elasticsearch + Logstash + Kibana) 搭建日志集中剖析平台实际 - https://wsgzao.github.io/post... 开源日志治理计划ELK和EFK的区别 - https://wsgzao.github.io/post... Grafana Loki开源日志聚合零碎代替ELK或EFK - https://wsgzao.github.io/post... mtail简介mtail - extract whitebox monitoring data from application logs for collection into a timeseries database mtail is a tool for extracting metrics from application logs to be exported into a timeseries database or timeseries calculator for alerting and dashboarding. ...

1.node_exporter 用户明码验证拜访yum install httpd-toolshtpasswd -nB "prometheus"[root@node3 node_exporter]# htpasswd -nB "prometheus"New password: Re-type new password: prometheus:$2y$05$TsMfhNUmHVD8PYmrAvWcNO5lisOfL25.5ybV0Z7t4NF43Aq1IennOnode_exporter web.config.yaml basic_auth_users: prometheus: $2y$05$TsMfhNUmHVD8PYmrAvWcNxO5OxfL25x.5ybV0Z7t4NF43Aq1IennO启动node_exporter ./node_exporter --web.config=web.config.yaml 设置node_exporter.service [Unit]Descriptiong=node_exporterDocumentation=After=network.target[Service]WorkingDirectory=/opt/node_exporter/ExecStart=/opt/node_exporter/node_exporter --web.config=/opt/node_exporter/web.config.yamlExecStop=/bin/kill -KILL $MAINPIDType=simpleKillMode=control-groupRestartSec=3s[Install]WantedBy=multi-user.target从新加载systemd systemctl daemon-reload2.将node_exporter退出到prometheusprometheus.yml scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: 'prometheus' # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: ['localhost:9090'] - job_name: 'node' basic_auth: username: prometheus password: 123456 static_configs: - targets: ['localhost:9100']查看配置文件是否正确 ...

背景：traefik搭建形式如下：https://www.yuque.com/duiniwukenaihe/ehb02i/odflm7 。Prometheus-oprator搭建形式如下：https://www.yuque.com/duiniwukenaihe/ehb02i/tm6vl7。Prometheus的文档写了grafana增加了traefik的监控模板。然而当初认真一看。traefik的监控图是空的，Prometheus的 target也没有对应traefik的监控。当初配置下增加traefik服务发现以及验证一下grafana的图表。 1. Prometheus Operator 监控 Traefik V2.41.1. Traefik 配置文件设置 Prometheus参照https://www.yuque.com/duiniwukenaihe/ehb02i/odflm7。配置中默认开启了默认的Prometheus监控。https://doc.traefik.io/traefik/observability/metrics/prometheus/可参照traefik官网文档。 1.2、Traefik Service 设置标签1.2.1 查看traefik service$ kubectl get svc -n kube-systemNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEcilium-agent ClusterIP None <none> 9095/TCP 15detcd-k8s ClusterIP None <none> 2379/TCP 8dhubble-metrics ClusterIP None <none> 9091/TCP 15dhubble-relay ClusterIP 172.254.38.50 <none> 80/TCP 15dhubble-ui ClusterIP 172.254.11.239 <none> 80/TCP 15dkube-controller-manager ClusterIP None <none> 10257/TCP 8dkube-controller-manager-svc ClusterIP None <none> 10252/TCP 6dkube-dns ClusterIP 172.254.0.10 <none> 53/UDP,53/TCP,9153/TCP 15dkube-scheduler ClusterIP None <none> 10259/TCP 8dkube-scheduler-svc ClusterIP None <none> 10251/TCP 6dkubelet ClusterIP None <none> 10250/TCP,10255/TCP,4194/TCP 8dtraefik ClusterIP 172.254.12.88 <none> 80/TCP,443/TCP,8080/TCP 11d1.2.2、编辑该 Service 设置 Label kubectl edit service traefik -n kube-system设置 Label “app: traefik”参照的是traefik-deploy.yaml 中的app:traefik这个标签用了，当然了也能够本人定义下用下别的...... ...

Prometheus 是一款基于时序数据库的开源监控告警零碎，说起 Prometheus 则不得不提 SoundCloud，这是一个在线音乐分享的平台，相似于做视频分享的 YouTube，因为他们在微服务架构的路线上越走越远，呈现了成千盈百的服务，应用传统的监控零碎 StatsD 和 Graphite 存在大量的局限性。 于是他们在 2012 年开始着手开发一套全新的监控零碎。Prometheus 的原作者是 Matt T. Proud，他也是在 2012 年退出 SoundCloud 的，实际上，在退出 SoundCloud 之前，Matt 始终就任于 Google，他从 Google 的集群管理器 Borg 和它的监控零碎 Borgmon 中获取灵感，开发了开源的监控零碎 Prometheus，和 Google 的很多我的项目一样，应用的编程语言是 Go。 很显然，Prometheus 作为一个微服务架构监控零碎的解决方案，它和容器也脱不开关系。早在 2006 年 8 月 9 日，Eric Schmidt 在搜索引擎大会上首次提出了云计算（Cloud Computing）的概念，在之后的十几年里，云计算的倒退长驱直入。 在 2013 年，Pivotal 的 Matt Stine 又提出了云原生（Cloud Native）的概念，云原生由微服务架构、DevOps 和以容器为代表的麻利基础架构组成，帮忙企业疾速、继续、牢靠、规模化地交付软件。 为了对立云计算接口和相干规范，2015 年 7 月，隶属于 Linux 基金会的 云原生计算基金会（CNCF，Cloud Native Computing Foundation） 应运而生。第一个退出 CNCF 的我的项目是 Google 的 Kubernetes，而 Prometheus 是第二个退出的（2016 年）。 ...

一、背景简略记录下，应用Prometheus对Canal进行监控。 二、实现步骤1、批改prometheus.yml配置文件vim /Users/huan/soft/prometheus/prometheus-2.25.0/prometheus.yml scrape_configs: - job_name: 'canal' scrape_interval: 30s static_configs: - targets: ['localhost:11112'] # 端口配置即为canal.properties中的canal.metrics.pull.port labels: nodename: 'canal'# 检测刚刚编写的 prometheus.yml 语法是否谬误./promtool check config prometheus.yml2、启动prometheusnohup /Users/huan/soft/prometheus/prometheus-2.25.0/prometheus \--config.file="/Users/huan/soft/prometheus/prometheus-2.25.0/prometheus.yml" \--web.listen-address="0.0.0.0:9080" \--web.enable-lifecycle \--storage.tsdb.retention.time="3d" \--log.level=debug \> logs/prometheus.out 2>&1 &3、查看prometheus是否胜利接入canal 4、canal原始指标解释指标阐明单位精度canal_instance_transactionsinstance接管transactions计数--canal_instanceinstance根本信息--canal_instance_subscriptionsinstance订阅数量--canal_instance_publish_blocking_timeinstance dump线程提交到异步解析队列过程中的阻塞工夫(仅parallel解析模式)msnscanal_instance_received_binlog_bytesinstance接管binlog字节数byte-canal_instance_parser_modeinstance解析模式(是否开启parallel解析)--canal_instance_client_packetsinstance client申请次数的计数--canal_instance_client_bytes向instance client发送数据包字节计数byte-canal_instance_client_empty_batches向instance client发送get接口的空后果计数--canal_instance_client_request_errorinstance client申请失败计数--canal_instance_client_request_latencyinstance client申请的响应工夫详情--canal_instance_sink_blocking_timeinstance sink线程put数据至store的阻塞工夫msnscanal_instance_store_produce_seqinstance store接管到的events sequence number--canal_instance_store_consume_seqinstance store胜利生产的events sequence number--canal_instance_storeinstance store根本信息--canal_instance_store_produce_meminstance store接管到的所有events占用内存总量byte-canal_instance_store_consume_meminstance store胜利生产的所有events占用内存总量byte-canal_instance_put_rowsstore put操作实现的table rows--canal_instance_get_rowsclient get申请返回的table rows--canal_instance_ack_rowsclient ack操作开释的table rows--canal_instance_traffic_delayserver与MySQL master的延时msmscanal_instance_put_delaystore put操作events的延时msmscanal_instance_get_delayclient get申请返回events的延时msmscanal_instance_ack_delayclient ack操作开释events的延时msms5、导入fana图表 图表json数据 { "__inputs": [ { "name": "DS_PROMETHEUS", "label": "prometheus", "description": "", "type": "datasource", "pluginId": "prometheus", "pluginName": "Prometheus" } ], "__requires": [ { "type": "grafana", "id": "grafana", "name": "Grafana", "version": "5.2.2" }, { "type": "panel", "id": "graph", "name": "Graph", "version": "5.0.0" }, { "type": "datasource", "id": "prometheus", "name": "Prometheus", "version": "5.0.0" } ], "annotations": { "list": [ { "builtIn": 1, "datasource": "-- Grafana --", "enable": true, "hide": true, "iconColor": "rgba(0, 211, 255, 1)", "name": "Annotations & Alerts", "type": "dashboard" } ] }, "editable": true, "gnetId": null, "graphTooltip": 0, "id": null, "iteration": 1536989235272, "links": [], "panels": [ { "collapsed": false, "gridPos": { "h": 1, "w": 24, "x": 0, "y": 0 }, "id": 30, "panels": [], "title": "Instance status", "type": "row" }, { "aliasColors": {}, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "Canal instance 根本信息。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 0, "y": 1 }, "id": 24, "legend": { "alignAsTable": true, "avg": false, "current": false, "hideEmpty": false, "hideZero": false, "max": false, "min": false, "rightSide": true, "show": true, "sideWidth": 500, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "repeat": null, "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "canal_instance{destination=~\"$destination\"}", "format": "time_series", "instant": true, "intervalFactor": 1, "legendFormat": "Destination: {{destination}}", "refId": "A" }, { "expr": "canal_instance_parser_mode{destination=~\"$destination\"}", "format": "time_series", "instant": true, "intervalFactor": 1, "legendFormat": "Parallel parser: {{parallel}}", "refId": "B" }, { "expr": "canal_instance_store{destination=~\"$destination\"}", "format": "time_series", "instant": true, "intervalFactor": 1, "legendFormat": "Batch mode: {{batchMode}}", "refId": "C" }, { "expr": "canal_instance_store{destination=~\"$destination\"}", "format": "time_series", "instant": true, "intervalFactor": 1, "legendFormat": "Buffer size: {{size}}", "refId": "D" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Basic", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "transparent": true, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": false, "values": [] }, "yaxes": [ { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": false }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": false } ], "yaxis": { "align": false, "alignLevel": null } }, { "aliasColors": { "inbound": "#bf1b00" }, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "Canal instance 网络带宽占用。\ninbound: 读取MySQL binlog.\noutbound: 对Client端传输格式化binlog.", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 6, "y": 1 }, "id": 6, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "rate(canal_instance_received_binlog_bytes{destination=~\"$destination\", parser=\"0\"}[2m]) / 1024", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "inbound", "refId": "A" }, { "expr": "rate(canal_instance_client_bytes{destination=~\"$destination\"}[2m]) / 1024", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "outbound", "refId": "B" }, { "expr": "rate(canal_instance_received_binlog_bytes{destination=~\"$destination\", parser=\"1\"}[2m]) / 1024", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "inbound-1", "refId": "C" }, { "expr": "rate(canal_instance_received_binlog_bytes{destination=~\"$destination\", parser=\"2\"}[2m]) / 1024", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "inbound-2", "refId": "D" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Network bandwith", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "KBs", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "aliasColors": { "ack": "#f29191", "get": "#cca300", "put": "#1f78c1" }, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "master: Canal server绝对于MySQL master的延时。通过master heartbeat机制能刷新idle状态下的延时。\nput: store put操作的工夫点为基准。\nget: client get操作的工夫点为基准。\nack: client ack操作的工夫点为基准。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 12, "y": 1 }, "id": 4, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "canal_instance_traffic_delay{destination=~\"$destination\"} / 1000", "format": "time_series", "hide": false, "interval": "15s", "intervalFactor": 2, "legendFormat": "master", "refId": "D" }, { "expr": "canal_instance_put_delay{destination=~\"$destination\"} / 1000", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "put", "refId": "A" }, { "expr": "canal_instance_get_delay{destination=~\"$destination\"} / 1000", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "get", "refId": "B" }, { "expr": "canal_instance_ack_delay{destination=~\"$destination\"} / 1000", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "ack", "refId": "C" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Delay", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "s", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "aliasColors": {}, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "sink线程blocking占比；dump线程blocking占比(仅parallel mode)。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 18, "y": 1 }, "hideTimeOverride": false, "id": 2, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "clamp_max(rate(canal_instance_publish_blocking_time{destination=~\"$destination\", parser=\"0\"}[2m]), 1000) / 10", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "dump", "refId": "B" }, { "expr": "clamp_max(rate(canal_instance_sink_blocking_time{destination=~\"$destination\"}[2m]), 1000) / 10", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "sink", "refId": "A" }, { "expr": "clamp_max(rate(canal_instance_publish_blocking_time{destination=~\"$destination\", parser=\"1\"}[2m]), 1000) / 10", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "dump-1", "refId": "C" }, { "expr": "clamp_max(rate(canal_instance_publish_blocking_time{destination=~\"$destination\", parser=\"2\"}[2m]), 1000) / 10", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "dump-2", "refId": "D" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Blocking", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "percent", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "collapsed": false, "gridPos": { "h": 1, "w": 24, "x": 0, "y": 6 }, "id": 32, "panels": [], "title": "Throughput", "type": "row" }, { "aliasColors": { "rowDatas": "#7eb26d", "tableRows": "#c15c17" }, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "Instance解决binlog的TPS(以master变更行数table rows为基准计算)。\nput: put操作TPS。\nget: get操作TPS。\nack: ack操作TPS。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 0, "y": 7 }, "id": 14, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "rate(canal_instance_put_rows{destination=~\"$destination\"}[2m])", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "put", "refId": "A" }, { "expr": "rate(canal_instance_get_rows{destination=~\"$destination\"}[2m])", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "get", "refId": "B" }, { "expr": "rate(canal_instance_ack_rows{destination=~\"$destination\"}[2m])", "format": "time_series", "intervalFactor": 1, "legendFormat": "ack", "refId": "C" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "TPS(table rows)", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "iops", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "aliasColors": { "transactions": "#f9ba8f" }, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "Canal instance 解决binlog的TPS，以MySQL transaction为单位计算。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 6, "y": 7 }, "id": 12, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "rate(canal_instance_transactions{destination=~\"$destination\"}[2m])", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "transactions", "refId": "A" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "TPS(MySQL transaction)", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "iops", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "collapsed": false, "gridPos": { "h": 1, "w": 24, "x": 0, "y": 12 }, "id": 34, "panels": [], "title": "Client", "type": "row" }, { "aliasColors": {}, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "Canal instance接管到的申请统计，后果按packet type分类。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 0, "y": 13 }, "id": 16, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "canal_instance_client_packets{destination=~\"$destination\"}", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "{{packetType}}", "refId": "A" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Client requests", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "none", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "aliasColors": {}, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "client 申请的GET与ACK包的QPS。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 6, "y": 13 }, "id": 38, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "rate(canal_instance_client_packets{destination=~\"$destination\",packetType=\"GET\"}[2m])", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "GET", "refId": "A" }, { "expr": "rate(canal_instance_client_packets{destination=~\"$destination\",packetType=\"CLIENTACK\"}[2m])", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "ACK", "refId": "B" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Client QPS", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "aliasColors": {}, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "server响应GET申请，但返回空包的占比。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 12, "y": 13 }, "id": 26, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "rate(canal_instance_client_empty_batches{destination=~\"$destination\"}[2m])", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "empty", "refId": "A" }, { "expr": "rate(canal_instance_client_packets{destination=~\"$destination\", packetType=\"GET\"}[2m])", "format": "time_series", "intervalFactor": 1, "legendFormat": "nonempty", "refId": "B" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Empty packets", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "wps", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "aliasColors": {}, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "Canal client 申请响应工夫的详情。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 18, "y": 13 }, "id": 18, "legend": { "alignAsTable": false, "avg": false, "current": false, "max": false, "min": false, "rightSide": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [ { "alias": "25.0", "yaxis": 1 }, { "alias": "100.0", "yaxis": 1 } ], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "rate(canal_instance_client_request_latency_bucket{destination=~\"$destination\"}[2m])", "format": "time_series", "hide": false, "interval": "15s", "intervalFactor": 2, "legendFormat": "{{le}}ms", "refId": "A" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Response time", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "transparent": false, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "collapsed": false, "gridPos": { "h": 1, "w": 24, "x": 0, "y": 18 }, "id": 36, "panels": [], "title": "Store", "type": "row" }, { "aliasColors": {}, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "Canal instance ringbuffer内未开释的events数量。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 0, "y": 19 }, "id": 20, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "canal_instance_store_produce_seq{destination=~\"$destination\"} - canal_instance_store_consume_seq{destination=~\"$destination\"}", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "events", "refId": "A" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Store remain events", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "decimals": null, "format": "none", "label": "", "logBase": 1, "max": null, "min": null, "show": true }, { "decimals": null, "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } }, { "aliasColors": {}, "bars": false, "dashLength": 10, "dashes": false, "datasource": "$datasource", "description": "Canal instance ringbuffer 内未开释events占用内存。", "fill": 1, "gridPos": { "h": 5, "w": 6, "x": 6, "y": 19 }, "id": 22, "legend": { "avg": false, "current": false, "max": false, "min": false, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 1, "links": [], "nullPointMode": "null", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [], "spaceLength": 10, "stack": false, "steppedLine": false, "targets": [ { "expr": "(canal_instance_store_produce_mem{destination=~\"$destination\"} - canal_instance_store_consume_mem{destination=~\"$destination\"}) / 1024", "format": "time_series", "interval": "15s", "intervalFactor": 2, "legendFormat": "memsize", "refId": "A" } ], "thresholds": [], "timeFrom": null, "timeShift": null, "title": "Store remain mem", "tooltip": { "shared": true, "sort": 0, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [] }, "yaxes": [ { "format": "deckbytes", "label": null, "logBase": 1, "max": null, "min": null, "show": true }, { "format": "short", "label": null, "logBase": 1, "max": null, "min": null, "show": true } ], "yaxis": { "align": false, "alignLevel": null } } ], "refresh": false, "schemaVersion": 16, "style": "dark", "tags": [ "canal" ], "templating": { "list": [ { "current": { "text": "prometheus", "value": "prometheus" }, "hide": 0, "label": "datasource", "name": "datasource", "options": [], "query": "prometheus", "refresh": 1, "regex": "", "type": "datasource" }, { "allValue": null, "current": {}, "datasource": "$datasource", "hide": 0, "includeAll": false, "label": "destination", "multi": false, "name": "destination", "options": [], "query": "label_values(canal_instance, destination)", "refresh": 1, "regex": "", "sort": 0, "tagValuesQuery": "", "tags": [], "tagsQuery": "", "type": "query", "useTags": false } ] }, "time": { "from": "now-6h", "to": "now" }, "timepicker": { "refresh_intervals": [ "5s", "10s", "30s", "1m", "5m", "15m", "30m", "1h", "2h", "1d" ], "time_options": [ "5m", "15m", "1h", "6h", "12h", "24h", "2d", "7d", "30d" ] }, "timezone": "", "title": "Canal instances", "uid": "8vh8NGpiz", "version": 103}三、参考链接1、https://github.com/alibaba/canal/wiki/Prometheus-QuickStart ...

我的项目地址指南我的项目地址我的项目阐明这是一个收费的prometheus底层原理课程(当然是精简版的) 次要介绍两大块内容，这也是大家常见的问题 prometheus采集k8s的原理prometheus的高可用存储怎么做付费全方位教程如果想进一线互联网大厂从事监控运维/开发的工作(冲击35k+的月薪) 须要更全面的理解Prometheus底层原理，并有高可用实战项⽬教训。 能够购买上面的付费课程， 课程链接：prometheus全组件配置应用、底层原理解析、高可用实战 付费课程介绍学完这个课程，你能够能够搭建如下架构哦门课指标用户收益 一线运维人员：学习应用、相熟配置、把握调优、升职加薪 能够从头到尾相熟prometheus、各种exporter、alertmanager、grafana、m3db、loki等组件的应用配置相熟支流exporter(中间件、存储)的告警表达式配置同时能把握相干组件调优的教训运维开发人员：学习高性能原理，可助⼒斩获⼤⼚监控运维开发offer 从源码级别理解prometheus高性能的设计方案把握二次开发相干组件的能力理解分布式系统高可用革新计划筹备工作在k8s中部署prometheuskubectl apply -f prome_k8s_all_pod/kube-stats-metricskubectl apply -f prome_k8s_all_pod/在k8s中部署grafanakubectl apply -f grafana/k8s关注指标剖析k8s中组件简单，咱们次要专一的无外乎四大块指标：容器根底资源指标、k8s资源指标、k8s服务组件指标、部署在pod中业务埋点指标 指标类型采集源利用举例发现类型grafana截图容器根底资源指标kubelet 内置cadvisor metrics接口查看容器cpu、mem利用率等k8s_sd node级别间接拜访node_ip k8s资源指标kube-stats-metrics (简称ksm)具体能够看 看pod状态如pod waiting状态的起因 数个数如：查看node pod按namespace散布状况通过coredns拜访域名 k8s服务组件指标服务组件 metrics接口查看apiserver 、scheduler、etc、coredns申请提早等k8s_sd endpoint级别 部署在pod中业务埋点指标pod 的metrics接口根据业务指标场景k8s_sd pod级别，拜访pod ip的metricspath

前言前几年做性能测试监控部署了telegraf+infludb+grafana，不便查看和存档性能监控数据，随着K8s流行起来，Prometheus计划开始失去各大厂青眼，最近尝试部署Prometheus+Grafana，再配合各种exporter，丰盛性能测试监控伎俩。Prometheus简介概念Prometheus是由SoundCloud开发的开源监控报警零碎和时序列数据库(TSDB)。Prometheus应用Go语言开发，是Google BorgMon监控零碎的开源版本。2016年由Google发动Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源我的项目。Prometheus目前在开源社区相当沉闷。Prometheus和Heapster(Heapster是K8S的一个子项目，用于获取集群的性能数据。)相比性能更欠缺、更全面。Prometheus性能也足够反对上万台规模的集群。官网地址：https://prometheus.io/特点多维度数据模型高效灵便的查问语句不依赖分布式存储，单个服务器节点是自主的通过基于HTTP的pull形式采集时序数据能够通过两头网关进行时序列数据推送通过服务发现或者动态配置来发现指标服务对象反对多种多样的图表和界面展现，比方Grafana等组件promethues server：次要获取和存储工夫序列数据exporters：次要作为agent收集数据发送到prometheus server，不同的数据收集由不同的exporters实现，如监控服务器有node-exporters，redis有redis-exporter。 更多exporters可参看EXPORTERS AND INTEGRATIONS对应端口号Default port allocations · prometheus/prometheus Wiki · GitHubpushgateway：容许短暂和批处理的jobs推送它们的数据到prometheus；因为这类工作的存在工夫不长，须要他们被动将数据推送到pushgateway，而后由pushgateway将数据发送给prometheus。alertmanager：实现prometheus的告警性能。架构 GrafanaGrafana是一个跨平台的开源的度量剖析和可视化工具，能够通过将采集的数据查问而后可视化的展现，并及时告诉。特点展现形式：疾速灵便的客户端图表，面板插件有许多不同形式的可视化指标和日志，官网库中具备丰盛的仪表盘插件，比方热图、折线图、图表等多种展现形式；数据源：Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch和KairosDB等；告诉揭示：以可视形式定义最重要指标的警报规定，Grafana将一直计算并发送告诉，在数据达到阈值时通过Slack、PagerDuty等取得告诉；混合展现：在同一图表中混合应用不同的数据源，能够基于每个查问指定数据源，甚至自定义数据源；正文：应用来自不同数据源的丰盛事件正文图表，将鼠标悬停在事件上会显示残缺的事件元数据和标记；过滤器：Ad-hoc过滤器容许动态创建新的键/值过滤器，这些过滤器会主动利用于应用该数据源的所有查问装置部署prometheus手动下载，并依据yml配置文件启动服务download the latest releasewget https://github.com/prometheus/prometheus/releases/download/v*/prometheus-*.*-amd64.tar.gztar xvf prometheus-*.*-amd64.tar.gzcd prometheus-*nohup ./prometheus --config.file=./prometheus.yml &grafana手动下载，并依据yml配置文件启动服务download the latest releasewget https://dl.grafana.com/oss/release/grafana-7.5.6-1.x86_64.rpmsudo yum install grafana-7.5.6-1.x86_64.rpmdocker装置docker-compose对立装置prometheus及grafanacd /optmkdir -p prometheus/config/mkdir -p grafana/datachmod 777 grafana/datamkdir -p /data/prometheuschmod 777 /data/prometheus创立prometheus.yml配置文件cd /opt/prometheus/config/touch prometheus.yml编辑prometheus.yml配置文件#my global configglobal: scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. #scrape_timeout is set to the global default (10s).#Alertmanager configurationalerting: alertmanagers: - static_configs: - targets: #- alertmanager:9093#Load rules once and periodically evaluate them according to the global 'evaluation_interval'.rule_files: #- "first_rules.yml" #- "second_rules.yml"#A scrape configuration containing exactly one endpoint to scrape:#Here it's Prometheus itself.scrape_configs: #The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: 'prometheus' #metrics_path defaults to '/metrics' #scheme defaults to 'http'. static_configs: - targets: ['192.168.9.140:9090'] - job_name: "node" static_configs: - targets: ["192.168.9.140:9100"] - job_name: "qianmingyanqian" static_configs: - targets: ["11.12.108.226:9100","11.12.108.225:9100"] ## config for the multiple Redis targets that the exporter will scrape - job_name: "redis_exporter_targets" scrape_interval: 5s static_configs: - targets: - redis://192.168.9.140:6379 - redis://192.168.9.140:7001 - redis://192.168.9.140:7004 metrics_path: /scrape relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: 192.168.9.140:9121创立docker-compose_prometheus_grafana.yml配置文件cd /optmkdir docker-composetouch docker-compose_prometheus_grafana.yml编辑docker-compose_prometheus_grafana.yml文件并键入version: '2'networks: monitor: driver: bridgeservices: prometheus: image: prom/prometheus:latest container_name: prometheus hostname: prometheus restart: always volumes: - /opt/prometheus/config:/etc/prometheus - /data/prometheus:/prometheus ports: - "9090:9090" expose: - "8086" command: - '--config.file=/etc/prometheus/prometheus.yml' - '--log.level=info' - '--web.listen-address=0.0.0.0:9090' - '--storage.tsdb.path=/prometheus' - '--storage.tsdb.retention=15d' - '--query.max-concurrency=50' networks: - monitor grafana: image: grafana/grafana:latest container_name: grafana hostname: grafana restart: always volumes: - /opt/grafana/data:/var/lib/grafana ports: - "3000:3000" - "26:26" networks: - monitor depends_on: - prometheusdocker-compose运行docker容器docker-compose -p prometheus_grafana -f docker-compose_prometheus_grafana.yml up -d启动胜利通过浏览器http://192.168.9.140:9090/拜访prometheus服务 ...

过来几年，Kubernetes曾经成为容器编排的规范，越来越多的公司开始在生产零碎应用Kubernetes。通常咱们应用Prometheus对K8S集群进行监控，但因为Prometheus本身单点的问题。不得不寻求一些联邦计划或者分布式高可用计划，社区热度比拟高的我的项目有Thanos,Cortex,VictoriaMetrics。本文就介绍应用VictoriaMetrics作为数据存储后端对K8S集群进行监控，k8s部署不再具体形容。 环境版本试验应用单节点k8s 网络组件应用cilium VictoriaMetrics存储应用localpv [root@cilium-1 victoria-metrics-cluster]# cat /etc/redhat-release CentOS Linux release 7.9.2009 (Core)[root@cilium-bgp-1 victoria-metrics-cluster]# uname -r4.19.110-300.el7.x86_64[root@cilium-1 pvs]# kubectl get nodeNAME STATUS ROLES AGE VERSIONcilium-1.novalocal Ready master 28m v1.19.4次要监控指标master,node节点负载状态k8s 组件状态etcd状态k8s集群资源状态 （deploy,sts,pod...）用户自定义组件(次要通过pod定义prometheus.io/scrape主动上报target)...监控须要部署的组件VictoriaMetrics(storage,insert,select,agent,vmalert)promxykube-state-metricsnode-exporterkarmaalertmanagergrafana...部署VictoriaMetrics创立localpv为storage组件提供StorageClass 也能够应用其余网络存储 ---apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: vm-disksprovisioner: kubernetes.io/no-provisionerreclaimPolicy: RetainvolumeBindingMode: WaitForFirstConsumer---apiVersion: v1kind: PersistentVolumemetadata: name: vm-1spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: vm-disks local: path: /mnt/vmdata-1 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - cilium-1.novalocal---...[root@cilium-1 pvs]# kubectl get scNAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGEvm-disks kubernetes.io/no-provisioner Retain WaitForFirstConsumer false 6m5s[root@cilium-1 pvs]# kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEvm-1 10Gi RWO Delete Available vm-disks 92svm-2 10Gi RWO Delete Available vm-disks 92svm-3 10Gi RWO Delete Available vm-disks 92s应用helm 进行装置增加helm repo 拉取chart包并解压 ...

在企业的零碎平台上运行artifactory可能每天有上百万个制品在一直流转，随着研发团队不断扩大，用户缓缓增多，并发量也相应的逐步增大，在保障高可用的同时，咱们对artifactory所在零碎及应用服务进行监控会显得尤其重要。那么如何实现零碎及利用的监控呢？ 这篇文章形容如何通过prometheus、grafana实现对Artifactory的根底零碎及利用JVM监控。一、Prometheus Server端部署下载安装包并解压（以版本2.11.1为例）下载地址：https://prometheus.io/download/mkdir /opt/monitor/prometheus;cd /opt/monitor/prometheusunzip prometheus.zip ./tar zxf prometheus-2.11.1.linux-amd64.tar.gzmv prometheus-2.11.1.linux-amd64 prometheus-2.11.1 增加为零碎服务vim /usr/lib/systemd/system/prometheus-server.service[Unit]Description=prometheus-serverAfter=network.target [Service]Type=simpleUser=rootExecStart=/opt/monitor/prometheus/prometheus-2.11.1/prometheus --config.file=/opt/monitor/prometheus/prometheus-2.11.1/prometheus.ymlRestart=on-failure [Install]WantedBy=multi-user.target 启动并退出开机自启systemctl start prometheus-serversystemctl enable prometheus-server 拜访http://ip:9090 二、Prometheus Node端部署下载安装包并解压（以版本0.18.1为例）cd /opt/monitor/prometheusunzip prometheus.zip ./tar zxf node_exporter-0.18.1.linux-amd64.tar.gzmv node_exporter-0.18.1.linux-amd64 node_exporter-0.18.1 增加为零碎服务vim /usr/lib/systemd/system/prometheus-node.service[Unit]Description=prometheus-nodeAfter=network.target [Service]Type=simpleUser=rootExecStart=/opt/monitor/prometheus/node_exporter-0.18.1/node_exporterRestart=on-failure [Install]WantedBy=multi-user.target 启动并退出开机自启systemctl start prometheus-nodesystemctl enable prometheus-node 三、Grafana部署下载安装包并装置（以6.2.5.1为例）wget https://dl.grafana.com/oss/re... yum localinstall grafana-6.2.5-1.x86_64.rpm -y 启动systemctl start/stop/restart/enable grafana-server 拜访http://IP:3000默认用户名/明码：admin/admin 四、配置Artifactory节点系统监控配置prometheus在Artifactory各个节点装置好Prometheus Node后，批改/opt/monitor/prometheus-2.11.1/prometheus.yml，增加： job_name: 'artifactory'      static_configs:            - targets: ['IP1:9100','IP2:9100']重启prometheus-serversystemctl restart prometheus-server 查看监控状态及数据查问示例 应用grafana展现，模板可参考https://grafana.com/dashboard... 监控状态如下图 五、配置Artifactory节点JVM监控下载jmx_prometheus_javaagent-0.12.0.jar下载地址参考：https://repo1.maven.org/maven...Jar包门路：/opt/monitor/prometueus/jmx_prometheus_javaagent-0.12.0.jar增加配置文件 vim /opt/monitor/prometheus/jmx_config.yamllowercaseOutputLabelNames: truelowercaseOutputName: true rules: pattern: ".*"批改Artifactory tomcat配置文件vim $ARTIFACTORY_HOME/tomcat/bin/catalina.sh,增加：JAVA_OPTS="$JAVA_OPTS -javaagent:/opt/monitor/prometheus/jmx_prometheus_javaagent-0.12.0.jar=30013:/opt/monitor/prometheus/jmx_config.yaml" ...

简介：在这篇博文中，咱们将简要解释须要思考的畛域，KEDA 如何使利用主动伸缩变得简略，以及为什么阿里云企业分布式应用服务（EDAS）在 KEDA 上齐全标准化。 联结作者 |  Yan Xun，阿里云 EDAS 团队高级工程师 Andy Shi，阿里云开发者倡导者 Tom Kerkhove，Codit 容器化业务负责人兼 Azure 架构师、KEDA 维护者、CNCF 大使 起源 | KubeVela 我的项目一起构建的。其总体架构如下图所示。 在生产上，EDAS 在阿里云上集成了 ARMS 监控服务，提供监控和利用的细粒度指标。EDAS 团队在 KEDA 我的项目中增加了一个 ARMS Scaler 来执行主动缩放。他们还增加了一些个性，并修复了 KEDA v1 版本中的一些 bug。包含： 当有多个触发器时，这些值将被求和，而不是作为独自的值留下。当创立 KEDA HPA 时，名称的长度将被限度为 63 个字符，以防止触发 DNS 投诉。不能禁用触发器，这可能会在生产中引起麻烦。EDAS 团队正在踊跃地将这些修复程序发送给上游 KEDA，只管其中一些曾经增加到 V2 版本中。 为什么阿里云将 KEDA 标准化为其利用的主动伸缩器当波及到主动扩大个性时，EDAS 最后应用上游 Kubernetes HPA 的 CPU 和内存作为两个指标。然而，随着用户群的增长和需要的多样化，EDAS 团队很快发现了上游 HPA 的局限性： 对定制指标的反对无限，特地是对应用程序级细粒度指标的反对。上游 HPA 次要关注容器级指标，比方 CPU 和内存，这些指标对于应用程序来说太毛糙了。反映应用程序负载的指标（如 RT 和 QPS）不受现成反对。是的，HPA 能够扩大。然而，当波及到应用程序级指标时，这种能力是无限的。EDAS 团队在尝试引入细粒度的应用程序级指标时，常常被迫分叉代码。不反对伸缩到零。当他们的微服务没有被应用时，许多用户都有将规模伸缩到零的需要。这一需要不仅限于 FaaS/无服务器工作负载。它为所有用户节省成本和资源。目前，上游 HPA 不反对此性能。不反对预约的伸缩。EDAS 用户的另一个强烈需要是预约的伸缩能力。同样，上游 HPA 不提供此性能，EDAS 团队须要寻找非供应商锁定的代替计划。基于这些需要，EDAS 团队开始布局 EDAS 主动伸缩个性的新版本。与此同时，EDAS 在 2020 年初引入了 OAM，对其底层外围组件进行了彻底改革。OAM 为 EDAS 提供了标准化的、可插入的利用程序定义，以取代其外部的 Kubernetes 应用程序 CRD。该模型的可扩展性使 EDAS 可能轻松地与 Kubernetes 社区的任何新性能集成。在这种状况下，EDAS 团队试图将对 EDAS 新的主动伸缩个性的需要与 OAM 主动伸缩个性的规范实现相结合。 基于用例，EDAS 团队总结了三个规范： ...

在时序数据库中的高基数问题能够看我之前写的文章高基数和prometheus中断定高基数的三种办法明天咱们解说下其中第二种断定办法的range_query 原理并且解说下query_log统计的原理总结range_query查问过程解析参数设置超时并设置opentracing依据queryEngine初始化query并解析promqlexec函数先设置 ExecTotalTimeexec函数进入队列排队 设置并计算 ExecQueueTimeexec函数 设置 EvalTotalTime 并执行execEvalStmt函数execEvalStmt函数 筹备存储上的querier+select series 设置并计算QueryPreparationTimeexecEvalStmt函数 设置InnerEvalTime，从存储拿到series后在本地内存中执行 evaluator.Eval(s.Expr)execEvalStmt函数设置并计算 ResultSortTimeprometheus query_log 配置配置# global段开启log即可global: query_log_file: /opt/logs/prometheus_query_logrange_query_log解析{ # 申请根底信息 "httpRequest":{ "clientIP":"192.168.43.114", "method":"POST", "path":"/api/v1/query_range" }, # 参数段 "params":{ "end":"2021-05-03T02:32:45.000Z", "query":"rate(node_disk_reads_completed_total{instance=~"192\\.168\\.43\\.114:9100"}[2m])", "start":"2021-05-03T02:17:45.000Z", "step":15 }, # 统计段 "stats":{ "timings":{ "evalTotalTime":0.000331799, "resultSortTime":0.000001235, "queryPreparationTime":0.000075478, "innerEvalTime":0.00024141, "execQueueTime":0.000012595, "execTotalTime":0.000354698 } }, # 申请工夫 "ts":"2021-05-03T02:32:49.876Z"}上面从源码层看下range_query的查问原理D:\nyy_work\go_path\pkg\mod\github.com\prometheus\prometheus@v1.8.2-0.20210220213500-8c8de46003d1\web\api\v1\api.go func (api *API) queryRange(r *http.Request) (result apiFuncResult) {}step1: 参数解析 // 解析start start, err := parseTime(r.FormValue("start")) if err != nil { return invalidParamError(err, "start") } // 解析end end, err := parseTime(r.FormValue("end")) if err != nil { return invalidParamError(err, "end") } // 判断end是否早于start if end.Before(start) { return invalidParamError(errors.New("end timestamp must not be before start time"), "end") } // 解析 step step, err := parseDuration(r.FormValue("step")) if err != nil { return invalidParamError(err, "step") } if step <= 0 { return invalidParamError(errors.New("zero or negative query resolution step widths are not accepted. Try a positive integer"), "step") }避免point过多 // 这里怎么了解？ // For safety, limit the number of returned points per timeseries. // This is sufficient for 60s resolution for a week or 1h resolution for a year. if end.Sub(start)/step > 11000 { err := errors.New("exceeded maximum resolution of 11,000 points per timeseries. Try decreasing the query resolution (?step=XX)") return apiFuncResult{nil, &apiError{errorBadData, err}, nil, nil} }设置超时 ctx := r.Context() if to := r.FormValue("timeout"); to != "" { var cancel context.CancelFunc timeout, err := parseDuration(to) if err != nil { return invalidParamError(err, "timeout") } ctx, cancel = context.WithTimeout(ctx, timeout) defer cancel() }step2： 依据queryEngine初始化query并解析promqlfunc (ng *Engine) NewRangeQuery(q storage.Queryable, qs string, start, end time.Time, interval time.Duration) (Query, error) { expr, err := parser.ParseExpr(qs) if err != nil { return nil, err } if expr.Type() != parser.ValueTypeVector && expr.Type() != parser.ValueTypeScalar { return nil, errors.Errorf("invalid expression type %q for range query, must be Scalar or instant Vector", parser.DocumentedType(expr.Type())) } qry, err := ng.newQuery(q, expr, start, end, interval) if err != nil { return nil, err } qry.q = qs return qry, nil}queryEngine从何而来？ ...

写在最前prometheus断定高基数的三种办法prometheus tsdb的统计接口prometheus 能够依据query_log中的queryPreparationTime来定位prometheus 通过count by 统计什么是高基数 high-cardinality基数狭义上是指汇合中值的数量 在数据库畛域，基数是指数据库的特定列或字段中蕴含的惟一值的数量。 工夫序列数据集的基数通常由每个独自的索引列的基数的叉积定义 高基数示例：工业物联网设想一下一个IoT场景，其中某个采石场中有大量的重型设施在开采岩石，破碎岩石和分选岩石。假如有10,000件设施，每个设施带有100个传感器，运行10个不同的固件版本，散布在100个站点中：timestamp | temper | mem_f | equipm | senso | firmwar | sit | (lat,long) | ature | ree | ent_id | r_id | e_version | e_id |--------------------+-------+--------+-------------------+------+-----------2019-04-04 | 85.2 | 10.2 | 1 | 98 | 1.0 | 4 | (x,y) 09:00:00 | | | | | | | 2019-04-04 | 68.8 | 16.0 | 72 | 12 | 1.1 | 20 | (x1,y1)09:00:00 | | | | | | | 2019-04-04 | 100.0 | 0.0 | 34 | 58 | 2.1 | 55 | (x2,y2) 09:00:00 | | | | | | | 2019-04-04 | 84.8 | 9.8 | 12 | 75 | 1.4 | 81 | (x3,y3)09:00:00 | | | | | | | 2019-04-04 | 68.7 | 16.0 | 89 | 4 | 2.1 | 13 | (x4,y4)09:00:00 | | | | | | | ... | | | | | | | 而后，此数据集的最大基数变为10亿[10,000 x 100 x 10 x 100]。当初，假如设施也能够挪动，并且咱们想存储准确的GPS地位（纬度，经度），并将其用作索引的元数据进行查问。因为（lat，long）是一个间断字段（与诸如equipment_id之类的离散字段绝对），所以通过在地位上建设索引，此数据集的最大基数当初无限大（无界）。高基数查问艰深的说就是返回的series或者查问到的series数量过多查问体现进去返回工夫较长，对应调用服务端资源较多的查问数量多少算多 10w~100w个别咱们定义在1小时内的range_query 响应工夫超过3秒则认为较重了prometheus断定高基数的三种办法prometheus tsdb的统计接口prometheus 能够依据query_log中的queryPreparationTime来定位prometheus 通过count by 统计办法一 tsdb的统计接口http://192.168.43.114:9090/ts...接口地址 /api/v1/status/tsdb是基于内存中的倒排索引 算最大堆取 top1010个最多的metric_name排序 ...

前言我看到很多人会这样应用联邦：联邦prometheus 收集多个采集器的数据切实看不下上来了，很多小白还在乱用prometheus的联邦其实很多人是想实现prometheus数据的可用性，数据分片保留，有个对立的查问中央(小白中的联邦prometheus)而且引入m3db等反对集群的tsdb可能比拟重 具体问题能够看我之前写的文章 m3db资源开销，聚合降采样，查问限度等注意事项m3db-node oom追踪和内存分配器代码查看明天写篇文章剖析下联邦的问题，并给出一个基于全副是prometheus的multi_remote_read计划架构图 联邦问题联邦文档地址联邦应用样例实质上就是采集级联说白了就是 a 从 b,c,d那里再采集数据过去能够搭配match指定只拉取某些指标上面就是官网文档给出的样例scrape_configs: - job_name: 'federate' scrape_interval: 15s honor_labels: true metrics_path: '/federate' params: 'match[]': - '{job="prometheus"}' - '{__name__=~"job:.*"}' static_configs: - targets: - 'source-prometheus-1:9090' - 'source-prometheus-2:9090' - 'source-prometheus-3:9090'看下面的样例配置怎么感觉是采集的配置呢不必狐疑就是，上面看看代码剖析一下 从上述配置能够看到采集的 path是 /federate // web.go 的 federate Handler router.Get("/federate", readyf(httputil.CompressionHandler{ Handler: http.HandlerFunc(h.federation), }.ServeHTTP))剖析下联邦函数 说白了就是读取本地存储数据处理func (h *Handler) federation(w http.ResponseWriter, req *http.Request) { // localstorage 的query q, err := h.localStorage.Querier(req.Context(), mint, maxt) defer q.Close() // 最终发送的Vector 数组 vec := make(promql.Vector, 0, 8000) hints := &storage.SelectHints{Start: mint, End: maxt} var sets []storage.SeriesSet set := storage.NewMergeSeriesSet(sets, storage.ChainedSeriesMerge) // 遍历存储中的full series for set.Next() { s := set.At() vec = append(vec, promql.Sample{ Metric: s.Labels(), Point: promql.Point{T: t, V: v}, }) for _, s := range vec { nameSeen := false globalUsed := map[string]struct{}{} protMetric := &dto.Metric{ Untyped: &dto.Untyped{}, } // Encode办法依据申请类型编码 if protMetricFam != nil { if err := enc.Encode(protMetricFam); err != nil { federationErrors.Inc() level.Error(h.logger).Log("msg", "federation failed", "err", err) return } } } protMetric.TimestampMs = proto.Int64(s.T) protMetric.Untyped.Value = proto.Float64(s.V) protMetricFam.Metric = append(protMetricFam.Metric, protMetric) } // if protMetricFam != nil { if err := enc.Encode(protMetricFam); err != nil { federationErrors.Inc() level.Error(h.logger).Log("msg", "federation failed", "err", err) } }}最终调用压缩函数压缩type CompressionHandler struct { Handler http.Handler}// ServeHTTP adds compression to the original http.Handler's ServeHTTP() method.func (c CompressionHandler) ServeHTTP(writer http.ResponseWriter, req *http.Request) { compWriter := newCompressedResponseWriter(writer, req) c.Handler.ServeHTTP(compWriter, req) compWriter.Close()}如果没有过滤那么只是一股脑把分片的数据集中到了一起，没意义很多时候是因为数据量太大了，扩散在多个采集器的数据是不能被一个联邦消化的正确应用联邦的姿态应用match加过滤，将采集数据分位两类 ...

简介：作为CNCF[成员](https://landscape.cncf.io/car...[Weave Flagger](flagger.app)提供了继续集成和继续交付的各项能力。Flagger将渐进式公布总结为3类： - **灰度公布/金丝雀公布(Canary)**：用于渐进式切流到灰度版本(progressive traffic shifting) - **A/B测试(A/B Testing)**：用于依据申请信息将作为CNCF成员，Weave Flagger提供了继续集成和继续交付的各项能力。Flagger将渐进式公布总结为3类： 灰度公布/金丝雀公布(Canary)：用于渐进式切流到灰度版本(progressive traffic shifting)A/B测试(A/B Testing)：用于依据申请信息将用户申请路由到A/B版本(HTTP headers and cookies traffic routing)蓝绿公布(Blue/Green)：用于流量切换和流量复制 (traffic switching and mirroring)本篇将介绍Flagger on ASM的渐进式灰度公布实际。 Setup Flagger1 部署Flagger执行如下命令部署flagger(残缺脚本参见：demo\_canary.sh)。 alias k="kubectl --kubeconfig $USER_CONFIG"alias h="helm --kubeconfig $USER_CONFIG"cp $MESH_CONFIG kubeconfigk -n istio-system create secret generic istio-kubeconfig --from-file kubeconfigk -n istio-system label secret istio-kubeconfig istio/multiCluster=trueh repo add flagger https://flagger.apph repo updatek apply -f $FLAAGER_SRC/artifacts/flagger/crd.yamlh upgrade -i flagger flagger/flagger --namespace=istio-system \ --set crd.create=false \ --set meshProvider=istio \ --set metricsServer=http://prometheus:9090 \ --set istio.kubeconfig.secretName=istio-kubeconfig \ --set istio.kubeconfig.key=kubeconfig2 部署Gateway在灰度公布过程中，Flagger会申请ASM更新用于灰度流量配置的VirtualService，这个VirtualService会应用到命名为public-gateway的Gateway。为此咱们创立相干Gateway配置文件public-gateway.yaml如下： ...

简介：服务网格ASM的Mixerless Telemetry技术，为业务容器提供了无侵入式的遥测数据。遥测数据一方面作为监控指标被ARMPS/prometheus采集，用于服务网格可观测性；另一方面被HPA和flaggers应用，成为利用级扩缩容和渐进式灰度公布的基石。 本系列聚焦于遥测数据在利用级扩缩容和渐进式灰度公布上的实际，将分三篇介绍遥测数据(监控指标)、利用级扩缩容，和渐进式灰度公布。序服务网格ASM的Mixerless Telemetry技术，为业务容器提供了无侵入式的遥测数据。遥测数据一方面作为监控指标被ARMPS/prometheus采集，用于服务网格可观测性；另一方面被HPA和flaggers应用，成为利用级扩缩容和渐进式灰度公布的基石。 本系列聚焦于遥测数据在利用级扩缩容和渐进式灰度公布上的实际，将分三篇介绍遥测数据(监控指标)、利用级扩缩容，和渐进式灰度公布。 总体架构本系列的总体架构如下图所示： ASM下发Mixerless Telemetry相干的EnvoyFilter配置到各ASM sidecar(envoy)，启用利用级监控指标的采集。业务流量通过Ingress Gateway进入，各ASM sidecar开始采集相干监控指标。Prometheus从各POD上采集监控指标。HPA通过Adapter从Prometheus查问相干POD的监控指标，并依据配置进行扩缩容。Flagger通过Prometheus查问相干POD的监控指标，并依据配置向ASM发动VirtualService配置更新。ASM下发VirtualService配置到各ASM sidecar，从而实现渐进式灰度公布。 Flagger渐进式公布流程Flagger官网形容了渐进式公布流程，这里翻译如下： 探测并更新灰度Deployment到新版本灰度POD实例数从0开始扩容期待灰度POD实例数达到HPA定义的最小正本数量灰度POD实例衰弱检测由flagger-loadtester实例发动acceptance-test验证灰度公布在验证失败时终止由flagger-loadtester实例发动load-test验证在配置流量复制时开始从生产全流量复制到灰度每分钟从Prometheus查问并检测申请成功率和申请提早等监控指标灰度公布在监控指标不符预期的数量达到阈值时终止达到配置中迭代的次数后进行流量复制开始切流到灰度POD实例更新生产Deployment到新版本期待生产Deployment滚动降级结束期待生产POD实例数达到HPA定义的最小正本数量生产POD实例衰弱检测切流回生产POD实例灰度POD实例缩容至0发送灰度公布剖析后果告诉原文如下： With the above configuration, Flagger will run a canary release with the following steps: detect new revision (deployment spec, secrets or configmaps changes)scale from zero the canary deploymentwait for the HPA to set the canary minimum replicascheck canary pods healthrun the acceptance testsabort the canary release if tests failstart the load testsmirror 100% of the traffic from primary to canarycheck request success rate and request duration every minuteabort the canary release if the metrics check failure threshold is reachedstop traffic mirroring after the number of iterations is reachedroute live traffic to the canary podspromote the canary (update the primary secrets, configmaps and deployment spec)wait for the primary deployment rollout to finishwait for the HPA to set the primary minimum replicascheck primary pods healthswitch live traffic back to primaryscale to zero the canarysend notification with the canary analysis result前提条件已创立ACK集群，详情请参见创立Kubernetes托管版集群。已创立ASM实例，详情请参见创立ASM实例。Setup Mixerless Telemetry本篇将介绍如何基于ASM配置并采集利用级监控指标(比方申请数量总数istio_requests_total和申请提早istio_request_duration等)。次要步骤包含创立EnvoyFilter、校验envoy遥测数据和校验Prometheus采集遥测数据。 ...

转自@twt社区，作者：李志伟 随着容器化、分布式的一直倒退，业务零碎的逻辑变得复杂，定位问题越来越艰难，就须要从宿主机、容器治理平台和容器利用等多个层面进行监控，才能够定位性能问题、异样问题、平安问题等。本文介绍容器治理平台（k8s）的监控办法。 监控形式 容器类监控个别采纳Prometheus进行监控，反对默认的pull模式获取数据，这也是官网举荐的形式。然而如果一些网络或防火墙等起因无奈间接pull到数据的状况，就要借助Pushgateway让Prometheus转换为push形式获取数据；又比方咱们将prometheus搭建在外网去监控内网利用的状况下，因为内网有诸多平安限度使得无奈穿透，这时就要借助push模式来解决问题，还有就是监控的轮询监控大于被监控程序的执行工夫，比方5秒pull一次数据，然而被监控程序1秒就执行完了。如下为pull和push的通用比拟： Pull 实时性取决于定时工作；客户端是有状态，须要晓得拉取点，服务器端无状态，通常是短连贯；难点实时性和流量的取舍。 Push 实时性较好；客户端无状态，服务器端有状态，须要理解每个客户端的推送点；通常是长链接；难点客户端能力和push能力不匹配问题。 K8s集群监控 应用系统命令查看kubectl top pod --all-namespaces 应用prometheus查问语句 `sum(kube_pod_container_resource_limits{resource="cpu", unit="core",namespace="$Namespace"})` CPU usage / available CPU in cluster sum (rate (container_cpu_usage_seconds_total{namespace="$Namespace"}[1m])) / sum(machine_cpu_cores) * 100Kube_namespaces_cpu_used_percent >80% Kube_namespaces_memory_memused_bytes_percebt>80% Kube_namespaces_requests_cpu_percent>80% Kube_namespaces_requests_memory_percent>80% Pod监控项 资源限度 spec: containers: image: http://gcr.io/google_containers/serve_hostnameimagePullPolicy: Always name: kubernetes-serve-hostname resources: limits: cpu: "1" memory: 512Mi requests: cpu: "1" memory: 512Mi Pod Metrics 监控项举例： Kube_pod_container_limit_cpu_cores>2 Node节点监控及告警 命令Kubectl get nodes 间断5分钟node状态是非ready，与master节点失联，最大告警2次 先查看状态 Systemctl status kubelet ...

简介： 本文将对 RocketMQ-Exporter 的设计实现做一个简略的介绍，读者可通过本文理解到 RocketMQ-Exporter 的实现过程，以及通过 RocketMQ-Exporter 来搭建本人的 RocketMQ 监控零碎。RocketMQ 在线可交互教程现已登录知口头手实验室，PC 端登录 start.aliyun.com 即可中转。 作者 | 陈厚道  冯庆起源 | 阿里巴巴云原生公众号 导读：本文将对 RocketMQ-Exporter 的设计实现做一个简略的介绍，读者可通过本文理解到 RocketMQ-Exporter 的实现过程，以及通过 RocketMQ-Exporter 来搭建本人的 RocketMQ 监控零碎。RocketMQ 在线可交互教程现已登录知口头手实验室，PC 端登录 start.aliyun.com 即可中转。RocketMQ 云原生系列文章： 阿里的 RocketMQ 如何让双十一峰值之下 0 故障当 RocketMQ 遇上 Serverless，会碰撞出怎么的火花？云原生时代 RocketMQ 运维管控的利器 - RocketMQ Operator云原生时代消息中间件的演进路线基于 RocketMQ Prometheus Exporter 打造定制化 DevOps 平台（本文）RocketMQ-Exporter 我的项目的 GitHub 地址：https://github.com/apache/rocketmq-exporter 文章次要内容蕴含以下几个方面： RocketMQ 介绍Prometheus 简介RocketMQ-Exporter 的具体实现RocketMQ-Exporter 的监控指标和告警指标RocketMQ-Exporter 应用示例RocketMQ 介绍RocketMQ 是一个分布式音讯和流数据平台，具备低提早、高性能、高可靠性、万亿级容量和灵便的可扩展性。简略的来说，它由 Broker 服务器和客户端两局部组成，其中客户端一个是音讯发布者客户端(Producer)，它负责向 Broker 服务器发送音讯；另外一个是音讯的消费者客户端(Consumer)，多个消费者能够组成一个生产组，来订阅和拉取生产 Broker 服务器上存储的音讯。 ...

[toc] prometheus脑图梳理官网grafanaprometheusnode_exporter官网脑图如下： 自我了解脑图：

VictoriaMetrics是一个疾速的工夫序列数据库。它反对Prometheus PromQL查问，其具备以下突出特点： 对高基数数据具备十分高的写入性能。无关详细信息，请参见本文。对大量数据时具备很高的查问性能。无关详细信息，请参见本文和此电子表格。对工夫序列数据具备高压缩率。在线即时快照，而不会影响数据库操作。让咱们钻研一下VictoriaMetrics反对下的即时快照如何工作。 简略介绍ClickHouseVictoriaMetrics将数据存储在相似于ClickHouse的 MergeTree表 数据结构中。它是用于剖析数据和其余事件流的最快的数据库。在典型的剖析查问上，它的性能要比PostgreSQL和MySQL等传统数据库高10到1000倍。这意味着单个ClickHouse服务器能够代替大量的惯例数据库。 ClickHouse的速度如此之快，这要归功于其MergeTree表引擎的架构。 什么是 MergeTree?MergeTree是面向列的表引擎，其建设在相似于Log Structured Merge Tree 的数据结构上。 MergeTree属性： 每列的数据别离存储。因为不须要在读取和跳过其余列的数据上破费资源，因而缩小了列扫描期间的开销。因为各个列通常蕴含类似的数据，因而这也进步了每列的压缩率。行按"主键"排序，该主键能够蕴含多列。主键没有惟一的束缚--多行可能具备雷同的主键。这样能够通过主键或其前缀疾速进行行查找和范畴扫描。另外，因为间断排序的行通常蕴含类似的数据，因而能够进步压缩率。行被分成中等大小的块。每个块由每个列的子块组成。每个块都是独立解决的。这意味着在多CPU零碎上具备靠近完满的可扩展性--只需为所有可用的CPU内核提供独立的块即可。能够配置块大小，然而倡议应用大小在64KB-2MB之间的子块，因而它们适宜CPU缓存。因为CPU缓存拜访比RAM拜访快得多，因而能够进步性能。另外，当必须从具备多行的块中仅拜访几行时，这会缩小开销。块合并为"parts"。这些parts相似于LSM树中的SSTables。 ClickHouse在后盾将较小的parts合并为较大的parts。与标准的LSM不同，MergeTree没有严格的part大小。合并过程进步了查问性能，因为每次查问都查看了较少的parts。另外，合并过程缩小了数据文件的数量，因为每个局部都蕴含与列数成比例的固定数量的文件。Parts合并还有另一个益处--更好的压缩率，因为它能够挪动更靠近已排序行的列数据。Parts通过"分区"分组到分区中。最后，ClickHouse容许在"Date"列上创立每月分区。当初，能够应用任意表达式来构建分区键。分区键的不同值导致不同的分区。这样能够疾速不便地按分区进行数据存档/删除。接下来真正介绍VictoriaMetrics中的即时快照。 VictoriaMetrics中的即时快照VictoriaMetrics将工夫序列数据存储在相似MergeTree的表中，因而它受害于上述性能。此外，它还存储了倒排索引，以便通过给定的工夫序列选择器进行疾速查找。倒排索引存储在mergeset中--一种数据结构，该数据结构建设在MergeTree思维的根底上，并针对倒排索引查找进行了优化。 MergeTree还有一个下面没有提到的重要属性--原子性。这意味着： 新减少的parts要么呈现在MergeTree中，要么无奈呈现。 MergeTree从不蕴含局部创立的parts。合并过程也是如此--parts要么齐全合并为新part，要么无奈合并。 MergeTree中没有局部合并的parts。MergeTree中的parts内容永不变。Parts是不可变的。合并到更大的Part后，才能够删除它们。这意味着MergeTree始终处于统一状态。 许多文件系统都提供诸如硬链接之类的"怪兽"。硬链接文件共享原始文件的内容。它与原始文件没有区别。硬链接不会在文件系统上占用额定的空间。删除原始文件后，硬链接文件将成为“原始文件”，因为它成为指向原始文件内容的惟一文件。无论文件大小如何，都会立刻创立硬链接。 VictoriaMetrics应用硬链接为工夫序列数据和倒排索引创立即时快照，因为它们都存储在相似MergeTree的数据结构中。它只是从原子上将所有parts的所有文件硬链接到快照目录。这是平安的，因为parts永远不会扭转。之后，能够应用任何适合的工具（例如，用于云存储的rsync或cp）将快照备份/存档到任何存储（例如，Amazon S3或Google Cloud Storage）。存档前无需进行快照压缩，因为它已蕴含高度压缩的数据--VictoriaMetrics为工夫序列数据提供了最佳的压缩率。 新创建的快照在文件系统上不占用额定的空间，因为其文件指向MergeTree表中的现有文件。即便快照大小超过10 TB也是如此！在原始MergeTree合并/删除从快照链接的局部之后，快照开始占用额定的空间。因而，不要遗记删除旧快照以开释磁盘空间。 论断VictoriaMetrics基于ClickHouse中MergeTree表引擎的杰出构想构建了即时快照。能够随时创立这些快照，而不会在VictoriaMetrics上造成任何停机工夫或失常操作的中断。 能够在单docker镜像或单服务器二进制文件上评估快照性能。可通过以下http处理程序应用： /snapshot/list — 列出所有可用的快照/snapshot/create — 创立一个新的快照/snapshot/delete?snapshot=… — 删除指定的快照创立的快照位于/<-storageDataPath>/snapshots目录下，其中-storageDataPath是命令行标记，其中蕴含VictoriaMetrics存储数据的文件系统门路。 PS: 本文属于翻译，原文

前言最近有个新我的项目须要搞一套残缺的监控告警零碎，咱们应用了开源监控告警零碎Prometheus；其功能强大，能够很不便对其进行扩大，并且能够装置和应用简略；本文首先介绍Prometheus的整个监控流程；而后介绍如何收集监控数据，如何展现监控数据，如何触发告警；最初展现一个业务系统监控的demo。 监控架构Prometheus的整个架构流程能够参考如下图片：整个流程大抵分为收集数据，存储数据，展现监控数据，监控告警；外围组件包含：Exporters，Prometheus Server，AlertManager，PushGateway； Exporters：监控数据采集器，将数据通过Http的形式裸露给Prometheus Server；Prometheus Server：负责对监控数据的获取，存储以及查问；获取的监控数据须要是指定的Metrics 格局，这样能力解决监控数据；对于查问Prometheus提供了PromQL不便对数据进行查问汇总，当然Prometheus自身也提供了Web UI；AlertManager：Prometheus反对通过PromQL来创立告警规定，如果满足规定则创立一条告警，后续的告警流程就交给AlertManager，其提供了多种告警形式包含email，webhook等形式；PushGateway：失常状况下Prometheus Server可能间接与Exporter进行通信，而后pull数据；当网络需要无奈满足时就能够应用PushGateway作为中转站了；收集数据Exporter的次要性能就是收集数据，而后将数据通过http的形式裸露给Prometheus，而后Prometheus通过定期拉取的形式来获取监控数据；数据的起源多种多样包含：零碎级监控数据比方节点的cpu，io等，中间件比方mysql，mq等，过程级监控比方jvm等，业务监控数据等；除了监控的业务数据每个零碎可能不一样，除此之外其余的监控数据其实每个零碎都是大同小异的；所以在Exporter的起源分成了两类：社区提供的，用户自定义的； Exporter起源社区提供范畴罕用Exporter数据库MySQL Exporter, Redis Exporter, MongoDB Exporter等硬件Node Exporter等音讯队列Kafka Exporter, RabbitMQ Exporter等HTTP服务Apache Exporter, Nginx Exporter等存储HDFS Exporter等API服务Docker Hub Exporter, GitHub Exporter等其余JIRA Exporter, Jenkins Exporter， Confluence Exporter等官网提供的第三方Exporter：Exporters 用户自定义除了以上提供的第三方Exporter，用户也能够自定义Exporter，当然须要基于Prometheus提供的Client Library创立本人的Exporter程序，提供了对多种语言的反对包含：Go、Java/Scala、Python、Ruby等； Exporter运行形式从Exporter的运行形式上来讲，又能够分为：独立运行和集成到利用中； 独立运行像mysql，redis，mq这些中间件自身时不反对Prometheus，这时候就能够提供一个独立的Exporter，通过中间件对外提供的监控数据API，来获取监控数据，而后转换成Prometheus能够辨认的数据格式； 集成到利用中一些须要自定义监控指标的零碎，能够通过Prometheus提供的Client Library将监控数据在零碎外部提供给Prometheus； 数据格式Prometheus通过轮询的形式从Exporter获取监控数据，当然数据须要遵循肯定的格局，不然Prometheus也是无奈辨认的，这个格局就是 Metrics 格局. <metric name>{<label name>=<label value>, ...}次要分为三个局部 各个局部需合乎相干的正则表达式 metric name：指标的名称，次要反映被监控样本的含意 a-zA-Z_:*_label name: 标签 反映了以后样本的特色维度 [a-zA-Z0-9_]*label value: 各个标签的值，不限度格局能够看一个JVM的监控数据： # HELP jvm_memory_max_bytes The maximum amount of memory in bytes that can be used for memory management# TYPE jvm_memory_max_bytes gaugejvm_memory_max_bytes{application="springboot-actuator-prometheus-test",area="nonheap",id="Metaspace",} -1.0jvm_memory_max_bytes{application="springboot-actuator-prometheus-test",area="heap",id="PS Eden Space",} 1.033895936E9jvm_memory_max_bytes{application="springboot-actuator-prometheus-test",area="nonheap",id="Code Cache",} 2.5165824E8jvm_memory_max_bytes{application="springboot-actuator-prometheus-test",area="nonheap",id="Compressed Class Space",} 1.073741824E9jvm_memory_max_bytes{application="springboot-actuator-prometheus-test",area="heap",id="PS Survivor Space",} 2621440.0jvm_memory_max_bytes{application="springboot-actuator-prometheus-test",area="heap",id="PS Old Gen",} 2.09190912E9更多：data_model ...

Prometheus是什么 基于时序数据库的开源监控告警零碎，应用go语言最后由在线音乐分享的平台SoundCloud开源，2016年退出云原生计算基金会（CNCF，Cloud Native Computing Foundation）宽泛用于 Kubernetes 集群的监控零碎中时序数据的特点是： 增：须要频繁的进行写操作，而且是按工夫排序程序写入删：不须要随机删除，个别状况下会间接删除一个工夫区块的所有数据改：不须要对写入的数据进行更新查：须要反对高并发的读操作，读操作是按工夫程序升序或降序读，数据量十分大，缓存不起作用与监控数据地特点非常吻合 和mysql、redis相比，特点很显著： 多维度数据模型-由指标键值对标识的工夫序列数据组成（底层的数据结构是时序数列，能够对指标增加标签便于筛选）PromQL，一种灵便的查询语言。（在查问的时候组合条件进行筛选）不依赖分布式存储; 单个服务器节点是自治的。部署不便以HTTP形式，通过pull模式拉取工夫序列数据反对通过两头网关推送工夫序列数据通过服务发现或者动态配置，来发现指标服务对象反对多种多样的图表和界面展现目标： 目前的监控比拟少，现有的是健康检查，在portainer里看有没有失常的启用，还有在运行室配置的一些监控指标。并且大部分工夫服务都是失常运行的，不出事的话显得监控没什么意义，一旦出了问题，监控能够看呈现故障时刻的监控指标。交易数过多，内存，cpu的状况。事先预警，预先追踪性能优化架构： 组件： Prometheus server，用于抓取和存储工夫序列数据用于检测利用程序代码的client libraries用于反对短期jobs的push网关针对HAProxy，StatsD，Graphite等服务的特定exporters预警管理器来治理预警各种反对工具工作原理：客户端装置exporter，裸露监控指标的接口，prometheus定期从客户端pull数据，通过grafana或api clinet进行查问。 实用场景：记录任何纯数字工夫序列。 它实用于以机器为核心的监控以及高度动静的面向服务架构的监控。 在微服务的世界中，Prometheus的多维度数据收集和查问十分弱小。Prometheus是为服务的可靠性而设计的，当服务呈现故障时，它能够使你疾速定位和诊断问题。 每个Prometheus服务器都是独立的，不依赖于网络存储或其余近程服务。 当基础架构的其余局部损坏时，您能够依赖它，并且您不须要设置大量的基础架构来应用它。如果您须要100％的准确度，例如按申请计费，Prometheus不是一个好的抉择，因为收集的数据可能不够具体和残缺。 在这种状况下，您最好应用其余零碎来收集和剖析数据以进行计费，并应用Prometheus进行其余监控。 ExporterMySQL server exporter ElasticSearch exporterMongoDB exporterOracle DB ExporterRedis exporterRabbitMQ exporterNode exporterSNMP exporter 服务发现：azure、consul、dns、ec2、openstack、file、gce、kubernetes、marathon、triton、zookeeper（nerve、serverset） pull拉取采样点的端点服务称之为instance，通常对应一个过程（实例）。具备雷同目标的instance，例如，为可伸缩性或可靠性而复制的流程称为job。, 则形成了一个job 数据模型：从根本上存储的所有数据都是工夫序列: 具备工夫戳的数据流只属于单个度量指标和该度量指标下的多个标签维度。除了存储工夫序列数据外，Prometheus还能够生成长期派生的工夫序列作为查问的后果。每一个工夫序列数据由metric度量指标名称和它的标签labels键值对汇合惟一确定。这个metric度量指标名称指定监控指标零碎的测量特色（如：http_requests_total- 接管http申请的总计数）。 metric度量指标可能蕴含ASCII字母、数字、下划线和冒号，他必须配正则表达式a-zA-Z_:* 。labels开启了Prometheus的多维数据模型：对于雷同的度量名称，通过不同标签列表的联合, 会造成特定的度量维度实例。(例如：所有蕴含度量名称为/api/tracks的http申请，打上method=POST的标签，则造成了具体的http申请)。这个查询语言在这些度量和标签列表的根底上进行过滤和聚合。扭转任何度量上的任何标签值，则会造成新的工夫序列。 counter 是示意单个枯燥递增计数器的累积度量，其值只能在重启时减少或重置为零。Eg：申请数gauge是一个度量指标，它示意一个既能够递增, 又能够递加的值。Eg：cpu内存占用histogram，对察看后果进行采样（通常是申请持续时间或响应大小等），并将其计入可配置存储桶中。它还提供所有察看值的总和。summary是采样点分位图统计(通常是申请持续时间和响应大小等)。尽管它还提供察看的总数和所有观测值的总和，但它在滑动工夫窗口上计算可配置的分位数。Pull和push基于Http形式的pull模型提供了一下长处： 当开发变动时，能够运行监控如果指标实例挂掉，能够很容易地晓得能够手动指定一个指标，并通过浏览器查看该指标实例的监控情况在我的项目的利用： 服务的革新： 通过actuator和prometheus，对外裸露端点Security对裸露的端点进行爱护，每个服务增加filter，爱护/actuator/**并放行/actuator/health，以便健康检查能够通过。辨别mvc和webflux利用服务发现： 通过服务对外裸露的IP:port，多正本状况下无奈获取每个容器的指标通过eureka-consul进行服务发现，能够获取注册到eureka上的所有服务。须要将prometheus部署到服务网络，通过外部ip:port获取Prometheus server：监控SIT/QA/UAT环境： 通过一个prometheus监控不同环境，通过标签（job_name）进行辨别。不可行Push gateway，架构简单，须要保障pushgateway的高可用；无奈获取各个服务的状态每个环境均搭建prometheus ，grafana共用一个，在grafana通过选取不同的数据源展现不同环境的数据， Openapi服务 监控性能 Grafana中boot，Mysql，Redis的模板下载对应exporter，批改配置，Prometheus批改配置，增加exporter监控Grafana导入模板和时序数据库的区别：心愿部署和保护十分不便。 在微服务架构中，不同维度有不同的监控形式。 健康检查。健康检查是对利用自身健康状况的监控，查看服务是否还失常存活。日志。日志是排查问题的次要形式，日志能够提供丰盛的信息用于定位和解决问题。调用链监控。调用链监控能够残缺的呈现出一次申请的全副信息，包含服务调用链路、所耗时间等。指标监控。指标是一些基于工夫序列的离散数据点，通过聚合和计算后能反映出一些重要指标的趋势。应用服务监控根底监控数据次要是指应用服务实例的运行时状态、资源应用状况等度量指标。Micrometer默认提供了十分丰盛的利用度量指标，只有接入了Micrometer就能够间接采集到这些数据，次要包含： 零碎信息，包含运行工夫、CPU使用率、零碎负载等；内存应用状况，包含堆内存应用状况和非堆内存应用状况；线程应用状况，包含线程数、守护线程数、线程峰值等；类加载信息；GC信息，包含GC次数、GC耗费工夫等；HTTP申请状况，形容HTTP申请的性能指标，是十分重要的监控指标，在统计HTTP服务的QPS、响应工夫和成功率时必不可少。

本期作者：吴洋爱可生上海研发核心成员，研发工程师。 景象测试环境中呈现了一个异样的告警景象：一条告警通过 Thanos Ruler 的 HTTP 接口察看到继续处于 active 状态，然而从 AlertManager 这边看这条告警为已解决状态。依照 DMP 平台的设计，告警已解决指的是告警上设置的完结工夫曾经过了以后工夫。一条发送至 AlertManager 的告警为已解决状态有三种可能：1. 手动解决了告警2. 告警只产生了一次，第二次计算告警规定时会发送一个已解决的告警3. AlertManager 接管到的告警会带着一个主动解决工夫，如果还没达到主动解决工夫，则将该工夫重置为 24h 后首先，因为理解到测试环境没有手动解决过异样告警，排除第一条；其次，因为该告警继续处于 active 状态，所以不会是因为告警只产生了一次而接管到已解决状态的告警，排除第二条；最初，告警的告警的产生工夫与主动解决工夫相差不是 24h，排除第三条。那问题出在什么中央呢？ 剖析上面咱们开始剖析这个问题。综合第一节的形容，初步的猜测是告警在达到 AlertManager 前的某些阶段的处理过程太长，导致告警达到 AlertManager 后就曾经过了主动解决工夫。咱们从剖析平台里一条告警的流转过程动手，找出告警在哪个解决阶段耗时过长。首先，一条告警的产生须要两方面的配合： metric 数据告警规定将 metric 数据输出到告警规定进行计算，如果符合条件则产生告警。DMP 平台集成了 Thanos 的相干组件，数据的提供和计算则会离开，数据还是由 Prometheus Server 提供，而告警规定的计算则交由 Thanos Rule（下文简称 Ruler）解决。下图是 Ruler 组件在集群中所处的地位： 看来，想要弄清楚现告警的产生到 AlertManager 之间的过程，须要先弄清除 Ruler 的大抵机制。官网文档对 Ruler 的介绍是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。 ...

开源我的项目地址:我的项目地址: https://github.com/ning1875/prome_shard

Cortex算得上反对prometheus的长久化存储的元老了，很早就退出到CNCF基金会，目前曾经处于孵化状态了。然而倒退却始终不温不火，反而thanos青出于蓝。细想其中的起因，其架构的复杂性无疑是一个重要的起因。上面是其chunk 存储模式的架构图： 波及到组件十几个，其chunk 模式，依赖两种存储，部署和保护艰难。 从瑜亮之争到双赢cortex和thanos 作为Prometheus长久化的两种计划，几乎就是瑜亮之争。各自有各自的劣势，不过貌似thanos倒退更好一些。 目前两种解决方案正在互相学习，逐渐补救本人的短处。乏味的是这两个计划，间接援用了对方的代码来补强性能。 对于thanos， 其变动体现在上面两个方面： 在写门路上，引入了receive组件，逐渐替换掉sidecar。在读门路上，引入了query-frontend 组件，用于split 大查问和缓存某些查问后果。对于cortex，其变动体现在引入block存储模式，简化了其架构模式。 实际上，在存储上，cortex向thanos学习更多一些。在读门路上，thanos向cortex学习更多一些。 上面咱们具体介绍一下cortex的block 存储引擎模式。 Block 存储引擎块存储是基于Prometheus TSDB的Cortex存储引擎：它将每个租户的工夫序列存储到本人的TSDB中，而后将其序列写到磁盘上的块中（默认为2h块范畴周期）。每个块由块文件（蕴含多个序列的工夫戳-值对）和索引组成，该索引将metrcis名称和labels索引到块文件中的工夫序列。 块存储反对的后端是： 亚马逊S3谷歌云存储Microsoft Azure存储本地文件系统（仅单节点）置信阿里云和腾讯云的对象存储也会很快反对。 架构运行Cortex块存储时，Cortex架构不会产生重大变动，因而惯例体系结构文档也实用于块存储。然而，运行块存储时还有两个其余的Cortex服务： Store-gatewayCompactor 能够看出compactor和store-gateway组件，显著学习了thanos。store-gateway负责查问chunk，并在查问时由查询器应用。抉择块存储模式时，须要store-gateway。compactor负责将较小的块合并和反复数据删除为较大的块，以缩小给定租户的长期存储中存储的块数量，并更无效地查问它们。compactor是可选的，然而在生产环境必不可少。 写门路Ingesters从distributors接管进来的sample。每个推送申请都属于一个租户，而ingester会将接管到的sample附加到存储在本地磁盘上的特定的每个租户TSDB。接管到的sample都保留在内存中，并写入到预写日志（WAL）中，并用于在内存忽然终止的状况下复原内存中的序列。一旦每个租户收到第一个sample，就会在每个租户中提早创立每个租户的TSDB。 创立新的TSDB块时，内存中的sample会定期刷新到磁盘，并且WAL会被截断，默认状况下，每2个小时会产生一次。而后，每个新创建的块都将上载到长期存储中，并保留在初始状态，直到配置的-blocks-storage.tsdb.retention-period到期为止，以便给予queriers 和 store-gateways足够的工夫来发现新块存储并下载其索引头。 为了无效地应用WAL并可能在忽然终止Inester后复原内存中的序列，WAL须要存储到一个永恒磁盘，该磁盘在产生Inester失败（例如AWS EBS卷或GCP）的状况下仍能够生存在云端运行时应用永恒磁盘）。例如，如果您在Kubernetes中运行Cortex集群，则能够将StatefulSet与长久化批量申明一起应用。文件系统上存储WAL的地位与存储本地TSDB块（从头压缩）的地位雷同，并且无奈解耦。 Distributor series 分片和复制Distributor 实现的series分片和复制不会依据存储引擎而扭转。请务必留神，因为复制因子为N（通常为3），因而与块存储不同的是，因为复制因子N，每个工夫序列均存储N个ingesters。因为每个实例都将其本人的块写入长期存储，因而这导致存储利用率是块存储的N倍。 Compactor通过将来自多个ingesters的块合并为一个块，并删除反复的sample来解决此问题。 读门路Queriers 和 store-gateways 定期在存储桶上进行迭代，以发现最近由ingesters上传的块。 对于每个发现的块，Queriers 仅下载块的meta.json文件（蕴含一些元数据，包含该块中sample的最小和最大工夫戳），而 store-gateways 下载meta.json以及索引头，这是一个store-gateways在查问时用于查找序列的块索引的一小部分。 Queriers应用块元数据来计算在查问时须要查问的块列表，并从保留所需块的store-gateways实例中获取匹配序列。 总结不过因为cortex 倒退比拟早，其组件更丰盛。也是将来thanos的倒退方向。例如cortex 封装了alertmanager，使其也反对多租户。 到底谁是赢家，不太好说。不过最终胜利的那个解决方案，身上肯定存满了另一个的影子。

Description: 本文是介绍了Prometheus的两种贮存类型和本地存储的原理 Author: 孙健，爱可生上海研发核心成员，研发工程师 一、前言Prometheus 提供了本地存储，本文次要讲述 Prometheus 自带的 tsdb 时序数据库。 二、本地存储（tsdb）1. 什么是时序数据库时序数据库全称为工夫序列数据库。工夫序列数据库次要用于指解决带工夫标签（依照工夫的程序变动，即工夫序列化）的数据，带工夫标签的数据也称为工夫序列数据。次要用于存储周期性的采集各种实时监控信息。 2. 特点垂直写，程度读 数据点写入扩散，且数据量微小热点数据显著　3．存储配置--storage.tsdb.path：数据存储目录。默认为 data/。--storage.tsdb.retention.time：数据过期清理工夫。默认为15天。--storage.tsdb.wal-compression：此标记启用预写日志（WAL）的压缩。依据您的数据，您能够预期WAL大小将缩小一半，而额定的CPU负载却很少。此标记在2.11.0中引入，默认状况下在2.20.0中启用。请留神，一旦启用，将Prometheus降级到2.11.0以下的版本将须要删除WAL。4．目录构造首先，block 在这里是一个数据块，每个数据块绝对独立，由一个目录组成，该目录里蕴含：一个或者多个 chunk 文件（保留 timeseries 数据）、一个 metadata文件、一个 index 文件（通过 metric name 和 labels 查找 timeseries 数据在 chunk 文件的地位）。 ./data├── 01BKGV7JBM69T2G1BGBGM6KB12│ └── meta.json├── 01BKGTZQ1SYQJTR4PB43C8PD98│ ├── chunks│ │ └── 000001│ ├── tombstones│ ├── index│ └── meta.json├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K│ └── meta.json├── 01BKGV7JC0RY8A6MACW02A2PJD│ ├── chunks│ │ └── 000001│ ├── tombstones│ ├── index│ └── meta.json└── wal ├── 00000002 └── checkpoint.0000015．贮存原理(write) ...

APMAPM ( Application Performance Management ) 是利用性能治理的缩写，代表了服务的行为、可靠性、性能等的监控和治理。当利用产生故障，利用 APM 设施能够迅速检测并定位到产生故障的起因。 现在的后端服务大都是分布式、微服务化的，做好 APM 尤为重要。APM 包含许多方面工作，包含链路追踪(Tracing)、日志(Logging) 和 指标(Metrics)监控与报警 等，对应的开源基础设施也有很多，如 Jaeger/Zipkin (链路跟踪)、ELK (日志)、Prometheus/Zabbix/InfluxDB (指标监控零碎)、Grafana (监控展现前端) 等。 明天来说说什么是指标监控，以及总结一下最近学习 Prometheus 的心得，梳理一下常识网络。 Metrics 指标和 Prometheus咱们通常在应用程序中产生日志，日志往往代表的是一个利用或申请生命周期中的一个事件，它是离散的数据。而指标往往代表着应用程序中可量化可聚合剖析的数据，例如服务接管的申请量，申请量是一个一直减少的数据，咱们能够依据它和工夫的对应关系，计算出申请的增长率；再比方，服务的申请提早，咱们能够收集所有的提早时长，统计出不同的分位数，以掂量服务的整体提早体现；再比方音讯队列零碎的工作沉积状况、服务的内存占用、主机的 CPU 占用率等，这些是一个个高低浮动的数值，能够反馈一些实时情况，并且通过历史工夫的数据，反馈过来一段时间的数据稳定状况，以预测将来变动。 通过 Prometheus 咱们就能够进行这些指标数据的统计、收集、查问/聚合剖析、可视化展现、非正常指标的报警等工作。能够把 Prometheus 了解为一个指标收集器与时序数据库 (TSDB) 的汇合。 Prometheus 架构 Prometheus 采纳 PULL 的模式定期从应用程序中拉取指标数据。应用程序指标地址能够以动态配置的形式提供，也能够配置服务注册核心，动静的形式获取指标地址，见 文档。 组件Exporter 采集指标数据，为 Prometheus server 提供采集接口。Exporter 能够集成在业务代码中，也能够是一个独自的过程服务，来采集其余的服务指标。Pushgateway 是一个两头服务，短生命周期的 job 上传指标到 Pushgateway，server 从 Pushgateway 采集指标。TSDB 是 Prometheus server 内置的时序数据库，用来存储采集的指标数据，并且内置了一套用以查问数据的语法 PromQL。Alertmanager 是独立于 Prometheus server 的一个服务，用来解决报警。Prometheus server 只负责评估报警规定是否被触发，后续的报警告诉等工作交由 Alertmanager 解决。部署本地应用 Docker Compose 进行部署。 ...

开源我的项目地址:我的项目地址: https://github.com/ning1875/prome-routePS: 这是一个仅用时半天就写完的我的项目 架构图 prometheus HAprometheus本地tsdb性能杰出，然而碍于其没有集群版本导致 实现伎俩留神这些伎俩都是要数据的对立存储 能够通过remote_write 到一个提供HA的tsdb存储中通过联邦收集到一个prometheus里问题来了，搞不定集中式的tsdb集群，或者集群挂了咋办本我的项目介绍原理介绍必定有一组prometheus 服务器和pod用来采集各式各样的数据那么采集器上本地的数据就是一个个分片，采集器自身也能够充当查问的角色而且每个采集器下面的指标通过一个特色标签比方cluster/app等辨别通常是定义global.external_labels中的 global: external_labels: cluster: a如果能有一个路由组件，晓得所有特色标签对应的采集器地址shard_addr_map = { "cluster_a": "1.1.1.1:9090", "cluster_b": "2.2.2.2:9090", "cluster_c": "3.3.3.3:9090", }而后依据申请中的expr获取到特色标签，将其替换掉因为在采集器本地存储的时候没有特色标签转发到指定的采集器申请数据后再返回给grafana即可须要适配的接口prometheus 3大查问接口instance_query : /api/v1/query 报警应用和以后点查问range_query : /api/v1/query_range 查问一段时间的曲线series ： /api/v1/series 应用label_values查问变量对应在代码中实现 func Routes(r *gin.Engine) { qApi := r.Group("/") qApi.GET("/api/v1/query_range", promeRangequery) qApi.GET("/api/v1/query", promeInstancequery) qApi.GET("/api/v1/series", promeSeriesQuery) }查问状态码不同时返回数据结构不同这个很好解决，用interface即可 respBytes, err := ioutil.ReadAll(resp.Body) if err != nil { log.Error(err.Error()) c.String(http.StatusInternalServerError, fmt.Sprintf(`target prome %s error by %s=%s `, targetProme, keyName, labelName)) return } var respInterface interface{} _ = json.Unmarshal(respBytes, &respInterface) c.JSON(resp.StatusCode, respInterface)优缺点长处 ...

一、前言本文介绍采纳 clickhouse-exporter + grafana + prometheus 搭建监控 clickhouse 单节点和集群的监控体系。 二、部署 exporter获取代码并编译mkdir -p $GO_PATH/src/github.com/Percona-Labcd $GO_PATH/src/github.com/Percona-Labgit clone https://github.com/Percona-Lab/clickhouse_exporter因为生产环境的零碎是基于 Linux，不能间接拜访外网。故在本人的 mac 零碎先编译成二进制，而后拷贝到生产环境。 在 mac 上编译 clickhouse_exporter，再下载到源代码目录。 cd $GO_PATH/src/github.com/Percona-LabGO111MODULE=off `CGO_ENABLED`=0 GOOS=linux GOARCH=amd64 go build clickhouse_exporter.go编译胜利会看到二进制文件，$ ./clickhouse_exporter -hUsage of ./clickhouse_exporter: -insecure Ignore server certificate if using https (default true) -log.level value Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal, panic]. -scrape_uri string URI to clickhouse http endpoint (default "http://localhost:8123/") -telemetry.address string Address on which to expose metrics. (default ":9116") -telemetry.endpoint string Path under which to expose metrics. (default "/metrics")配置比较简单，就是指定 scrape_uri=clickhouse_server_ip:port，  ...

在Kubernetes中手动形式部署Statefulset的Grafana，并应用StorageClass来长久化数据，并且配置ingress-nginx拜访。本篇应用StorageClass来长久化数据，搭建Statefulset的Grafana，并且在Dashboard导入前配置后面曾经创立好的Prometheus的集群外部拜访地址，同时配置ingress-nginx内部拜访。 环境我的本地环境应用的 sealos 一键部署，次要是为了便于测试。 OSKubernetesHostNameIPServiceUbuntu 18.041.17.7sealos-k8s-m1192.168.1.151node-exporter prometheus-federate-0Ubuntu 18.041.17.7sealos-k8s-m2192.168.1.152node-exporter grafana alertmanager-0Ubuntu 18.041.17.7sealos-k8s-m3192.168.1.150node-exporter alertmanager-1Ubuntu 18.041.17.7sealos-k8s-node1192.168.1.153node-exporter prometheus-0 kube-state-metricsUbuntu 18.041.17.7sealos-k8s-node2192.168.1.154node-exporter prometheus-1Ubuntu 18.041.17.7sealos-k8s-node2192.168.1.155node-exporter prometheus-2部署 Grafana创立Grafana的SA文件 mkdir /data/manual-deploy/grafana/cat grafana-serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata: name: grafana namespace: kube-system创立Grafana的sc配置文件 cat grafana-data-storageclass.yamlapiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: grafana-lpvprovisioner: kubernetes.io/no-provisionervolumeBindingMode: WaitForFirstConsumer创立Grafana的pv配置文件 cat grafana-data-pv.yamlapiVersion: v1kind: PersistentVolumemetadata: name: grafana-pv-0spec: capacity: storage: 10Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: grafana-lpv local: path: /data/grafana-data nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - sealos-k8s-m2在调度节点上创立pv目录与赋权 ...

本章节次要讲主动发现应用场景介绍与Prometheus基于文件、DNS的主动发现配置当咱们应用各类exporter别离对系统、数据库和HTTP服务进行监控指标采集，对于所有监控指标对应的Target的运行状态和资源应用状况，都是用Prometheus的动态配置性能 static_configs 来手动增加主机IP和端口，而后重载服务让Prometheus发现。 对于一组比拟少的服务器的测试环境中，这种手动形式增加配置信息是最简略的办法。然而理论生产环境中，对于成千盈百的节点组成的大型集群又或者Kubernetes这样的大型集群，很显著，手动形式顾此失彼了。为此，Prometheus提前曾经设计了一套服务发现性能。 Prometheus 服务发现可能自动检测分类，并且可能辨认新节点和变更节点。也就是说，能够在容器或者云平台中，主动发现并监控节点或更新节点，动静的进行数据采集和解决。目前 Prometheus 曾经反对了很多常见的主动发现服务，比方 consul ec2 gce serverset_sd_config openStack kubernetes 等等。咱们罕用的就是sd_config、DNS、kubernetes、consul这些足够了。如果有须要其余配置的探讨，能够与我交换，我能够补上来。 本章节中会对Prometheus主动发现中的基于文件、DNS进行发现解说，consul 在前面会独自开展来讲，如何能够使其完满的解决以后场景下常见的各类服务发现监控。 为什么要用主动发现?在基于云(IaaS或者CaaS)的基础设施环境中用户能够像应用水、电一样按需应用各种资源（计算、网络、存储）。按需应用就意味着资源的动态性，这些资源能够随着需要规模的变动而变动。例如在AWS中就提供了专门的AutoScall服务，能够依据用户定义的规定动静地创立或者销毁EC2实例，从而使用户部署在AWS上的利用能够主动的适应拜访规模的变动。 这种按需的资源应用形式对于监控零碎而言就意味着没有了一个固定的监控指标，所有的监控对象(基础设施、利用、服务)都在动静的变动。对于Nagias这类基于Push模式传统监控软件就意味着必须在每一个节点上装置相应的Agent程序，并且通过配置指向核心的Nagias服务，受监控的资源与核心监控服务器之间是一个强耦合的关系，要么间接将Agent构建到基础设施镜像当中，要么应用一些自动化配置管理工具(如Ansible、Chef)动静的配置这些节点。当然理论场景下除了基础设施的监控需要以外，咱们还须要监控在云上部署的利用，中间件等等各种各样的服务。要搭建起这样一套中心化的监控系统实施老本和难度是不言而喻的。 而对于Prometheus这一类基于Pull模式的监控零碎，显然也无奈持续应用的static_configs的形式动态的定义监控指标。而对于Prometheus而言其解决方案就是引入一个两头的代理人（服务注册核心），这个代理人把握着以后所有监控指标的访问信息，Prometheus只须要向这个代理人询问有哪些监控指标控即可， 这种模式被称为服务发现。 在不同的场景下，会有不同的货色扮演者代理人（服务发现与注册核心）这一角色。比方在AWS私有云平台或者OpenStack的公有云平台中，因为这些平台本身把握着所有资源的信息，此时这些云平台本身就表演了代理人的角色。Prometheus通过应用平台提供的API就能够找到所有须要监控的云主机。在Kubernetes这类容器治理平台中，Kubernetes把握并治理着所有的容器以及服务信息，那此时Prometheus只须要与Kubernetes打交道就能够找到所有须要监控的容器以及服务对象。Prometheus还能够间接与一些开源的服务发现工具进行集成，例如在微服务架构的应用程序中，常常会应用到例如Consul这样的服务发现注册软件，Promethues也能够与其集成从而动静的发现须要监控的应用服务实例。除了与这些平台级的私有云、公有云、容器云以及专门的服务发现注册核心集成以外，Prometheus还反对基于DNS以及文件的形式动静发现监控指标，从而大大的缩小了在云原生，微服务以及云模式下监控施行难度。 如上所示，展现了Push零碎和Pull零碎的外围差别。相较于Push模式，Pull模式的长处能够简略总结为以下几点： 只有Exporter在运行，你能够在任何中央（比方在本地），搭建你的监控零碎；你能够更容易的查看监控指标实例的衰弱状态，并且能够疾速定位故障；更利于构建DevOps文化的团队；松耦合的架构模式更适宜于云原生的部署环境。基于文件的服务发现在Prometheus反对的泛滥服务发现的实现形式中，基于文件的服务发现是最通用的形式。这种形式不须要依赖于任何的平台或者第三方服务。对于Prometheus而言也不可能反对所有的平台或者环境。通过基于文件的服务发现形式下，Prometheus会定时从文件中读取最新的Target信息，因而，你能够通过任意的形式将监控Target的信息写入即可。用户能够通过JSON或者YAML格局的文件，定义所有的监控指标。例如，在上面的yaml文件中别离定义了2个采集工作，以及每个工作对应的Target列表： yaml格局 - targets: ['192.168.1.220:9100'] labels: app: 'app1' env: 'game1' region: 'us-west-2'- targets: ['192.168.1.221:9100'] labels: app: 'app2' env: 'game2' region: 'ap-southeast-1'json格局 [ { "targets": [ "192.168.1.221:29090"], "labels": { "app": "app1", "env": "game1", "region": "us-west-2" } }, { "targets": [ "192.168.1.222:29090" ], "labels": { "app": "app2", "env": "game2", "region": "ap-southeast-1" } }]同时还能够通过为这些实例增加一些额定的标签信息，例如应用env标签标示以后节点所在的环境，这样从这些实例中采集到的样本信息将蕴含这些标签信息，从而能够通过该标签依照环境对数据进行统计。 ...

本章节次要解说Alertmanager高可用的搭建与配置的具体的常识内容。为了晋升Prometheus的服务可靠性，咱们会部署两个或多个的Prometheus服务，两个Prometheus具备雷同的配置（Job配、告警规定、等），当其中一个Down掉了当前，能够保障Prometheus继续可用。 AlertManager自带警报分组机制，即便不同的Prometheus别离发送雷同的警报给Alertmanager，Alertmanager也会主动把这些警报合并解决。 | 去重 | 分组 | 路由 | | :-----: | :----: |:----: | |Daduplicates|Groups|Route||将雷同的警报合并成一个|依据定义的分组|通过路由分发给指定的receiver| 尽管Alertmanager 可能同时解决多个雷同的Prometheus的产生的警报，如果部署的Alertmanager是单节点，那就存在显著的的单点故障危险，当Alertmanager节点down机当前，警报性能则不可用。 解决这个问题的办法就是应用传统的HA架构模式，部署Alertmanager多节点。然而因为Alertmanager之间关联存在不能满足HA的需要，因而会导致警报告诉被Alertmanager反复发送屡次的问题。 Alertmanager为了解决这个问题，引入了Gossip机制，为多个Alertmanager之间提供信息传递机制。确保及时的在多个Alertmanager别离承受到雷同的警报信息的状况下，不会发送反复的警报信息给Receiver. Gossip 机制要晓得什么是Gossip机制，必须理解分明Alertmanager中的每一次警报告诉是如何产生的，上面一图很具体的论述了警报个流程： 阶段形容Silence在这个阶段中Alertmanager会判断以后告诉是否匹配任何静默规定；如果没有则进入下一个阶段，否则会中断流程不发送告诉。WaitAlertmanager 会依据以后集群中所处在的程序[index]，期待 index * 5s 的工夫。Dedup当期待完结实现，进入 Dedup 阶段，这时会判断以后Alertmanager TSDB中警报是否曾经发送，如果发送则中断流程，不发送警报。Send如果下面的未发送，则进入 Send 阶段，发送警报告诉。Gossip警报发送胜利当前，进入最初一个阶段 Gossip ，告诉其余Alertmanager节点，以后警报曾经发送胜利。其余Alertmanager节点会保留以后曾经发送过的警报记录。Gossip的俩个要害： Alertmanager 节点之间的Silence设置雷同，这样确保了设置为静默的警报都不会对外发送Alertmanager 节点之间通过Gossip机制同步警报告诉状态，并且在流程中标记Wait阶段，保障警报是顺次被集群中的Alertmanager节点读取并解决。搭建本地 Alertmanager 集群启动Alertmanager集群之前，须要理解一些集群相干的参数 参数阐明--cluster.listen-address="0.0.0.0:9094"集群服务监听端口--cluster.peer初始化关联其余节点的监听地址--cluster.advertise-address播送地址--cluster.gossip-interval集群音讯流传工夫，默认 200s--cluster.probe-interval各个节点的探测工夫距离# 间接复制之前曾经装置过的Alertmanager文件夹cp -r alertmanager/ /usr/local/alertmanager01cp -r alertmanager/ /usr/local/alertmanager02cp -r alertmanager/ /usr/local/alertmanager03# 复制实现当前，写入启动脚本，# Alertmanager01cat << EOF> /lib/systemd/system/alertmanager01.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0[Service]Type=simpleUser=prometheusExecStart=/usr/local/alertmanager01/bin/alertmanager \--config.file=/usr/local/alertmanager01/conf/alertmanager.yml \--storage.path=/usr/local/alertmanager01/data \--web.listen-address=":19093" \--cluster.listen-address=192.168.1.220:19094 \--log.level=debugRestart=alwaysRestartSec=1[Install]WantedBy=multi-user.targetEOF# Alertmanager02cat << EOF> /lib/systemd/system/alertmanager02.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0[Service]Type=simpleUser=prometheusExecStart=/usr/local/alertmanager02/bin/alertmanager \--config.file=/usr/local/alertmanager02/conf/alertmanager.yml \--storage.path=/usr/local/alertmanager02/data \--web.listen-address=":29093" \--cluster.listen-address=192.168.1.220:29094 \--cluster.peer=192.168.1.220:19094 \--log.level=debugRestart=alwaysRestartSec=1[Install]WantedBy=multi-user.targetEOF# Alertmanager03cat <<EOF > /lib/systemd/system/alertmanager03.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0[Service]Type=simpleUser=prometheusExecStart=/usr/local/alertmanager03/bin/alertmanager \--config.file=/usr/local/alertmanager03/conf/alertmanager.yml \--storage.path=/usr/local/alertmanager03/data \--web.listen-address=":39093" \--cluster.listen-address=192.168.1.220:39094 \--cluster.peer=192.168.1.220:19094 \--log.level=debugRestart=alwaysRestartSec=1[Install]WantedBy=multi-user.targetEOF# 开启systemd脚本启动systemctl enable alertmanager01 alertmanager02 alertmanager03systemctl start alertmanager01 alertmanager02 alertmanager03启动实现后，就能够拜访http://192.168.1.220:19093能够看到以下集群状态了，我这里是为了测试，本地启动了多个端口，如果是理论生产环境中，是不同节点以及不同的IP，这些依据本人的需要设计即可。 ...

本章次要对介绍什么是 Silences ， 在哪些场景中应用、以及如何设置 警报长期静默 Silences。静默 Silences 是指让通过设置让警报在指定工夫临时不会发送警报的一种形式。通常静默个别用于解决重大生产故障问题时，因所破费的工夫过长，通过静默设置防止接管到过多的无用告诉。在已知的例行保护中，为了避免对例行保护的机器发送不必要的警报，能够在保护期间设置一个工夫范畴，长期敞开警报发送，期待保护实现，在将静默敞开，另外次要下本人的时区，这里应用的是UTC工夫做的测试。 设置 Silences的形式有俩种，始终是通过 WEB UI 配置，一种是通过 amtool 工具在命令行进行设置。 Silences 创立信息形容： | 名字 | 形容 || :-----: | :----: | |Start|静默的开始工夫||End|静默的完结工夫||Duration|主动计算静默工夫，就是说开始当前，残余的工夫会在此显示||Matches|应用Labels来辨认须要静默的警报，能够间接匹配，也能够应用正则表达式。||Creator|创建者名称||Comment|形容信息| 通过下面的形容其实能够很容易晓得须要制订的参数信息，当输出实现后，间接点击create创立即可，此时去触发警报就会发现，警报不会在告诉，上面是已创立好的Silences信息。 这个时候咱们能够应用 service process_exporter stop 来触发警报，查看静默是否失效，在浏览器咱们能够看到，触发的警报曾经呈现在咱们创立的 Silences 中了。 这个时候咱们能够假如保护，并没有实现，用 Expire 来模仿保护工夫达到，而后在 Alerts 中我就能够看到警报了，相干的告诉会发送到对应的Receiver中。

m3dbnode oomoom时排查内存火焰图: 80G内存 bytes_pool_get_on_empty qps 很高db read qps增长 80%node cpu kernel 暴涨 看图论断 m3dbnode 内存oom过程很短，很激烈：总工夫不超过7分钟内存从27G增长到250G节点sys态cpu暴涨：因为大量的mem_alloca sys_call内存增长曲线和db_read_qps曲线和bytes_pool_get_on_empty曲线高度吻合内存火焰图： 27G的rpc 40G的pool.(*objectPool).tryFill查看代码，追踪火焰图中这个tryFill内存分配器目标很简略:本人治理内存，防止频繁的mem_allocate sys_call 晋升速度，空间换工夫 外围构造初始化时调用init 向池中注入type objectPool struct { opts ObjectPoolOptions values chan interface{} alloc Allocator size int refillLowWatermark int refillHighWatermark int filling int32 initialized int32 dice int32 metrics objectPoolMetrics} for i := 0; i < cap(p.values); i++ { p.values <- p.alloc() }从池中获取对象时池中还有残余则间接获取否则走各自的alloc调配同时设置bytes_pool_get_on_emptyfunc (p *objectPool) Get() interface{} { if atomic.LoadInt32(&p.initialized) != 1 { fn := p.opts.OnPoolAccessErrorFn() fn(errPoolGetBeforeInitialized) return p.alloc() } var v interface{} select { case v = <-p.values: default: v = p.alloc() p.metrics.getOnEmpty.Inc(1) } p.trySetGauges() return v}同时判断池水位，是否加油 if p.refillLowWatermark > 0 && len(p.values) <= p.refillLowWatermark { p.tryFill() }加油过程用CompareAndSwapInt32做并发管制标记位加油加到refillHighWatermarkfunc (p *objectPool) tryFill() { if !atomic.CompareAndSwapInt32(&p.filling, 0, 1) { return } go func() { defer atomic.StoreInt32(&p.filling, 0) for len(p.values) < p.refillHighWatermark { select { case p.values <- p.alloc(): default: return } } }()}默认池参数 defaultRefillLowWaterMark = 0.3 defaultRefillHighWaterMark = 0.6总结思考默认池低水位为什么不是0:因为 从水位判断到tryFill两头的并发申请使得最初tryFill开始时低水位可能低于0.3火焰图中的tryFill耗费了40G内存不是一次性的，类比右侧thriftrpc27，属于累加内存耗费值一次性的内存耗费必定没有这么多：每次加油时内存耗费低于初始化所以能够失去论断，oom是因为在过后byte_pool频繁的get耗费，而后tryFill频繁的加油导致内存调配所以根本原因还是查问导致的解决办法:限度query资源耗费爱护db批改m3coordinator参数 ...

m3dbnode oomoom时排查内存火焰图: 80G内存 bytes_pool_get_on_empty qps 很高db read qps增长 80%node cpu kernel 暴涨 看图论断 m3dbnode 内存oom过程很短，很激烈：总工夫不超过7分钟内存从27G增长到250G节点sys态cpu暴涨：因为大量的mem_alloca sys_call内存增长曲线和db_read_qps曲线和bytes_pool_get_on_empty曲线高度吻合内存火焰图： 27G的rpc 40G的pool.(*objectPool).tryFill查看代码，追踪火焰图中这个tryFill内存分配器目标很简略:本人治理内存，防止频繁的mem_allocate sys_call 晋升速度，空间换工夫 外围构造初始化时调用init 向池中注入type objectPool struct { opts ObjectPoolOptions values chan interface{} alloc Allocator size int refillLowWatermark int refillHighWatermark int filling int32 initialized int32 dice int32 metrics objectPoolMetrics} for i := 0; i < cap(p.values); i++ { p.values <- p.alloc() }从池中获取对象时池中还有残余则间接获取否则走各自的alloc调配同时设置bytes_pool_get_on_emptyfunc (p *objectPool) Get() interface{} { if atomic.LoadInt32(&p.initialized) != 1 { fn := p.opts.OnPoolAccessErrorFn() fn(errPoolGetBeforeInitialized) return p.alloc() } var v interface{} select { case v = <-p.values: default: v = p.alloc() p.metrics.getOnEmpty.Inc(1) } p.trySetGauges() return v}同时判断池水位，是否加油 if p.refillLowWatermark > 0 && len(p.values) <= p.refillLowWatermark { p.tryFill() }加油过程用CompareAndSwapInt32做并发管制标记位加油加到refillHighWatermarkfunc (p *objectPool) tryFill() { if !atomic.CompareAndSwapInt32(&p.filling, 0, 1) { return } go func() { defer atomic.StoreInt32(&p.filling, 0) for len(p.values) < p.refillHighWatermark { select { case p.values <- p.alloc(): default: return } } }()}默认池参数 defaultRefillLowWaterMark = 0.3 defaultRefillHighWaterMark = 0.6总结思考默认池低水位为什么不是0:因为 从水位判断到tryFill两头的并发申请使得最初tryFill开始时低水位可能低于0.3火焰图中的tryFill耗费了40G内存不是一次性的，类比右侧thriftrpc27，属于累加内存耗费值一次性的内存耗费必定没有这么多：每次加油时内存耗费低于初始化所以能够失去论断，oom是因为在过后byte_pool频繁的get耗费，而后tryFill频繁的加油导致内存调配所以根本原因还是查问导致的解决办法:限度query资源耗费爱护db批改m3coordinator参数 ...

本章次要对如何应用开源组件和Alertmanager组件集成警报告诉。Kubernetes的警报集成后续会间接在配置文件解说，原理大同小异，此处仅对相干警报告诉做集成。警报告诉接收器后面始终是在Web UI 查看警报信息，当初开始应用接收器与Alertmanager集成，发送警报信息到 Email、企业微信、钉钉机器人，对于警报要求比拟高的同学，能够依据上面提到的开源组件 【PrometheusAlert全家桶】 配置飞书、短信、语音电话等警报。 Email后面曾经讲过，Alertmanager默认反对配置Email，也是最一般的形式，在Alertmanager组件中内置了SMTP协定。间接能够把后面的Alertmanager.yml中的SMTP局部截取进去，而后进行调整与配置 global: resolve_timeout: 5m # smtp配置 smtp_from: "1234567890@qq.com" # 发送邮件主题 smtp_smarthost: 'smtp.qq.com:465' # 邮箱服务器的SMTP主机配置 smtp_auth_username: "1234567890@qq.com" # 登录用户名 smtp_auth_password: "auth_pass" # 此处的auth password是邮箱的第三方登录受权明码，而非用户明码，尽量用QQ来测试。 smtp_require_tls: false # 有些邮箱须要开启此配置，这里应用的是163邮箱，仅做测试，不须要开启此性能。route: receiver: ops group_wait: 30s # 在组内期待所配置的工夫，如果同组内，30秒内呈现雷同报警，在一个组内呈现。 group_interval: 5m # 如果组内内容不变动，合并为一条警报信息，5m后发送。 repeat_interval: 24h # 发送报警距离，如果指定工夫内没有修复，则从新发送报警。 group_by: [alertname] # 报警分组 routes: - match: team: operations group_by: [env,dc] receiver: 'ops' - receiver: ops # 路由和标签，依据match来指定发送指标，如果 rule的lable 蕴含 alertname， 应用 ops 来发送 group_wait: 10s match: team: operations# 接收器指定发送人以及发送渠道receivers:# ops分组的定义- name: ops email_configs: - to: '9935226@qq.com,xxxxx@qq.com' # 如果想发送多集体就以 ','做宰割，写多个邮件人即可。 send_resolved: true headers: from: "警报核心" subject: "[operations] 报警邮件" to: "小煜狼皇"配置实现后，间接重启Alertmanager组件，使配置失效，而后应用后面内存阈值触发一次警报来看下发送后果。 ...

本章次要对如何应用Prometheus与Alertmanager组件集成配置，以及对警报规定 Rules 的俩种类型及其模板内容进行解说。与Alertmanager集成Prometheus把产生的警报发给Alertmanager进行解决时，须要在Prometheus应用的配置文件中增加关联Alertmanager的组件的对应配置信息。 alerting: alert_relabel_configs: [ - <relabel_config> ... ] alertmanagers: [ - <alertmanager_config> ... ]# alertmanagers 为 alertmanager_config 数组，配置范例： alerting: alert_relabel_configs: # 动静批改 alert 属性的规定配置。 - source_labels: [dc] regex: (.+)\d+ target_label: dc1 alertmanagers: - static_configs: - targets: ['127.0.0.1:9093'] # 单实例配置 #- targets: ['172.31.10.167:19093','172.31.10.167:29093','172.31.10.167:39093'] # 集群配置 - job_name: 'Alertmanager' # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: ['localhost:19093']下面的配置中的 alert_relabel_configs是指警报从新标记在发送到Alertmanager之前利用于警报。 它具备与指标从新标记雷同的配置格局和操作，内部标签标记后利用警报从新标记，次要是针对集群配置。 这个设置的用处是确保具备不同内部label的HA对Prometheus服务端发送雷同的警报信息。 ...

本期作者：罗韦 爱可生上海研发核心成员，研发工程师，次要负责 DMP 平台监控告警性能的相干工作。 Prometheus 的监控对象各式各样，没有统一标准。为了解决这个问题，Prometheus 制订了一套监控标准，合乎这个标准的样本数据能够被 Prometheus 采集并解析样本数据。Exporter 在 Prometheus 监控零碎中是一个采集监控数据并通过 Prometheus 监控标准对外提供数据的组件，针对不同的监控对象能够实现不同的 Exporter，这样就解决了监控对象规范不一的问题。从狭义上说，所有能够向 Prometheus 提供监控样本数据的程序都能够称为 Exporter，Exporter 的实例也就是咱们上期所说的"target"。 Exporter 的运行形式Exporter 有两种运行形式集成到利用中应用 Prometheus 提供的 Client Library，能够很不便地在应用程序中实现监控代码，这种形式能够将程序外部的运行状态裸露给 Prometheus，实用于须要较多自定义监控指标的我的项目。目前一些开源我的项目就减少了对 Prometheus 监控的原生反对，如 Kubernetes，ETCD 等。 独立运行在很多状况下，对象没法间接提供监控接口，可能起因有： 1. 我的项目公布工夫较早，并不反对 Prometheus 监控接口，如 MySQL、Redis； 2. 监控对象不能间接提供 HTTP 接口，如监控 Linux 零碎状态指标。 对于上述情况，用户能够抉择应用独立运行的 Exporter。除了用户自行实现外，Prometheus 社区也提供了许多独立运行的 Exporter，常见的有 Node Exporter、MySQL Server Exporter。更多详情能够到官网理解：https://prometheus.io/docs/in... Exporter 接口数据标准Exporter 通过 HTTP 接口以文本模式向 Prometheus 裸露样本数据，格局简略，没有嵌套，可读性强。每个监控指标对应的数据文本格式如下： # HELP <监控指标名称> <监控指标形容># TYPE <监控指标名称> <监控指标类型><监控指标名称>{ <标签名称>=<标签值>,<标签名称>=<标签值>...} <样本值1> <工夫戳><监控指标名称>{ <标签名称>=<标签值>,<标签名称>=<标签值>...} <样本值2> <工夫戳>...以 # 结尾的行，如果前面跟着"HELP"，Prometheus 将这行解析为监控指标的形容，通常用于形容监控数据的起源；以 # 结尾的行，如果前面跟着"TYPE"，Prometheus 将这行解析为监控指标的类型，反对的类型有：Counter、Gauge、Histogram、Summary、Untyped。在往期文章中介绍过 Prometheus 在存储数据时是不辨别数据类型的，所以当你在犹豫一个数据类型应该用 Counter 或 Gauge 时，能够试试 Untype；以 # 结尾的行，如果前面没有跟着"HELP"或"TYPE"，则 Prometheus 将这行视为正文，解析时疏忽；如果一个监控指标有多条样本数据，那么每条样本数据的标签值组合应该是惟一的；每行数据对应一条样本数据；工夫戳应为采集数据的工夫，是可选项，如果 Exporter 没有提供工夫戳的话，Prometheus Server 会在拉取到样本数据时将工夫戳设置为以后工夫；Summary 和 Histogram 类型的监控指标要求提供两行数据别离示意该监控指标所有样本的和、样本数量，命名格局为：<监控指标名称>_sum、<监控指标名称>_count；Summary 类型的样本数据格式：1. 依据 Exporter 提供的分位点，样本会被计算后拆分成多行数据，每行应用标签"quantile"辨别，"quantile"的值包含 Exporter 提供的所有分位点。2. 数据的排列程序必须是依照标签"quantile"值递增；3. 举个栗子：一个名为x的监控指标，提供的分位点为：0.5, 0.9, 0.99，那么它裸露给 Prometheus 的接口数据格式如下：# HELP x balabala# TYPE x summaryx{quantile="0.5"} value1x{quantile="0.9"} value2x{quantile="0.99"} value3x_sum sum(values)x_count count(values)Histogram 类型的样本数据格式：1. 依据 Exporter 提供的 Bucket 值，样本会被计算后拆分成多行数据，每行应用标签"le"辨别，"le"为 Exporter 提供的 Buckets；2. 数据的排列程序必须是依照标签"le"值递增；3. 必须要有一行数据的标签 le="+Inf"，值为该监控指标的样本总数；4. 举个栗子：一个名为 x 的监控指标，提供的 Buckets 为：20, 50, 70，那么它裸露给 Prometheus 的接口数据格式如下： ...

前言本系列着重介绍Prometheus以及如何用它和其周边的生态来搭建一套属于本人的实时监控告警平台。 本系列受众对象为首次接触Prometheus的用户，大神勿喷，偏重于操作和实战，然而重要的概念也会精炼出提及下。系列次要分为以下几块 Prometheus各个概念介绍和搭建，如何抓取数据(一步步教你用Prometheus搭建实时监控零碎系列(一)——上帝之火，普罗米修斯的崛起)如何推送数据至Prometheus，推送和拉取别离用于什么样的场景(本次分享内容)Prometheus数据的构造以及查询语言PromQL的应用Java利用如何和Prometheus集成，如何启用服务发现，如果自定义业务指标Prometheus如何和Grafana可视化套件进行集成和设置告警教你如何手写一个集成了监控Dubbo各个指标的java套件理论案例分享，如何做各个业务端和零碎端的监控大盘抓取和推送拉取模式： Prometheus获取数据的形式只有拉取(PULL)，即Prometheus会以固定频率去申请每个target所提供的http url来获取数据。这就须要每个服务端点提供http的接口来获取实时的数据。 推送模式： Prometheus也变相的实现了推送数据的形式。 为什么说是变相呢。因为Prometheus获取数据的形式始终是拉取形式，官网并没有提供推送数据的性能。然而官网为了兼容推送这种形式，减少了一个PushGateway组件。 这个组件相当于一个代理服务，独立部署。它没有数据抓取性能，只能被动的期待数据推送。利用把数据推送到PushGateway后，Prometheus再从PushGateway抓取。 推送模式要留神的点即使客户端推了全量的数据到了PushGateway，Prometheus也不是每次拉取这个期间用户推上来的所有数据。 事实上Prometheus只拉取用户最初一次push上来的数据。 在这个系列一的时候，已经提到过Prometheus其实并不需要每一个准确的数据，长期保留的是中等或者低精度的数据。它每次只抓取一个数据，在固定的频率下。也能造成某种数据的趋势。 如果客户端始终没有推送新的指标到PushGateway，那么Prometheus将始终拉取最初推送上的数据，直到指标隐没，默认是5分钟。 Pushgateway本意是不会存储指标的，然而为了让pushgateway意外重启一类的故障之后可能从新读取到原来的指标，增加了一个将指标临时存储到本地的性能，参数--persistence.interval=5m就是默认放弃5分钟，5分钟后，本地存储的指标会删除。能够通过调节这个值来修改发现异常的工夫。 通过单个Pushgateway监控多个实例时，Pushgateway有可能成为单点故障和潜在瓶颈 如果要用Pushgateway的话，倡议多点部署。而后后面通过nginx进行反向代理多个节点，进行负载平衡。 推送模式实用的场景Prometheus 采纳定时拉取模式，可能因为子网络或者防火墙的起因，不能间接拉取各个Target的指标数据，此时能够采纳各个Target往PushGateway上推送数据，而后Prometheus去PushGateway上定时拉取在监控各个业务数据时，须要将各个不同的业务数据进行对立汇总，此时也能够采纳PushGateway来对立收集，而后Prometheus来对立拉取搭建Pushgateway分docker装置和一般装置两种，这里才用一般装置 先上prometheus的github release主页 https://github.com/prometheus...依照须要下载对应的包，我这里是须要部署在linux服务器上，所以下载这个 下载好，解压。运行： nohup ./pushgateway &启动起来后，默认端口为9091 在浏览器上依据ip+port能够拜访到如下页面，就算启动胜利了： 除此之外还要在Prometheus的配置文件里设置Target: - job_name: 'pushgateway' scrape_interval: 10s # 每过10秒拉取一次 honor_labels: true static_configs: - targets: ['localhost:9091'] labels: instance: pushgateway设置结束后重启Prometheus，而后会在Target选项卡里看到状态为UP的Pushgateway。 设置阶段就实现了。 URL推送测试我这里用postman软件进行推送测试，推送url的格局为：/metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>} 这个测试用例为意思是，推送一个指标aaa，标签为bbb=BBB,ccc=CCC，值为111.1到一个组上，这个组为job=pushgateway,instance=demo。 其实你能够简略的了解为这个指标aaa带有4个标签：job，instance，bbb，ccc。只是job和instance是属于组上的标签。 同一个组里的雷同的指标，Prometheus每次只取最新的，不同组内能够有雷同的指标。 对于数据结构和标签构造系列的下一篇文章会具体介绍。 总之，你提交这个POST申请后，能够在http://ip:9091上看到如下数据： 能够看到，aaa这个标签曾经胜利的被提交到Pushgateway里了。 接下来，咱们在Prometheus里查问这个指标： 能够看到，Prometheus也胜利的拉取到了这个指标。 Java端利用SDK进行推送尽管咱们在java服务端也能利用httpclient等工具进行提交，然而须要自行组装很多申请体。Prometheus官网提供了一个SDK。 首先在Maven中引入依赖包： <dependency> <groupId>io.prometheus</groupId> <artifactId>simpleclient_pushgateway</artifactId> <version>0.9.0</version></dependency>对Gauge,Timer,Counter,Summary四种常见的指标进行推送示例： ...

前言本系列着重介绍Prometheus以及如何用它和其周边的生态来搭建一套属于本人的实时监控告警平台。 本系列受众对象为首次接触Prometheus的用户，大神勿喷，偏重于操作和实战，然而重要的概念也会精炼出提及下。系列次要分为以下几块 Prometheus各个概念介绍和搭建，如何抓取数据(一步步教你用Prometheus搭建实时监控零碎系列(一)——上帝之火，普罗米修斯的崛起)如何推送数据至Prometheus，推送和拉取别离用于什么样的场景(本次分享内容)Prometheus数据的构造以及查询语言PromQL的应用Java利用如何和Prometheus集成，如何启用服务发现，如果自定义业务指标Prometheus如何和Grafana可视化套件进行集成和设置告警教你如何手写一个集成了监控Dubbo各个指标的java套件理论案例分享，如何做各个业务端和零碎端的监控大盘抓取和推送拉取模式： Prometheus获取数据的形式只有拉取(PULL)，即Prometheus会以固定频率去申请每个target所提供的http url来获取数据。这就须要每个服务端点提供http的接口来获取实时的数据。 推送模式： Prometheus也变相的实现了推送数据的形式。 为什么说是变相呢。因为Prometheus获取数据的形式始终是拉取形式，官网并没有提供推送数据的性能。然而官网为了兼容推送这种形式，减少了一个PushGateway组件。 这个组件相当于一个代理服务，独立部署。它没有数据抓取性能，只能被动的期待数据推送。利用把数据推送到PushGateway后，Prometheus再从PushGateway抓取。 推送模式要留神的点即使客户端推了全量的数据到了PushGateway，Prometheus也不是每次拉取这个期间用户推上来的所有数据。 事实上Prometheus只拉取用户最初一次push上来的数据。 在这个系列一的时候，已经提到过Prometheus其实并不需要每一个准确的数据，长期保留的是中等或者低精度的数据。它每次只抓取一个数据，在固定的频率下。也能造成某种数据的趋势。 如果客户端始终没有推送新的指标到PushGateway，那么Prometheus将始终拉取最初推送上的数据，直到指标隐没，默认是5分钟。 Pushgateway本意是不会存储指标的，然而为了让pushgateway意外重启一类的故障之后可能从新读取到原来的指标，增加了一个将指标临时存储到本地的性能，参数--persistence.interval=5m就是默认放弃5分钟，5分钟后，本地存储的指标会删除。能够通过调节这个值来修改发现异常的工夫。 通过单个Pushgateway监控多个实例时，Pushgateway有可能成为单点故障和潜在瓶颈 如果要用Pushgateway的话，倡议多点部署。而后后面通过nginx进行反向代理多个节点，进行负载平衡。 推送模式实用的场景Prometheus 采纳定时拉取模式，可能因为子网络或者防火墙的起因，不能间接拉取各个Target的指标数据，此时能够采纳各个Target往PushGateway上推送数据，而后Prometheus去PushGateway上定时拉取在监控各个业务数据时，须要将各个不同的业务数据进行对立汇总，此时也能够采纳PushGateway来对立收集，而后Prometheus来对立拉取搭建Pushgateway分docker装置和一般装置两种，这里才用一般装置 先上prometheus的github release主页 https://github.com/prometheus...依照须要下载对应的包，我这里是须要部署在linux服务器上，所以下载这个 下载好，解压。运行： nohup ./pushgateway &启动起来后，默认端口为9091 在浏览器上依据ip+port能够拜访到如下页面，就算启动胜利了： 除此之外还要在Prometheus的配置文件里设置Target: - job_name: 'pushgateway' scrape_interval: 10s # 每过10秒拉取一次 honor_labels: true static_configs: - targets: ['localhost:9091'] labels: instance: pushgateway设置结束后重启Prometheus，而后会在Target选项卡里看到状态为UP的Pushgateway。 设置阶段就实现了。 URL推送测试我这里用postman软件进行推送测试，推送url的格局为：/metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>} 这个测试用例为意思是，推送一个指标aaa，标签为bbb=BBB,ccc=CCC，值为111.1到一个组上，这个组为job=pushgateway,instance=demo。 其实你能够简略的了解为这个指标aaa带有4个标签：job，instance，bbb，ccc。只是job和instance是属于组上的标签。 同一个组里的雷同的指标，Prometheus每次只取最新的，不同组内能够有雷同的指标。 对于数据结构和标签构造系列的下一篇文章会具体介绍。 总之，你提交这个POST申请后，能够在http://ip:9091上看到如下数据： 能够看到，aaa这个标签曾经胜利的被提交到Pushgateway里了。 接下来，咱们在Prometheus里查问这个指标： 能够看到，Prometheus也胜利的拉取到了这个指标。 Java端利用SDK进行推送尽管咱们在java服务端也能利用httpclient等工具进行提交，然而须要自行组装很多申请体。Prometheus官网提供了一个SDK。 首先在Maven中引入依赖包： <dependency> <groupId>io.prometheus</groupId> <artifactId>simpleclient_pushgateway</artifactId> <version>0.9.0</version></dependency>对Gauge,Timer,Counter,Summary四种常见的指标进行推送示例： ...

这篇文章介绍了如何利用Apache Flink的内置指标零碎以及如何应用Prometheus来高效地监控流式应用程序。 为什么抉择Prometheus？随着深刻地理解Prometheus，你会发现一些十分好的性能： 服务发现使配置更加容易。Prometheus反对consul，etcd，kubernetes以及各家私有云厂商主动发现。对于监控指标动静发现，这点特地符合Cloud时代，利用动静扩缩的特点。咱们无奈设想，在Cloud时代，须要运维一直更改配置。开源社区建设了数百个exporter。基本上涵盖了所有基础设施和支流中间件。工具库可从您的应用程序获取自定义指标。基本上支流开发语言都有对应的工具库。它是CNCF旗下的OSS，是继Kubernetes之后的第二个毕业我的项目。Kubernetes曾经与Promethues深度联合，并在其所有服务中公开了Prometheus指标。Pushgateway，Alermanager等组件，基本上涵盖了一个残缺的监控生命周期。Flink官网曾经提供了对接Prometheus的jar包，很不便就能够集成。因为本系列文章重点在Flink on Kubernetes， 因而咱们所有的操作都是基于这点开展。 部署Prometheus对k8s不相熟的同学，能够查阅k8s相干文档。因为部署不是本博客的重点，所以咱们间接贴出yaml文件： --- apiVersion: v1 kind: ServiceAccount metadata: name: monitor namespace: kube-system labels: kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: monitor labels: kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: monitor labels: kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: monitor subjects: - kind: ServiceAccount name: monitor namespace: kube-system--- apiVersion: v1 kind: ConfigMap metadata: labels: app: monitor name: monitor namespace: kube-system data: prometheus.yml: |- global: scrape_interval: 10s evaluation_interval: 10s scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs: - action: keep regex: true source_labels: - __meta_kubernetes_pod_annotation_prometheus_io_scrape - action: replace regex: (.+) source_labels: - __meta_kubernetes_pod_annotation_prometheus_io_path target_label: __metrics_path__ - action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 source_labels: - __address__ - __meta_kubernetes_pod_annotation_prometheus_io_port target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - action: replace source_labels: - __meta_kubernetes_namespace target_label: kubernetes_namespace - action: replace source_labels: - __meta_kubernetes_pod_name target_label: kubernetes_pod_name --- apiVersion: apps/v1 kind: StatefulSet metadata: labels: app: monitor name: monitor namespace: kube-system spec: serviceName: monitor selector: matchLabels: app: monitor replicas: 1 template: metadata: labels: app: monitor spec: containers: - args: - --config.file=/etc/prometheus/prometheus.yml - --storage.tsdb.path=/data/prometheus - --storage.tsdb.retention.time=10d image: prom/prometheus:v2.19.0 imagePullPolicy: IfNotPresent name: prometheus ports: - containerPort: 9090 protocol: TCP readinessProbe: httpGet: path: /-/ready port: 9090 initialDelaySeconds: 30 timeoutSeconds: 30 livenessProbe: httpGet: path: /-/healthy port: 9090 initialDelaySeconds: 30 timeoutSeconds: 30 resources: limits: cpu: 1000m memory: 2018Mi requests: cpu: 1000m memory: 2018Mi volumeMounts: - mountPath: /etc/prometheus name: config-volume - mountPath: /data name: monitor-persistent-storage restartPolicy: Always priorityClassName: system-cluster-critical serviceAccountName: monitor initContainers: - name: "init-chown-data" image: "busybox:latest" imagePullPolicy: "IfNotPresent" command: ["chown", "-R", "65534:65534", "/data"] volumeMounts: - name: monitor-persistent-storage mountPath: /data subPath: "" volumes: - configMap: defaultMode: 420 name: monitor name: config-volume volumeClaimTemplates: - metadata: name: monitor-persistent-storage namespace: kube-system spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: gp2--- apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb labels: app: monitor name: monitor namespace: kube-system spec: ports: - name: http port: 9090 protocol: TCP targetPort: 9090 selector: app: monitor type: LoadBalancer这里咱们简略说下，因为咱们想利用Prometheus的Kubernetes的服务发现的形式，所以须要RBAC受权，受权prometheus 实例对集群中的pod有一些读取权限。 ...

这篇文章介绍了如何利用Apache Flink的内置指标零碎以及如何应用Prometheus来高效地监控流式应用程序。 为什么抉择Prometheus？随着深刻地理解Prometheus，你会发现一些十分好的性能： 服务发现使配置更加容易。Prometheus反对consul，etcd，kubernetes以及各家私有云厂商主动发现。对于监控指标动静发现，这点特地符合Cloud时代，利用动静扩缩的特点。咱们无奈设想，在Cloud时代，须要运维一直更改配置。开源社区建设了数百个exporter。基本上涵盖了所有基础设施和支流中间件。工具库可从您的应用程序获取自定义指标。基本上支流开发语言都有对应的工具库。它是CNCF旗下的OSS，是继Kubernetes之后的第二个毕业我的项目。Kubernetes曾经与Promethues深度联合，并在其所有服务中公开了Prometheus指标。Pushgateway，Alermanager等组件，基本上涵盖了一个残缺的监控生命周期。Flink官网曾经提供了对接Prometheus的jar包，很不便就能够集成。因为本系列文章重点在Flink on Kubernetes， 因而咱们所有的操作都是基于这点开展。 部署Prometheus对k8s不相熟的同学，能够查阅k8s相干文档。因为部署不是本博客的重点，所以咱们间接贴出yaml文件： --- apiVersion: v1 kind: ServiceAccount metadata: name: monitor namespace: kube-system labels: kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: monitor labels: kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: monitor labels: kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: monitor subjects: - kind: ServiceAccount name: monitor namespace: kube-system--- apiVersion: v1 kind: ConfigMap metadata: labels: app: monitor name: monitor namespace: kube-system data: prometheus.yml: |- global: scrape_interval: 10s evaluation_interval: 10s scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs: - action: keep regex: true source_labels: - __meta_kubernetes_pod_annotation_prometheus_io_scrape - action: replace regex: (.+) source_labels: - __meta_kubernetes_pod_annotation_prometheus_io_path target_label: __metrics_path__ - action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 source_labels: - __address__ - __meta_kubernetes_pod_annotation_prometheus_io_port target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - action: replace source_labels: - __meta_kubernetes_namespace target_label: kubernetes_namespace - action: replace source_labels: - __meta_kubernetes_pod_name target_label: kubernetes_pod_name --- apiVersion: apps/v1 kind: StatefulSet metadata: labels: app: monitor name: monitor namespace: kube-system spec: serviceName: monitor selector: matchLabels: app: monitor replicas: 1 template: metadata: labels: app: monitor spec: containers: - args: - --config.file=/etc/prometheus/prometheus.yml - --storage.tsdb.path=/data/prometheus - --storage.tsdb.retention.time=10d image: prom/prometheus:v2.19.0 imagePullPolicy: IfNotPresent name: prometheus ports: - containerPort: 9090 protocol: TCP readinessProbe: httpGet: path: /-/ready port: 9090 initialDelaySeconds: 30 timeoutSeconds: 30 livenessProbe: httpGet: path: /-/healthy port: 9090 initialDelaySeconds: 30 timeoutSeconds: 30 resources: limits: cpu: 1000m memory: 2018Mi requests: cpu: 1000m memory: 2018Mi volumeMounts: - mountPath: /etc/prometheus name: config-volume - mountPath: /data name: monitor-persistent-storage restartPolicy: Always priorityClassName: system-cluster-critical serviceAccountName: monitor initContainers: - name: "init-chown-data" image: "busybox:latest" imagePullPolicy: "IfNotPresent" command: ["chown", "-R", "65534:65534", "/data"] volumeMounts: - name: monitor-persistent-storage mountPath: /data subPath: "" volumes: - configMap: defaultMode: 420 name: monitor name: config-volume volumeClaimTemplates: - metadata: name: monitor-persistent-storage namespace: kube-system spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: gp2--- apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb labels: app: monitor name: monitor namespace: kube-system spec: ports: - name: http port: 9090 protocol: TCP targetPort: 9090 selector: app: monitor type: LoadBalancer这里咱们简略说下，因为咱们想利用Prometheus的Kubernetes的服务发现的形式，所以须要RBAC受权，受权prometheus 实例对集群中的pod有一些读取权限。 ...

上帝之火本系列讲述的是开源实时监控告警解决方案Prometheus，这个单词很牛逼。每次我都能联想到带来上帝之火的希腊之神，普罗米修斯。而这个开源的logo也是火，集体挺喜爱这个logo的设计。 本系列着重介绍Prometheus以及如何用它和其周边的生态来搭建一套属于本人的实时监控告警平台。 本系列受众对象为首次接触Prometheus的用户，大神勿喷，偏重于操作和实战，然而重要的概念也会精炼出提及下。系列次要分为以下几块 Prometheus各个概念介绍和搭建，如何抓取数据（本次分享内容）如何推送数据至Prometheus，推送和拉取别离用于什么样的场景Prometheus数据的构造以及查询语言PromQL的应用Java利用如何和Prometheus集成，如何启用服务发现，如果自定义业务指标Prometheus如何和Grafana可视化套件进行集成和设置告警教你如何手写一个集成了监控Dubbo各个指标的java套件理论案例分享，如何做各个业务端和零碎端的监控大盘Prometheus以及时序数据库的基本概念Prometheus当初在Github有3w多的star，基本上过万星的开源工具，能够认为是社区里相对的支流，社区也相当沉闷，能够有大量的教训能够借鉴。在企业级零碎中，能够释怀的应用。 Prometheus 是由 SoundCloud 开发的开源监控报警零碎和时序列数据库。从字面上了解，Prometheus 由两个局部组成，一个是监控报警零碎，另一个是自带的时序数据库（TSDB）。 对于时序数据库(TSDB)这里要说下，咱们能够简略的了解为一个优化后用来解决工夫序列数据的数据库，并且数据中的数组是由工夫进行索引的。相比于传统的结构化数据库次要有几个益处： 工夫序列数据专一于海量数据的疾速摄取。时序数据库视数据的每一次变动为一条新的数据，从而能够去掂量变动：剖析过来的变动，监测当初的变动，以及预测将来将如何变动，传统结构化数据在数据量小的时候能做到，在数据量大的时候就须要破费大量的老本。高精度数据保留工夫较短，中等或更低精度的摘要数据保留工夫较长。对于实时监控来说，不肯定须要每一个精准的数据，而是固定工夫段时间数据的摘要。这对于结构化数据库来说就意味着要进行筛选，在保障大量的写入同时还要进行帅选，这是一个超出结构化数据库设计来解决的工作量。数据库自身必须间断计算来自高精度数据的摘要以进行长期存储。这些计算既包含一些简略的聚合，同时也有一些简单计算。传统数据库无奈接受那么大量的计算。因为必须去实时统计这些聚合和简单运算。开始搭建Prometheushttps://prometheus.io/在Prometheue官网Download标签页进行下载，这里以linux版本为例： 下载好之后，解压，运行 nohup /data/prometheus/prometheus --web.listen-address=0.0.0.0:9090 --config.file=/data/prometheus/prometheus.yml --web.enable-lifecycle --storage.tsdb.path=/data/prometheus/data --storage.tsdb.retention.time=15d &这样，就简略的搭建起来Prometheus服务端了。这时候，咱们能够在web上拜访 http://127.0.0.1:9090就能够拜访到治理页面 界面上几个标签阐明下： Alert：用来配置告警规定。之后咱们会用Grafana本身的告警界面配置来代替这个。 Graph：用来运行PromQL语句的一个控制台，并且能够把运行进去的语句用用图形化进行展现，此块咱们前面章节会介绍到。 Status：蕴含零碎信息，零碎状态，配置信息，指标节点的状态，服务发现状态等元信息的查看。 Prometheus整体架构以及生态 这张图是官网的整体架构图。米黄色局部是Prometheus本人的组件，绿色的为第三方的中间件和利用。 简略介绍下整个Prometheus的生态架构： Prometheus获取数据的形式只有一种，就是scrape，也称作pull，意为拉取。Prometheus每隔一段时间会从指标(target)这里以Http协定拉取指标(metrics)，这些指标能够是利用，也能够是代理，缓存中间件，数据库等等一些中间件。拉取出来的数据Prometheus会存到本人的TSDB数据库。本人的WebUI控制台以及Grafana能够对其数据进行工夫范畴内的一直查问，绘制成实时图表工展示。Prometheus 反对例如zookeeper,consul之类的服务发现中间件，用以对指标(target)的主动发现。而不必一个个去配置target了。alertManager组件反对自定义告警规定，告警渠道也反对很多种拉取数据Prometheus次要是通过拉取的形式获取数据，说简略点，就是每隔固定工夫去拜访配置的target，target就是一个获取数据的url。 当初咱们就来模仿一个数据源，并让prometheus去拉取。 新建一个springboot的web我的项目，pom依赖加上 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId></dependency><dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId></dependency>application.properties里加上 server.port=8080anagement.endpoints.web.exposure.include=*启动结束后，咱们就能够在页面上拜访如下地址： http://127.0.0.1:8080/actuator/prometheus失去如下数据： 对于actuator如何监控利用指标以及自定义指标我会在之后的系列里独自剖析，这里只有了解成咱们启动了一个服务，提供了一个url能列出一些kv模式的指标就行了。 例如jvm_memory_max_bytes{area="heap",id="PS Old Gen",} 2.863661056E9这个指标，后面是key，前面为value。 其中key上又分key name和key labels，key name就是`jvm_memory_max_bytes，key labels`有2个。 这个指标提供了jvm的最大内存，其中area为heap，表明这是堆内存区域，id为PS Old Gen，表明这是老年代。综合起来看，这个指标就是jvm中老年代的最大值。数值类型是byte，换算下来大略是286M左右。 咱们有指标的数据源后，再在prometheus 的根目录下编辑prometheus.yml文件，增加如下配置： - job_name: 'test' scrape_interval: 5s metrics_path: '/actuator/prometheus' static_configs: - targets: ['localhost:8080'] labels: instance: demo这个配置示意：prometheue每隔5秒钟从http://localhost:8080/actuator/prometheus这个url拉取指标，并且为每个指标增加instance这个标签。 ...

prometheus 实质上是一个时序数据库, 再配以alermanager pushgateway等子组件, 便可搭建成一个监控平台, 目前曾经是比拟支流的做法, 本文次要介绍一下此组件的简略应用和能够利用到的场景.官网文档doc docker配置以docker-compose的模式进行配置prometheus根本配置在文件夹新建一个docker-compose.yml文件, 将以下内容填入. version: "3.7" services: pro_server: image: prom/prometheus # 官网镜像ports: - "9090:9090" volumes: - ./prometheus:/prometheus # 用于存储Prometheus的状态, 下次启动能够连续- ./docker/prometheus.yml:/etc/prometheus/prometheus.yml # 内部传入Prometheus配置解下来新建./这是prometheus文件夹, 新建./docker/prometheus.yml文件, 写入以下信息 # my global config global: scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. # scrape_timeout is set to the global default (10s). # Alertmanager configuration alerting: #alertmanagers: #- static_configs: #- targets: #- pro_alert_manager:9093 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: # - "first_rules.yml" # - "second_rules.yml" # A scrape configuration containing exactly one endpoint to scrape: # Here it's Prometheus itself. scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: 'prometheus' # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: ['localhost:9090'] prometheus的主体服务, docker-compose up的话, 就能够在浏览器进行Prometheus的初体验了. 这个配置文件是Prometheus的默认配置, 能够看到它本人申明了一个job: prometheus, 外面监听了本人的9090端口. 你能够自行察看 /metrics接口内的数据, 领会一下数据结构. ...

本文代码基于prometheus 2.19.2剖析基本概念什么是tsdbTime Series DBMS are designed to efficiently collect, store and query various time series with high transaction volumesprometheus 基本概念sample 数据点type sample struct { t int64 v float64}sample代表一个数据点size:16byte: 蕴含 1个8byte int64工夫戳和1个8byte float64 value Label 标签type Label struct { Name, Value string}一对label 比方 job="ec2"Labels 标签组type Labels []Label 就是metric 一个指标的所有tag valuesvector 向量type Vector []Samplevector 向量,是samples的别名,然而所有sample具备雷同timestamp ,罕用作instance_query的后果Scalar 标量type Scalar struct { T int64 V float64}Scalar 标量 间接查个数字Series 数据流type Series struct { Metric labels.Labels `json:"metric"` Points []Point `json:"values"`}Series 是一个metric的数据流Matrix 矩阵type Matrix []SeriesMatrix是series的切片，个别的range_query返回的后果数据点压缩 ...

本文代码基于prometheus 2.19.2剖析基本概念什么是tsdbTime Series DBMS are designed to efficiently collect, store and query various time series with high transaction volumesprometheus 基本概念sample 数据点type sample struct { t int64 v float64}sample代表一个数据点size:16byte: 蕴含 1个8byte int64工夫戳和1个8byte float64 value Label 标签type Label struct { Name, Value string}一对label 比方 job="ec2"Labels 标签组type Labels []Label 就是metric 一个指标的所有tag valuesvector 向量type Vector []Samplevector 向量,是samples的别名,然而所有sample具备雷同timestamp ,罕用作instance_query的后果Scalar 标量type Scalar struct { T int64 V float64}Scalar 标量 间接查个数字Series 数据流type Series struct { Metric labels.Labels `json:"metric"` Points []Point `json:"values"`}Series 是一个metric的数据流Matrix 矩阵type Matrix []SeriesMatrix是series的切片，个别的range_query返回的后果数据点压缩 ...

{{ define "__subject" }}[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .GroupLabels.SortedPairs.Values | join " " }} {{ if gt (len .CommonLabels) (len .GroupLabels) }}({{ with .CommonLabels.Remove .GroupLabels.Names }}{{ .Values | join " " }}{{ end }}){{ end }}{{ end }}{{ define "__alertmanagerURL" }}{{ .ExternalURL }}/#/alerts?receiver={{ .Receiver }}{{ end }}{{ define "__text_alert_list" }}{{ range . }}**Labels**{{ range .Labels.SortedPairs }}> - {{ .Name }}: {{ .Value | markdown | html }}{{ end }}**Annotations**{{ range .Annotations.SortedPairs }}> - {{ .Name }}: {{ .Value | markdown | html }}{{ end }}**Source:** [{{ .GeneratorURL }}]({{ .GeneratorURL }}){{ end }}{{ end }}{{ define "default.__text_alert_list" }}{{ range . }}---**告警级别:** {{ .Labels.severity | upper }}**运营团队:** {{ .Labels.team | upper }}**触发时间:** {{ dateInZone "2006.01.02 15:04:05" (.StartsAt) "Asia/Shanghai" }}**事件信息:** {{ range .Annotations.SortedPairs }}> - {{ .Name }}: {{ .Value | markdown | html }}{{ end }}**事件标签:**{{ range .Labels.SortedPairs }}{{ if and (ne (.Name) "severity") (ne (.Name) "summary") (ne (.Name) "team") }}> - {{ .Name }}: {{ .Value | markdown | html }}{{ end }}{{ end }}{{ end }}{{ end }}{{ define "default.__text_alertresovle_list" }}{{ range . }}---**告警级别:** {{ .Labels.severity | upper }}**运营团队:** {{ .Labels.team | upper }}**触发时间:** {{ dateInZone "2006.01.02 15:04:05" (.StartsAt) "Asia/Shanghai" }}**结束时间:** {{ dateInZone "2006.01.02 15:04:05" (.EndsAt) "Asia/Shanghai" }}**事件信息:**{{ range .Annotations.SortedPairs }}> - {{ .Name }}: {{ .Value | markdown | html }}{{ end }}**事件标签:**{{ range .Labels.SortedPairs }}{{ if and (ne (.Name) "severity") (ne (.Name) "summary") (ne (.Name) "team") }}> - {{ .Name }}: {{ .Value | markdown | html }}{{ end }}{{ end }}{{ end }}{{ end }}{{/* Default */}}{{ define "default.title" }}{{ template "__subject" . }}{{ end }}{{ define "default.content" }}#### \[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}\] **[{{ index .GroupLabels "alertname" }}]({{ template "__alertmanagerURL" . }})**{{ if gt (len .Alerts.Firing) 0 -}}**====侦测到故障====**{{ template "default.__text_alert_list" .Alerts.Firing }}{{- end }}{{ if gt (len .Alerts.Resolved) 0 -}}{{ template "default.__text_alertresovle_list" .Alerts.Resolved }}{{- end }}{{- end }}{{/* Legacy */}}{{ define "legacy.title" }}{{ template "__subject" . }}{{ end }}{{ define "legacy.content" }}#### \[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}\] **[{{ index .GroupLabels "alertname" }}]({{ template "__alertmanagerURL" . }})**{{ template "__text_alert_list" .Alerts.Firing }}{{- end }}{{/* Following names for compatibility */}}{{ define "ding.link.title" }}{{ template "default.title" . }}{{ end }}{{ define "ding.link.content" }}{{ template "default.content" . }}{{ end }}

作者：徐亚松   原文：http://www.xuyasong.com/?p=1921监控系统的历史悠久，是一个很成熟的方向，而 Prometheus 作为新生代的开源监控系统，慢慢成为了云原生体系的事实标准，也证明了其设计很受欢迎。 本文主要分享在 Prometheus 实践中遇到的一些问题和思考，如果你对 K8S 监控体系或 Prometheus 的设计还不太了解，可以先看下容器监控系列。 几点原则： 监控是基础设施，目的是为了解决问题，不要只朝着大而全去做，尤其是不必要的指标采集，浪费人力和存储资源（To B商业产品例外）。需要处理的告警才发出来，发出来的告警必须得到处理。简单的架构就是最好的架构，业务系统都挂了，监控也不能挂。Google Sre 里面也说避免使用 Magic 系统，例如机器学习报警阈值、自动修复之类。这一点见仁见智吧，感觉很多公司都在搞智能 AI 运维。一、版本的选择Prometheus 当前最新版本为 2.16，Prometheus 还在不断迭代，因此尽量用最新版，1.X版本就不用考虑了。 2.16 版本上有一套实验 UI，可以查看 TSDB 的状态，包括Top 10的 Label、Metric. 二、Prometheus 的局限Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件(Event)、调用链(Tracing)。Prometheus 默认是 Pull 模型，合理规划你的网络，尽量不要转发。对于集群化和水平扩展，官方和社区都没有银弹，需要合理选择 Federate、Cortex、Thanos等方案。监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功。这个后面说 Thanos 去重的时候会提到。Prometheus 不一定保证数据准确，这里的不准确一是指 rate、histogram_quantile 等函数会做统计和推断，产生一些反直觉的结果，这个后面会详细展开。二来查询范围过长要做降采样，势必会造成数据精度丢失，不过这是时序数据的特点，也是不同于日志系统的地方。三、K8S 集群中常用的 exporterPrometheus 属于 CNCF 项目，拥有完整的开源生态，与 Zabbix 这种传统 agent 监控不同，它提供了丰富的 exporter 来满足你的各种需求。你可以在这里看到官方、非官方的 exporter。如果还是没满足你的需求，你还可以自己编写 exporter，简单方便、自由开放，这是优点。 但是过于开放就会带来选型、试错成本。之前只需要在 zabbix agent里面几行配置就能完成的事，现在你会需要很多 exporter 搭配才能完成。还要对所有 exporter 维护、监控。尤其是升级 exporter 版本时，很痛苦。非官方exporter 还会有不少 bug。这是使用上的不足，当然也是 Prometheus 的设计原则。 ...

本期作者：罗韦爱可生上海研发中心成员，研发工程师，主要负责 DMP 平台监控告警功能的相关工作。 上篇文章（第02期：数据采集一）介绍了 Prometheus 数据采集的格式和分类，本文会对采集过程进行详细的介绍。 Prometheus 数据采集过程介绍Prometheus 从采集数据到将存储的过程中，会对采集目标及数据样本作一系列处理。了解这个过程有利于帮助我们更充分、合理的使用可配参数。 一、文章中使用的概念简介target：采集目标，Prometheus Server 会从这些目标设备上采集监控数据sample： Prometheus Server 从 targets 采集回来的数据样本meta label： 执行 relabel 前，target 的原始标签。可在 Prometheus 的 /targets 页面或发送 GET /api/v1/targets 请求查看。 二、数据采集流程 2.1 relabel (targets 标签修改/过滤)relabel 是 Prometheus 提供的一个针对 target 的功能，relabel 发生 Prometheus Server 从 target 采集数据之前，可以对 target 的标签进行修改或者使用标签进行 target 筛选。注意以下几点： Prometheus 在 relabel 步骤默认会为 target 新增一个名为 instance 的标签，并设置成 "__address__" 标签的值；在 relabel 结束后，以 "__" 开头的标签不会被存储到磁盘；meta label 会一直保留在内存中，直到 target 被移除。在 Prometheus 的 targets 页面，可以看到 target 在 relabel 之前的标签，如下图所示，在 relabel 之前，target 的标签有："__address__"，"__metrics_path__"，"__schema__"，"job"。经过 relabel 之后我们最终看到的 targets 的标签为：instance、job。 ...

安装jmx-exporter $ wget https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.13.0/jmx_prometheus_javaagent-0.13.0.jarmv jmx_prometheus_javaagent-0.13.0.jar /data/hdfs$ for i in {2..5};do scp /data/hdfs/jmx_prometheus_javaagent-0.13.0.jar hadoop-test-$i:/data/hdfs/;donehdfs $ vim /data/hdfs/nn.yamlstartDelaySeconds: 0hostPort: 192.168.233.65:1234 #master为本机IP（一般可设置为localhost）；1234为想设置的jmx端口#jmxUrl: service:jmx:rmi:///jndi/rmi://127.0.0.1:1234/jmxrmissl: falselowercaseOutputName: falselowercaseOutputLabelNames: false$ vim /data/hdfs/dn.yaml---startDelaySeconds: 0hostPort: 192.168.233.65:1244 #master为本机IP（一般可设置为localhost）；1244为想设置的jmx端口（可设置为未被占用的端口）#jmxUrl: service:jmx:rmi:///jndi/rmi://127.0.0.1:1234/jmxrmissl: falselowercaseOutputName: falselowercaseOutputLabelNames: false$ vim etc/hadoop/hadoop-env.shexport HADOOP_NAMENODE_JMX_OPTS="-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.port=1234 -javaagent:/data/hdfs/jmx_prometheus_javaagent-0.13.0.jar=9211:/data/hdfs/nn.yaml"export HADOOP_DATANODE_JMX_OPTS="-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.port=1244 -javaagent:/data/hdfs/jmx_prometheus_javaagent-0.13.0.jar=9212:/data/hdfs/dn.yaml"$ vim bin/hdfsif [ "$COMMAND" = "namenode" ] ; then CLASS='org.apache.hadoop.hdfs.server.namenode.NameNode' HADOOP_OPTS="$HADOOP_OPTS $HADOOP_NAMENODE_OPTS $HADOOP_NAMENODE_JMX_OPTS" #添加namenode JMX环境变量elif [ "$COMMAND" = "zkfc" ] ; then CLASS='org.apache.hadoop.hdfs.tools.DFSZKFailoverController' HADOOP_OPTS="$HADOOP_OPTS $HADOOP_ZKFC_OPTS"elif [ "$COMMAND" = "secondarynamenode" ] ; then CLASS='org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode' HADOOP_OPTS="$HADOOP_OPTS $HADOOP_SECONDARYNAMENODE_OPTS"elif [ "$COMMAND" = "datanode" ] ; then CLASS='org.apache.hadoop.hdfs.server.datanode.DataNode' HADOOP_OPTS="$HADOOP_OPTS $HADOOP_DATANODE_JMX_OPTS" #添加datanode jmx变量 if [ "$starting_secure_dn" = "true" ]; then HADOOP_OPTS="$HADOOP_OPTS -jvm server $HADOOP_DATANODE_OPTS" else HADOOP_OPTS="$HADOOP_OPTS -server $HADOOP_DATANODE_OPTS"$ stop-dfs.sh$ start-dfs.shyarn ...

## 我写的分布式c/s ping & http 探测代码## 地址 [https://github.com/ning1875/xprober](https://github.com/ning1875/xprober)  ## xprober特点 - 基于公有混合云ec2的ping监控，可以得到不同region之间的网络延迟 - 可以从不同region对http接口发起探测，可以trace 一个http请求的各个stage的耗时 - icmp target可由 存活agent上报 / 可以在配置文件中指定 - http target 在配置文件中指定 ## 预览图 ### http 探测结果 ### 互ping 结果 # 项目说明 xprober 是分布式c / s架构接口检测框架： Ping监控：基于不同区域之间的公共云混合云ec2检测Ping监视：根据代理启动来建立目标池，可以获取两个区域的Ping结果作为彼此的源和目标目标源：同时，它还支持服务器端配置文件以指定目标Http监视：它可以获取从不同区域到目标接口在不同http阶段花费的时间服务器端逻辑*   RPC接收代理agent IP报告 *   定时器将探测目标池刷新到本地缓存中 *   server 根据agent rpc信息返回给其探测目标池 *   rpc接收数据 *   更新到本地缓存 *   定时器数据处理 *   公开prome http指标建造$ git clone https://github.com/ning1875/xprober.git# build agent$ cd xprober/pkg/cmd/agent && go build -o xprober-agent main.go # build server$ cd ../server/ && go build -o xprober-server main.go` 启动服务# for server xprober-server --config.file=xprober.yml# for agent xprober-agent --grpc.server-address=$server_rpc_ip:6001与promtheus集成将以下文本添加到promtheus.yaml的scrape_configs部分 ...

前段时间使用Prometheus，其中的PromQL还是很厉害的查询语法，现在总结下其中的数据查询规则。为了能够帮助用户理解和区分这些不同监控指标之间的差异，Prometheus定义了4种不同的指标类型(metric type)：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）。返回的样本数据中，其注释中也包含了该样本的类型。例如： # HELP node_cpu Seconds the cpus spent in each mode.# TYPE node_cpu counternode_cpu{cpu="cpu0",mode="idle"} 362812.7890625Counter：只增不减的计数器Counter类型的指标其工作方式和计数器一样，只增不减（除非系统发生重置）。常见的监控指标，如http_requests_total，node_cpu都是Counter类型的监控指标。 一般在定义Counter类型指标的名称时推荐使用_total作为后缀。 样记录值：每个时刻对应的总数，因此随着时间增加该值递增或不变。 Counter 的应用最近10分钟cpu时间增加量： increase(node_cpu_seconds_total[10m])最近10分钟cpu的增长率（增量/时间间隔）： rate(node_cpu_seconds_total[10m])最近10分钟cpu的增长率（该时间段的最后两个值之差/时间间隔）：i irate(node_cpu_seconds_total[10m])cpu时间排名前10的： topk(10,node_cpu_seconds_total)Gauge：可增可减的仪表盘与Counter不同，Gauge类型的指标侧重于反应系统的当前状态。因此这类指标的样本数据可增可减。常见指标如：node_memory_MemFree（主机当前空闲的内容大小）、node_memory_MemAvailable（可用内存大小）都是Gauge类型的监控指标。 样记录值：每个抓取时刻对应的设置值，因此没有设置值即0。 Gauge 的应用Gauge 用法比较单一，一般直接展示即可，也可做预测。 最近10分钟的变化情况： delta(node_load1[10m])预测系统磁盘空间在4个小时之后的剩余情况： predict_linear(node_filesystem_free{job="node"}[1h], 4 * 3600)Histogram 和 Summary 分析数据分布情况Histogram和Summary主用用于统计和分析样本的分布情况。 这两个指标类型拥有Counter的全部功能，都有_sum记录值之和， _count记录值的个数，其独特的功能是拥有获取数据分布情况的能力。 Histogram由 Prometheus server 计算分布，这也是使用 Histogram 的情况比 Summary 多的原因。分桶标签 ‘le’使用 quantile 函数查看分为数值metrics 样例 # HELP ts_http_seconds_bucket web http response time in seconds# TYPE ts_http_seconds_bucket histogramts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="1"} 0ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="2"} 0ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="4"} 0ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="8"} 0ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="16"} 0ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="32"} 0ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="64"} 0ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="128"} 0ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="512"} 0ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="1024"} 877ts_http_seconds_bucket_bucket{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200",le="+Inf"} 1062ts_http_seconds_bucket_sum{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200"} 1.19617e+06ts_http_seconds_bucket_count{error="false",method="put",path="/app/tri",serverName="Java-application",stage="beta",statusCode="200"} 1062Summary由 Prometheus client 计算分布分布标签 'quantile'metrics 样例 ...

这篇文章主要是为了庆祝 Node Exporter 终于迎来了 v1.0.0 版本。Prometheus 是最早由 SoundCloud 开源的监控告警解决方案。并已经成长为继 Kubernetes 之后，第二个从 CNCF 毕业的项目。伴随着云原生理念的普及和 Kubernetes 等技术的发展， Prometheus 在监控领域也有了长足的发展。 其主要组件包括 Prometheus，Alertmanager，Node Exporter，Blackbox Exporter 和 Pushgateway 等。 本文主要是为了庆祝 Node Exporter 终于迎来了 v1.0.0 版本， 所以重点主要放在一直被人诟病的安全性相关上，具体而言就是利用 TLS 和 Basic Auth 提升其安全性。 背景Node Exporter 是 Prometheus 官方发布的，用于采集节点的系统信息，比如 CPU，内存，磁盘和网络等信息。通常情况下，如果我们在使用 Prometheus 作为监控方案，那 Node Exporter 基本都会用到的。 在 Promethues 的监控体系中，社区中一直存在的一个观点是，Metrics 不包含过于私密的信息。所以你可以看到，大多数的 /metrics 接口都是直接暴露出来的，没什么特别的安全措施。 但随着 Prometheus 在生产中的大量应用，安全问题变得更加重要。 大家最先想到的解决办法就是，为 Prometheus 与监控目标之间的连接启用 TLS。 但由于各类 exporter 并不原生支持 TLS 连接，所以通常情况下我们会选择配合反向代理来完成。 这种方式能满足需求，但未免复杂了些。近期 Prometheus 对其安全模型做了修改 ， 从 Node Exporter 开始到后续其他的组件，都将支持 TLS 和 basic auth， 同时也列出了最新的安全基准（默认情况下都支持 TLS v1.2 及以上） ...