[lv4] ft_services(7/6) grafana視覚化 + レビュートラブルシュート
<- 前(6/6): telegraf -> influxdb -> grafana連携実装
9. ftps作る
(10. ftpsを永続ボリューム化)
11. grafanaの起動
12. influxdb -> grafana連携
13. telegraf -> influxDB連携
14. grafanaカスタマイズ
15. grafanaのprovisioning
16. livenessprobe
telefraf -> influxDB -> grafanaができているか確認します
sh ./run.sh
https://192.168.10.10:3000/
ログイン：admin / admin
【Datasources作成】
1. [画面左の歯車] -> [Datasourses] -> [Add data source] -> [influxDB]
2. 3点埋め
Name: ftps ( default を解除します）
URL: http://influxdb:8086
Database: ftps # influxdbのdatabase名と合わせます。
-> [Save & Test]
> Data source is workingData source登録完了です。
【Dashboard作成】
3. [画面左の+] -> [Create Dashboard] -> [Add new panel]
情報量増えて目移りするかもしれません。データ表示までの操作。
4.
【datasource設定】
Queryタブの下、[datasource] : ftps
[FROM]: default, cpu
[SELECT]: field(usage_user)
【画面右設定】
[Settings] -> [Panel title]: ftps_cpu
[Visualization]: 任意
画面右上[Apply] -> 完了
15. grafanaのprovisioning
grafana設定は、podを消すごとに削除されてしまいます。
あらかじめ設定ファイルを用意しておくことで、grafana起動時に作成することも可能です。せっかくなので実装します。
(ref)GrafanaのDashboard等をファイルで管理する
/srcs/grafana/dashboards/dashboards.yaml
# official doc
# https://qiita.com/chroju/items/f7df76c2cd11b935a0a5
apiVersion: 1
providers:
- name: 'ft_services'
orgId: 1
folder: ''
type: file
disableDeletion: true
editable: true
options:
path: /grafana/conf/provisioning/dashboards/srcs/grafana/dashboards/ftps.json
grafanaから取得します。
出力したい画面を作成したら。
画面上[Share アイコン] -> [Exportタブ] -> [View JSON] -> [Copy to Clipboard]
コピーしたら、
/srcs/grafana/dashboards/ftps.json 保存。
/srcs/grafana/datasources/datasources.yaml
# GrafanaのDashboard等をファイルで管理する
# https://qiita.com/chroju/items/f7df76c2cd11b935a0a5
apiVersion: 1
datasources:
- name: ftps
type: influxdb
access: proxy
orgId: 1
url: http://influxdb:8086
database: ftps
editable: true # GUI edit
version: 1/srcs/grafana/Dockerfile
# add COPYs
COPY dashboards /grafana/conf/provisioning/dashboards
COPY datasources /grafana/conf/provisioning/datasources再起動して、provisioningされるか確認します。
sh run.sh
https://192.168.10.10:3000
➜ kubectl get po
NAME READY STATUS RESTARTS AGE
ftps-85569b47c6-7ldz4 1/1 Running 0 83s
grafana-cc46f6d9c-pjwjb 1/1 Running 0 80s
influxdb-fdb98d47b-gw9bc 1/1 Running 0 78s
mysql-66f676bdb8-jjvdr 1/1 Running 0 87s
nginx-metallb-5656cd6d78-qrjcp 1/1 Running 0 92s
phpmyadmin-6ccbb54945-wxhzl 1/1 Running 0 91s
wordpress-84dcf6c85-pwl96 1/1 Running 3 85s
[login] admin / admin
[左の歯車アイコン] -> [Data sources] -> ftps exist
[左の□□アイコン: dashboards] -> [Manage] -> Dashboardにアクセス復元されていれば成功です。
その他6アプリケーションについても、
・telegraf.conf の設置
・/srcs/grafana/dashboards/***.json の設置
・/srcs/grafana/datasources/datasources.yaml に追記
・各種Dockerfileに追記
・各種start.shに追記
を行います。
/srcs/grafana/datasources/datasources.yaml
--------------datasource単位で設置------------------
- name: ftps
type: influxdb
access: proxy
orgId: 1
url: http://influxdb:8086
database: ftps
editable: true # GUI edit
version: 1
--------------datasource単位で増設------------------
- name: grafana
type: influxdb
access: proxy
orgId: 1
url: http://influxdb:8086
database: grafana
editable: true # GUI edit
version: 1
...16. livenessprobe
A. deploymentの仕事はポッドの管理。ダメなポッドを殺して、新しいポッドを立ち上げ、replicasで指定の数に合わせてくれます。
ですが万能ではなくて、ポッドの中で不調が発生した場合までは探知できないようです。
例えば、ポッドの中のプロセスをkillしたり、ポッドの中のコンテナが停止してしまった場合、ポッドはエラーを返さないため、不具合が継続してしまいます。
その場合、ポッドがコンテナを管理できるようです。
livenessprobeは、ポッドの管理設定です。
永続ボリューム以外のすべてのyamlに同じ追記をしますが、ftpsで実装します。
/srcs/ftps/ftps.yaml
containers:
- image: myftps
imagePullPolicy: Never
name: ftps
---------------livenessprove追記----------------------
livenessProbe:
exec:
command: ["sh", "./livenessprobe.sh"]
initialDelaySeconds: 30 # コンテナ起動してから確認を開始するまで
timeoutSeconds: 10
periodSeconds: 30
-------------------------------------------------
ports:
- containerPort: 20
name: ftps-datapathQ. 設定？
A.
initialDelaySeconds :
コンテナが開始してからProbeを行うまでの初期遅延を秒単位で指定する。
timeoutSeconds :
Probeのタイムアウトを秒単位で指定する。デフォルトは1秒だ。
periodSeconds :
Probeの間隔を秒単位で指定する。デフォルトは10秒で最小の値は1秒だ。
successThreshold :
Probeが成功したと判断する最小回数を指定。デフォルトは1回だ。
failureThreshold :
Probeが失敗したと判断する最小回数を指定。デフォルトは3回だ。
VMとても重いので、特にtimeoutsecondsは長く設定するのがよさそうです。（1敗）
デフォルトの1秒だと失敗しすぎて最悪落ちます。10秒でいいです。
/srcs/ftps/livenessprobe.sh
# ➜ work git:(master) ✗ kubectl exec deploy/nginx -- pkill nginx
# ➜ work git:(master) ✗ kubectl exec deploy/nginx -- pgrep nginx
# command terminated with exit code 1
pgrep vsftpd
health=$?
if [ $health -ne 0 ]; then
return 1
fi
pgrep telegraf
health=$?
if [ $health -ne 0 ]; then
return 1
fiQ. pgrep?
A. プロセスが存在するか確認できます。存在しなければ、エラーメッセージと戻り値1が返ってくるようです。
A. ftpsのstart.shで起動しているプログラム、すべてについて健康状態をチェックするように実装します。
/srcs/ftps/Dockerfile
# COPY追記
COPY livenessprobe.sh /livenessprobe.sh再起動し、動作確認。
sh run.sh
➜ kubectl get po
NAME READY STATUS RESTARTS AGE
ftps-5778cf88c5-8wk2h 1/1 Running 0 38s
grafana-cc46f6d9c-xkz6l 1/1 Running 0 34s
influxdb-fdb98d47b-n2dsw 1/1 Running 0 32s
mysql-66f676bdb8-dcc58 1/1 Running 0 42s
nginx-metallb-5656cd6d78-n8mrw 1/1 Running 0 48s
phpmyadmin-6ccbb54945-x7pfm 1/1 Running 0 46s
wordpress-84dcf6c85-jthsk 1/1 Running 0 40s
➜ kubectl exec deploy/ftps -- ps
PID USER TIME COMMAND
1 root 0:00 {start.sh} /bin/sh /start.sh
7 root 0:00 telegraf -config /etc/telegraf.conf
8 root 0:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
43 root 0:00 ps
# telegraf と vsftpdが生きているのがわかるので、殺します。
➜ kubectl exec deploy/ftps -- pkill telegraf
➜ kubectl exec deploy/ftps -- ps
PID USER TIME COMMAND
1 root 0:00 {start.sh} /bin/sh /start.sh
8 root 0:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
69 root 0:00 ps
# PID:7 が死にました。
➜ kubectl get po
NAME READY STATUS RESTARTS AGE
ftps-5778cf88c5-8wk2h 1/1 Running 1 4m57s
# podのNAMEは変わらず、RESTARTSが増えているのがわかります。
# podがプロセスの死を探知して、コンテナ再起動しました。
➜ kubectl exec deploy/ftps -- ps
PID USER TIME COMMAND
1 root 0:00 {start.sh} /bin/sh /start.sh
7 root 0:00 telegraf -config /etc/telegraf.conf
8 root 0:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
25 root 0:00 ps
# telegrafよみがえりました。成功です。これらを、
・/srcs/***/ftps.yaml
・/srcs/***/livenessprobe.sh
・/srcs/***/Dockerfile
に適応させます。
すべて終了させる場合。
・ローカルの永続ボリューム(/dafa)が残っているので、不要なら消します。
・imageが大量にあり、容量を食うので、不要なら消します。
/shutdown.sh
kubectl delete -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl delete -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
kubectl delete -f srcs/metallb/metallb-config.yaml
kubectl delete -f srcs/nginx/nginx.yaml
kubectl delete -f srcs/mysql/mysql.yaml
# kubectl delete -f srcs/mysql/mysql-pv.yaml
kubectl delete -f srcs/phpmyadmin/phpmyadmin.yaml
kubectl delete -f srcs/wordpress/wordpress.yaml
kubectl delete -f srcs/ftps/ftps.yaml
# kubectl delete -f srcs/ftps/ftps-pv.yaml
kubectl delete -f srcs/grafana/grafana.yaml
kubectl delete -f srcs/influxdb/influxdb.yaml
# kubectl delete -f srcs/influxdb/influxdb-pv.yaml
minikube delete
# image全削除
docker ps -aq | xargs docker stop
docker ps -aq | xargs docker rm
docker images -aq | xargs docker rmi
# https://qiita.com/Ikumi/items/b319a12d7e2c9f7b904d
docker volume rm "$(docker volume ls -qf dangling=true)"
# pvのhostpath消す
sudo rm -rf /data
# 確認
docker images
docker ps
docker volume ls
ls /dataQ. -pvのdeleteは？
A. 頻繁に処理が止まるので外しました…。8時間動かないこともあります。なぜでしょう。
イメージおよびコンテナをすべて削除できているのでよしとしています。
./setup.sh 追記
# install
sudo apt-get install lftp
sudo apt install conntrack
sudo dpkg -r --force-depends golang-docker-credential-helpersQ. conntrack?
A. minikube start --vm-driver=none
で必要。
Q. dpkg?
A. パッケージのアンインストール。docker buildでSIGABRTが出るため。以下対応。
https://github.com/docker/docker-credential-helpers/issues/103
Q. 相手の環境でminikube startがこける
A. レビュワー環境にもともとある/.minikubeの設定がバッティングしてしまっているかも。削除後うまく動作しました。
cd ~
sudo rm -rf .minikube
sudo rm -rf .kubeQ. レビュワーとversionがあわない
・kubectl version
・kubectl minikube
で確認できます。
A. paste binの再実行で最新版になります。
https://pastebin.com/4HnnSUpe?
Q. livenessprobeを殺したい
A.
// 1回目
kubectl exec deploy/ftps -- pkill telegraf
kubectl exec deploy/influxdb -- pkill telegraf
kubectl exec deploy/grafana -- pkill telegraf
kubectl exec deploy/mysql -- pkill telegraf
kubectl exec deploy/nginx -- pkill telegraf
kubectl exec deploy/phpmyadmin -- pkill telegraf
kubectl exec deploy/wordpress -- pkill telegraf
// 2回目
kubectl exec deploy/ftps -- pkill vsftpd
kubectl exec deploy/influxdb -- pkill influxd
kubectl exec deploy/grafana -- pkill grafana-server
kubectl exec deploy/mysql -- pkill mysql
kubectl exec deploy/nginx -- pkill nginx
kubectl exec deploy/phpmyadmin -- pkill nginx
kubectl exec deploy/wordpress -- pkill nginx
// 3回目
kubectl exec deploy/phpmyadmin -- pkill php-fpm7
kubectl exec deploy/wordpress -- pkill php-fpm7sh ./shutdown.sh
この記事が気に入ったらサポートをしてみませんか？