|
collectd是一个守护(daemon)进程，用来收集系统性能和提供各种存储方式来存储不同值的机制。. d( y) S2 U7 k, f$ ~
influxdb 是一个时序数据库。( H" p& u& y% x6 k( k
grafana是一个前端展示工具。 可以使用collectd 的virt插件通过Libvirtd 的API 收集虚拟机的数据，然后保存到时序数据库influxdb。最后通过grafana将influxdb中存储的数据以图标的形式展示出来。 一、部署 collectd influxdb grafana prometheus5 X" x2 v) E2 L8 {1 h( {
1.修改全局配置globals.yml文件，设置部署监控相关文件。 vim /etc/kolla/globals.yml
% T: g8 b: B) t' p9 ~# r% D V1 H/ I# ?
enable_collectd: "yes" 9 H# t3 b& U9 n& @
enable_grafana: "yes" . W8 l+ _4 X% `4 \( |- K1 m
enable_influxdb: "yes" 1 Q* [* p+ c- |2 P3 a* |9 X
enable_prometheus: "yes" + K2 |! r7 Q) u; \( @: v8 H
prometheus_cmdline_extras: "-storage.local.retention 720h" 7 N0 A J& ?# I8 G+ n7 j
" [" G- [$ @( \. Vprometheus-server 数据保存30天 单位d无法识别。可以附加的参数 可参考 https://blog.csdn.net/dengxiangbao3167/article/details/102365367相应的prometheus的exporter包含 #enable_prometheus_haproxy_exporter: "{{ enable_haproxy | bool }}"! f! r3 \& ~: S8 v" d% I# w- B
#enable_prometheus_mysqld_exporter: "{{ enable_mariadb | bool }}"# P! C5 J/ x4 R# E. |
#enable_prometheus_node_exporter: "{{ enable_prometheus | bool }}"$ h1 s- u8 T" x4 Q7 q0 {0 J
#enable_prometheus_cadvisor: "{{ enable_prometheus | bool }}"
6 j3 e7 f! U. I8 e#enable_prometheus_memcached: "{{ enable_prometheus | bool }}"
" U4 L: `( X$ w/ C+ s2 D#enable_prometheus_alertmanager: "{{ enable_prometheus | bool }}"
" @% n3 `; v4 s+ ^( ^#enable_prometheus_ceph_mgr_exporter: "{{ enable_prometheus | bool and enable_ceph | bool }}"7 {: J, D9 |. ^
#enable_prometheus_openstack_exporter: "{{ enable_prometheus | bool }}"8 k5 T8 A/ c1 p0 s* s
#enable_prometheus_elasticsearch_exporter: "{{ enable_prometheus | bool and enable_elasticsearch | bool }}"
7 @% Q$ Y, A& E0 |6 e: ~3 d2 \; F#enable_prometheus_blackbox_exporter: "{{ enable_prometheus | bool }}"
+ O! G1 I I) \0 ^+ Q7 G; {" \) U! z5 C$ m: S$ |5 C; h9 j5 x! C
2.安装部署相应的容器组件 kolla-ansible deploy -i /etc/kolla/all-in-one * [- t5 R% z x% @) \% \
1; m8 `5 R v. ^; X1 ?" ]
3.完成后查看相关组件docker容器是否部署完成 docker ps -a | grep -e collectd -e influxdb -e grafana -e prometheus" @% Q- s& I& ~$ Z7 ~) f
1 ) c" V! y% j3 C \4 U* ?
二、修改相应配置文件，通过libvirt监控虚拟机
& M* C& j' q, M+ b自定义的配置文件位置，该位置的配置文件会取代默认配置文件。 # The directory to merge custom config files the kolla's config files; x1 j! L; L8 s- f; m* }- K
node_custom_config: "/etc/kolla/config"' i/ c8 r) ?) i4 K$ A
1 C# E/ _0 Y% X8 h7 e5 T0 W j# Q$ s
mkdir /etc/kolla/config3 t$ z- t: M! A" C8 x! V5 [
1* ^, B o! ^/ `: O/ ~( C
使用kolla部署完成后。默认配置文件是/etc/kolla/<< service name >>/<< config file >>。
4 ]1 P) _# G! b' L自定义配置文件路径是/etc/kolla/config/,且自定义配置文件一旦设置，就会覆盖且替换原配置文件。
$ @- o5 H9 I3 t! A- T路径可以是 /etc/kolla/config/<< config file >>,
0 \ A! v5 d& n5 m% C) l; T/ h/etc/kolla/config/<< service name >>/<< config file >>,6 Y* {% f+ o# ^" n
/etc/kolla/config/<< service name >>/<< hostname >>/<< config file >>* r- u4 A; i( d' B. I4 _8 d3 Q0 O4 ?
) T* Z9 @: b+ N( U. B M. _
1.collectd 配置$ g# a+ S4 z& l8 Q4 N# Y
libvirt有不同的虚拟机库， 通过API可以访问控制虚拟机。OpenStack也是通过libvirt的API也控制底层的虚拟机的。 cp /etc/kolla/collectd/collectd.conf /etc/kolla/config/2 E+ `# D2 _+ C( y2 \
vim /etc/kolla/config/collectd.conf ) q' J6 h* A. @
16 }5 U( d% o* q- a5 Z# b0 Q
2
6 ^3 M& c4 Z$ g. t: EFQDNLookup false& Z2 A# n/ [, H" Z- m1 J/ F
LoadPlugin syslog* a( \4 O& h& o5 S5 e3 s4 m
LoadPlugin cpu
" F0 S1 J$ d+ R; Q% y4 ]LoadPlugin interface: Q1 Y: O: r q9 Q2 v# [( t
LoadPlugin load
P+ B' q3 j4 W2 M; Z/ D' NLoadPlugin memory LoadPlugin network LoadPlugin logfile
, \( t: h+ [$ q% S& `7 gLoadPlugin virt
( S# W$ i$ ~+ { {5 H; y$ g6 f<Plugin network> i/ f8 h9 I$ l$ T( c$ w
Server "192.168.199.90" "25826"
% g0 b O4 ?8 N, N: t) A</Plugin>
7 @* F1 ?5 v0 g- M( E3 M& N<Plugin logfile> 2 j. H3 V' v+ L& x
LogLevel info W- n/ L1 @% B9 E. E# }
File "/var/log/kolla/collectd/collectd.log" 3 ?1 ~! {9 v6 s
Timestamp true ! n2 F; b/ }7 L( Y0 `( }: J, @
PrintSeverity false
" }& d1 B; p1 `% f( l</Plugin>
3 E) u& d, t3 H% U$ C& m! s<Plugin virt>
) b8 F( P( p6 N4 [, v Connection "qemu+tcp://192.168.199.90/system" , B8 A$ ]& N* B% _5 B: G
HostnameFormat hostname
, `# R9 u2 d0 n, T2 B1 h& N8 q PluginInstanceFormat uuid ' S$ N8 r6 c9 C' w& X
BlockDeviceFormat target
! J6 [2 J$ m% u" v# B/ X InterfaceFormat name
! ~: D1 g, d0 b! |% C) a ExtraStats "cpu_util" 9 T- H" [! i' ~+ W1 `% ?2 {$ f
</Plugin>
2 C5 x' ?, g; [' T/ j9 \ V, m( q0 A9 F0 h( x- X
启用了插件 logfile virt network。logfile是日志插件，virt就是与libvirtd的API通信的插件，network网络插件将收集的数据通过网络发送出去。 network插件设置。 Server "192.168.199.90" "25826"( |5 h. J( e8 `9 m5 }: B9 F
1$ U2 m: D7 z) f, ^* j4 ~
表示将数据发送到192.168.199.90主机的25826端口。就是下一步设置的influxdb收集collectd数据的主机 端口。 LoadPlugin cpu
7 W1 a7 y5 N. B& `/ t2 n9 H2 QLoadPlugin interface
. k) f) p; G9 |1 a2 mLoadPlugin load, L" k* U2 @8 o7 h+ F
LoadPlugin memory
* r2 d* d& z N/ V' H4 t* [6 W- F& L" S6 |
这四个插件是用来收集宿主机的信息的。interface可能还会监听了虚拟机虚拟网卡的信息，如果不希望通过interface插件收集虚拟网卡信息（virt插件会收集）。可以设置interface只监听想要监听的网卡名。 <Plugin "interface">
* C! @& r# v, D9 i1 w& A$ y% y Interface "ens33"
8 s; `. ^3 H6 h6 y f Interface "ens34"
& j- K( _% E$ j9 F5 R</Plugin>
, a8 A; ~8 J0 B2 B+ B! z, A2 M3 L: l7 v# W1 H/ w" E) s8 B& _) P
virt 插件设置 <Plugin virt>
6 h- c1 _7 P9 z; Y Connection "qemu+tcp://192.168.199.90/system" 2 e/ R9 `4 J) D+ d+ b" A
HostnameFormat hostname
5 p3 |5 N3 S7 E$ \! C- l+ @9 O PluginInstanceFormat uuid
' P3 g$ \4 B/ s2 J' Q BlockDeviceFormat source
' r: M( T7 X" |( H4 \2 G5 f) _ T BlockDeviceFormatBasename false ( Y ~( ~: N* A3 L
InterfaceFormat name
5 B5 Z# x/ B2 j( B ExtraStats "cpu_util"
# [* r M$ d4 \/ e8 J</Plugin>
6 s0 [" g. s: t0 W& a$ ^/ r, X+ i3 d' v# L; K
具体参数详情可以看官网 ( J0 {& K1 A4 t1 s1 c( o! l, o
https://collectd.org/documentati ... 5.shtml#plugin_virtConnection 表示连接的libvirt API服务。
& f4 a6 t; o: Q) U4 ^ 就像使用qemu+kvm创建虚拟机时使用virsh管理时使用virsh -c qemu+tcp://192.168.199.90:16509/system
: J6 w* Z5 P% ?3 i 即可连接到libvirtd服务控制虚拟机相关。由于16509是默认端口号，可以省略
0 o' f, E ]% ]. j# Q/ p; @ 由于是ALLInOne 所以collectd设置只有一个，多个主机部署时，需要每个计算节点上安装collectd指向本机的libvirt。+ C( v" m+ U: g6 i/ x2 r; w
因此每个collectd设置文件都不相同。 HostnameFormat name|uuid|hostname|...
; d' G4 n2 t& M( g f8 `+ c 当virt插件记录数据时，会根据此设置设置所收集数据的主机名。; W& [- C s; W) Y: {8 x/ j
默认的做法是使用hypervisor提供的来宾名称，这等于设置为虚拟机name。
7 K7 ^0 g: \# }3 l% o/ J UUID 意味着使用虚拟机的UUID。如果您想跨迁移跟踪同一个客户，这是很有用的。
% e' z- |4 x) M. ]1 @ hostname 意味着使用“全局主机名”设置，这本身可能并不有用，因为所有来宾似乎都有相同的名称。9 ?! W9 R+ z& b8 \! j. |
hostname就是宿主机名。。。这个其实挺重要的（在有多个宿主机的虚拟机数剧都保存到一个数据库时，可以通过hostname来确定不同虚拟机在哪一个主机。）
( k* {/ k/ O+ ^ 至于实例的 名称或UUID 可以使用PluginInstanceFormat来设置 PluginInstanceFormat name|uuid|none
( I; ~* J) C% d% z5 j; T: H 当virt插件记录数据时，它会根据此设置设置所收集数据的plugin_instance。默认情况是不设置plugin_instance。(只有一个宿主机时可以直接设置HostnameFormat name来代替PluginInstanceForma的设置)
8 i( q8 F9 e+ L1 [2 b& I; s name是指使用管理程序提供的虚拟机名称。UUID意味着使用虚拟机的UUID。0 Y" E5 l3 I5 g' H
OpenStack中是根据uuid来管理虚拟机的，虚拟机在libvirtd中的name和OpenStack中设置的并不一致。libvirtd底层管理是自动生成的，OpenStack中创建时手动命名的。 `( w4 m2 u& c5 }& V3 r
HostnameFormat和PluginInstanceFormat都可以使用多个fields。如name uuid。会同时显示名称和uuid中间使用 : 分隔。如foo:1234-1234-1234-1234 BlockDeviceFormat target|source( E9 |% K2 S+ g- [
挂载到虚拟机中的磁盘设备名设置。: X# F) n) K2 W) ~; c- G6 L% g
virsh # domblklist instance-0000000a
. V8 A- _+ M) w Target Source
) G/ c8 ^6 M8 B8 B# |* |2 k8 Z ------------------------------------------------
V+ F6 g$ L5 r/ U9 |6 U. T' o vda /var/lib/nova/instances/86862558-141c-45b7-bfcf-b4e497f91bda/disk( k; b U3 ~" }' o" W$ o/ L
vdb /dev/sdc/ u0 L! r$ u. h
target 是映射到实例中的磁盘名 vda vdb。即实例中可以通过lsblk看到的。
# o# y) z4 o4 ~( A3 g" P7 ] source 虚拟磁盘对应的路径及磁盘文件名。/var/lib/nova/instances/86862558-141c-45b7-bfcf-b4e497f91bda/disk /dev/sdc3 ?; h5 ^. i/ b- U0 s" ]; b2 g7 t2 j/ C9 Q! _
如果设置BlockDeviceFormatBasename设置为true，则只显示文件名 不显示前面的路径。 默认未设置BlockDeviceFormatBasename，是false即显示前面路径
P/ Z* n8 d2 A5 f* O3 JInterfaceFormat name|address9 t% \: T3 P5 t0 ?0 p
虚拟机的网卡显示 name或者address。name网卡名，address网卡mac地址。
# ^/ i/ M3 X" ~. \; _: J4 ?, t* P! f ; y4 y! U( ]0 V8 o" Y
ExtraStats "cpu_util"
8 @9 w3 J: s: J% L virt额外记录的数据。此处只设置了一个cpu_util 即CPU的利用率。) S& T# `) W) b) n4 @/ P# a% C
virsh # domiflist instance-00000002 & c+ y! X% u; ^4 B: ~
Interface Type Source Model MAC
5 V" f( w0 J' y$ V -------------------------------------------------------' M6 }# n, T( Q6 l+ p) l$ P- f8 S
tap97caffeb-9a bridge qbr97caffeb-9a virtio fa:16:3e:64:5f:c0# e8 E" t% Q5 Y; p1 l
interface就是name ，MAC就是address
. c2 n3 h2 I! o- @这是单个主机ALLinOne下设置配置文件的情况，如果多个计算节点，每个计算节点的collectd的配置文件是不同的，需要单独设置（主要不同就是连接的libvirtd API的IP不同）,每个计算节点需要一个collectd收集本计算节点的相应libvirt 数据。
很奇怪的一点，似乎使用kolla部署的collectd容器收集虚拟机数据时无法收集虚拟机的内存信息，只能获取虚拟机全部内存。 直接使用yum安装的collectd却可以收集used,availble 等。。。不知道原因 2.influxdb 配置1 H" p6 a: N" a8 `! L
cp /etc/kolla/influxdb/influxdb.conf /etc/kolla/config/
- p$ D$ @1 F7 Fvim /etc/kolla/config/influxdb.conf % Y( p& j% t; \6 B% Y6 W7 o5 o
1
) f2 P9 O/ e- r; ~" y" A22 N1 \& t% a9 a0 U# c- X
reporting-disabled = true
9 q8 J* W8 e4 N[logging]( \8 [+ K- C$ F( z5 q. i1 G7 b: F1 e
level = "info"% I6 T) }& f: d. S' y9 M0 a
file = "/var/log/kolla/influxdb/influxdb.log"" u5 u( U- X r" v
[meta]7 X' G8 \! b7 u9 A4 v- z1 A- c
dir = "/var/lib/influxdb/meta"$ u' J. I7 @1 x
retention-autocreate = true
5 \# l! m; H* F4 @7 f logging-enabled = true
* T( ?; ^3 V9 }; s[data]6 Y, S/ F1 m2 U7 v
dir = "/var/lib/influxdb/data"
3 z8 p) \. A# |) p wal-dir = "/var/lib/influxdb/wal"2 V0 d: U9 \" M2 U" \$ h
wal-logging-enabled = true: P- l7 [% S: h( N# D" z" l. r
data-logging-enabled = true
* n+ M. [1 |8 N: C! @, Y index-version = "tsi1"
6 x- h' ?, u6 C2 Z3 @2 N$ Y[coordinator]0 F7 A6 o8 D( d0 m5 m
write-timeout = "10s"4 a" X5 `6 ~+ V1 K* s" Q
max-concurrent-queries = 0
: M! f$ R A# c/ t- ~) v; o query-timeout = "0s"
6 y$ G, j( ^1 x& T2 Y) M" D! P max-select-point = 0
1 f' g# v* R, G: g! x+ s! { max-select-series = 0
+ i. Z5 y: |( c7 l3 q* n* S5 s! T" C6 v max-select-buckets = 0, O4 `% T9 X0 o( s
[retention]
6 f; @7 W; S9 n% \/ G& [ enabled = true: s( ]9 |9 y: Q, }
check-interval = "30m"$ o7 k+ W. g' P0 g L
[shard-precreation]. C9 r, m! H& f4 w U
enabled = true
& d. ^5 B& P2 t. z R" h check-interval = "10m"
' b& O* U+ _& A$ f3 |+ i$ {$ D9 i: y advance-period = "30m", w) V. `+ K. L
[monitor]9 T J, @4 Q- n/ e+ p4 @4 _
store-enabled = true7 A e: a" Q$ v0 O/ D& w3 c
store-database = "_internal"
- \7 N* x; t5 {& k0 Y( y store-interval = "10s"
2 v1 H: k* k) g5 d0 E5 P[http]
9 x1 E5 C/ d. T" u6 H9 L5 R enabled = true
! e7 w3 P) z2 ?- _: f bind-address = "192.168.199.90:8086"
! A- O8 [; }. K4 E auth-enabled = false
% j& A* O) { @% c1 K, D: x log-enabled = true& V( x# B' I; F4 Z) K
write-tracing = false
7 x; A/ y3 k5 S pprof-enabled = false- J& e$ C; W( |& W# W
https-enabled = false9 g9 L6 P! ]. T
[[graphite]]2 T1 n- P: w7 y6 o
enabled = false) ]* Y6 g9 z* f( x# U( q% m; A8 c% {' S
[[opentsdb]]- t" ~ Q) o) e0 w
enabled = false; g0 }! b( G2 x. `
[[udp]]
* b- @4 I5 }7 @: z2 @* [5 e enabled = false
1 H8 X1 w8 e* m6 G1 P3 y2 B[continuous_queries]
7 p) _' k T) T log-enabled = true( [. @- ^- r9 C/ L
enabled = true [[collectd]]
& w* i2 f( S. L% h1 T' t enabled = true
3 f( Q o! N7 ~% ] O bind-address = "192.168.199.90:25826" 6 t$ W" l# s* b c
database = "collectd"
' ?$ k+ O% a( X6 y typesdb = "/var/lib/influxdb/types.db"
# \! ?# X m, W1 j, [9 s. J
6 d0 y3 P- D3 R- S" ]主要是添加了 末尾一段。influxdb是可以作为collectd的network Server，可以将collectd发送的数据保存起来。前提是有对应的type.db数据格式。
# }' R; B0 @# V+ Uhttps://download.csdn.net/download/dandanfengyun/14989445[[collectd]]
: {. @9 M. g; u, Y" G0 V2 ]- j enabled = true
% j% {: [9 n% [# B" ~/ U+ N( h3 T; ~ bind-address = "192.168.199.90:25826": a* @% m( K7 i/ r( t( b
database = "collectd"3 |' h; f& i$ h2 ?
typesdb = "/var/lib/influxdb/types.db"
3 ]2 b( `, @6 N8 k3 W6 G' |( R& C5 O1 D I
bind-address = "192.168.199.90:25826"表示监听192.168.199.90主机25827端口的数据。然后保存到库collectd中。数据格式typesdb = “/var/lib/influxdb/types.db” 数据格式文件需要手动添加。部署OpenStack时，对于一些特别的需要存储数据的组件docker，都有相应的docker volume附加卷。直接映射到容器内。 influxdb容器附加卷在宿主机中对应位置 {' h% `" m# d4 w4 A
"Type": "volume",
5 E K3 T8 t6 o& ]- b "Name": "influxdb",
6 p- P7 m, H# t6 w1 | "Source": "/var/lib/docker/volumes/influxdb/_data",. y: t) T4 @4 y8 a
"Destination": "/var/lib/influxdb",* G2 ~! S2 i" S8 I* p
"Driver": "local",
& k6 N* D$ M6 Y( r t l2 s0 t "Mode": "rw",
, g: J9 B& h( t7 X2 p: C- a% k "RW": true,
1 F0 @6 s$ u2 H( K. D "Propagation": ""' d" |: w5 N& {% ?% U8 s; t7 S
},
i5 P/ l( H9 k# {将文件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.db3 W# {9 ^5 L5 E, M9 {
1
6 z( W8 T- h/ q0 O# b/ J[root@ALLInOne-Kolla ~]# ls /var/lib/docker/volumes/influxdb/_data/
x# |0 {9 t. p g/ M! |9 p; @data meta types.db wal# P: w7 q3 f8 v% G8 H5 o1 S4 [
1+ \ q- S5 L/ Q5 P; y1 d7 B
2
# f* h, H7 G$ ~4 F' n* D3.加载个人配置。
. @3 e6 s* ]" S- N6 wkolla-ansible reconfigure -i /etc/kolla/all-in-one 5 T5 ~* e& e2 ?3 W
1
/ z/ c, J$ a, _( Y完成后，会使用个人配置替代默认配置。并重启相应的组件容器加载新的配置。 新配置生效之后，最好将influxdb数据库原数据清除一下，因为原数据中会包含一些不符合新配置的数据。 删除库 collectd 创建库collectd （如果有数据存入，该库会被自动创建的） curl -i -XPOST http://192.168.199.90:8086/query --data-urlencode 'q=SHOW RETENTION POLICIES ON collectd'
7 E. s& D7 A0 ?6 v1 , N$ l) {2 N2 U3 [/ m
设置新的保存策略 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'
7 U+ ^1 n. s3 c1 o `$ m* H1 4 `+ ?6 ^5 H7 o7 M$ w. I
删除旧策略 1; I" \* }1 J ~1 z4 E' D
2
r# @7 s0 w8 N% T7 r4 H4.influxdb一些其它的api。
6 |$ A$ O: p. j" w, R) @+ X2 ~2 n: i6 g删除数据库 curl -i -XPOST http://192.168.199.90:8086/query --data-urlencode 'q=DROP DATABASE collectd' ' G* S! N: E3 @: i. O4 l* \) A
1 6 N* j+ I- _7 G4 i2 q4 J" i$ \; F
查看库 列表 curl -G 'http://192.168.199.90:8086/query?q=SHOW+DATABASES'
0 v5 g( H6 A" n' A+ M; h6 r1
- S# U+ `" c7 {$ I6 k5 q- K查看库measurements 可以理解为表 curl -G 'http://192.168.199.90:8086/query' --data-urlencode "db=collectd" --data-urlencode 'q=show measurements'
, v) {- S) W3 s! x6 m2 D' A. E1
" y/ O' J9 [$ v. q查看具体数据 curl -G 'http://192.168.199.90:8086/query' --data-urlencode "db=collectd" --data-urlencode 'q=select * from virt_rx limit 10'* n; [! z# ~$ f' i- A! O# r
1: W3 `) I6 r2 v/ s0 I
prometheus和grafana等暂不需额外配置文件。 不过由于直接通过libvirt的API监控虚拟机状态。没有经过OpenStack，所以虚拟机的名称无法对应。需要通过虚拟机的UUID来确定。" L# J6 I. A2 k" o/ \ R- r8 p) t
连接的是libvirt，也就是计算节点的libvirt。一个collectd只能监听一个计算节点livirtd，多节点部署多个计算节点，需要在每个计算节点安装collectd连接本节点libvirtd。
" V2 E- [! M2 a- m: g" w对OpenStack的整体信息，如虚拟机数量等也无法统计。且虚拟机移除后，数据不会随之消失，只是无有新的数据统计。保存策略是永久。 所以需要配合prometheus使用。prometheus_openstack_exporter会获取OpenStack的整体信息。如vm数量，cinder数量，glance的镜像数量等。但是没有具体虚拟机的具体信息 。 用户 admin。密码可在grafana /etc/kolla/passwords.yml 中找grafana_admin_password egrep grafana /etc/kolla/passwords.yml % H- F, A$ H* ?4 d" k9 N
1+ N1 b/ J1 y) z" m1 t% M) u0 t! t
登录成功后设置数据源 1.influxdb的collectd数据源 Name：collectd (这个是自定义的grafana数据源名)2 `4 D% f. _* @1 `% P4 {
URL ： 192.168.199.90:8086
. V s- Q1 T) s1 L4 G# ]. {Database：collectd 完成点Save & Test 即可，成功的话是 Data source is working
9 M' Z+ W1 W6 {9 V' b) m失败查看一下influxdb组件docker容器是否启动，IP端口对不对等。。。 2.prometheus数据源
`. v" K3 \5 T9 g0 ~1 z5 u2.设置dashboard的变量
) b) i7 q0 z0 R6 |基本上不可能只有一个 虚拟机，且把多个虚拟机的信息一起展示也不合理。所以设置一些变量来确定当前展示的数据是哪一个虚拟机的。
* d7 p# ^1 b( B2 ^& ~+ K9 ^) M$ whost SHOW TAG VALUES WITH KEY=host
' j4 c- P& w- n) `) J' f9 einstance_uuid SHOW TAG VALUES WITH KEY=instance WHERE host='$host'* @# a" w- ]5 B4 [% |
virt_interface SHOW TAG VALUES FROM virt_rx,virt_tx WITH KEY=type_instance WHERE instance='$instance_uuid'! y) G3 y+ j2 z4 \ l$ B* L
virt_disk SHOW TAG VALUES FROM virt_read,virt_write WITH KEY=type_instance WHERE instance='$instance_uuid'. ^1 s+ n9 I, h t6 K4 G% ^
instance_name label_values(openstack_nova_server_status{id="$instance_uuid"}, name)4 w( I5 N9 x: w$ d' t# p( y
7 o( S7 D& n0 p3 d6 e2 J# n2 h分别设置宿主机名 虚拟实例uuid 虚拟网卡 虚拟磁盘 以及实例名5 }1 v0 a9 e+ p% [) R, E1 K
宿主机变量
虚拟机实例uuid变量
( K. N0 r m: @* i( T( K* o9 v虚拟网卡变量
5 M7 [, ~* y& b0 O; N: q9 P虚拟磁盘变量
实例名
6 |/ K: _8 _; h6 I* w7 R- r2 khost 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。
, U% e- R, j: A! b这个根据influxdb查询语句和grafana使用个人创建即可。 1 |5 z# s8 e, H) ~$ E1 r
创建数据源 略。 点击import导入模板
+ |/ |' G' x. _- d O: ]2 Q选择模板文件
1 L- y3 E n) f+ h2 F! G最终导入
8 m# j$ R4 E1 ^$ e1 u
附
_% D; ~) U: x4 t0 m" D如果Prometheus和influxdb中collectd数据 实例 基本一致，可以设置更多的变量信息。
" U: y9 x! Q) n) d- V- V如 实例不同状态根据Prometheus数据库查询。
7 n0 d% s: N, A1 d; @- k# Auuid也使用Prometheus 数据库根据实例状态查询。
5 L _. O' Z& T- k6 o( d( b! Q3 e其他的数据根据uuid在influxdb的collectd库中查询。 w" L/ I2 q M% U
一致的是，实例名依然只能作为一个展示数据，而不能作为真正变量影响数据展示。 结合了prometheus展示了虚拟机的状态，根据状态查询实例uuid，选择ACTIVE可以避免查询到已经废弃的实例，也可选择SHUTOFF查询已停止运行实例的状态 不好的是也会查到状态是BUILD的实例 不过实例状态查询 重要的就是查询最近一段时间内 活动实例 的状态，因此状态变量选择基本是ACTIVE，只用于筛选出活动的变量即可。
& c3 B! I$ D4 L: S' d2 X( O且BUILD 状态的实例BUILD状态只会存在很短的时间，最终会转化成ACTIVE。 grafana变量设置 host 宿主机名（influxdb）. O) y3 t% N s( p
SHOW TAG VALUES WITH KEY=host instance_status 实例状态（prometheus）& j) T: w* z, o/ P
label_values(openstack_nova_server_status{hypervisor_hostname="$host"}, status) instance_uuid 实例uuid（prometheus）因为此处使用prometheus查询uuid可以根据实例状态查询& `) t! Q; ~# |( i7 V; F! c F
label_values(openstack_nova_server_status{hypervisor_hostname="$host",status="$instance_status"}, uuid) virt_interface 实例虚拟网卡（influxdb） ]' o( k) c8 V7 ?0 ?/ d" }
SHOW TAG VALUES FROM virt_rx,virt_tx WITH KEY=type_instance WHERE instance='$instance_uuid' virt_disk 实例虚拟磁盘（influxdb） H: W4 \. x" a9 M7 f( ]
SHOW TAG VALUES FROM virt_read,virt_write WITH KEY=type_instance WHERE instance='$instance_uuid' instance_name 实例名（prometheus）* s& H/ N- Q9 {& ?" g9 T% o
label_values(openstack_nova_server_status{id="$instance_uuid"}, name)" h! ]$ Y8 I) Z, |3 A
+ v, m9 s, n, Epanel都不用改变。。。。。。 https://download.csdn.net/download/dandanfengyun/15137036 这里有一个问题 不知道理解的对不对。。。' R; ], A7 @* X2 P# u, r
prometheus和collectd都是时序数据库。! g0 J) J4 [0 n4 |( ^2 H
Prometheus记录的实例信息也是按时间存放多个的。（隔一段时间存放当时的实例状态信息） grafana变量也是和时间相关的（也就是grafana变量不仅和其他变量相关，也和时间相关）7 |+ |, u4 ^/ t- w( J4 ]) P( j
也就是说，一个实例的状态信息选择时间段不同，是可能有多个不同的变量的。
" q5 e: c3 x8 W5 z5 u- E, k, C! n如变量为实例运行状态 15分钟前关闭了该实例。假设只有两个实例，一个运行 一个15分钟前关闭。 那么选择5分钟前到现在的时间段，变量就有active和shutoff。active的实例只有一个，shutoff的实例也只有一个。 被删除的实例则没有ACTIVE或SHUT OFF状态，但是prometheus和influxdb中都记录了被删除前虚拟实例的运行状况。 但是当选择30分钟前到现在的时间段，变量就有active和shutoff。shutoff的实例还是只有一个，但是active的实例有两个（这个听起来有点那啥），只要记住 prometheus是时序数据库，不能把该变量当成真正的纯粹记录当前实例状态的布尔值。 30前到15分钟前，该实例是active的，15分钟前到现在，该实例是shutoff的，所以该实例有两个运行状态。。。 问题0 k% z! q$ [( _6 L# b1 L1 d
collectd 无法通过OpenStack获取用户等信息。如果要使用grafana展示可能要通过prometheus。
4 C, A9 \# z" a' T+ o. y. @) vgrafana需要通过prometheus和influxdb两个数据源才能展示实例的状态信息。 collectd也无法收集实例 内空间使用占用情况。
3 t: S2 T6 d* D0 B: X5 o/ j8 W( v0 d |
发表于 2021-7-2 17:00:28