Slide 1

Slide 1 text

© 2024 SPLUNK LLC Kubernetes環境の オブザーバビリティの 次の一歩を OpenTelemetryで実現すると 何がどうなるの? CloudNative Days Winter 2024 Track C 2024/11/28 14:20-15:00

Slide 2

Slide 2 text

Forward- looking statements © 2024 SPLUNK LLC This presentation may contain forward-looking statements that are subject to the safe harbors created under the Securities Act of 1933, as amended, and the Securities Exchange Act of 1934, as amended. All statements other than statements of historical facts are statements that could be deemed forward-looking statements. These statements are based on current expectations, estimates, forecasts, and projections about the industries in which we operate and the beliefs and assumptions of our management based on the information currently available to us. Words such as “expects,” “anticipates,” “targets,” “goals,” “projects,” “intends,” “plans,” “believes,” “momentum,” “seeks,” “estimates,” “continues,” “endeavors,” “strives,” “may,” variations of such words, and similar expressions are intended to identify such forward-looking statements. In addition, any statements that refer to (1) our goals, commitments, and programs; (2) our business plans, initiatives, and objectives; and (3) our assumptions and expectations, including our expectations regarding our financial performance, products, technology, strategy, customers, markets, acquisitions and investments are forward-looking statements. These forward-looking statements are not guarantees of future performance and involve significant risks, uncertainties and other factors that may cause our actual results, performance or achievements to be materially different from results, performance or achievements expressed or implied by the forward-looking statements contained in this presentation. Readers are cautioned that these forward-looking statements are only predictions and are subject to risks, uncertainties, and assumptions that are difficult to predict, including those identified in the “Risk Factors” section of Cisco’s most recent report on Form 10-Q filed on February 20, 2024 and its most recent report on Form 10-K filed on September 7, 2023, as well as the “Risk Factors” section of Splunk’s most recent report on Form 10-Q filed with the SEC on November 28, 2023. The forward-looking statements made in this presentation are made as of the time and date of this presentation. If reviewed after the initial presentation, even if made available by Cisco or Splunk, on Cisco or Splunk’s website or otherwise, it may not contain current or accurate information. Cisco and Splunk undertake no obligation to revise or update any forward-looking statements for any reason, except as required by law. In addition, any information about new products, features, functionality or our roadmap outlines our general product direction and is subject to change at any time without notice. It is for informational purposes only and shall not be incorporated into any contract or other commitment or be relied upon in making a purchasing decision. We undertake no commitment, promise or obligation either to develop the features or functionalities described, in beta or in preview (used interchangeably), or to include any such feature or functionality in a future release. The development, release, and timing of any features or functionality described for our products remains at our sole discretion. Splunk, Splunk> and Turn Data Into Doing are trademarks and registered trademarks of Splunk LLC in the United States and other countries. All other brand names, product names or trademarks belong to their respective owners. © 2024 Splunk LLC. All rights reserved.

Slide 3

Slide 3 text

© 2024 SPLUNK LLC Kazunori Otani Senior Solutions Architect, Observability @katzchang オブザーバビリティ・エンジニアリング共訳 @open-telemetry/docs-ja-approvers OpenTelemetry Meetup

Slide 4

Slide 4 text

© 2024 SPLUNK LLC https://www.oreilly.co.jp/books/9784814400126/

Slide 5

Slide 5 text

© 2024 SPLUNK LLC OpenTelemetry Meetupは11/20開催でした https://www.youtube.com/live/hwlF8X2NrFQ

Slide 6

Slide 6 text

© 2024 SPLUNK LLC Kubernetes環 境のオブザーバ ビリティの次の一 歩を OpenTelemetry で実現すると何が どうなるの? 本セッションでは、KubernetesやPrometheusに詳しいプラットフォームエンジ ニア向けに、オブザーバビリティの次のステージを実現するための OpenTelemetry活用法を解説します。Kubernetes環境における実践例を通じ て、メトリクスやトレースの統合による運用効率向上と、リアルタイムな可視化の 価値を探ります。また、Splunk Observability製品との連携 によって得られる 効果的なモニタリングと課題解決のアプローチもご紹介します。 もくじ: 1. なぜOpenTelemetryなのか? 2. OpenTelemetryを使い始めるには 3. 集まったデータをどう利用するか: Splunk Observabilityの例 お持ち帰りいただくもの : ● 既存のモニタリング環境をより良くするためのアイデアを学ぶ ● 運用しているKubernetes環境にOpenTelemetryの導入を進めるための方 法を学ぶ ● Splunk Observabilityという選択肢を持っていただく 本日の内容

Slide 7

Slide 7 text

© 2024 SPLUNK LLC なぜ OpenTelemetry なのか

Slide 8

Slide 8 text

© 2024 SPLUNK LLC ある日のこと・・・ 1. 同時に複数のアラート がなりました 2. 何が起こっているか、最初の対策を知りたいが、同時にア ラートがなっているので、何を戻せばいいか、何を再起動す ればいいのかわからない 3. ログを調べよう!エラーログは見えるが、そのエラーがどう いう処理を起点に発生したかわからない 、そもそもこのエ ラーは通常時はどうなんだっけ... 4. 調べてるうちになんと現象が収まった 5. 再現待ち...(1に戻る) あなたはオンコール担当としてアラートに備えています

Slide 9

Slide 9 text

© 2024 SPLUNK LLC 今までのシステムとそのモニタリング ● 3層アーキテクチャー: ○ プレゼンテーション、ウェブサーバー、アプリサーバー、RDB ● ある程度の数の、同じ構成のVM ● 監視のポイント : 数箇所 ○ 計算機リソース: CPU, Memory, Network, Disk ○ アプリケーション: ポートの死活監視, REDメトリクス ○ RDB: 接続状況, クエリ処理 ○ 何かあればログを調査

Slide 10

Slide 10 text

© 2024 SPLUNK LLC 現代的なシステムとそのモニタリング ● 複数のマイクロサービス, 複数のDB, 外部サービスへの依存 ● コンテナ環境(Kubernetesのノードとポッド、コンテナ) ● 監視のポイント : マイクロサービス x ポッドで増える ○ 計算機リソース: CPU, Memory, Network, Disk ○ アプリケーション: ポートの死活監視, REDメトリクス ○ データベース: 接続状況, クエリ処理 ■ 違うアーキテクチャーのDBが複数稼働 ○ ログも増える

Slide 11

Slide 11 text

© 2024 SPLUNK LLC どこで何が起こっているのか、よくわからない ● ポッドは頻繁に入れ替わる(そうじゃないとマイクロサービス化の恩恵を受けていない) ● とにかく色々頻繁に変更される(基盤、アプリケーション) ● マイクロサービスは管理不可能になるまで増殖 する(パーキンソンの法則的な) 👉 現在の状態を把握することは困難 結果として: ● 対策が取れないのでトラブルを繰り返す ● システムやチームに対する信頼性を失う

Slide 12

Slide 12 text

© 2024 SPLUNK LLC どう解決しますか? ● メトリクスの計測を増やす : URLパス単位, クエリ単位, … ○ カーディナリティが爆発する ○ メトリクスの生成、転送、取り込み、可視化の負荷が増える ○ どんなメトリクスを見るべきかわからない、そもそもどんなメ トリクスがあるかわからない ○ 機械的な相関分析を導入したくなる ■ 管理コストが増える ■ 関連はわかるが、因果関係はわからない ● ログの分析を増やす ○ ログ量が増えて生成、転送、取り込み、可視化の負荷が増 える ○ 前後関係がわからないので因果関係がわからない ○ そのためにログを標準化 して「トランザクションID」のような ものを導入したくなるが、仕様の策定や実装の手間がかか る

Slide 13

Slide 13 text

© 2024 SPLUNK LLC 従来のツールスタックの課題 ● メトリクス中心 の監視: ○ 因果関係がわからない ○ カーディナリティの制御が難しい ● ログ中心の監視: ○ エラー発生時にログを一つひとつ確認するのは非効率 ○ 分散トランザクションの途中で発生した問題の特定が困難

Slide 14

Slide 14 text

© 2024 SPLUNK LLC なぜOpenTelemetryが必要とされたのか? ● 標準化されたトレースによる分散システム全体の可視化 ○ リクエストがどのサービスを通過し、どこで失敗したのかを明確化 ○ トランザクションIDのような独自実装を不要にする ○ トレースは「標準化・構造化されたログである」 「トレース、メトリクス、ログ、プロファイリング、あらゆるテレメトリーのあらゆる 形態を相関させる」 https://www.amazon.co.jp/dp/4814401027 https://learning.oreilly.com/library/view/learning-opentelemetry/9781098147174/

Slide 15

Slide 15 text

© 2024 SPLUNK LLC OpenTelemetry https://opentelemetry.io/ja/ ● OpenTelemetry は API、SDK、 ツールのコレクション です。 テレメト リーデータ(メトリクス、ログ、トレース) の計装、生成、収集、エクスポート に 使用し、ソフトウェアのパフォーマン スや動作の分析 に役立てましょう。 ● CNCF (Cloud Native Computing Foundation) incubating project ○ 「2番目に活発」

Slide 16

Slide 16 text

© 2024 SPLUNK LLC インフラ環境(オンプレ /クラウド) オブザーバビリティのためのアーキテクチャ サーバー サーバー サーバー/VM コンテナ環境 コンテナ環境 コンテナ マネージドサービ ス マネージドサービ ス マネージド サービス テレメトリー転 送 パイプライン テレメトリー分析 バックエンド ① テレメトリーの作成(計装)と転送 ② 分析 トレース/メトリクス/ログ/プロファイルなど

Slide 17

Slide 17 text

© 2024 SPLUNK LLC OpenTelemetryを 使い始めるには

Slide 18

Slide 18 text

© 2024 SPLUNK LLC インフラ環境(オンプレ /クラウド) オブザーバビリティのためのアーキテクチャ サーバー サーバー サーバー/VM コンテナ環境 コンテナ環境 コンテナ マネージドサービ ス マネージドサービ ス マネージド サービス テレメトリー転 送 パイプライン テレメトリー分析 バックエンド ① テレメトリーの作成(計装)と転送 ② 分析 トレース/メトリクス/ログ/プロファイルなど

Slide 19

Slide 19 text

© 2024 SPLUNK LLC 導入のステップ( 1つの例) 1. OpenTelemetry Collectorをインストールする 2. トレース: アプリケーションにSDKをセットアップする 3. メトリクス: Prometheusメトリクスをスクレイプする 4. ログ: アプリケーションログにトレースコンテキストを埋め込む

Slide 20

Slide 20 text

© 2024 SPLUNK LLC OpenTelemetry Collectorをインストールする helm repo add splunk-otel-collector-chart \ https://signalfx.github.io/splunk-otel-collector-chart helm install my-splunk-otel-collector \ --set="splunkObservability.realm=us0,splunkObservability.accessToken=xxxxxx,clusterName=my-cluster" \ splunk-otel-collector-chart/splunk-otel-collector helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts helm install my-opentelemetry-collector open-telemetry/opentelemetry-collector \ --set image.repository="otel/opentelemetry-collector-k8s" \ --set mode= \ Upstream Splunk Distro

Slide 21

Slide 21 text

© 2024 SPLUNK LLC トレース: アプリケーションに SDKをセットアップする # Install the Splunk Java Agent ADD https://github.com/signalfx/splunk-o tel-java/releases/latest/download/sp lunk-otel-javaagent.jar /splunk-otel-javaagent.jar # Set appropriate permissions RUN chmod -R go+r /splunk-otel-javaagent.jar containers: - name: myapp env: - name: SPLUNK_OTEL_AGENT valueFrom: fieldRef: fieldPath: status.hostIP - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://$(SPLUNK_OTEL_AGENT):4318" - name: OTEL_SERVICE_NAME value: "dreamcast" - name: OTEL_RESOURCE_ATTRIBUTES value: "deployment.environment=cndw2024,service.version=2024" command: - java - -javaagent:/splunk-otel-javaagent.jar - -Dsplunk.profiler.enabled=true - -Dsplunk.profiler.memory.enabled=true - -jar - myapp.jar 1. Dockerfileに記 述を追加して... 2. deploymentに 記述を追加する

Slide 22

Slide 22 text

© 2024 SPLUNK LLC メトリクス : Prometheusメトリクスをスクレイプする ● PrometheusのメトリクスをOTel Collectorでそのまま取り込める ● 既存のPrometheusダッシュボードやアラート設定を維持しつつ、トレー スやログの追加が可能 ● Receiver Creator: prometheus.io アノテーション があるポッドや サービスを見つけて、Prometheus Receiverを作る 実はもう出来ています

Slide 23

Slide 23 text

© 2024 SPLUNK LLC Prometheus Receiver, Receiver Creatorは何をしているか? receiver_creator: watch_observers: [k8s_observer] receivers: prometheus_simple: # Enable prometheus scraping for pods with standard prometheus annotations rule: type == "pod" && annotations["prometheus.io/scrape"] == "true" config: metrics_path: '`"prometheus.io/path" in annotations ? annotations["prometheus.io/path"] : "/metrics"`' endpoint: '`endpoint`:`"prometheus.io/port" in annotations ? annotations["prometheus.io/port"] : 9090`' https://github.com/signalfx/splunk-otel-collector-chart/blob/main/helm-charts/splunk-otel-collector/templates/config/_otel-agent.tpl 条件に合致するときに、 Collectorのレシーバーの コンポーネントインスタンスを作る prometheus.io/scrapeアノテーションがある ポッドを対象する

Slide 24

Slide 24 text

© 2024 SPLUNK LLC ログ: アプリケーションログにトレースコンテキストを埋め込む 実はもう出来ているかも %d{yyyy-MM-dd HH:mm:ss} - %logger{36} - %msg trace_id=%X{trace_id} span_id=%X{span_id} service=%X{service.name}, env=%X{deployment.environment} trace_flags=%X{trace_flags} %n LogBackの例

Slide 25

Slide 25 text

© 2024 SPLUNK LLC OpenTelemetryによるテレメトリーデータの統合と最適化 ● リソース属性の標準化: ○ Kubernetesのポッド名、ノード名、クラスタ名を簡単に追跡 する ● トレース・メトリクス・ログの関連付け: ○ メトリクスで検知し、トレースで原因を特定 、ログでさらに調査 する ● テレメトリーデータの利用を最適化することで、コストを制御 する ○ さらに: サンプリングやフィルタリングを活用したデータ量をコントロール

Slide 26

Slide 26 text

© 2024 SPLUNK LLC 集まったデータを どう利用するか : Splunk Observabilityの 例

Slide 27

Slide 27 text

© 2024 SPLUNK LLC Splunk Observability APM アプリケーション監視 RUM 実ユーザのUX監視 Splunk Cloud/Enterprise Log Observer Connect ログ監視・調査 Infrastructure Monitoring インフラ監視 Synthetic Monitoring 外形監視/合成監視 フロントエンドからバックエンドまで、 インシデントの検知から解消まで、 問題解決を End to End で支援

Slide 28

Slide 28 text

© 2024 SPLUNK LLC 例: メトリクスの可視化とダッシュボード

Slide 29

Slide 29 text

© 2024 SPLUNK LLC 例: メトリクスの可視化とダッシュボード

Slide 30

Slide 30 text

© 2024 SPLUNK LLC 例: サービスマップと SLO管理

Slide 31

Slide 31 text

© 2024 SPLUNK LLC 例: 相関付け

Slide 32

Slide 32 text

© 2024 SPLUNK LLC テレメトリーデータ利用の最適化 : メトリクスの分析

Slide 33

Slide 33 text

© 2024 SPLUNK LLC さらに: 生成AIになんでも聞いてみよう Preview

Slide 34

Slide 34 text

© 2024 SPLUNK LLC まとめ

Slide 35

Slide 35 text

© 2024 SPLUNK LLC Kubernetes環 境のオブザーバ ビリティの次の一 歩を OpenTelemetry で実現すると何が どうなるの? 本セッションでは、KubernetesやPrometheusに詳しいプラットフォームエンジ ニア向けに、オブザーバビリティの次のステージを実現するための OpenTelemetry活用法を解説します。Kubernetes環境における実践例を通じ て、メトリクスやトレースの統合による運用効率向上と、リアルタイムな可視化の 価値を探ります。また、Splunk Observability製品との連携 によって得られる 効果的なモニタリングと課題解決のアプローチもご紹介します。 もくじ: 1. なぜOpenTelemetryなのか? 2. OpenTelemetryを使い始めるには 3. 集まったデータをどう利用するか: Splunk Observabilityの例 お持ち帰りいただくもの : ● 既存のモニタリング環境をより良くするためのアイデアを学ぶ ● 運用しているKubernetes環境にOpenTelemetryの導入を進めるための方 法を学ぶ ● Splunk Observabilityという選択肢を持っていただく 本日の内容

Slide 36

Slide 36 text

© 2024 SPLUNK LLC まとめ 1. なぜOpenTelemetryなのか? 👉 トレースの必要性 👉 テレメトリーデータ統合の必要性 2. OpenTelemetryを使い始めるには 👉 OpenTelemetry Collectorを便利につかう 👉 トレースを導入しつつ、既存のメトリクスやログの変更を最小限にしながら統合する 3. 集まったデータをどう利用するか : Splunk Observabilityの例 👉 テレメトリーデータを統合して分析できる 👉 リアルタイム性 👉 利用状況の把握と管理

Slide 37

Slide 37 text

© 2024 SPLUNK LLC 次のステップ 1. チームへの浸透 : ツールはそこにあるだけでは使われない 👉 勉強会 👉 訓練 👉 負荷試験などで使う 2. カスタム計装の追加 👉 カスタム属性、カスタムスパン、事業に応じたカスタムメトリクス 3. 領域の拡大 👉 フロントエンドモニタリング(RUM) 👉 レガシー環境との統合(ログ主体のモニタリング)

Slide 38

Slide 38 text

© 2024 SPLUNK LLC ブースにもぜひ お越しください! Thank you!