Prometheus adalah sistem pemantauan dan penggera sumber terbuka berdasarkan pangkalan data siri masa. untuk melakukan perkongsian Video YouTube, kerana mereka pergi lebih jauh ke jalan seni bina perkhidmatan mikro, mempunyai beratus-ratus perkhidmatan, dan terdapat banyak batasan dalam menggunakan sistem pemantauan tradisional StatsD dan Graphite.
Jadi mereka mula membangunkan sistem pemantauan baharu pada tahun 2012. Pengarang asal Prometheus ialah Matt T. Proud, yang turut menyertai SoundCloud pada tahun 2012. Malah, sebelum menyertai SoundCloud, Matt telah bekerja di Google, dia mendapat inspirasi daripada pengurus kluster Google dan sistem pemantauannya Borgmon sistem pemantauan sumber Prometheus Seperti kebanyakan projek Google, bahasa pengaturcaraan yang digunakan ialah Go.
Jelas sekali, sebagai penyelesaian untuk sistem pemantauan seni bina perkhidmatan mikro, Prometheus juga tidak boleh dipisahkan daripada bekas. Seawal 9 Ogos 2006, Eric Schmidt mula mencadangkan konsep pengkomputeran awan (Cloud Computing) pada Persidangan Enjin Carian Dalam tempoh sepuluh tahun berikutnya, perkembangan pengkomputeran awan telah berkembang pesat.
Pada tahun 2013, Matt Stine dari Pivotal mencadangkan konsep Cloud Native terdiri daripada seni bina perkhidmatan mikro, DevOps dan infrastruktur tangkas yang diwakili oleh kontena untuk membantu perusahaan dengan cepat, berterusan, boleh dipercayai dan skala.
Untuk menyatukan antara muka pengkomputeran awan dan piawaian yang berkaitan, pada Julai 2015, Cloud Native Computing Foundation (CNCF), yang bergabung dengan Linux Foundation, telah wujud. Projek pertama yang menyertai CNCF ialah Kubernetes Google, dan Prometheus adalah yang kedua menyertainya (pada 2016).
Pada masa ini, Prometheus telah digunakan secara meluas dalam sistem pemantauan kluster Kubernetes Pelajar yang berminat dengan sejarah Prometheus boleh melihat ucapan jurutera SoundCloud Tobias Schmidt pada persidangan PromCon 2016: Sejarah Prometheus di SoundCloud.
Walau bagaimanapun, Prometheus juga menyediakan cara untuk menyokong mod Tekan Anda boleh menolak data anda ke Gerbang Tekan, dan Prometheus memperoleh data daripada Gerbang Tekan melalui Tarik. Pengeksport semasa sudah boleh mengumpul kebanyakan data pihak ketiga, seperti Docker, HAProxy, StatsD, JMX, dll. Tapak web rasmi mempunyai senarai Pengeksport.
Sebagai tambahan kepada empat ciri utama ini, semasa Prometheus terus berkembang, ia mula menyokong ciri yang lebih dan lebih maju, seperti: penemuan perkhidmatan, paparan carta yang lebih kaya, penggunaan storan luaran, peraturan penggera yang berkuasa dan pelbagai kaedah pemberitahuan. Gambar berikut ialah gambar rajah seni bina keseluruhan Prometheus:
Seperti yang dapat dilihat daripada gambar di atas, ekosistem Prometheus mengandungi beberapa komponen utama: pelayan Prometheus, Pushgateway, Alertmanager, UI Web, dll., tetapi kebanyakan komponen adalah tidak diperlukan Sudah tentu, komponen teras ialah pelayan Prometheus, yang bertanggungjawab untuk mengumpul dan menyimpan data penunjuk, menyokong pertanyaan ekspresi dan menjana penggera. Seterusnya kami akan memasang pelayan Prometheus.
Prometheus boleh menyokong pelbagai kaedah pemasangan, termasuk Docker, Ansible, Chef, Puppet, Saltstack, dll. Dua kaedah paling mudah diperkenalkan di bawah Salah satunya ialah menggunakan fail boleh laku yang tersusun, yang boleh digunakan di luar kotak, dan satu lagi adalah menggunakan imej Docker.
Mula-mula dapatkan versi terkini dan alamat muat turun Prometheus daripada halaman muat turun tapak web rasmi Versi terkini ialah 2.4.3 (Oktober 2018).
$ wget https://github.com/prometheus/prometheus/releases/download/v2.4.3/prometheus-2.4.3.linux-amd64.tar.gz $ tar xvfz prometheus-2.4.3.linux-amd64.tar.gz
Kemudian Tukar ke direktori penyahmampatan dan semak versi Prometheus:
$ cd prometheus-2.4.3.linux-amd64 $ ./prometheus --version prometheus, version 2.4.3 (branch: HEAD, revision: 167a4b4e73a8eca8df648d2d2043e21bdb9a7449) build user: root@1e42b46043e9 build date: 20181004-08:42:02 go version: go1.11.1
Jalankan pelayan Prometheus:
$ ./prometheus --config.file=prometheus.yml
使用 Docker 安装 Prometheus 更简单,运行下面的命令即可:
$ sudo docker run -d -p 9090:9090 prom/prometheus
一般情况下,我们还会指定配置文件的位置:
$ sudo docker run -d -p 9090:9090 \ -v ~/docker/prometheus/:/etc/prometheus/ \ prom/prometheus
我们把配置文件放在本地 ~/docker/prometheus/prometheus.yml,这样可以方便编辑和查看,通过 -v 参数将本地的配置文件挂载到 /etc/prometheus/ 位置,这是 prometheus 在容器中默认加载的配置文件位置。如果我们不确定默认的配置文件在哪,可以先执行上面的不带 -v 参数的命令,然后通过 docker inspect 命名看看容器在运行时默认的参数有哪些(下面的 Args 参数):
$ sudo docker inspect 0c [...] "Id": "0c4c2d0eed938395bcecf1e8bb4b6b87091fc4e6385ce5b404b6bb7419010f46", "Created": "2018-10-15T22:27:34.56050369Z", "Path": "/bin/prometheus", "Args": [ "--config.file=/etc/prometheus/prometheus.yml", "--storage.tsdb.path=/prometheus", "--web.console.libraries=/usr/share/prometheus/console_libraries", "--web.console.templates=/usr/share/prometheus/consoles" ], [...]
正如上面两节看到的,Prometheus 有一个配置文件,通过参数 --config.file 来指定,配置文件格式为 YAML。我们可以打开默认的配置文件 prometheus.yml 看下里面的内容:
/etc/prometheus $ cat 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: # - 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: ['localhost:9090']
Prometheus 默认的配置文件分为四大块:
Selepas memasang Prometheus melalui langkah di atas, kami kini boleh mula mengalami. Prometheus menyediakan UI Web visual untuk memudahkan operasi kami Hanya lawati http://localhost:9090/ Ia akan melompat ke halaman Graf secara lalai:
Anda mungkin terharu apabila anda melawat halaman ini untuk kali pertama pertama Lihat kandungan di bawah menu lain, contohnya: Makluman memaparkan semua peraturan penggera yang ditentukan, Status boleh melihat pelbagai maklumat status Prometheus, termasuk Maklumat Runtime & Binaan, Bendera Baris Perintah, Konfigurasi, Peraturan, Sasaran, Penemuan Perkhidmatan, dan lain-lain.
Malah, halaman Graf adalah fungsi Prometheus yang paling berkuasa Di sini kita boleh menggunakan ungkapan khas yang disediakan oleh Prometheus untuk menanyakan data pemantauan ini dipanggil PromQL (Prometheus Query Language). Anda bukan sahaja boleh menanyakan data pada halaman Graf melalui PromQL, tetapi anda juga boleh menanyakannya melalui API HTTP yang disediakan oleh Prometheus. Data pemantauan yang ditanya boleh dipaparkan dalam dua bentuk: senarai dan graf (sepadan dengan dua label Konsol dan Graf dalam rajah di atas).
Seperti yang kami katakan di atas, Prometheus sendiri juga mendedahkan banyak penunjuk pemantauan, yang juga boleh ditanya pada halaman Graf Kembangkan kotak lungsur di sebelah butang Laksanakan, dan anda boleh melihat banyak nama penunjuk satu sesuka hati, contohnya: promhttp_metric_handler_requests_total, penunjuk ini Mewakili bilangan lawatan ke halaman /metrics Prometheus menggunakan halaman ini untuk menangkap data pemantauannya sendiri. Hasil pertanyaan dalam teg Console adalah seperti berikut:
Apabila memperkenalkan fail konfigurasi Prometheus di atas, anda boleh melihat bahawa parameter scrape_interval ialah 15s, yang bermaksud Prometheus mengakses halaman /metrics setiap 15s, jadi kami memuat semula halaman selepas 15s Anda boleh melihat bahawa nilai penunjuk akan meningkat secara automatik. Ini boleh dilihat dengan lebih jelas dalam tag Graf:
要学习 PromQL,首先我们需要了解下 Prometheus 的数据模型,一条 Prometheus 数据由一个指标名称(metric)和 N 个标签(label,N >= 0)组成的,比如下面这个例子:
promhttp\_metric\_handler\_requests\_total{code="200",instance="192.168.0.107:9090",job="prometheus"} 106
这条数据的指标名称为 promhttp_metric_handler_requests_total,并且包含三个标签 code、instance 和 job,这条记录的值为 106。上面说过,Prometheus 是一个时序数据库,相同指标相同标签的数据构成一条时间序列。如果以传统数据库的概念来理解时序数据库,可以把指标名当作表名,标签是字段,timestamp 是主键,还有一个 float64 类型的字段表示值(Prometheus 里面所有值都是按 float64 存储)。另外,搜索公众号Linux就该这样学后台回复“Linux”,获取一份惊喜礼包。
这种数据模型和 OpenTSDB 的数据模型是比较类似的,详细的信息可以参考官网文档 Data model。
虽然 Prometheus 里存储的数据都是 float64 的一个数值,但如果我们按类型来分,可以把 Prometheus 的数据分成四大类:
Counter digunakan untuk mengira, seperti: bilangan permintaan, bilangan penyelesaian tugas, dan bilangan kesilapan ini nilai akan terus meningkat dan tidak akan berkurangan. Tolok ialah nilai umum, yang boleh besar atau kecil, seperti perubahan suhu dan perubahan penggunaan memori. Histogram ialah histogram, atau carta bar, yang sering digunakan untuk menjejaki skala peristiwa, seperti masa permintaan dan saiz tindak balas.
Apa yang istimewa tentangnya ialah ia boleh mengumpulkan kandungan yang dirakam dan menyediakan fungsi kiraan dan jumlah. Ringkasan sangat serupa dengan Histogram dan juga digunakan untuk menjejak skala kejadian peristiwa Perbezaannya ialah ia menyediakan fungsi kuantil yang boleh membahagikan hasil penjejakan dengan peratusan. Sebagai contoh: nilai kuantil 0.95 bermakna mengambil 95% daripada data dalam nilai sampel.
Empat jenis data ini hanya dibezakan oleh pembekal penunjuk, iaitu Pengeksport yang dinyatakan di atas Jika anda perlu menulis Pengeksport anda sendiri atau mendedahkan penunjuk untuk Prometheus merangkak dalam sistem sedia ada, anda boleh menggunakan perpustakaan klien Prometheus, di. kali ini anda perlu mempertimbangkan jenis data penunjuk yang berbeza. Jika anda tidak perlu melaksanakannya sendiri, tetapi terus menggunakan beberapa Pengeksport sedia, dan kemudian semak data penunjuk yang berkaitan dalam Prometheus, maka anda tidak perlu memberi perhatian terlalu banyak kepada perkara ini, bagaimanapun, memahami jenis data daripada Prometheus juga berguna untuk menulis PromQL yang betul dan munasabah.
我们从一些例子开始学习 PromQL,最简单的 PromQL 就是直接输入指标名称,比如:
# 表示 Prometheus 能否抓取 target 的指标,用于 target 的健康检查 up
这条语句会查出 Prometheus 抓取的所有 target 当前运行情况,譬如下面这样:
up{instance="192.168.0.107:9090",job="prometheus"} 1 up{instance="192.168.0.108:9090",job="prometheus"} 1 up{instance="192.168.0.107:9100",job="server"} 1 up{instance="192.168.0.108:9104",job="mysql"} 0
也可以指定某个 label 来查询:
up{job="prometheus"}
这种写法被称为 Instant vector selectors,这里不仅可以使用 = 号,还可以使用 !=、=~、!~,比如下面这样:
up{job!="prometheus"} up{job=~"server|mysql"} up{job=~"192\.168\.0\.107.+"} #=~ 是根据正则表达式来匹配,必须符合 RE2 的语法。
和 Instant vector selectors 相应的,还有一种选择器,叫做 Range vector selectors,它可以查出一段时间内的所有数据:
http_requests_total[5m]
这条语句查出 5 分钟内所有抓取的 HTTP 请求数,注意它返回的数据类型是 Range vector,没办法在 Graph 上显示成曲线图,一般情况下,会用在 Counter 类型的指标上,并和 rate() 或 irate() 函数一起使用(注意 rate 和 irate 的区别)。
# 计算的是每秒的平均值,适用于变化很慢的 counter # per-second average rate of increase, for slow-moving counters rate(http_requests_total[5m]) # 计算的是每秒瞬时增加速率,适用于变化很快的 counter # per-second instant rate of increase, for volatile and fast-moving counters irate(http_requests_total[5m])
此外,PromQL 还支持 count、sum、min、max、topk 等 聚合操作,还支持 rate、abs、ceil、floor 等一堆的 内置函数,更多的例子,还是上官网学习吧。如果感兴趣,我们还可以把 PromQL 和 SQL 做一个对比,会发现 PromQL 语法更简洁,查询性能也更高。
我们不仅仅可以在 Prometheus 的 Graph 页面查询 PromQL,Prometheus 还提供了一种 HTTP API 的方式,可以更灵活的将 PromQL 整合到其他系统中使用,譬如下面要介绍的 Grafana,就是通过 Prometheus 的 HTTP API 来查询指标数据的。实际上,我们在 Prometheus 的 Graph 页面查询也是使用了 HTTP API。
我们看下 Prometheus 的 HTTP API 官方文档,它提供了下面这些接口:
GET /api/v1/query GET /api/v1/query_range GET /api/v1/series GET /api/v1/label/<label_name>/values GET /api/v1/targets GET /api/v1/rules GET /api/v1/alerts GET /api/v1/targets/metadata GET /api/v1/alertmanagers GET /api/v1/status/config GET /api/v1/status/flags
从 Prometheus v2.1 开始,又新增了几个用于管理 TSDB 的接口:
POST /api/v1/admin/tsdb/snapshot POST /api/v1/admin/tsdb/delete_series POST /api/v1/admin/tsdb/clean_tombstones
虽然 Prometheus 提供的 Web UI 也可以很好的查看不同指标的视图,但是这个功能非常简单,只适合用来调试。要实现一个强大的监控系统,还需要一个能定制展示不同指标的面板,能支持不同类型的展现方式(曲线图、饼状图、热点图、TopN 等),这就是仪表盘(Dashboard)功能。
因此 Prometheus 开发了一套仪表盘系统 PromDash,不过很快这套系统就被废弃了,官方开始推荐使用 Grafana 来对 Prometheus 的指标数据进行可视化,这不仅是因为 Grafana 的功能非常强大,而且它和 Prometheus 可以完美的无缝融合。
Grafana 是一个用于可视化大型测量数据的开源系统,它的功能非常强大,界面也非常漂亮,使用它可以创建自定义的控制面板,你可以在面板中配置要显示的数据和显示方式,它 支持很多不同的数据源,比如:Graphite、InfluxDB、OpenTSDB、Elasticsearch、Prometheus 等,而且它也 支持众多的插件。
下面我们就体验下使用 Grafana 来展示 Prometheus 的指标数据。首先我们来安装 Grafana,我们使用最简单的 Docker 安装方式:
$ docker run -d -p 3000:3000 grafana/grafana
运行上面的 docker 命令,Grafana 就安装好了!你也可以采用其他的安装方式,参考 官方的安装文档。安装完成之后,我们访问 http://localhost:3000/ 进入 Grafana 的登陆页面,输入默认的用户名和密码(admin/admin)即可。
要使用 Grafana,第一步当然是要配置数据源,告诉 Grafana 从哪里取数据,我们点击 Add data source 进入数据源的配置页面:
我们在这里依次填上:
Nama RN: Prometheusrujuk data di sini. sumber: Pelayar dan Proksi. Mod Penyemak Imbas bermaksud bahawa apabila pengguna mengakses panel Grafana, penyemak imbas mengakses sumber data secara langsung melalui URL manakala mod Proksi bermaksud bahawa penyemak imbas mula-mula mengakses antara muka proksi Grafana (alamat antara muka ialah /api/datasources/proxy; /), yang dikawal oleh antara muka proksi Grafana Pelayan mengakses URL sumber data Kaedah ini sangat berguna jika sumber data digunakan pada intranet dan tidak boleh diakses secara langsung oleh pengguna melalui penyemak imbas.
Selepas mengkonfigurasi sumber data, Grafana akan menyediakan beberapa panel yang dikonfigurasikan untuk anda gunakan secara lalai Seperti yang ditunjukkan dalam rajah di bawah, tiga panel disediakan secara lalai: Prometheus Stats, Prometheus 2.0 Stats dan metrik Grafana. Klik Import untuk mengimport dan menggunakan panel ini.
Kami mengimport panel Prometheus 2.0 Stats dan anda boleh melihat panel pemantauan berikut. Jika syarikat anda mempunyai syarat, anda boleh memohon monitor besar untuk digantung di dinding, menayangkan panel ini pada skrin besar, dan memerhati status sistem dalam talian dalam masa nyata Ia boleh dikatakan sangat keren.
Setakat ini, apa yang kita lihat hanyalah beberapa penunjuk yang tidak mempunyai kegunaan praktikal Jika kita ingin benar-benar menggunakan Prometheus dalam persekitaran pengeluaran kita, kita sering perlu memberi perhatian kepada pelbagai penunjuk . Contohnya, beban CPU pelayan, penggunaan memori, overhed IO, trafik rangkaian masuk dan keluar, dsb.
Seperti yang dinyatakan di atas, Prometheus menggunakan kaedah Tarik untuk mendapatkan data penunjuk Untuk Prometheus mendapatkan data daripada sasaran, anda mesti terlebih dahulu memasang program pengumpulan penunjuk pada sasaran dan mendedahkan antara muka HTTP untuk Prometheus membuat pertanyaan Program pengumpulan dipanggil Pengeksport Penunjuk yang berbeza memerlukan Pengeksport yang berbeza untuk dikumpulkan Pada masa ini, terdapat sejumlah besar Pengeksport yang tersedia, meliputi hampir semua sistem dan perisian yang biasa kami gunakan.
Laman web rasmi menyenaraikan senarai Pengeksport yang biasa digunakan Setiap Pengeksport mengikut konvensyen pelabuhan untuk mengelakkan konflik pelabuhan, iaitu, bermula dari 9100 dan meningkat dalam urutan Berikut ialah senarai port Pengeksport yang lengkap. Perlu juga diperhatikan bahawa sesetengah perisian dan sistem tidak perlu memasang Pengeksport kerana mereka sendiri menyediakan fungsi mendedahkan data penunjuk dalam format Prometheus, seperti Kubernetes, Grafana, Etcd, Ceph, dll.
Dalam bahagian ini marilah kami mengumpul beberapa data yang berguna.
首先我们来收集服务器的指标,这需要安装 node_exporter,这个 exporter 用于收集 *NIX 内核的系统,如果你的服务器是 Windows,可以使用 WMI exporter。
和 Prometheus server 一样,node_exporter 也是开箱即用的:
$ wget https://github.com/prometheus/node_exporter/releases/download/v0.16.0/node_exporter-0.16.0.linux-amd64.tar.gz $ tar xvfz node_exporter-0.16.0.linux-amd64.tar.gz $ cd node_exporter-0.16.0.linux-amd64 $ ./node_exporter
node_exporter 启动之后,我们访问下 /metrics 接口看看是否能正常获取服务器指标:
$ curl http://localhost:9100/metrics
如果一切 OK,我们可以修改 Prometheus 的配置文件,将服务器加到 scrape_configs 中:
scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['192.168.0.107:9090'] - job_name: 'server' static_configs: - targets: ['192.168.0.107:9100']
修改配置后,需要重启 Prometheus 服务,或者发送 HUP 信号也可以让 Prometheus 重新加载配置:
$ killall -HUP prometheus
在 Prometheus Web UI 的 Status -> Targets 中,可以看到新加的服务器:
Dalam kotak drop-down penunjuk pada halaman Graf, anda boleh melihat banyak penunjuk yang namanya bermula dengan nod Contohnya, kami masukkan node_load1
Perhatikan beban pelayan:
Jika anda ingin melihat penunjuk pelayan dalam Grafana. , anda boleh mencari nod pada halaman Papan Pemuka pengeksport Grafana, terdapat banyak templat panel yang boleh digunakan secara langsung, seperti: Metrik Pelayan Pengeksport Nod atau Pengeksport Nod Penuh, dsb. Kami membuka halaman papan pemuka Import Grafana dan masukkan URL panel (https://grafana.com/dashboards/405) atau ID (405).
一般情况下,node_exporter 都是直接运行在要收集指标的服务器上的,官方不推荐用 Docker 来运行 node_exporter。如果逼不得已一定要运行在 Docker 里,要特别注意,这是因为 Docker 的文件系统和网络都有自己的 namespace,收集的数据并不是宿主机真实的指标。可以使用一些变通的方法,比如运行 Docker 时加上下面这样的参数:
docker run -d \ --net="host" \ --pid="host" \ -v "/:/host:ro,rslave" \ quay.io/prometheus/node-exporter \ --path.rootfs /host
关于 node_exporter 的更多信息,可以参考 node_exporter 的文档 和 Prometheus 的官方指南 Monitoring Linux host metrics with the Node Exporter。
mysqld_exporter 是 Prometheus 官方提供的一个 exporter,我们首先 下载最新版本 并解压(开箱即用):
$ wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.11.0/mysqld_exporter-0.11.0.linux-amd64.tar.gz $ tar xvfz mysqld_exporter-0.11.0.linux-amd64.tar.gz $ cd mysqld_exporter-0.11.0.linux-amd64/
mysqld_exporter 需要连接到 mysqld 才能收集它的指标,可以通过两种方式来设置 mysqld 数据源。第一种是通过环境变量 DATA_SOURCE_NAME,这被称为 DSN(数据源名称),它必须符合 DSN 的格式,一个典型的 DSN 格式像这样:user:password@(host:port)/。
$ export DATA_SOURCE_NAME='root:123456@(192.168.0.107:3306)/' $ ./mysqld_exporter
另一种方式是通过配置文件,默认的配置文件是 ~/.my.cnf,或者通过 --config.my-cnf 参数指定:
$ ./mysqld_exporter --config.my-cnf=".my.cnf"
配置文件的格式如下:
$ cat .my.cnf [client] host=localhost port=3306 user=root password=123456
如果要把 MySQL 的指标导入 Grafana,可以参考 这些 Dashboard JSON。
这里为简单起见,在 mysqld_exporter 中直接使用了 root 连接数据库,在真实环境中,可以为 mysqld_exporter 创建一个单独的用户,并赋予它受限的权限(PROCESS、REPLICATION CLIENT、SELECT),最好还限制它的最大连接数(MAX_USER_CONNECTIONS)。
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'password' WITH MAX_USER_CONNECTIONS 3; GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
官方提供了两种收集 Nginx 指标的方式。
不过,在 nginx-module-vts 最新的版本中增加了一个新接口:/status/format/prometheus,这个接口可以直接返回 Prometheus 的格式,从这点这也能看出 Prometheus 的影响力,估计 Nginx VTS exporter 很快就要退役了(TODO:待验证)。
除此之外,还有很多其他的方式来收集 Nginx 的指标,比如:nginx_exporter 通过抓取 Nginx 自带的统计页面 /nginx_status 可以获取一些比较简单的指标(需要开启 ngx_http_stub_status_module 模块);nginx_request_exporter 通过 syslog 协议 收集并分析 Nginx 的 access log 来统计 HTTP 请求相关的一些指标;nginx-prometheus-shiny-exporter 和 nginx_request_exporter 类似,也是使用 syslog 协议来收集 access log,不过它是使用 Crystal 语言 写的。还有 vovolie/lua-nginx-prometheus 基于 Openresty、Prometheus、Consul、Grafana 实现了针对域名和 Endpoint 级别的流量统计。另外,搜索公众号技术社区后台回复“猴子”,获取一份惊喜礼包。
有需要或感兴趣的同学可以对照说明文档自己安装体验下,这里就不一一尝试了。
最后让我们来看下如何收集 Java 应用的指标,Java 应用的指标一般是通过 JMX(Java Management Extensions) 来获取的,顾名思义,JMX 是管理 Java 的一种扩展,它可以方便的管理和监控正在运行的 Java 程序。
JMX Exporter 用于收集 JMX 指标,很多使用 Java 的系统,都可以使用它来收集指标,比如:Kafaka、Cassandra 等。首先我们下载 JMX Exporter:
$ wget https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.3.1/jmx_prometheus_javaagent-0.3.1.jar
JMX Exporter 是一个 Java Agent 程序,在运行 Java 程序时通过 -javaagent 参数来加载:
$ java -javaagent:jmx_prometheus_javaagent-0.3.1.jar=9404:config.yml -jar spring-boot-sample-1.0-SNAPSHOT.jar
其中,9404 是 JMX Exporter 暴露指标的端口,config.yml 是 JMX Exporter 的配置文件,它的内容可以 参考 JMX Exporter 的配置说明 。然后检查下指标数据是否正确获取:
$ curl http://localhost:9404/metrics
至此,我们能收集大量的指标数据,也能通过强大而美观的面板展示出来。不过作为一个监控系统,最重要的功能,还是应该能及时发现系统问题,并及时通知给系统负责人,这就是 Alerting(告警)。
Prometheus 的告警功能被分成两部分:一个是告警规则的配置和检测,并将告警发送给 Alertmanager,另一个是 Alertmanager,它负责管理这些告警,去除重复数据,分组,并路由到对应的接收方式,发出报警。常见的接收方式有:Email、PagerDuty、HipChat、Slack、OpsGenie、WebHook 等。
我们在上面介绍 Prometheus 的配置文件时了解到,它的默认配置文件 prometheus.yml 有四大块:global、alerting、rule_files、scrape_config,其中 rule_files 块就是告警规则的配置项,alerting 块用于配置 Alertmanager,这个我们下一节再看。现在,先让我们在 rule_files 块中添加一个告警规则文件:
rule_files: - "alert.rules"
然后参考 官方文档,创建一个告警规则文件 alert.rules:
groups: - name: example rules: # Alert for any instance that is unreachable for >5 minutes. - alert: InstanceDown expr: up == 0 for: 5m labels: severity: page annotations: summary: "Instance {{ $labels.instance }} down" description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes." # Alert for any instance that has a median request latency >1s. - alert: APIHighRequestLatency expr: api_http_request_latencies_second{quantile="0.5"} > 1 for: 10m annotations: summary: "High request latency on {{ $labels.instance }}" description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"
这个规则文件里,包含了两条告警规则:InstanceDown 和 APIHighRequestLatency。顾名思义,InstanceDown 表示当实例宕机时(up === 0)触发告警,APIHighRequestLatency 表示有一半的 API 请求延迟大于 1s 时(api_http_request_latencies_second{quantile="0.5"} > 1)触发告警。
配置好后,需要重启下 Prometheus server,然后访问 http://localhost:9090/rules 可以看到刚刚配置的规则:
访问 http://localhost:9090/alerts 可以看到根据配置的规则生成的告警:
这里我们将一个实例停掉,可以看到有一条 alert 的状态是 PENDING,这表示已经触发了告警规则,但还没有达到告警条件。这是因为这里配置的 for 参数是 5m,也就是 5 分钟后才会触发告警,我们等 5 分钟,可以看到这条 alert 的状态变成了 FIRING。
虽然 Prometheus 的 /alerts 页面可以看到所有的告警,但是还差最后一步:触发告警时自动发送通知。这是由 Alertmanager 来完成的,我们首先 下载并安装 Alertmanager,和其他 Prometheus 的组件一样,Alertmanager 也是开箱即用的:
$ wget https://github.com/prometheus/alertmanager/releases/download/v0.15.2/alertmanager-0.15.2.linux-amd64.tar.gz $ tar xvfz alertmanager-0.15.2.linux-amd64.tar.gz $ cd alertmanager-0.15.2.linux-amd64 $ ./alertmanager
Alertmanager 启动后默认可以通过 http://localhost:9093/ 来访问,但是现在还看不到告警,因为我们还没有把 Alertmanager 配置到 Prometheus 中,我们回到 Prometheus 的配置文件 prometheus.yml,添加下面几行:
alerting: alertmanagers: - scheme: http static_configs: - targets: - "192.168.0.107:9093"
这个配置告诉 Prometheus,当发生告警时,将告警信息发送到 Alertmanager,Alertmanager 的地址为 http://192.168.0.107:9093。也可以使用命名行的方式指定 Alertmanager:
$ ./prometheus -alertmanager.url=http://192.168.0.107:9093
这个时候再访问 Alertmanager,可以看到 Alertmanager 已经接收到告警了:
下面的问题就是如何让 Alertmanager 将告警信息发送给我们了,我们打开默认的配置文件 alertmanager.ym:
global: resolve_timeout: 5m route: group_by: ['alertname'] group_wait: 10s group_interval: 10s repeat_interval: 1h receiver: 'web.hook' receivers: - name: 'web.hook' webhook_configs: - url: 'http://127.0.0.1:5001/' inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' equal: ['alertname', 'dev', 'instance']
其中 global 块表示一些全局配置;route 块表示通知路由,可以根据不同的标签将告警通知发送给不同的 receiver,这里没有配置 routes 项,表示所有的告警都发送给下面定义的 web.hook 这个 receiver;如果要配置多个路由,可以参考 这个例子:
routes: - receiver: 'database-pager' group_wait: 10s match_re: service: mysql|cassandra - receiver: 'frontend-pager' group_by: [product, environment] match: team: frontend
紧接着,receivers 块表示告警通知的接收方式,每个 receiver 包含一个 name 和一个 xxx_configs,不同的配置代表了不同的接收方式,Alertmanager 内置了下面这些接收方式:
email_config hipchat_config pagerduty_config pushover_config slack_config opsgenie_config victorops_config wechat_configs webhook_config
虽然接收方式很丰富,但是在国内,其中大多数接收方式都很少使用。最常用到的,莫属 email_config 和 webhook_config,另外 wechat_configs 可以支持使用微信来告警,也是相当符合国情的了。
Sebenarnya, adalah sukar untuk menyediakan kaedah pemberitahuan penggera yang merangkumi semua, kerana terdapat pelbagai perisian pemesejan, dan setiap negara mungkin berbeza, jadi adalah mustahil untuk menutupnya sepenuhnya, Alertmanager telah memutuskan untuk tidak menambah penerima baharu , tetapi mengesyorkan Gunakan webhooks untuk menyepadukan kaedah penerimaan tersuai. Anda boleh merujuk kepada contoh penyepaduan ini, seperti menyambungkan DingTalk ke Prometheus AlertManager WebHook.
Setakat ini, kami telah mempelajari kebanyakan fungsi Prometheus + Grafana + Alertmanager sepenuhnya boleh membina sistem pemantauan yang sangat lengkap. Namun, apabila benar-benar menggunakannya, kita akan mendapati lebih banyak masalah.
Memandangkan Prometheus secara aktif memperoleh data pemantauan melalui Pull, adalah perlu untuk menentukan senarai nod pemantauan secara manual Apabila bilangan nod yang dipantau meningkat, fail konfigurasi perlu diubah setiap kali nod ditambahkan. yang sangat menyusahkan Pada masa ini Ini perlu diselesaikan melalui mekanisme penemuan perkhidmatan (SD).
Prometheus menyokong pelbagai mekanisme penemuan perkhidmatan dan secara automatik boleh mendapatkan sasaran untuk dikumpulkan Anda boleh merujuk di sini Mekanisme penemuan perkhidmatan yang disertakan termasuk: azure, consul, dns, ec2, openstack, file, gce, kubernetes, marathon,. triton, zookeeper ( saraf, set pelayan), untuk kaedah konfigurasi, sila rujuk halaman Konfigurasi manual. Ia boleh dikatakan bahawa mekanisme SD sangat kaya, tetapi pada masa ini disebabkan oleh sumber pembangunan yang terhad, mekanisme SD baharu tidak lagi dibangunkan, dan hanya mekanisme SD berasaskan fail dikekalkan. Ikuti komuniti Cina Linux
Terdapat banyak tutorial mengenai penemuan perkhidmatan di Internet, seperti artikel ini dalam blog rasmi Prometheus Penemuan Perkhidmatan Lanjutan dalam Prometheus 0.14.0, yang mempunyai pengenalan yang agak sistematik mengenai perkara ini dan secara menyeluruh menerangkan konfigurasi pelabelan semula Dan cara menggunakan DNS-SRV, Konsul dan fail untuk penemuan perkhidmatan.
Selain itu, laman web rasmi juga menyediakan contoh pengenalan penemuan perkhidmatan berasaskan fail The Prometheus tutorial pengenalan bengkel yang ditulis oleh Julius Volz juga menggunakan DNS-SRV untuk penemuan perkhidmatan.
Tidak kira konfigurasi Prometheus atau konfigurasi Alertmanager, tiada API untuk kami mengubah suai secara dinamik. Senario yang sangat biasa ialah kita perlu membina sistem penggera dengan peraturan yang boleh disesuaikan berdasarkan Prometheus Pengguna boleh membuat, mengubah suai atau memadam peraturan penggera pada halaman mengikut keperluan mereka sendiri, atau mengubah suai kaedah pemberitahuan penggera dan orang yang boleh dihubungi, seperti dalam. Soalan daripada pengguna ini dalam Kumpulan Google Prometheus: Bagaimana untuk menambahkan peraturan makluman secara dinamik dalam fail rules.conf dan prometheus yml melalui API atau sesuatu?
Malangnya, Simon Pasquier berkata di bawah bahawa pada masa ini tiada API sedemikian, dan tiada rancangan sedemikian untuk membangunkan API sedemikian pada masa hadapan, kerana fungsi tersebut harus diserahkan kepada alatan seperti Boneka, Chef, Ansible, dan Salt Sistem pengurusan konfigurasi sedemikian.
Pushgateway digunakan terutamanya untuk mengumpul beberapa pekerjaan jangka pendek Memandangkan pekerjaan sedemikian wujud untuk masa yang singkat, ia mungkin hilang sebelum Prometheus datang ke Pull. Pegawai mempunyai penjelasan yang baik tentang masa untuk menggunakan Pushgateway.
Prometheus telah berkembang dengan sangat pesat dalam tempoh dua tahun yang lalu, komuniti ini juga sangat aktif, dan semakin ramai orang di China sedang belajar Prometheus. Dengan mempopularkan konsep seperti perkhidmatan mikro, DevOps, pengkomputeran awan dan asli awan, semakin banyak syarikat mula menggunakan Docker dan Kubernetes untuk membina sistem dan aplikasi mereka sendiri seperti Nagios dan Cacti akan menjadi semakin popular . Semakin kurang sesuai, saya percaya Prometheus akhirnya akan berkembang menjadi sistem pemantauan yang paling sesuai untuk persekitaran awan.
Atas ialah kandungan terperinci Dikenali sebagai sistem pemantauan generasi akan datang! Mari lihat betapa hebatnya ia. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!