Slide 1

Slide 1 text

自律化した 運用

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

本日のアジェンダ コンテナのモニタリング の仕組み

Slide 4

Slide 4 text

コンテナのモニタリング

Slide 5

Slide 5 text

可観測性 は複雑であるため、クラスタ内の問題の 原因を特定することは困難です。 特定のノードに何か問題があるだけでなく、コンテナイ メージの不具合、 動作の異常、 の接続性 など、その原因は多岐にわたります。 サーバーやアプリに入って調査せずとも、システムの状態を把握すること

Slide 6

Slide 6 text

クラウドネイティブな監視 従来の監視 クラウドネイティブな監視 動的に監視を 運用できることがメリット

Slide 7

Slide 7 text

データを累積すること。一貫 性を有し、それぞれが一つの 論理的計量ユニット、あるい は一定時間内のヒストグラム に表す。 シングルリクエストの範囲内 にて情報処理を行うこと。 いかなるデータも、全てシス テムの単一トランザクションに バンディングされる。 いくつかの離散した(非連続 の)ことがらを、データとして記 述すること。 データ量

Slide 8

Slide 8 text

▶ イベントの集計した結果が時間ととも にどのように変化しているかを示す ▶ よく使われるメトリクスは、 リクエ スト数やリクエストの処理にかかったレ スポンスタイム、リソース使用量など ▶ コンテキストをフィルタリングすることで、 データ量や処理範囲を調整する

Slide 9

Slide 9 text

▶ つのリクエストの範囲で関数呼び出し などの複数のイベントを記録し、ボトル ネックがどこにあるのかを示す スタックトレース ▶プロセスをまたぐものは、分散トレーシ ングと呼ばれる ▶ サンプリングによってデータ量を保ちつ つ、パフォーマンスに及ぼす影響を適正 化する

Slide 10

Slide 10 text

▶ イベントのコンテキストの一部を記録 アクセスログ ▶ 特定のイベントにどのような問題があるのか を正確に特定できる ▶ 収集結果を保存するために大量のストレー ジと帯域が必要になる

Slide 11

Slide 11 text

の ▶ ▶ ▶ が示す に準拠

Slide 12

Slide 12 text

の仕組み

Slide 13

Slide 13 text

とは 型のメトリクス監視 側から各メトリクスを定期的に取得する 監視サーバは監視対象をすべて把握しているため、監視対象から データが取得できなかった場合には異常があると気づくことが容易 多くの を提供 による時系列データ検索 クラウド よりサービスの情報を取得できる 保管済みデータに対して集計クエリを発行できる 社によって開発され、 化されたプロダクト。現在は によってメンテナンスされている。

Slide 14

Slide 14 text

型のメトリクス監視 が監視対象の データを取得 監視対象から監視用データを 送信したい場合は に送信 scrape_configs: - job_name: 'node_exporter' static_configs: - targets: [‘targethost:9100'] を通して データを直接取得

Slide 15

Slide 15 text

$ curl https://[‘target exporter’]/metrics

Slide 16

Slide 16 text

• ごとに つの値を返す • 時間幅に渡るデータをそれぞれ含んで いる時系列の集合 • 単純な浮動小数点数の数値 • 単純な文字列の値 のデータは以下の 種類が規定されている。 ## Match Label {} node_load5{instance=‘XXX.XXX.XXX.XXX‘} 0.25 便利な統計関数がある • • • 期間中の平均値に対する現在値の割合を返す。 • 与えられた の中で、値の変化が何回起 こったかをカウント。 • 与えられた の絶対値を返す。 • 結果を昇順でソートする。 ## 直近1時間のデータを表示する node_load5[1h] ## 直近1時間のデータを表示する node_load5[1h]

Slide 17

Slide 17 text

route: receiver: 'containers_notification' receivers: - name: 'containers_notification' slack_configs: - api_url: '[[YOUR SLACK WEBHOOK]]' channel: '#general' text: "{{ .CommonAnnotations.summary }}" send_resolved: true は、以下を含む受信アラートを管理するコンポーネントです。 •アラートの非通知 •アラートの抑制 •アラートの集約 •アラートの重複排除 グループ化 • 、 、 、 などにアラートを通知

Slide 18

Slide 18 text

の全体像 が監視対象の データを取得 定期的に全ての からリソース情報 を収集。監視したデータは 内 の に保持される。 のメトリクスを可視化するツール 監視対象から監視用データを 送信したい場合は に送信 からのアラートに関する 情報を受け取って通知する

Slide 19

Slide 19 text

いままで人が対応してきた運用を が自律的に行う

Slide 20

Slide 20 text

と によって、 の監視設定、運用を自律化する。

Slide 21

Slide 21 text

展開を定義 します。 は常に と一致するデプロイメン トが実行されていることを確 認します。 を監視す る方法を宣言的に指定しま す。 は、定義に基づい て の 設定を自動的に生成します。 を監視する方 法を宣言的に指定します。 は、定義に基づい て の 設定を自動的に生成します。 展開を定 義します。オペレーターは常 に、 と一致するデプロイ メントが実行されていることを 確認します。 オブジェクトは宣言的に デプロイメントの望ましい状態を記述し、 は によって監視されるターゲットのセットを記述します。 必要な ルー ルファイルを定義します。これ は、 アラートお よび記録ルールを含む インスタンスに よってロードできます。 インスタンス管理 メトリクス取得対象設定 通知ルール設定 インスタンス管理

Slide 22

Slide 22 text

インスタンス管理 の を動的に定義します。 は常に、 に一致する が実行 されていることを確認します。 apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: generation: 2 labels: prometheus: k8s name: k8s namespace: openshift-monitoring spec: nodeSelector: kubernetes.io/os: linux serviceAccountName: prometheus-k8s replicas: 2 listenLocal: true serviceMonitorSelector: {} resources: requests: cpu: 200m memory: 1Gi

Slide 23

Slide 23 text

メトリクス取得対象設定 apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: example-app labels: team: frontend spec: selector: matchLabels: app: example-app endpoints: - port: web を監視する方法を宣言的に指定します。 は、定義に基づいて の 設定を自動的に生成します。

Slide 24

Slide 24 text

の監視とは アプリケーション固有のメトリクス収集 セッション数、リクエストレスポンスタイム、データ容量 オブジェクトのメトリクス収集 数、 のリソース利用量、 のラベル ノードのメトリクス収集 の 、 、 ▶ ▶ ▶ アプリケーションもノードも な設計 全て動的に監視が行われなければいけない。

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

の監視とは アプリケーション固有のメトリクス収集 セッション数、リクエストレスポンスタイム、データ容量 オブジェクトのメトリクス収集 数、 のリソース利用量、 のラベル ノードのメトリクス収集 の 、 、 ▶ ▶ ▶ アプリケーションもノードも な設計 全て動的に監視が行われなければいけない。

Slide 27

Slide 27 text

コンポーネント 説明 スタックの中心的なコンポーネントです。これは、デプロイされたモニタリングコンポーネントおよびリソースを 制御し、それらを最新の状態に保ちます。 および インスタンスを作成し、設定、管理します。また、 ラベルのク エリーに基づいてモニタリングターゲットの設定を自動生成します。 は、システムおよびサービスのモニタリングシステムであり、モニタリングスタックのベースとな ります。 アダプターは、 のクラスターリソースメトリクス を公開し ます。リソースメトリクスは およびメモリーの使用率です。 サービスは、 によって送信されるアラートを処理します。 は、 オブジェクトを が使用できるメトリクスに 変換します。 は、メトリクスを収集するためにすべてのノードにデプロイされるエージェントです。 は、メトリクスの分析および可視化のためのダッシュボードを提供します。モニタリングスタックおよ びダッシュボードと共に提供される インスタンスは読み取り専用です。

Slide 28

Slide 28 text

オブジェクトのメトリクス収集 数、 のリソース利用量、 のラベル ノードのメトリクス収集 の 、 、 ▶ ▶ によって管理された が「 」「 」に接続を行い、 オブジェク ト、ノードのメトリクスを収集する。

Slide 29

Slide 29 text

の設定 内の global: evaluation_interval: 30s scrape_interval: 30s external_labels: prometheus: openshift-monitoring/k8s prometheus_replica: prometheus-k8s-0 rule_files: - /etc/prometheus/rules/prometheus-k8s-rulefiles- 0/*.yaml scrape_configs: - job_name: openshift-apiserver-operator/openshift- apiserver-operator/0 - job_name: openshift-apiserver/openshift-apiserver/0 - job_name: openshift-authentication- operator/authentication-operator/0 - job_name: openshift-authentication/oauth- openshift/0 - job_name: openshift-cloud-credential- operator/cloud-credential-operator/0 … 初期設定の「 」にて が決まっている

Slide 30

Slide 30 text

から取得した オブジェクトのステート情 報は、 の に表示される。

Slide 31

Slide 31 text

「 」は、 固有のオブ ジェクトのメトリクスを取得します。 • • • • • • 例

Slide 32

Slide 32 text

から取得したノードの ステート情報は、 の に表示される。

Slide 33

Slide 33 text

による可視化 で提供される インスタンスは、そのダッシュボードとともに読み取り専用です。 カスタマイズしたい場合は、 が提供するコミュニティ版の を導入してください。 対象外です。

Slide 34

Slide 34 text

作成 apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: volumeClaimTemplate: metadata: name: localpvc spec: storageClassName: local-storage resources: requests: storage: 40Gi $ oc -n openshift-monitoring create configmap cluster-monitoring-config $ oc -n openshift-monitoring edit configmap cluster-monitoring-config の設定は、 を設定する。 data: config.yaml: | : 設定を に で記載 例 のローカル永続ストレージ を要求

Slide 35

Slide 35 text

の 一覧 の によって、 項目ほどのアラート ルールが設定されています。

Slide 36

Slide 36 text

の設定 global: resolve_timeout: 5m route: group_wait: 30s routes: - receiver: watchdog repeat_interval: 5m match: alertname: Watchdog - receiver: team-frontend-page match: severity: critical receivers: - name: default - name: watchdog - name: team-frontend-page pagerduty_configs: - service_key: "your-key" ## Export Secret $ oc -n openshift-monitoring get secret alertmanager- main --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml ## Edit Secret $ vi alertmanager.yaml ## Replace Secret $ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry- run -o=yaml | oc -n openshift-monitoring replace secret --filename=- 継続的に実行される アラートが同梱され ています。 は、 などの通 知プロバイダーに、 アラートの通知を送信 できます。 例 に通知を送信

Slide 37

Slide 37 text

の変更可能な設定例 ・ の指定ノードへの移動 ・ への容認 の割り当て ・永続ストレージの設定 の設定、メトリクスデータの保持期間変更など ・ の設定 の追加など 参照:

Slide 38

Slide 38 text

対象外の操作 ・追加の オブジェクトを に作成する。 ・予期しない オブジェクト、または オブジェクトの作成。 ・ による の を停止する。 ・ を他のリソースで使用。 ・新規 の追加。 ・ のリソース、 インスタンスの変更。 に設定されているルールのカスタマイズは 対象外 クラスタの監視対象は、 に委ねられている

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

の監視とは アプリケーション固有のメトリクス収集 セッション数、リクエストレスポンスタイム、データ容量 オブジェクトのメトリクス収集 数、 のリソース利用量、 のラベル ノードのメトリクス収集 の 、 、 ▶ ▶ ▶ アプリケーションもノードも な設計 全て動的に監視が行われなければいけない。

Slide 41

Slide 41 text

とは異なる を配置し、それに を設定することで、アプリケーションのメ トリクスを収集する。 ただし、アプリケーション用の 用メトリク ス は事前に設定が必要。 アプリケーション固有のメトリクス収集 セッション数、リクエストレスポンスタイム、データ容量 ▶

Slide 42

Slide 42 text

apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | techPreviewUserWorkload: enabled: true $ oc -n openshift-monitoring edit configmap cluster-monitoring-config $ oc -n openshift-user-workload-monitoring get pod NAME READY STATUS RESTARTS AGE prometheus-operator-85bbb7b64d-7jwjd 1/1 Running 0 3m24s prometheus-user-workload-0 5/5 Running 1 3m13s prometheus-user-workload-1 5/5 Running 1 3m13s の から 個別サービスモニタリン グの有効化 とメトリクス取得用 が起動

Slide 43

Slide 43 text

apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: k8s-app: prometheus-example-monitor name: prometheus-example-monitor namespace: ns1 spec: endpoints: - interval: 30s port: web scheme: http selector: matchLabels: app: prometheus-example-app サービスを行っている に を定義することで、アプリケーションモニタリング用のメト リクス設定が行える。

Slide 44

Slide 44 text

# HELP http_requests_total Count of all HTTP requests # TYPE http_requests_total counter http_requests_total{code="200",method="get"} 2 # HELP version Version information about this binary # TYPE version gauge version{version="v0.1.0"} 1 にて参照権限を与えられたメンバーのみが、 からメトリクス情報を参照できる。 の情報

Slide 45

Slide 45 text

の挙動をモニタリング は、 を活用して、システムコールをキャプチャし、アプリケーションの 異常な振る舞いを検出できる仕組み。 ▶ の のプロジェクト ▶ で使用可能な が提供 ▶ オープンソースとして提供 ▶ 社によって商用プロダクトとしても利用可能

Slide 46

Slide 46 text

によるモニタリング は、 のシステムコールの実行を検出してルー ルに基づいて警告できます。 たとえば、 は次のようなコンテナランタイムの操作を 検出できます。 ・コンテナ内でのシェルの実行 ・サーバープロセスが予期しない子プロセスの生成 ・機密ファイル など の読み取り ・非デバイスファイル など への書き込み ・特定バイナリによる、ネットワーク接続の確立 など - rule: Disallowed SSH Connection desc: Detect any new ssh connection to a host other than those in an allowed group of hosts condition: (inbound_outbound) and ssh_port and not allowed_ssh_hosts output: Disallowed SSH Connection (command=%proc.cmdline connection=%fd.name user=%user.name container_id=%container.id image=%container.image.repository) priority: NOTICE tags: [network, mitre_remote_service]

Slide 47

Slide 47 text

をベースに視覚 的に を作成できます。 ランタイムルールは、特定の 、 、 などにフィル ターを適用でき、複数のクラスタ 環境を統合的に管理できます。

Slide 48

Slide 48 text

まとめ

Slide 49

Slide 49 text

いままで人が対応してきた運用を が自律的に行う

Slide 50

Slide 50 text

徹底解説 無料プレゼント 「徹底解説 」 抜粋版 無料プレゼント 以下 より ダウンロードください。

Slide 51

Slide 51 text

No content