Oracle Cloud Hangout Cafe - Observability再入門

Observability再入門 Oracle Cloud Hangout Cafe – Season 4 #6 Yutaka
Ichikawa Solutions Architect Oracle Corporation Japan SEP 08, 2021

2 Copyright © 2021, Oracle and/or its affiliates Profile Name
• Yutaka Ichikawa/市川豊 Belong • Solutions Architect Role • Principal Cloud Solution Engineer SNS • Twitter/GitHub/Qiita:cyberblack28 Blog • https://cyberblack28.hatenablog.com/ Materials • https://speakerdeck.com/cyberblack28/ Community • CloudNative Days Tokyo #cndt • Cloud Native Bright Future #cnbfmeetup Certified • Certified Kubernetes Administrator • Certified Kubernetes Application Developer Publications

3 Copyright © 2021, Oracle and/or its affiliates 本書では、アプリケーションエンジニア、インフラエンジニア、オペレーションエンジニアの方々を対象に、これまでのアプリ
ケーション開発とコンテナアプリケーション開発の違い、コンテナアプリケーション開発に必要となるDocker、 Kubernetesや自動化で必要となるCI/CD、コンテナアプリケーションの運用方法を基本から解説しています。 Dockerコンテナ開発・環境構築の基本 2021/7/27 発売

Observability • そもそも監視って？ • 背景 • What’s Observability ? •
Telemetry Telemetry & Tool • Metrics • Logs • Traces Observability Practice • Istio + Prometheus + Grafana + Kiali + Jaeger + Loki • Oracle’s Observability • 参考資料 4 Copyright © 2021, Oracle and/or its affiliates Agenda

Copyright © 2021, Oracle and/or its affiliates 5 Observability そもそも監視って？
背景 What’s Observability ? Telemetry

7 Copyright © 2021, Oracle and/or its affiliates Observability Monitoring
= 監視、観察して記録するそもそも監視って？

8 Copyright © 2021, Oracle and/or its affiliates Observability 何のために、監視、観察して記録する？
そもそも監視って？

9 Copyright © 2021, Oracle and/or its affiliates Observability •
サービスやアプリケーションの健全性を確認 • 障害やトラブルの原因調査 • キャパシティ分析 • サービス利用者の行動分析技術、運用、ビジネスなどに多岐にわたるそもそも監視って？

10 Copyright © 2021, Oracle and/or its affiliates Observability そもそも監視って？
サービスやシステムを利用するユーザに影響を与えないためユーザ体験を損なわないようにするため

11 Copyright © 2021, Oracle and/or its affiliates サービスやシステムの利用者が、問題なく利用できる、「安定稼働している状態」を維持する！
Observability そもそも監視って？

12 Copyright © 2021, Oracle and/or its affiliates 監視の意義 •
より良い方法で、システムの稼働状況を把握できている状態 • システム運用において、判断に必要となる情報を取得できている状態 • 迅速に障害やトラブルに対応できる状態これまでもこれからも、こうした本質は変わらない Observability そもそも監視って？

14 Copyright © 2021, Oracle and/or its affiliates Observability 背景
これまでのシステム従来のWeb3層モデルのようなシンプルな構成のシステムであれば、比較的容易に障害を調査することが可能。 LB/Web/App/DBなどそれぞれのコンポーネントを追いやすい

分散システム分散システムのような小さなサービスが疎結合するようなシステムでは、構成が複雑となり障害発生個所や原因追求が困難であり、まして人の手で行うことは非現実的。それぞれのコンポーネントを追うのは非現実的

分散システム右図にあるような分散システムでは、大量のサービスが連携して、一つのシステムとして成り立っているため、障害が発生した際の検知など、これまでのように容易にはいかない… 『Adoption of Cloud Native Architecture, Part 2: Stabilization Gaps and Anti-Patterns』 https://www.infoq.com/articles/cloud-native-architecture-adoption-part2/

17 Copyright © 2021, Oracle and/or its affiliates What’s Observability
?

18 Copyright © 2021, Oracle and/or its affiliates Observability What’s
Observability ? Observabilityの意味 Observability might mean different things to different people. 可観測性は、人によって意味が異なる場合があります。『 Distributed Systems Observability』 https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ Observability = 可観測性 Observability（可観測性）は、人によってまたはシステムによって基準、観点、解釈の仕方が違うものなので本セッションの内容も一例と捉えてください。

Observability ? クラウドネイティブにおけるObservability Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。『 CNCF Cloud Native Definition v1.0』 https://github.com/cncf/toc/blob/main/DEFINITION.md クラウドネイティブの文脈では、Observability（可観測性）は、クラウドネイティブなシステムを実現する一要素

Observability ? クラウドネイティブにおけるObservability クラウドネイティブ技術速く、正確に高品質なサービスを提供して、エンドユーザ様の満足度、企業収益、ビジネス価値の向上

Observability ? クラウドネイティブにおけるObservability 提供だけではなく、常にユーザエクスペリエンスを損なうことが無いよう維持、そして、障害やトラブルが発生した場合も速く、正確に対応できる体制も維持する！

Observability ? クラウドネイティブにおけるObservability Kubernetes上のPod(コンテナ)を例に考えてみると、決められたNodeに決められたPod(コンテナ)が稼働するとは限らないため、これまでの監視方法とは違うアプローチが必要となる。 OKE Virtual Machine Virtual Machine Virtual Machine Operator Node状況、Kubernetes Cluster状況（Podなど）、アプリケーション、データベースなど色々ある

Observability ? 結局のところObservabilityとは？ • 人またはシステムによって基準・観点は異なる • クラウドネイティブなシステムを実現するまたは支える一要素 • 従来のシステムとは異なるアプローチが必要（分散システム、コンテナなど） • より良い方法で、システムの稼働状況を把握できている状態 • システム運用において、判断に必要となる情報を取得できている状態 • 迅速に障害やトラブルに対応できる状態この本質も不変！

25 Copyright © 2021, Oracle and/or its affiliates Observability Telemetry
Observabilityを実現する3要素 Metrics Logs Traces Telemetry システムの状態を収集後、付加情報を付与して数値に変換したもの正常・異常動作など、システムにより生成されるテキストデータコンポーネント間を跨ぐイベントまたはトランザクションの因果連鎖の指標 Telemetryの各要素が連携して Observabilityを実現させることが重要

Observabilityを実現する主なツール Metrics Logs Traces Jaeger Zipkin Grafana Loki Prometheus & Grafana EFK この他にもベンダー製品やクラウドベンダーのサービスもあります。 Open Telemetry

Oracle Cloud Observability and Management Platform • KubernetesまたはDockerコンテナに展開されたマイクロサービスからテレメトリを取り込み • 分散トレース向けの OpenTracingおよび OpenMetricsと互換性がある Cloud Native Feature

The CNCF End User Technology Radar The CNCF End User Technology Radarは、CNCFエンドユーザーコミュニティに代わって、クラウドネイティブテクノロジーを評価するためのガイド 1.最も一般的に採用されているツールはオープンソース最も「採用」票を獲得した3つのツール（Prometheus、Grafana、Elastic）と最も合計票を獲得した5つのツール（Prometheus、Grafana、Elastic、Jaeger、 OpenTelemetry）はすべてオープンソースです。 2.可観測性の領域に統合はない多くの企業が複数のツールを使用しています。企業の半数は5つ以上のツールを使用しており、3分の1は10以上のツールを使用した経験があります。 3.PrometheusとGrafanaはほぼ一緒に利用回答者の3分の2は、これら2つのツールを組み合わせて使用しています。これは当然のことですが、高い相関関係は注目に値します。『The CNCF End User Technology Radar Observability, September 2020』 https://radar.cncf.io/2020-09-observability

3要素の調和が重要 Metrics Logs Traces Telemetry Telemetryの各要素が連携して Observabilityを実現させることが重要！！ MetricsからLogsやTraces、 TracesからMetricsやLogsのように、1つの要素から別の要素を見据える！！

Copyright © 2021, Oracle and/or its affiliates 30 Telemetry &
Tool Metrics Logs Tracing

32 Copyright © 2021, Oracle and/or its affiliates Telemetry &
Tool Metrics What’s metrics ? • システムの状態を収集後、付加情報を付与して数値に変換したもの • 監視対象が経時的にどのような変化をするか統計的に予測するもの • Metrics自体では、単なる事実でしかないので、経時的に見て、予測につなげる • Metricsの数値を閾値として、アラート通知につなげる Use of metrics Example of metrics CPU・メモリの使用率リクエスト数ネットワーク通信料

Tool Metrics 収集するメトリクス例メトリクス監視を始める際に、収集するメトリクスを何にすべきか悩む場合の抽象化された例。 1.USE リソースをベースとしたメトリクス収集 Utilization リソースの単位時間あたりの使用率(例:CPU、メモリの使用率等) Saturation リソースの飽和状況(例:実行キューの長さ等) Error エラーイベントのカウント(例:ネットワーク、I/Oのエラーなどをカウント) 2.RED サービスをベースとしたメトリクス収集 Rate(Request) 秒間のリクエスト数 Error 失敗しているリクエスト数 Duration リクエストの処理に要した時間

Tool Metrics 3.The Four Golden Signals 『SREサイトリライアビリティエンジニアリング』で述べられている4大シグナル Latency リクエストを処理するのに要した時間。正常なレスポンスと異常なレスポンスは分けるようにする。 Traffic システムに対するリクエスト量。リクエスト数やネットワークI/O、セッション数など。 Error 処理の失敗。 Saturation サービスが手一杯になっている状態。メモリ、ディスク、CPUやI/Oのなど。 https://www.oreilly.co.jp/books/9784873117911/ 収集するメトリクス例

Tool Metrics Prometheus Prometheusは、Pull型のメトリクス監視システムで、Kubernetesとも親和性が高くサービスディスカバリ機能によって、監視対象を自動的に見つけることが可能主な特徴 • クラスタ全体のリソース監視 • PodごとのCPU、RAM、Network使用量の監視 • ラベルを利用したメトリクス管理 • メトリクス集約に特化した独自のクエリ言語（PromQL）を持つ

Tool Metrics Prometheus Architecture What is Prometheus? | https://prometheus.io/docs/introduction/overview/#architecture Prometheus本体 • 各監視ターゲットからMetrics （メトリクス）を収集 • 収集したMetricsに対してクエリを発行してMetrics情報を参照 • クエリを自動的に内部で定期的に実行してアラートの管理 Service Discovery 監視対象の情報を自動的に取得する仕組みで、監視対象のAPIを利用して、インスタンス情報を収集 Exporter 取得したメトリクスをPrometheus が処理できるフォーマットに変換 Alerting Alertmanagerが通知に特化したコンポーネント PromQL PromQLを利用して、Metricsのラベルによるフィルタリング、集計、アラート実行など幅広く利用できるクエリー言語 Visualization Prometheusにおける可視化、専用のWebUIによるクエリ実行、さらに Grafanaと連携してグラフ化など

Tool Metrics Push型とPull型 PrometheusからExporterという軽量のHTTPサーバにリクエストを送ることで動的に変化する環境監視を可能にする監視対象システムエージェント監視システム監視対象システム Exporter Prometheus Push型 Pull型 HTTP Request HTTP Response

Tool Metrics Pull型における懸念を回避 Prometheusが収集対象のアプリケーションを見つけるために、都度エンドポイントを設定していては運用に影響があるのでは？ Prometheusでは監視対象のリストを動的に更新するサービスディスカバリという仕組みで対応、またDNSの利用やファイルに書かれた対象のリスト、静的に記載した設定なども利用可能監視対象のIPアドレスやポート等を知ることやPodやNodeをスケールする場合はどうなる？

Tool Metrics Exporterについて Exporterは、ターゲットが持つ独自形式のメトリクスをExporterが取得して、Prometheusが処理できるフォーマットに変化する役割を担う Exporter Target ① メトリクスをリクエスト ② メトリクスを収集メトリクスを取得 ③ 取得したメトリクスをPrometheusが処理できるフォーマットに変換 ④ メトリクスのレスポンス

Tool Metrics Exporterについて Podデザインパターンの一つであるアダプタパターンを利用して取得することも可能 Pod MySQL Exporter MySQL 独自の形式でメトリクスを提供 Prometheusが処理できるフォーマットにメトリクスを変換

Tool Metrics Exporterについて Prometheusは、Exporter経由ではなく、アプリケーションにクライアントライブラリを埋め込むことによってアプリケーションから直接メトリクスを取得することもできます。 Application Pod Library

Tool Metrics ラベルによるメトリクス管理 • Prometheusはメトリクスを区別するためにラベルを利用 • PromQLでラベルによる集約対象の絞り込みが可能 • ラベルはメトリクスを出力する際に付与 • サービスディスカバリの結果を付与したり、固定値として設定可能ラベルについてメトリクスはメトリクス名・ラベルとその値・メトリクスの値で構成 http_requests_total {pod=“sample-web-service”, namespace=“default”} 2021 メトリクス名ラベルとその値メトリクスの値

Tool Metrics PromQL PrometheusはPromQLというメトリクス集約に特化したクエリ言語があり、それを使用してメトリクスを集約が可能（例）sample-web-serviceというPodが受けたリクエスト数の10分間の平均を求める場合 rate(http_requests_total{pod=”sample-web-service”}[10m]) PrometheusのWebUIを利用して、フォームに PromQLを入力、実行すると結果を表示可能メトリクス名、ラベルフィルタリング、正規表現フィルタリング、関する利用など可能 ※左画像は、メトリクス名のみの例

Tool Metrics Alertmanager • Alertmanagerは、通知に特化したコンポーネント • 収集したメトリクスにアラートとして発報するルールを設定可能 • ルールをPromQLで設定し、定期的に評価されて、条件を満たすとアラートがAlertmanagerに送信される仕組み • アラートは、メールやSlackなどへ通知可能 • 通知間隔、連続通知抑止、グルーピングなど管理可能 • アラート、通知に関するものはPrometheusでなくAlertmanagerで管理 Alertmanager Others アラート条件の評価、Alertmanagerへの通知アラート通知

Tool Metrics Grafana Grafanaは、Prometheusと連携して監視データを高度に可視化するツールで、Webブラウザでグラフ化されたデータをリアルタイムに確認可能

セキュリティ監査システム安定運用 47 Copyright © 2021, Oracle and/or its affiliates
Telemetry & Tool Logs What’s logs ? 正常・異常動作など、システムにより生成されるテキストデータ、ファイル、標準出力、標準エラー出力として出力されるもの • システム安定運用「いつ、どこで、何が起きた」 • セキュリティ監査「いつ、誰が、何をした」 Use of logs • システムログ • アプリケーションログ Examples of logs • イベントログ • 通信ログ • 監査ログ • 認証ログ

Tool Logs 取得するログの例 Kubernetes • アプリケーションログ ✓ Kubernetesクラスタ上で稼働しているコンテナアプリケーション • システムログ ✓ システムコンポーネント（kube-controller-manager、kubeletなど） ✓ システム準コンポーネント（CoreDNSやCNIなど） ✓ Kubernetes Node • 監査ログ ✓ Kubernetes APIへの接続情報 Kubernetesへの変更はシステムコンポーネントやエコシステムを含めて、すべてAPIサーバを介して行われるので、どのようなユーザがどのようなリクエストを送っているかを記録した監査ログはセキュリティ上重要

Tool Logs ログの取得方法 Kubernetes Logging Architecture | https://kubernetes.io/docs/concepts/cluster-administration/logging/

Tool Logs 1.アプリケーションログ「重要度」、「ログ量」、「整形、フィルタリング有無」などによって、いくつかのパターンでログを取得・送信することが可能 a.DaemonSet Node単位でログを集約して、DaemonSetが一括にログを転送。コンテナランタイムが出力するログファイルのディレクトリを監視して、ラベルなどの情報を付与して転送。 App Node App logs Log Agent DaemonSet Logging Backend • 個別フォーマットに整形不要、多少の遅延が許容できる場合に有効 • DaemonSet Podが他のPodよりも先に削除されると一部のログが欠損する

Tool Logs b.Sidecar アプリケーションコンテナのSidecarとして起動しているログエージェントが転送する。 App Pod Log Agent logs Logging Backend • 汎用的なログエージェントコンテナを作成すれば、他のシステムでもSidecarとして利用できる • ログエージェントコンテナがアプリケーションコンテナよりも先に停止した場合はログが欠損するため、コンテナの停止タイミングに注意する必要がある Sidecar

Tool Logs c.Library アプリケーションからライブラリを利用して直接ログを転送する。 App Pod Logging Backend • アプリケーション側にログ転送先の設定が入ることで結合度が高くなる • ログサービスに対する認証情報をアプリケーション側で持つ必要がある App

Tool Logs 2.システムログ Kubernetesのシステムコンポーネント、準システムコンポーネントは主に以下の方法で稼働しているケースが多いので、それに合わせた方法で取得 • Namespace 「kube-system」上にPodとして稼働 ➢ Podとして起動している場合は、基本的にDaemonSetによるログエージェントで取得 • Node上にsystemdとして稼働 ➢ Node側でログを取得 • ユーザが確認できないブラックボックスで稼働 ➢ マネージドサービスの場合、Control Planeのコンポーネントはユーザからアクセスできないので、サービス提供側が提示する方法で取得

Tool Logs 3.監査ログ • 監査ログは、Kubernetes のシステムコンポーネント（kube-apiserver）に対してどこに出力するかを設定して取得可能 • 監査ログの主な設定 • どのリソースに対する操作の監査 • 「リクエスト受信時」「レスポンス開始時」「レスポンス完了後」「エラー発生後」などのフェーズによる監査 • 「メタデータのみ」「リクエスト」「リクエストとレスポンス」などどの程度情報を記録するか全ての監査ログを取得を試みるとログのデータ量が膨大に増えるので、注意が必要！

Tool Logs 3.監査ログ Auditing | https://kubernetes.io/docs/tasks/debug-application-cluster/audit/

Tool Logs Grafana Loki Grafana Labsが主体となって開発するスケールアウト・高可用性・マルチテナントといった特性を持つのログアグリゲーションシステム主な特徴 • Prometheusのようにラベルでログを絞り込んだり、grepのように文字列を絞り込むことが可能 • 書き込み、読み込み、アラーティング、データ圧縮など複数の役割を持った分散システム構成 • データストレージを持たないので、ローカルまたは外部ストレージと連携 • Grafanaと連携してダッシュボードでのログの可視化や検索可能

Tool Logs Loki Architecture Loki’s Architecture | https://grafana.com/docs/loki/latest/architecture/ Distributor • 受信したログをIngesterへ送信 • Ingesterへのルーティングには、Consistent Hashアルゴリズムの利用、Consulのデータを参照 Ingester • ログをストレージに保存 • Distributorから受信したログのラベルセット/ テナントIDから対応するChunkにログを追加 • 対応するChunkが無い場合は新規作成 Querier • ログの検索処理 • Ingester、Chunkからログを取得 Chunk Store • 内部/外部ストレージ • Indexは、ログ検索のための置換インデックス • Chunkは、実際のログを保存 Query Frontend • 検索結果のキャッシュ • クエリキューイング Ruler • Querierにクエリを発行して、アラート処理 Compactor • Indexデータの圧縮処理 Consul • DistributorがIngesterへ送信する際に参照するストア

Tool Traces What’s traces ? コンポーネント間を跨ぐイベントまたはトランザクションの因果連鎖の指標トレースが必要となる背景分散システム、マイクロサービスにおけるメトリクスとログの限界 • 1リクエストが複数のシステムやサービスを跨ぐ状況がある • リクエストがどのシステムまたはサービスのどのアプリケーションで稼働しているのか不明瞭リクエスト、トランザクションのようなある範囲内のイベントを記録して、追跡を可能にする必要がある！

Tool Traces Trace & Span トレーシング（分散トレーシング）は、TraceとSpanを可視化して、問題個所を特定する A B E C D Trace Span Span Span Span Span 処理A 処理B 処理C 処理D 処理E Request OutPut Traceは、Spanの集合体 Spanは、各サービス内の処理 Request X Start Request X End

Tool Traces Jaeger Jaegerは、分散サービス間のトランザクションをトレースするためのオープンソース・ソフトウェア主な特徴 • クライアント/バックエンドを提供 ✓ クライアント：アプリケーションからSpanを取得して送信 ✓ バックエンド：Spanを受け取り保存 • モダンなWebUI • 高可用性

Tool Traces Jaeger Architecture Architecture | https://grafana.com/docs/loki/latest/architecture/ jaeger-client • OpenTracing標準に準拠した各言語のSDKを実装 • アプリケーションで指定されたサンプリングポリシーに従ってTrace情報をjaeger- agentに送信 jaeger-agent • 受信したTrace情報のSpanをjaeger- collectorへ送信 jaeger-collector • 受信したSpanをストレージへ保存 jaeger-query • 保存されたSpanを取得および可視化 Storage • Cassandra、Elasticsearch、Kafkaによるメッセージングをサポート

Tool Traces トレーシング（分散トレーシング）標準化についてオブザバビリティの多様化に向けた標準化 OpenTracing • トレーシング（分散トレーシング）のためのAPI仕様およびフレームワーク • Jaeger、Zipkinなど様々なバックエンドに対応 • トレーシング（分散トレーシング）において、ベンダーニュートラルな仕様を規定 OpenCensus • トレーシング（分散トレーシング）のためのライブラリ群（多言語に対応） • Jaeger、Zipkinなど様々なバックエンドに対応

Tool Traces トレーシング（分散トレーシング）標準化について OpenTracingとOpenSensusがOpenTelemetryに統合して、トレース、メトリクス、ログのようなテレメトリーデータの作成及び管理するAPI、SKD、ツールを提供する方向へ、そして、基本的にバックエンドは持たない仕様 OpenTelemetry Merging OpenTracing and OpenCensus: Goals and Non-Goals | https://medium.com/opentracing/merging-opentracing-and-opencensus-f0fe9c7ca6f0

Prometheus Virtual Machine Virtual Machine Virtual Machine Node Exporter node exporter Service prometheus Service node-exporterを利用して、各ノードの空きメモリ量、直近5分での各ノードの空きメモリ量、3ノードの空きメモリ量の合計をPromQLで検索

Prometheus node_memory_MemAvailable_bytes 各ノードのメモリの空き容量

Prometheus node_memory_MemAvailable_bytes[3m] 直近3分での各ノードのメモリ空き容量

Prometheus sum without (instance, kubernetes_node) (node_memory_MemAvailable_bytes) 3ノードの空き容量サイズ合計

Prometheus

Loki + Grafana Virtual Machine Virtual Machine Virtual Machine Node Exporter node exporter Service prometheus Service grafana Service loki Service Promtail GrafanaにData SourceとしてLokiの追加とlokiとistiodのログをGrafanaで確認

Loki + Grafana {app=“loki”} Lokiのログを検索ログの詳細を確認

Loki + Grafana {app=“istiod”} Lokiのログを検索ログの詳細を確認

Prometheus + Grafana Virtual Machine Virtual Machine Virtual Machine Node Exporter node exporter Service prometheus Service grafana Service loki Service Promtail Istioのアドンとして、Prometheus、Grafanaがインストールされているので、Istio環境の状況をGrafanaで確認

Prometheus + Grafana Istio Architecture https://istio.io/latest/docs/ops/deployment/architecture/ Istio Control Plane • トラフィックをルーティングするためにプロキシの設定やポリシーを管理する • Control Planeは単一のバイナリ(istiod)として稼働 • Istiodは、Pilot、Cltadel、Galleyの3コンポーネント Istio Data Plane • Proxyが、サービスメッシュ内の全サービスのインバウンド、アウトバンドトラフィックを仲介 • Proxyは、Envoyが利用されているが、仕様を満たしていれば差し替えも可能

Prometheus + Grafana Istio Control Plane DashboardとIstio Performance Dashboardを確認

Istio + BookInfo + Kiali + Jaeger Virtual Machine Virtual Machine Virtual Machine Istio環境上にBookInfoというマイクロサービスアプリケーションを利用して、KialiでTraffic、JaegerでTracingを確認 BookInfo

Istio + BookInfo + Kiali + Jaeger BookInfoは、書籍情報を表示するWebアプリケーション Details と Reviews を呼び出して、フロントーページを生成書評情報を持ち、Ratings を呼び出す V1:Ratings を呼び出さない V2:Ratings を呼び出して、各書評1-5の黒星表示 V3:Ratings を呼び出して、各書評1-5の赤星表示書籍の情報を格納書評に関連するランキング情報を持つ

Istio + BookInfo + Kiali + Jaeger BookInfo

Istio + BookInfo + Kiali + Jaeger 各Traceの発生時刻（横軸）、処理時間（縦軸）各TraceのSpan情報一覧各spanの時系列

Observability Practice Copyright © 2020, Oracle and/or its affiliates |
Confidential: Internal/Restricted/Highly Restricted 83 Oracle’s Observability An Enterprise Container Platform • Intelligent Workload Management Across Environments • Integrated Pre-Wired Observability • Application Lifecycle Management • Integrated Security • Multi-Cluster Infrastructure Management https://verrazzano.io/

Traditional Applications Polyglot Microservices Copyright © 2020, Oracle and/or its
affiliates | Confidential: Internal/Restricted/Highly Restricted 84 Multi-Cluster Infrastructure Management Integrated, Pre-Wired Monitoring Intelligent Workload Management Across Environments Application Lifecycle Management Integrated Security Java Microservices ohere ce Multi-Cloud Kubernetes Public Cloud Kubernetes Private Cloud Kubernetes An Enterprise Container Platform

85 Copyright © 2021, Oracle and/or its affiliates Verrazzano Enterprise
Container Platform Observability Practice Oracle’s Observability Verrazzano in a Multicluster Environment https://verrazzano.io/docs/applications/multicluster/ Verrazzano Admin Cluster • Admin ClusterにあるVerazzano Operatorと各 Managed ClusterにあるVerrazzano Operatorが連携 • Verrazzano Enterprise Container Platformで利用できるOSSで、各Managed Clusterを管理可能 • Verrazzano Enterprise Container Platformで利用できるOSSについては、Oracleで有償サポート

87 Copyright © 2021, Oracle and/or its affiliates 参考資料 Observabilityをはじめよう！(前編)
〜Observabilityの背景と構成要素〜 https://knowledge.sakura.ad.jp/26395/ Observabilityをはじめよう！(後編) 〜Metrics/Logs/Tracesチュートリアル〜 https://knowledge.sakura.ad.jp/26409/ 今日から始めるPrometheusによるシステム監視(1) 〜Prometheusの特徴とアーキテクチャ〜 https://knowledge.sakura.ad.jp/27501/ 最短で理解して運用するGrafana Loki https://zenn.dev/taisho6339/articles/0654040691aaab クラウドネイティブ時代の分散トレーシング Distributed Tracing in a Cloud Native Age https://eventmarketing.blob.core.windows.net/decode2019-after/decode19_PDF_DT81.pdf Prometheus https://prometheus.io/ Grafana https://grafana.com/ Jaeger https://www.jaegertracing.io/ デモで利用した資材 https://github.com/oracle-japan/ochacafe-s4-6

Oracle Cloud Hangout Cafe - Observability再入門

Oracle Cloud Hangout Cafe - Observability再入門

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript