「Prometheus＋Grafana」でのk8s監視 ⼀晩で押さえるKubernetes監視の世界- cndjp第7回勉強会

⾃⼰紹介 n吉村 翔太(yoshimura shota) nNTTコミュニケーションズ所属 nインフラエンジニア/データエンジニアリング nDocker/k8sは４ヶ⽉くらい 他はkafka、hadoop、spark、presto etc n趣味はボードゲーム

チームのインフラに対する要件 • データ分析 チームタスク • チームメンバの分析⽤の基盤 ⽤途 • OSS、コンテナ積極採⽤ ポリシー • オンプレミス 環境

今⽇話すモデル 監視 可視化 通知 管理 Prometheus Grafana Mattermost (Slackクローン) GitLab nOSSでオンプレでも構築可であることを前提に構築

k8s監視に期待すること Must Better n故障が検知できる n故障解析に必要な情報が確保できる n故障検知からサービス復旧までを⾃動化できる

ここでいう監視とは 監視項⽬ 監視⽅法 アプリケーションの監視 リクエスト数、レスポンスタイム etc 対象のソフト毎の固有の情報 サービス監視 httpのリクエストの結果 ログ監視 該当ファイルへの”error”等の⽂字列の有無 プロセス監視 プロセスの有無、プロセスの数 リソース監視 CPU/メモリ使⽤率、ディスクI/O、 ディスク容量、ネットワークトラフィック 死活監視 Pingの応答結果 ハードウェア監視 電源、ファン、温度 etc nコンテナの場合：ログの収集の検討も必要

k8s監視の課題 Pod Pod Pod Service Podへのアクセス nPod⽣成時にIPが振られる n該当Podへのアクセスが保証されない k8s Cluster 困ったこと n今までの監視の仕組みが使えない nk8sに対応した監視ソフトが欲しい

Prometheusとは nk8sと同じCNCFのProject nk8sとの連携機能あり 参考< https://www.cncf.io/projects/ >

今回使った機能 参考< https://github.com/prometheus/prometheus >

Prometheusの構築の要件と実装⽅法 k8s Cluster node node master 監視サーバ federation API Server node n監視サーバはk8s Clusterの外に配置したい nk8sへの外部からのアクセス制御を回避したい

k8sで監視できること(1/2) 上記のexampleを参考に構築すると以下のmetricsが取得可 nkubernetes-apiservers n/metrics nk8s-APIサーバーのステータス nkubernetes-nodes n/api/v1/nodes/${host}/proxy/metrics nノードのメトリクス nkubernetes-cadvisor(v1.12削除予定) n/api/v1/nodes/${host}/proxy/metrics/cadvisor nノードのメトリクス 参考< https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml >

k8sで監視できること(2/2) nkubernetes-service-endpoints n/api/v1/namespaces/${namespace}/services/${service-name}:${service- port}/proxy/metrics nService以下のメトリクスの収集 n「prometheus.io/scrape: “true”」 が付与されているものを⾃動的にスクレイプ nkubernetes-pods napi/v1/namespaces/${namespace}/pods/${pod-name}:${pod-port}/proxy/metrics nPodのメトリクスの収集 n「prometheus.io/scrape: “true”」 が付与されているものを⾃動的にスクレイプ n「prometheus.io/path: /metrics」 や「 prometheus.io/port: “9100”」 を定義可

<参考>実際に取れるメトリクス APIServiceOpenAPIAggregationControllerQueue1_adds counter APIServiceOpenAPIAggregationControllerQueue1_depth gauge APIServiceOpenAPIAggregationControllerQueue1_queue_latency summary APIServiceOpenAPIAggregationControllerQueue1_retries counter APIServiceOpenAPIAggregationControllerQueue1_work_duration summary APIServiceRegistrationController_adds counter APIServiceRegistrationController_depth gauge APIServiceRegistrationController_queue_latency summary APIServiceRegistrationController_retries counter APIServiceRegistrationController_work_duration summary AvailableConditionController_adds counter AvailableConditionController_depth gauge AvailableConditionController_queue_latency summary AvailableConditionController_retries counter AvailableConditionController_work_duration summary DiscoveryController_adds counter ： ： nkubernetes-apiserversだけで99項⽬・・・・多い・・

Node-exporter nやっぱりnode-exporterは欲しい nDeamonSetで配置 nkubernetes-podsがannotationsみて 拾ってくれる!!

Blackbox-exporter nk8sのクラスタ外から監視したい nユーザが使⽤する通信経路と同じとこから監視したい 監視サーバ Blackbox-exporter k8s Cluster HTTP

各アプリケーション毎のExporter nサイドカーで配置 nアプリとexporterの接続性が課題 nアプリの数に合わせてexporterが配置 nkubernetes-podsがannotationsみて 拾ってくれる!! Pod k8s Cluster Logstash exporter Logstash

k8sの基本機能も活⽤ nLiveness n死活監視、プロセス監視相当 n故障検知から復旧までの運⽤を削減 nReadiness nサービス監視相当(LBのヘルスチェックに近い) n故障検知から復旧までの運⽤を削減 nCluster Autoscaler nリソース監視相当 nサーバを追加してクラスタ組み込みを⾃動で n当然クラウドのみ・・

結局こうなる 監視項⽬ 監視⽅法 備考 アプリケーションの監視 kubernetes-pods(k8s) - Apache exporter - Logstash_exporter etc Sidecarで監視 サービス監視 Readiness(ReplicaSet) Blackbox-exporter ログ監視 未検討(課題) ログ収集基盤とセットで 考えたい プロセス監視 Liveness(ReplicaSet) kubernetes-pods(k8s) kubernetes-nodes(k8s) kubernetes-service-endpoints(k8s) 期待するpod数の有無で判定 リソース監視 kubernetes-apiservers(k8s) kubernetes-nodes(k8s) kubernetes-cadvisor(k8s) kubernetes-service-endpoints(k8s) kubernetes-pods(k8s) - Node-exporter(DaemonSet) 死活監視 kubernetes-pods(k8s) - Node-exporter(DaemonSet) 期待するnode数の有無で判定

ログ収集 nコンテナのログをどうにかしたい n公式ドキュメントを参考に案を検討 参考< https://kubernetes.io/docs/concepts/cluster-administration/logging/ >

ログ収集 案1 nログの出⼒先をPV-PVCで外部ストレージをマウント nCronJobでローテート Persistent Volume Claim Persistent Volume ストレージ Pod

ログ収集 案2 nSidecarでLogShipper nk8s外にログ収集基盤を配置してそっちに投げる nログ監視もそっちで⾏う Pod k8s Cluster LogShipper アプリ ログ収集基盤 k8s Cluster外

ログ収集 案2の懸念 n監視も考えるとコンテナ4つ？ nログ収集基盤の信頼性 n⽬的はデータ分析 nk8s基盤構築 nログ収集基盤構築 n運⽤コスト⾼い・・ Pod アプリ LogShipper LogShipper exporter アプリexporter

ログ収集 案3 n標準出⼒に投げて、LogShipper(DaemonSet)が投げる nログ監視もそっちで⾏う n監視含めても1Podに2コンテナで済みそう Pod k8s Cluster アプリ ログ収集基盤 k8s Cluster外 Pod LogShipper log

可視化&通知 nPrometheusと相性のいいGrafanaを採⽤ nGrafanaで検知してMattermostに通知 nQ：PrometeusのAlertmanagerは使わないの？ A：通知のルールと故障を確認するviewが1:1の構成の⽅が 運⽤がシンプルと判断 n公式にk8s⽤のサンプルがあるので使うと幸せ 参考< https://grafana.com/dashboards/315>

イメージ k8sクラスタ

イメージ Logstash

全体のアーキテクチャ k8s Cluster node node master federation API Server node Blackbox-exporter HTTP Node-exporter Node-exporter Node-exporter Node-exporter cAdvisor cAdvisor cAdvisor cAdvisor Sidecarの exporter 監視サーバ 通知 Mattermost Prometheus Grafana

管理 nGit、CIが1個で完結して嬉しいのでGitLabを使⽤ n管理⽬的 n故障情報の蓄積と改善 n情報の共有と可視化によるワンオペの防⽌

やりたいこと 1. Mattermostで気づく 2. GitLabでissueきる 3. kubectlで以下のコマンドを実⾏して確認 1. kubectl get pod 2. kubectl describe pod xxxxxx 3. kubectl logs xxxxxx 4. 解析状況を適宜追記 n“kubectl”使える⼈を絞るなら別の⽅法でログ観れるようにしないと・・ 結局、ログ収集基盤が・・・