Upgrade to Pro — share decks privately, control downloads, hide ads and more …

マルチクラウド、マルチクラスタ構成のk8s環境で監視システムを運用していく話

 マルチクラウド、マルチクラスタ構成のk8s環境で監視システムを運用していく話

GREE Tech Conference 2024で発表された資料です。
https://techcon.gree.jp/2024/session/TrackA-5

gree_tech

October 25, 2024
Tweet

Video

More Decks by gree_tech

Other Decks in Technology

Transcript

  1. Monitoring Unitが提供するコンポーネント • 監視基盤=主にGrafana(OSS/Cloud)/Prometheusを中心としたスタック + 多数の独自コンポーネント • オンプレ / VMベース(EC2

    on AWS) / コンテナベース(EKS/GKE) • AWS環境はSaaSを利用したログ基盤もあわせて提供 • 今回はEKS/GKE環境についてお話します 8
  2. EKS環境のモニタリング構成 • 2015年頃〜のEC2運用で作り込んだ監視用EC2インスタンスを利用 • メトリクスはEBSボリュームで持つ • メトリクスの精度と保持期間 ◦ 15秒精度:70日間 ◦

    1時間精度:400日間 • ログアラートはLambdaを経由してすべてのアラートは共通基盤に集約 • プロダクトごとにPrometheus/GrafanaがありALB+Cognitoで社内の 認証基盤と連携 14
  3. Grafana Cloudの構成 • プロダクトごとにスタックを作成 • 権限や費用の分離 ◦ EntraID + SAMLを利用

    ◦ Viewer/Editorのロール割当 ◦ AdminはGrafanaのorgで管理 ◦ 使い終わったら一式まるごと削除 • スタックの構築はTerraform + 一部手作業 20
  4. Grafana Cloudの管理 • Terraformで管理 ◦ 基本構成 ◦ アラートルール ◦ ダッシュボード

    ◦ サービスアカウント • 手動管理 ◦ スタックごとのSAML構成 ◦ 定期的な証明書更新などが ある 21
  5. ここまでのまとめ • グリーでは少人数のチームで全社向けの監視基盤をメンテしている • オンプレ / AWS / GCPでそれぞれ異なった技術スタックを採用しながら Prometheus/Grafanaエコシステムを利用することで近いユーザー体験を

    提供する • EKSは既存資産を活かすためにEC2運用、GKEは高カーディナリティ メトリクスの安定運用のためGrafanaCloudを選択 • k8s環境(GKE/EKS)ではkube-prometheus-stackをベースとして マニフェストを可能な限り共通化して効率化 • 後半で運用の課題などについてさらにお話していきます 25
  6. monitoring.coreos.com/v1/podmonitor prometheusのスクレイプ設定をk8sリソースの形で簡単に記述することができる 28 apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: apache-exporter

    labels: release: kube-prometheus-stack spec: namespaceSelector: any: true selector: matchExpressions: - key: apache-exporter operator: In values: ['true'] podMetricsEndpoints: - port: web-telemetry path: /metrics - job_name: podMonitor/monitoring/apache-exporter/0 scrape_interval: 15s scrape_timeout: 10s metrics_path: /metrics relabel_configs: - source_labels: [job] separator: ; regex: (.*) target_label: __tmp_prometheus_ job_name replacement: $1 action: replace - source_labels: [__meta_kubernetes_pod_phase] separator: ; regex: (Failed|Succeeded) replacement: $1 action: drop … PodMonitor 生成されるPrometheusのConfig
  7. kustomize/helmを用いてEKS/GKE間の環境の差異を吸収 29 prometheus: enabled: true prometheusSpec: resources: requests: # This

    is minimum resources. # overwrite for each product cpu: 200m memory: 510Mi scrapeInterval: 15s retention: 12h resources: {} remoteRead: [] remoteWrite: [] … prometheus: serviceAccount: name: prometheus annotations: # GCPはWorkloadIdentityの設定が必要 iam.gke.io/gcp-service-account: "[email protected]" … Base Overlay/GKE prometheus: serviceAccount: name: prometheus # AWSは特にannotationsの設定の必要はない … Overlay/EKS
  8. pintのChecks alerts/absent absent()評価の利用に際し、forが正しいか alerts/annotation アラートのannotationが正しく設定されているか alerts/comparison アラートの条件に正しく比較演算子が使われている か alerts/external_lables アラートで参照しているラベルが実在するかどうか

    promql/counter counterタイプのメトリクスが正しく扱われている か promql/range_query 評価している時間範囲が適切かどうか promql/regexp 正規表現にムダや誤りがないか promql/series アラートやルールで利用しているメトリクスが実在す るかどうか query/cost クエリ実行時のコストが許容範囲かどうか rule/dependency 削除したルールに依存した他のルールがないか 35 etc…
  9. pintの実行 - lintモード 36 アラートルールのあるディレクトリを指定すると、自動でパースしてPrometheusにクエリを投げてくれる $ pint -c config.hcl -l

    DEBUG lint /path/to/rules/ … level=INFO msg="Configured new Prometheus server" name=local uris=1 uptime=up tags=[] include=[] exclude=[] level=DEBUG msg="Running prometheus query" uri=http://localhost:9090 query=count(my_metric{environment="production"}) level=DEBUG msg="Parsed response" uri=http://localhost:9090 query=count(my_metric{environment="production"}) series=0 … /path/to/rules/my_alert.yml:10 Bug: `local` Prometheus server at http://localhost:9090 didn't have any series for `my_metric` metric in the last 1w. (promql/series) 10 | expr: sum by (instance_id, instance_type, region) (my_metric{environment="production"}) == 0