ラベル 運用 の投稿を表示しています。 すべての投稿を表示
ラベル 運用 の投稿を表示しています。 すべての投稿を表示

2021年8月17日火曜日

grafanaの通知テスト

課題:
grafanaを介して、CPUの閾値オーバーした場合、Lineに通知されることを検証してみる。


手順:

■アラートの通知を設定

1)ベルのマークを選択 > Nitification chasnnnelsタブからAdd channnelを選択する。








2)Name: line test(適当)

3)Type:   LINE

4)Token: 以下のサイトで発行した物を使用する

https://notify-bot.line.me/ja/


























5)Saveを行う。

以下のように作成できていることが把握できる。


















■ダッシュボードの作成

1)Dashboardを選択





































2)Add new pannelを選択















■ダッシュボードの作成

Metorics: 今回、対象のコンテナのCPU使用率(例:60%)をトリガーに

Lineに通知する実験を行いました。



コンテナのCPU使用率の閾値:

1)Metricsにクエリを挿入する。

1分平均のリクエスト数からどれくらい増えているかというクエリになる。

sum(rate(container_cpu_usage_seconds_total[1m])) by (pod) * 30


2)Applyを押す

->以下のグラフが表示されていることが把握できる。
















■アラートルールの作成


次に上記で作成した閾値に対してのアラート通知を行ってみる

1)Alertタブを選択 > Create Alertを押す。








メモ(アラート通知のフローについて):


アラートまでのフローとして以下になる

グリーン -> オレンジ(Pending) ->レッド(通知を行う)


以下、赤枠の色が変化していくことになる。









2)Evaluate every:1m

->状態変化の判定(間隔)を決める箇所


3)For:2m

->pending判定から2分以上を継続して閾値オーバーになった場合、通知を行う。


4)IS ABOVE: 60

->上記の値を超えると閾値オーバーになる。


5)Send to: line test

->上記で作成したLine通知を指定する


6)Message: お試しに作成してみる。



■実験開始

障害ツール(Gremlin)を使ってCPU使用率を上げてみる


対象:

wordpressのコンテナをターゲットにしている。




以下、Lensというk8sのモニタリングツールを使って

wordpressコンテナのプロセスをみると、gremlinが実行されているのが把握できる。

(CPU使用率も設定した60%になっている)


テスト実施後、pending判定(オレンジ色)になってから赤色のステータス(約2分後)になり

アラートの通知を送信される。



以下、LineCPU閾値オーバーの通知を受信したのを確認できる。



2021年7月7日水曜日

Prometheus&Grafanaの導入(for Raspberry pi)

 現時点で、Prometheus&Grafanaは、ARMベースのCPUで稼働してないので
ソースコードを使って導入を行ってみる。

■go-langの導入
1)go langをインストールする。
apt install golang








2)環境変数を設定する。

# cat >> ~/.bashrc << 'EOF'

> export GOPATH=$HOME/go

> export PATH=$PATH:$GOPATH/bin

> EOF








3)上記で設定内容を反映させる。

source ~/.bashrc





4)kube-state-metricsのARM用のイメージをビルドしている人のソースコードが
あったので使うことにする。

git clone https://github.com/carlosedp/cluster-monitoring



5)read meに記載している内容のい従ってmakeを実施。

make vendor

6)マニフェストを適応させる。

kubectl apply -f ./manifests/setup/

kubectl apply -f ./manifests/


7)以下、各種podが作成されたことが把握できる。

kubectl get pods -n monitoring



prometheusの修正を行う

1)マニュフェストの内容を見直しを行う。

sudo vi manifests/prometheus-service.yaml 

①NodePortを追記

②30909を追記



2)再適用を行う

kubectl apply -f manifests/prometheus-service.yaml 




■grafanaの修正

1)マニュフェストの修正を行う。

sudo vi manifests/grafana-service.yaml 

①NodePortを追記

②30300を追記











































2)再適用を行う。

kubectl apply -f manifests/grafana-service.yaml 



prometheus(2)の編集
1)マニュフェストの内容を見直しを行う。
externalUrl: http://prometheus.192.168.13.10(master nodeのIP).nip.ioに修正
②retention: 5dに修正する。


































2)最適応を行う
kubectl apply -f manifests/prometheus-prometheus.yaml



3)各種ポートが適応できているようだ。







4Grafanaのログインも可能に




5)Prometheusとの連携設定を行う







6)Prometheusを選択
















7)先ほど、Prometheusのマニュフェストで修正したポート(30909)を指定する



8)ダッシュボードの指定:

Prometheus 2.0 Statsを選択




9)以下のサイトを参考に、カスタマイズされた物をインポートする。
(参照先)

https://www.conversion.co.jp/technology/blog/-/detail/=/blog_id=7390284


(Grafana Dashboard)

https://grafana.com/grafana/dashboards


10)以下にて、監視画面の完成になる。



11)リソースメータも表示された



各種podについて

①prometheus-operator-alermanager

Alert Manager 本体


②prometheus-operator

Prometheus Operator 本体


③grafana

Prometheusのメトリクス可視化用のGrafana 本体


④kube-state-metrics

Kubernetes のオブジェクトごとのメトリクス出力用 exporter


⑤prometheus-node-exporter

ノードごとのメトリクス出力用 node exporter


⑥prometheus-operator-prometheus

Prometheus 本体











2020年5月21日木曜日

Chaosエンジニアリング

障害について、避けるもっとも最良な方法は、継続的に障害を起こす事!!
   -> Chaos Monky by ネットフリックス(障害ツール)
         -> わざと障害を起こすツール

メモ:
1)セキュリティモンキー:セキュリティグループの不適切をチェック
2)Chaos Golila: 単位の停止をシュミレート


FIT:Nitflix Techblogより
 ->インフレイヤーを直接扱うツール。
(Netflixのblogチェック)


Chaos Kong:
リージョンを停止をシュミレーションするツール


カオスエンジニア:
本番に置ける不安な状況を耐えることができるという自信を
構築するため実施する実験の規律である

ChAP:

メモ:
Chaos Enginaling  by Netflix(書籍)
Lamdaのchaosテスト(git)もある。


Gremlin inc  (www.gremlin.com
    -> 一連の障害発生ツール(ライブラリ)を提供されている企業。
         ->  テストをしてくれて、問題点をレポートの作成されるらしい。(mmmm….Nice…)

心得:
Chaosテストしよう!!。本番環境で安全に、継続的に!!


ログの設計について

ログの設計:
ログの種類と利用用途を考えること!!
    
ログのレベル:
FATAL / Warning / Info / Debug/ Development /test
用途と緊急度によって適切なログレベルを設定する。

権限:
適切なログなのか

運用について

運用設計:
①CloudWatchをベースにEC2の死活監視やRoute53の外形監視を使ってアラートの設定をして異常を検知する
②使用しているサービスのメトリクスで何を見るのか、何をアラートトリガーにするか決めておく(障害定義)
③アプリ側のメトリクス取得やログの外部出力(S3、CloudWatch Logs)を行うこと
④検知後の一次切り分けや復旧フローを作成する
   ->結構重要!!
⑤実施にフローを流してみる
⑥可能な限り自動化できることを模索すること


バックアップ:
①EC2の場合、AMIから復旧かEBSスナップショットからの復旧をするのか?
②IPアドレスが変更した場合も考慮する
③自動バックアップサービス
- Amazon DLM
- AWS Backup
- Opswitch

復旧計画:
①AZ障害が起こった場合の冗長構成はできているか?
②リージョンレベルでも考慮されているか?
③CloudFormationで、テンプレ化しておくと復旧が楽。
④変更の反映に手間になりすぎない構成にするのがベスト。


アカウント:
①扱うAWS環境が多くなる場合には、環境ごとにAWSアカウント自体を分けたほうが良い
②システム毎に分けるか、ステージ毎(本番・検証・開発)で分けるなど


セキュリティ:
①IAMユーザは、MFAを使う
②コードを扱う端末は全てにgit-secretを導入
③最小権限を意識する
④AWS利用ユーザーの方に、IAMの扱いについて教育する
⑤AWS CloudTrail:ログイン履歴を記録
⑥AWS Config:AWSリソースベースの変更履歴を記録
⑦Amazon GurdDuty:不正な動きを検知・不正なログインやその他脅威を検知する。

S3:
S3のアクセス制御について
①IAMポリシー
②バケットポリシー
③ACL
④パブリックアクセスブロック
⑤IAMユーザ・ロールにアクセス権を与える時はResouceでバケットを最小限に限定する(EC2/Lambdaなど)
⑥パブリックアクセスブロックで外部からのアクセスを多重に防ぐ



ローカルLLMでコーディングさせるポイント

 簡単な指示で、依頼するとコンテキストオーバーで記憶喪失になって コードの内容が一致しないことが起こるので、work.mdみたいな作業メモを取らせたるのがよい 途中から、別スレッドに再実施する場合でも、work.mdが引き継ぎとして 参照して実施してくれるのがポイント