|
collectd是一个守护(daemon)进程，用来收集系统性能和提供各种存储方式来存储不同值的机制。
2 R. x o: c. }& p) {3 B2 ainfluxdb 是一个时序数据库。
% S( N$ z; S1 f' m6 _% i9 dgrafana是一个前端展示工具。 可以使用collectd 的virt插件通过Libvirtd 的API 收集虚拟机的数据，然后保存到时序数据库influxdb。最后通过grafana将influxdb中存储的数据以图标的形式展示出来。 一、部署 collectd influxdb grafana prometheus- G$ `* y8 l9 Z0 f- x# v+ t
1.修改全局配置globals.yml文件，设置部署监控相关文件。 vim /etc/kolla/globals.yml
: D6 B8 @$ E, p* R E. \& |3 K& g6 X1 n
enable_collectd: "yes" 6 Z( T$ r p' E
enable_grafana: "yes"
- z8 `: j' n/ o( f! C0 j0 zenable_influxdb: "yes"
* {0 m7 q2 ]% T! fenable_prometheus: "yes" 6 K+ X7 _! A3 l4 e
prometheus_cmdline_extras: "-storage.local.retention 720h"
8 M9 l3 T7 Q) R. k A* x3 ]
) `7 d! u) M. h2 t0 Gprometheus-server 数据保存30天 单位d无法识别。可以附加的参数 可参考 https://blog.csdn.net/dengxiangbao3167/article/details/102365367相应的prometheus的exporter包含 #enable_prometheus_haproxy_exporter: "{{ enable_haproxy | bool }}"
4 j/ U h9 F& g @* C! N" s$ `; j#enable_prometheus_mysqld_exporter: "{{ enable_mariadb | bool }}". I4 [' x1 i( |2 ~9 m
#enable_prometheus_node_exporter: "{{ enable_prometheus | bool }}"
! W3 E E, _& p( ]- X$ B#enable_prometheus_cadvisor: "{{ enable_prometheus | bool }}"
, ~) q7 X. a* l0 x% g# ~3 J#enable_prometheus_memcached: "{{ enable_prometheus | bool }}"
1 G% B) m1 v6 z: j. S' H, I#enable_prometheus_alertmanager: "{{ enable_prometheus | bool }}"
; J0 {$ w( ~- v0 Y( l#enable_prometheus_ceph_mgr_exporter: "{{ enable_prometheus | bool and enable_ceph | bool }}"
( z5 K: ?# C. P; m9 I* C#enable_prometheus_openstack_exporter: "{{ enable_prometheus | bool }}"5 M6 m( ^! D- a! ]5 n
#enable_prometheus_elasticsearch_exporter: "{{ enable_prometheus | bool and enable_elasticsearch | bool }}"& ~: \; |4 ]# q* R0 X- Z
#enable_prometheus_blackbox_exporter: "{{ enable_prometheus | bool }}"
# c6 ?$ y; D0 U* A2 s" C, S& ?& D0 U: S( P. E a$ L0 m& H! ~* C
2.安装部署相应的容器组件 kolla-ansible deploy -i /etc/kolla/all-in-one 6 C0 u' c# J: g- {: i/ G6 P% y9 t
1# i. H! y: r, f% J& x' q4 o. e+ ~
3.完成后查看相关组件docker容器是否部署完成 docker ps -a | grep -e collectd -e influxdb -e grafana -e prometheus
& [0 V- [& \* d7 |4 i$ V: T/ [1
0 w6 X, [& m8 M- V二、修改相应配置文件，通过libvirt监控虚拟机! C5 w' J, C7 w
自定义的配置文件位置，该位置的配置文件会取代默认配置文件。
# The directory to merge custom config files the kolla's config files$ W5 v0 b7 I/ ~, N! W
node_custom_config: "/etc/kolla/config"! `% e7 q1 k5 |3 P
' u& w6 O/ x/ a: R
mkdir /etc/kolla/config
4 E9 u, f t1 t1 r) P- t9 v1! N i/ D' m, c) ]: C
使用kolla部署完成后。默认配置文件是/etc/kolla/<< service name >>/<< config file >>。
1 _. T' b8 m. p9 A7 D自定义配置文件路径是/etc/kolla/config/,且自定义配置文件一旦设置，就会覆盖且替换原配置文件。5 a1 ]7 J! h0 u' Y. p
路径可以是 /etc/kolla/config/<< config file >>,
) Y# B- ]/ \/ Z' H' o- F' e/etc/kolla/config/<< service name >>/<< config file >>,
|8 p$ B$ U6 k! l1 n8 j1 G# \/etc/kolla/config/<< service name >>/<< hostname >>/<< config file >>
! C4 l0 g( p+ u5 p4 M# l! B3 o9 N @6 [% Q! |9 k
1.collectd 配置' k) ]) [' J* R/ \+ q v
libvirt有不同的虚拟机库， 通过API可以访问控制虚拟机。OpenStack也是通过libvirt的API也控制底层的虚拟机的。 cp /etc/kolla/collectd/collectd.conf /etc/kolla/config/
; v7 r( @7 k& [- `vim /etc/kolla/config/collectd.conf
, W \- n- e/ ?2 ^* W15 [. z0 ^- F: m2 f$ N
2+ ~ o% l( q0 k1 h
FQDNLookup false
" ]* M) z2 o s0 c, [! ~LoadPlugin syslog$ I. s4 [7 @# X( `! o8 G A
LoadPlugin cpu
2 o* ^' k1 d( a: }5 `" [LoadPlugin interface
$ {# B4 O3 |) p+ NLoadPlugin load# G" s4 P7 _/ S' Q7 z! r
LoadPlugin memory LoadPlugin network LoadPlugin logfile
5 {+ Q0 K; I q; i0 s4 kLoadPlugin virt % K8 M5 k3 F. L7 j. |
<Plugin network>
, f* k9 `0 k- R/ ?) _+ ^. i6 @- t Server "192.168.199.90" "25826" / K# h+ S# r# i7 _, r* F
</Plugin> ; h- I4 x9 `6 g5 X, j% @& s
<Plugin logfile> K0 C$ O4 t- }) H
LogLevel info
, j4 e/ v$ j5 d; L8 m( q File "/var/log/kolla/collectd/collectd.log" 7 r2 Z, q3 u2 J: h
Timestamp true
, D# N. s' M' F6 I2 Z& M; p PrintSeverity false $ Y5 c- I: {# O5 l) F* P9 B* {1 i- V
</Plugin> 3 Q4 o$ U# c) R
<Plugin virt> : z+ b# ]; D. I5 Z9 l; i
Connection "qemu+tcp://192.168.199.90/system"
: X) ?% [: W5 y+ c! T/ ]5 p" a HostnameFormat hostname 4 B, O/ S: r& n- U1 s" y
PluginInstanceFormat uuid $ z; U$ D, t8 ^1 c9 u8 m
BlockDeviceFormat target $ ^0 |6 y8 V8 ~. o' }
InterfaceFormat name
$ ]! |: s( K' _9 v: G7 x ExtraStats "cpu_util"
$ K' p r, s& F d4 G6 Q N" M9 ^' W. u</Plugin>
7 s; x* ~2 H1 `' Z; g4 Q7 N7 ~7 p& @1 H5 n5 k5 `6 i1 a9 {; L
启用了插件 logfile virt network。logfile是日志插件，virt就是与libvirtd的API通信的插件，network网络插件将收集的数据通过网络发送出去。 network插件设置。 Server "192.168.199.90" "25826"# @: r& `2 T2 m, V; d# w) X9 t
1
5 c: Z- Y% k7 f5 V; P0 ^( T表示将数据发送到192.168.199.90主机的25826端口。就是下一步设置的influxdb收集collectd数据的主机 端口。 LoadPlugin cpu
$ `; z9 j; }, ?# f/ Q. x0 W+ N# gLoadPlugin interface
9 W6 M/ F+ r, I3 E5 D1 ~LoadPlugin load
/ k- o9 [. _% P. m2 H, n5 T) [LoadPlugin memory
. T3 I' ?2 h9 Z, f; i
+ j' Z! o5 b$ h* S. R这四个插件是用来收集宿主机的信息的。interface可能还会监听了虚拟机虚拟网卡的信息，如果不希望通过interface插件收集虚拟网卡信息（virt插件会收集）。可以设置interface只监听想要监听的网卡名。 <Plugin "interface">
5 h i/ _' J: \3 ]8 D Interface "ens33"( E4 U ~) ]+ `# n7 f
Interface "ens34"
- a6 Q2 r+ P- T5 b</Plugin>
0 J" S+ ]7 S9 C+ v- k Y7 q! Z5 m1 g. V
. O9 X: I! ]; j7 M. Evirt 插件设置 <Plugin virt>
6 x8 @' X m7 R Connection "qemu+tcp://192.168.199.90/system"
9 L0 v9 ^- m3 S3 P: r HostnameFormat hostname
# Z. T$ s& ^6 e \ PluginInstanceFormat uuid
7 T9 u5 V" G3 N8 ^ o, H+ U BlockDeviceFormat source , v% p) f4 ~$ J, j8 M
BlockDeviceFormatBasename false 5 J: S; c$ H8 z+ [. j6 ?8 V9 U& d: T& C4 P
InterfaceFormat name
0 `9 R7 p- O H. B ExtraStats "cpu_util" 2 | v/ W/ K' o4 P8 U
</Plugin>
* Z% Y: T+ u, J* t9 o) W2 h* X% p. O# y' w7 ~0 w/ y
具体参数详情可以看官网
" e1 p% j8 g* q, O6 s! ohttps://collectd.org/documentati ... 5.shtml#plugin_virtConnection 表示连接的libvirt API服务。7 K+ X4 u; z7 p7 x) N- o D
就像使用qemu+kvm创建虚拟机时使用virsh管理时使用virsh -c qemu+tcp://192.168.199.90:16509/system
# S- ?- h) N: D 即可连接到libvirtd服务控制虚拟机相关。由于16509是默认端口号，可以省略
0 E; L: Q4 V8 i- o# D 由于是ALLInOne 所以collectd设置只有一个，多个主机部署时，需要每个计算节点上安装collectd指向本机的libvirt。
/ v. ?9 [. M' ~) h+ w0 K+ L# s 因此每个collectd设置文件都不相同。 HostnameFormat name|uuid|hostname|...
; R! W$ W! ^$ {0 L% h) e 当virt插件记录数据时，会根据此设置设置所收集数据的主机名。
+ R) o1 S R- h: V1 I1 s3 l 默认的做法是使用hypervisor提供的来宾名称，这等于设置为虚拟机name。7 s+ V! t6 `0 S' e9 u3 g+ I1 K
UUID 意味着使用虚拟机的UUID。如果您想跨迁移跟踪同一个客户，这是很有用的。
/ |5 r5 n2 H5 d3 s7 s. s: m hostname 意味着使用“全局主机名”设置，这本身可能并不有用，因为所有来宾似乎都有相同的名称。
/ r- v' S0 b+ | hostname就是宿主机名。。。这个其实挺重要的（在有多个宿主机的虚拟机数剧都保存到一个数据库时，可以通过hostname来确定不同虚拟机在哪一个主机。）: o' b2 ` c" C* d
至于实例的 名称或UUID 可以使用PluginInstanceFormat来设置 PluginInstanceFormat name|uuid|none
~) d5 m; A$ [/ C9 @6 g 当virt插件记录数据时，它会根据此设置设置所收集数据的plugin_instance。默认情况是不设置plugin_instance。(只有一个宿主机时可以直接设置HostnameFormat name来代替PluginInstanceForma的设置)8 }! x, q A$ h
name是指使用管理程序提供的虚拟机名称。UUID意味着使用虚拟机的UUID。& ^6 r" Y3 `9 s# h9 o- C9 j
OpenStack中是根据uuid来管理虚拟机的，虚拟机在libvirtd中的name和OpenStack中设置的并不一致。libvirtd底层管理是自动生成的，OpenStack中创建时手动命名的。
1 y, `% H$ Z8 c$ _9 \ HostnameFormat和PluginInstanceFormat都可以使用多个fields。如name uuid。会同时显示名称和uuid中间使用 : 分隔。如foo:1234-1234-1234-1234 BlockDeviceFormat target|source& F! c: |/ I9 U M( A4 z
挂载到虚拟机中的磁盘设备名设置。' Y9 _2 r& y b) P
virsh # domblklist instance-0000000a/ _* l! F- O' P* L$ p
Target Source- E+ I2 s8 B( u' i( y7 Y
------------------------------------------------0 ]4 a4 ^6 W; `
vda /var/lib/nova/instances/86862558-141c-45b7-bfcf-b4e497f91bda/disk
& f4 \/ p3 S/ P/ Y vdb /dev/sdc; \) A5 @& n. s& d" w% u, {9 r3 z
target 是映射到实例中的磁盘名 vda vdb。即实例中可以通过lsblk看到的。3 i( a2 v2 |$ [8 q F: b
source 虚拟磁盘对应的路径及磁盘文件名。/var/lib/nova/instances/86862558-141c-45b7-bfcf-b4e497f91bda/disk /dev/sdc8 M3 p* R1 ]$ `( n) l5 F
如果设置BlockDeviceFormatBasename设置为true，则只显示文件名 不显示前面的路径。 默认未设置BlockDeviceFormatBasename，是false即显示前面路径
" F* k( O3 d& |4 L/ m/ \InterfaceFormat name|address% ^$ j& [+ F; X- o# c5 _
虚拟机的网卡显示 name或者address。name网卡名，address网卡mac地址。' ]# w( C* C, n
) _0 l; h9 h: f6 H
ExtraStats "cpu_util"
: k% k6 ^ [! f7 j5 E% { virt额外记录的数据。此处只设置了一个cpu_util 即CPU的利用率。
( p, a' ?2 S/ A virsh # domiflist instance-00000002 7 K$ p- C/ L$ N3 i- c! n b
Interface Type Source Model MAC
6 c$ d O' }( S; {" r/ K( ? -------------------------------------------------------* w9 {, M. q$ k
tap97caffeb-9a bridge qbr97caffeb-9a virtio fa:16:3e:64:5f:c0
# f# I- ?/ ?" J2 x5 ~. W interface就是name ，MAC就是address
0 Z b- b3 j: ]8 j2 W# W' r# t
这是单个主机ALLinOne下设置配置文件的情况，如果多个计算节点，每个计算节点的collectd的配置文件是不同的，需要单独设置（主要不同就是连接的libvirtd API的IP不同）,每个计算节点需要一个collectd收集本计算节点的相应libvirt 数据。 很奇怪的一点，似乎使用kolla部署的collectd容器收集虚拟机数据时无法收集虚拟机的内存信息，只能获取虚拟机全部内存。 直接使用yum安装的collectd却可以收集used,availble 等。。。不知道原因 2.influxdb 配置* |5 T: g6 Y$ l
cp /etc/kolla/influxdb/influxdb.conf /etc/kolla/config/
% L* ~! h! V; D1 h$ Z- U( H: Ovim /etc/kolla/config/influxdb.conf ! B, e6 J' e% t: S, u! d4 z+ B
1
8 v+ j c* j& e0 q) e21 t5 o* C$ z8 @* Z1 t
reporting-disabled = true6 S& m) z' @/ p6 K
[logging]
4 X6 t: E$ U3 C9 R, l; Q, h2 L* N9 j level = "info": y8 N# U+ P5 G
file = "/var/log/kolla/influxdb/influxdb.log"6 z1 o& V; K6 Y2 Z( J$ v( C
[meta]
2 _( v; X' |# r! p dir = "/var/lib/influxdb/meta"5 g) ^& G: B5 O2 { v% g: m
retention-autocreate = true9 d3 b/ Y" I# Y( E# s/ j H5 B
logging-enabled = true
& `! Z+ R# z& |7 ~% N+ r[data]8 \" E( @2 S2 D* ^
dir = "/var/lib/influxdb/data"1 x# z% U$ E' s8 e9 \- H
wal-dir = "/var/lib/influxdb/wal"
# D6 e' j M' \1 Z! i wal-logging-enabled = true
L8 U6 {, u5 h data-logging-enabled = true' p M' H. q& j
index-version = "tsi1", N D9 k3 `2 G& }9 X+ Q0 D
[coordinator]
0 I! ]4 ]1 D! H' l write-timeout = "10s"0 V% N8 m' E8 B
max-concurrent-queries = 07 g. `; _# ^& m) w4 e
query-timeout = "0s"" ]& v' R2 E. S+ S" W1 G( Y
max-select-point = 0
9 L3 m( |& a$ W, l7 m7 l' a" D7 E max-select-series = 08 S' F w! q3 O0 Z; Z$ O7 _/ U
max-select-buckets = 0' o1 D( S/ h2 f! l, y
[retention]6 b0 U1 S& W3 i8 ]0 f
enabled = true) P1 Y* | I; v
check-interval = "30m"" ?/ \" |4 Y# v% P1 C
[shard-precreation]
0 n4 u/ D2 g6 Z; q& z; n; O& z7 c$ c enabled = true% d+ W* c! r) q, ]* h
check-interval = "10m"
* X* f4 d, R) U7 ]0 P; z advance-period = "30m"
" b9 Q m! W+ Y[monitor]
. T$ |+ m: [1 L' q" d store-enabled = true; E! U5 I' q4 r
store-database = "_internal"
D& R1 {; |, F( V; D: g# w store-interval = "10s"
: W! @: O( m* K" s- [3 F5 Q( _[http]* ~; Q" g" V/ y1 z
enabled = true
# Q4 u- m/ Y6 s4 F; V; g8 S( }' ` bind-address = "192.168.199.90:8086"
( D! C% J8 z5 B G3 F auth-enabled = false9 C2 i; F& L7 x7 l0 |
log-enabled = true: d3 C! k; i& H" ?4 Z
write-tracing = false, n- `2 D7 W5 b6 D m5 S# J& {7 C
pprof-enabled = false
, \ \( P S6 x https-enabled = false4 I% ^1 t( o7 m
[[graphite]]- N; V1 [, U# e
enabled = false# ]; p' e% t# r9 S8 H9 X
[[opentsdb]]# H: ]( p0 {" p6 T/ g
enabled = false, w" E! ]- C: L2 e4 T2 [
[[udp]]2 M1 A p( P" w" b: x
enabled = false
, v8 p( K% I7 ~( R/ B% L[continuous_queries]+ L# W9 e& T) r* S) Q' L
log-enabled = true) U) l4 x0 a) ]! m) u
enabled = true [[collectd]] - X e- \, E8 l" O. s$ }- X! p2 k
enabled = true
8 G3 v d. m$ \9 ] bind-address = "192.168.199.90:25826"
6 l( P" w) L4 W; h9 _" d& ~( J database = "collectd" + O2 s0 o" A* R& x# U
typesdb = "/var/lib/influxdb/types.db" ' K2 w% W l+ {7 x
% n; P. s/ d4 h5 D1 O主要是添加了 末尾一段。influxdb是可以作为collectd的network Server，可以将collectd发送的数据保存起来。前提是有对应的type.db数据格式。 ; Q) G0 Y5 ^% f, J. T+ h6 d
https://download.csdn.net/download/dandanfengyun/14989445[[collectd]]! H( _ R6 I9 E/ |
enabled = true2 f$ A( X* a. d! u
bind-address = "192.168.199.90:25826"0 } b* O* q9 s* p; R& q0 {
database = "collectd"/ k( e% l( `" j+ |! }/ h
typesdb = "/var/lib/influxdb/types.db"- v' w, ?8 l% G- [( Z( R7 J
! S# k$ o; {- t# Z; G- R( l1 T; F1 ~bind-address = "192.168.199.90:25826"表示监听192.168.199.90主机25827端口的数据。然后保存到库collectd中。数据格式typesdb = “/var/lib/influxdb/types.db” 数据格式文件需要手动添加。部署OpenStack时，对于一些特别的需要存储数据的组件docker，都有相应的docker volume附加卷。直接映射到容器内。 influxdb容器附加卷在宿主机中对应位置 {
6 {1 B; h! v9 A- `5 H4 I5 p "Type": "volume",7 g1 b4 l. A g) t
"Name": "influxdb",+ u. P1 a T8 Y1 m
"Source": "/var/lib/docker/volumes/influxdb/_data",0 [$ T! |9 `7 ?0 ?
"Destination": "/var/lib/influxdb",
1 M' ?& X, t: b( b6 x "Driver": "local",
; ? l9 j( z0 [# l5 o& I$ m "Mode": "rw",
2 q1 H$ }+ k" f4 d "RW": true,
# p! Y- k7 j0 p4 B t( D( B "Propagation": "": e, l) n5 B: [* R& o" M6 n
}, : [! f( `' M! _( `
将文件types.db保存到/var/lib/docker/volumes/influxdb/_data，容器内即可在/var/lib/influxdb位置找到该文件。 docker exec collectd cat /usr/share/collectd/types.db > /var/lib/docker/volumes/influxdb/_data/types.db
& w v: E' A# f' _2 x+ Q0 i1
- l# d8 v; v ^4 t[root@ALLInOne-Kolla ~]# ls /var/lib/docker/volumes/influxdb/_data/$ s/ y* O* C) \
data meta types.db wal
8 P# z. h6 Y0 Q1 q9 ]" w- K13 _# R5 I9 ] z7 m
2- z/ G4 q# e$ e- T
3.加载个人配置。8 u. w5 T# g2 j2 y& e
kolla-ansible reconfigure -i /etc/kolla/all-in-one
4 \ I' K( ^3 s7 q# w1 y1
% E" f- l6 C* m. h7 e完成后，会使用个人配置替代默认配置。并重启相应的组件容器加载新的配置。 新配置生效之后，最好将influxdb数据库原数据清除一下，因为原数据中会包含一些不符合新配置的数据。 删除库 collectd 创建库collectd （如果有数据存入，该库会被自动创建的） curl -i -XPOST http://192.168.199.90:8086/query --data-urlencode 'q=SHOW RETENTION POLICIES ON collectd'
; o; D0 U5 G% v2 W# u$ \6 V- ?5 v1 . B9 e- Q; `% ~ u
设置新的保存策略 30天 并设置为默认策略 curl -i -XPOST http://192.168.199.90:8086/query --data-urlencode 'q=CREATE RETENTION POLICY "train" ON "collectd" DURATION 720h REPLICATION 1 DEFAULT' ) J. B9 r; B9 u0 |$ d! `# O
1 - E8 p% g1 E+ Z9 }( p# M7 E
删除旧策略 19 K. t) j G3 A3 D( B& q
2
6 d/ y# T2 V% e( l. F4.influxdb一些其它的api。
1 Z5 ^) W- C2 l( S% I) M删除数据库 curl -G 'http://192.168.199.90:8086/query?q=SHOW+DATABASES'! r b1 i/ H+ I* A* d
1* K2 a' |+ ]- z! {5 ?" p" d
查看库measurements 可以理解为表 curl -G 'http://192.168.199.90:8086/query' --data-urlencode "db=collectd" --data-urlencode 'q=show measurements'1 g# \3 A5 h. [# v3 t
1
1 s' P9 l2 _+ d4 J4 b查看具体数据 curl -G 'http://192.168.199.90:8086/query' --data-urlencode "db=collectd" --data-urlencode 'q=select * from virt_rx limit 10', M6 W+ L3 B, X5 k: w! w
1
d* g: N Z: k8 P+ D1 Fprometheus和grafana等暂不需额外配置文件。 不过由于直接通过libvirt的API监控虚拟机状态。没有经过OpenStack，所以虚拟机的名称无法对应。需要通过虚拟机的UUID来确定。
' A0 v5 a* i- j. N" H. C连接的是libvirt，也就是计算节点的libvirt。一个collectd只能监听一个计算节点livirtd，多节点部署多个计算节点，需要在每个计算节点安装collectd连接本节点libvirtd。4 g2 T( y1 l4 V9 Z
对OpenStack的整体信息，如虚拟机数量等也无法统计。且虚拟机移除后，数据不会随之消失，只是无有新的数据统计。保存策略是永久。 所以需要配合prometheus使用。prometheus_openstack_exporter会获取OpenStack的整体信息。如vm数量，cinder数量，glance的镜像数量等。但是没有具体虚拟机的具体信息 。 用户 admin。密码可在grafana /etc/kolla/passwords.yml 中找grafana_admin_password egrep grafana /etc/kolla/passwords.yml
, d& O" y/ C! B' m1! s3 `7 m, p9 ]+ C
登录成功后设置数据源 1.influxdb的collectd数据源 Name：collectd (这个是自定义的grafana数据源名)- E# _# R, R; l
URL ： 192.168.199.90:80868 d6 P) x1 R5 T. n- H+ o, s$ `- ]
Database：collectd 完成点Save & Test 即可，成功的话是 Data source is working
. ~) g3 d5 g% P8 J% ^- g- K失败查看一下influxdb组件docker容器是否启动，IP端口对不对等。。。 2.prometheus数据源
8 v/ E( f2 _0 l) l2.设置dashboard的变量( Y5 p4 J) Z0 ]# P6 {' ?
基本上不可能只有一个 虚拟机，且把多个虚拟机的信息一起展示也不合理。所以设置一些变量来确定当前展示的数据是哪一个虚拟机的。
' P* w' [- g4 ~7 z& J: j* Xhost SHOW TAG VALUES WITH KEY=host+ b C) U& K& t2 ]3 B
instance_uuid SHOW TAG VALUES WITH KEY=instance WHERE host='$host'0 o7 t$ F( I' p
virt_interface SHOW TAG VALUES FROM virt_rx,virt_tx WITH KEY=type_instance WHERE instance='$instance_uuid'& u: r( E# s/ l f9 g. T n( O
virt_disk SHOW TAG VALUES FROM virt_read,virt_write WITH KEY=type_instance WHERE instance='$instance_uuid'
$ ]6 ]" z3 V g0 Q8 Vinstance_name label_values(openstack_nova_server_status{id="$instance_uuid"}, name)
1 F' f0 H! P n! n% b
5 R' }+ c0 k/ W5 k& J. [分别设置宿主机名 虚拟实例uuid 虚拟网卡 虚拟磁盘 以及实例名
4 Q7 I# c0 r% q宿主机变量
虚拟机实例uuid变量
8 \9 V/ M. \8 ]9 B; K虚拟网卡变量
0 }) Q% i' B% Q# u0 V虚拟磁盘变量
实例名
) E. D8 Y/ c# Q* z f& J$ R i- ~host instance_uuid virt_interface virt_disk都是根据collectd库中数据查询产生
最后一个比较特殊，不应该称之为变量。而应该作为一个展示的文字。是根据host_uuid根据prometheus查询而来。（一个dashboard当然可以使用多个数据源） 由于Libvirtd 的API中显示的实例名是类似于instance-000001这种的，与OpenStack创建时设置的实例名并不一致（UUID一致），所以通过collectd收集的数据 上没有真实的OpenStack的实例名，可以通过Prometheus来获取对应uuid的实例名， 仅在此处使用一次Prometheus数据源。 因此最后一个变量并不能称为变量，实际上是根据uuid通过prometheus查询出的一个值。 3.设置panel。& A- k5 ]7 I" q; J8 X
这个根据influxdb查询语句和grafana使用个人创建即可。 ' K0 _2 \, o2 V. _( r: g
创建数据源 略。 点击import导入模板 $ Y; |( t6 @/ h x
选择模板文件 3 N& H0 M5 k3 B _+ m8 |& q- O5 W2 h K
最终导入 @; k: p. v) ?4 B$ E# l1 V( s
附9 u5 u) U: I1 X/ M1 K$ y) C/ E
如果Prometheus和influxdb中collectd数据 实例 基本一致，可以设置更多的变量信息。/ q0 H% `* m- D& C D9 n( e
如 实例不同状态根据Prometheus数据库查询。
7 z# v4 k' J2 s% A9 D+ W: Wuuid也使用Prometheus 数据库根据实例状态查询。
# {- B0 j( b2 l2 g" b其他的数据根据uuid在influxdb的collectd库中查询。- u( A+ \/ d2 l8 e! @7 G
一致的是，实例名依然只能作为一个展示数据，而不能作为真正变量影响数据展示。 结合了prometheus展示了虚拟机的状态，根据状态查询实例uuid，选择ACTIVE可以避免查询到已经废弃的实例，也可选择SHUTOFF查询已停止运行实例的状态 不好的是也会查到状态是BUILD的实例 不过实例状态查询 重要的就是查询最近一段时间内 活动实例 的状态，因此状态变量选择基本是ACTIVE，只用于筛选出活动的变量即可。4 R5 \6 L- {+ W% R- _6 ?
且BUILD 状态的实例BUILD状态只会存在很短的时间，最终会转化成ACTIVE。 grafana变量设置 host 宿主机名（influxdb）
0 z( c" i; R w# f, G SHOW TAG VALUES WITH KEY=host instance_status 实例状态（prometheus）
2 Z1 L& `: D( X' [& V5 t# |( u label_values(openstack_nova_server_status{hypervisor_hostname="$host"}, status) instance_uuid 实例uuid（prometheus）因为此处使用prometheus查询uuid可以根据实例状态查询
2 d+ \( K4 W* y; F2 D label_values(openstack_nova_server_status{hypervisor_hostname="$host",status="$instance_status"}, uuid) virt_interface 实例虚拟网卡（influxdb）, X( O: N0 K6 {5 Q% }
SHOW TAG VALUES FROM virt_rx,virt_tx WITH KEY=type_instance WHERE instance='$instance_uuid' virt_disk 实例虚拟磁盘（influxdb）4 ~) D& G* ^+ s; _7 s
SHOW TAG VALUES FROM virt_read,virt_write WITH KEY=type_instance WHERE instance='$instance_uuid' instance_name 实例名（prometheus）* T! G& F' A, r! n
label_values(openstack_nova_server_status{id="$instance_uuid"}, name)
2 j$ `+ `6 \: Y& A( {, W
( B1 ]9 w8 L2 ^' Q6 z5 p3 |panel都不用改变。。。。。。 https://download.csdn.net/download/dandanfengyun/15137036 这里有一个问题 不知道理解的对不对。。。' E& y0 X7 e9 ^6 M7 J
prometheus和collectd都是时序数据库。# _ X0 Y( W/ E2 B
Prometheus记录的实例信息也是按时间存放多个的。（隔一段时间存放当时的实例状态信息） grafana变量也是和时间相关的（也就是grafana变量不仅和其他变量相关，也和时间相关）
( m5 n: |: g; u+ Z5 U. `9 j$ g也就是说，一个实例的状态信息选择时间段不同，是可能有多个不同的变量的。5 L2 M1 q) {. {: A* t9 Z/ o7 e5 P
如变量为实例运行状态 15分钟前关闭了该实例。假设只有两个实例，一个运行 一个15分钟前关闭。 那么选择5分钟前到现在的时间段，变量就有active和shutoff。active的实例只有一个，shutoff的实例也只有一个。 被删除的实例则没有ACTIVE或SHUT OFF状态，但是prometheus和influxdb中都记录了被删除前虚拟实例的运行状况。 但是当选择30分钟前到现在的时间段，变量就有active和shutoff。shutoff的实例还是只有一个，但是active的实例有两个（这个听起来有点那啥），只要记住 prometheus是时序数据库，不能把该变量当成真正的纯粹记录当前实例状态的布尔值。 30前到15分钟前，该实例是active的，15分钟前到现在，该实例是shutoff的，所以该实例有两个运行状态。。。 问题
" v( ~& ~3 ]* J; ~collectd 无法通过OpenStack获取用户等信息。如果要使用grafana展示可能要通过prometheus。
4 k) x% d2 H* M9 P* S3 e( l- xgrafana需要通过prometheus和influxdb两个数据源才能展示实例的状态信息。 collectd也无法收集实例 内空间使用占用情况。
, } \& L0 e/ a+ m2 ^6 ? |
发表于 2021-7-2 17:00:28