Logs are better with elastic apm 20210623

100 Views

June 23, 21

スライド概要

Elastic APM のログ活用法https://www.elastic.co/jp/webinars/learn-more-from-your-logs-with-elastic-apm

profile-image

ヴイエムウェア株式会社 ソリューションアーキテクト本部 プリンシパルエンタープライズアーキテクト。 Microsoft で13年間、テクニカルエバンジェリストとして .NET、Visual Studio、Windows、iOS、Android、Microsoft Azure 等の開発者向け最新技術啓発活動を実施。その後、Dell、Accenture、Elastic で開発者向け技術啓発活動等を経て現職。 モダンアプリケーション開発、マルチクラウド対応、アーキテクチャ策定等を中心に、技術者向けに最新技術の啓発活動を実施中。 2019年4月〜2021年8月迄、内閣官房 IT 総合戦略室 政府 CIO 補佐官を兼務、2021年9月〜2024年3月迄、デジタル庁 PjM ユニット ソリューションアーキテクトを兼務。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

Elastic APM のログ活⽤法 鈴⽊ 章太郎 Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリスト 内閣官房 IT 総合戦略室 政府 CIO 補佐官

2.

⾃⼰紹介 鈴⽊ 章太郎 Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリスト 内閣官房 IT 総合戦略室 政府 CIO 補佐官 2003年マイクロソフト⼊社。公共営業部⾨の担当アーキテクトとして .NET の技術啓発活動に従事。 2006年開発者向けマーケティング部⾨に異動、テクニカルエバンジェリスト として Windows/iOS/Android や Microsoft Azure の開発者向け 技術啓発活動を10年にわたり担当。 ⽇本マイクロソフト退社後は、Dell、Accenture 等を経て、2020年6⽉ からは Elastic で開発者向け技術啓発活動に携わる。 2019年4⽉〜 内閣官房 IT 総合戦略室 政府 CIO 補佐官。

3.

3 Solutions, 1 Stack, Deploy Anywhere 3 つのソリューション Elastic エンタープライズサーチ Elastic オブザーバビリティ Elastic セキュリティ 可視化 & 管理 Kibana Elastic スタックで実現 Beats 豊富なデプロイ選択肢 蓄積、検索、分析 Elasticsearch Logstash Elastic Cloud Elastic Cloud Enterprise SaaS (AWS/Azure/GCP) IaaS (クラウド & オンプレ) Elastic Cloud on Kubernetes Kubernetes (クラウド & オンプレ) 収集

4.

メトリックとログ ログはイベントの時系列レコード 64.242.88.10 - - [07/Jan/2019:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" 200 6291 64.242.88.10 - - [07/Jan/2019:16:11:58 -0800] "POST /twiki/bin/view/TWiki/WikiSyntax HTTP/1.1" 404 7352 64.242.88.10 - - [07/Jan/2019:16:20:55 -0800] "GET /twiki/bin/view/Main/DCCAndPostFix HTTP/1.1" 200 5253 イベントごとに、何が起こったかを表⽰

5.

メトリックとログ ログはイベントの時系列レコード 64.242.88.10 - - [07/Jan/2019:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" 200 6291 64.242.88.10 - - [07/Jan/2019:16:11:58 -0800] "POST /twiki/bin/view/TWiki/WikiSyntax HTTP/1.1" 404 7352 64.242.88.10 - - [07/Jan/2019:16:20:55 -0800] "GET /twiki/bin/view/Main/DCCAndPostFix HTTP/1.1" 200 5253 イベントごとに、何が起こったかを表⽰ メトリックは数値 KPI の定期的な測定 07/Jan/2019 16:10:00 07/Jan/2019 16:20:00 07/Jan/2019 16:30:00 all all all 2.58 2.56 2.64 0.00 0.00 0.00 0.70 0.69 0.65 1.12 1.05 1.15 x 分ごとに CPU 負荷を測定し、それを印刷し、メタデータでアノテート 0.05 0.04 0.05 95.55 95.66 95.50 server1 server2 server2 containerX containerY containerZ regionA regionB regionC

6.

なぜ APM? 例: 応答の遅い時間またはロード時間 03:43:45 Request "GET cyclops.ESProductDetailView" 03:43:57 Response "cyclops.ESProductDetailView 200 OK" 12 seconds - zZzzZZz

7.

なぜ APM? 例: エラーと例外 03:43:59 Request "POST /api/checkout" 03:43:59 Response "/api/checkout 500 ERROR"

11.

Application Performance Monitoring (APM) • • • • • ログ、APM、インフラメトリックは監視の3⼤要素 3つの領域には重なり合う部分もあり、相互に関連付 ける際に役⽴つ ログは、エラーが⽣じた痕跡を⽰すが、エラーの理由ま では⽰さない メトリックはサーバー上で CPU 使⽤量にスパイクが あったことを⽰すかもしれないが、何が原因だったかは ⽰さない ただし、うまく組み合わせて活⽤すれば、はるかに広い 範囲の問題を解決できる可能性がある

12.

ログ • ログとメトリックには、わずかな違い • 通常、ログは何かが⽣じたときに発信されるイベント • あるリクエストが受信された、反応があった、ファイルを開いた、コードで printf が発⽣... etc. • ログの情報は、アプリケーションの全体を把握するというより、コンポーネン トレベルにとどまる • しかし⼈間が読む上では便利 • ログは通常、対応するアプリケーションやサービスが実⾏されているホスト /マシン/コンテナーインスタンス上で使⽤でき、この例のように⼈間が読め る情報であるため"便利" • ⼀⽅でログには「コードを書いておかなければ、プリントされない」という 本質的なデメリットも • Ruby で puts、Java で system.out.println、あるいは類似の作 業が必須 • またプリントする場合も、フォーマットが重要 たとえば、Apache HTTPサーバーのプロジェクトからくるよくあるロ グ形式はこんな感じ(フェイクデータ、短縮のため⼀部省略)。 264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "GET /ESProductDetailView HTTP/1.1" 200 6291 264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "POST /intro.m4v HTTP/1.1" 404 7352 264.242.88.10 - - [22/Jan/2018:16:38:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253 この例では、IPアドレスと、明らかに設定のないフィールド、⽇付、 ユーザーがアクセスしていたページ(とその⽅法)、いくつかの数字 を確認できる 経験から、⼀連の数字がレスポンスコード(200はよい、404は 良くないが、500よりはマシ)等や、データが返された量であること がわかる

13.

インフラメトリック • メトリックは周期的なサマリーやカウントの情報が主 • たとえば右はローカルマシン mac の iostat の例 • この10秒間に、平均 CPU は12% • アプリケーションが使⽤したメモリ量は 27 MB • プライマリディスクの容量は 71% • といったこと(多くのメトリックの存在)がわかる • 傾向や履歴を⽰したいときに便利 • シンプルで予測可能、また信頼できるルールを作成してインシデントや 異常を捉える場合に特に役⽴つ • ⼀⽅、メトリックのデメリットとして • インフラレイヤーの監視、コンポーネントインスタンスレベル(ホスト、コ ンテナー、ネットワークなど)のデータ捕捉が中⼼ • カスタムアプリケーションレベルのデータをあまり扱わない • メトリックは⼀定の経過時間に対してサンプルされるため、わずかな外れ 値が"平均化"されるリスクを伴うため

14.

APM (アプリケーションパフォーマンス監視) • メトリックとログのギャップに橋を架ける存在 • ログやメトリックは、インフラや複数のコンポーネントを扱う横断的なデータ • • APM は特にアプリケーションに注⽬し、エンドユーザーエクスペリエンスを含むスタック中の アプリ層を、IT 部⾨や開発者が監視できるようサポート 監視に APM を追加するメリットとして、次のような点 • サービス提供にかかる時間と、クラッシュの原因を把握できる • サービスと他の要素の通信状況や、ボトルネックを可視化できる • パフォーマンスのボトルネックやエラーの予防的な発⾒・修正に役⽴つ • 最良のシナリオは、多数のエンドユーザーが影響を受ける前の発⾒・修正 • 開発チームの⽣産性向上をサポート • ブラウザー上でエンドユーザーエクスペリエンスを追跡可能

15.

ログと APM とで得られる情報を⽐較 264.242.88.10 - - [22/Jan/2018:16:38:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253 APMが捉えた内容︓最終発⽣⽇時、 発⽣頻度、アプリケーションで処理 されたか否か、という情報が表⽰ たとえば NumberParseException を 使って例外処理の詳細を⾒ると、エ ラーが発⽣した回数の分布がウイン ドウで視覚的に表⽰される ⼀定の時間に数回起きているということ、 ⼀⽇中発⽣していることがわかる ログで⾒ても、ログファイルの1つに対応す るスタックの痕跡が⾒つかるはず しかし APM のようにそのコンテクストや メタデータまで⾒つかる可能性は⾼くない ⾚い部分はこの例外処理を実施した コード⾏ APMが提供するメタデータが問題の正 確な内容 プログラマーでない⼈間が⾒ても問題 が正確に理解でき、チケットをオープ ンのために必要⼗分な情報がある

16.

Elastic APM APM は Elastic Stack に エンドユーザー体験と アプリケーションレベルの監視を追加 • APM データの上での検索体験を重視 • Elastic Stack の「もう⼀つのインデックス」 対応言語 ● Python ● Java ● Node.js ● Go ● Ruby ● .NET ● RUM ● PHP

17.

Elastic APM の概要

18.

Application Performance Monitoring (APM) • • ブラウザーでのエンド ユーザー エクスペリエンス • JavaScript エージェントを使⽤してエンド・ユーザーの • パフォーマンスをモニターする エラーログ • • ログとメトリックとの相関 • • コードによってスローされたエラーとスタック トレースをキャプチャする ログデータとメトリックデータ間でデータを⾃動的に関連付ける 根本原因分析 • ドリルダウンしながら探る

19.

Elastic Application Performance Monitoring • マルチページアプリ、シングルページアプリの双⽅で有効 • Node.js、Python、Ruby、.NET、 Java、Go Real User Monitoring(JavaScript)をサポート • 対応⾔語のさらなる追加も予定 • • • • Elasticがサポートする⾔語はこちら Jaeger や OpenTelemetry 等各種のオープンスタンダードもサポート インストルメンテーション済みのアプリから Elastic APM へ驚くほど簡単にデータを 送れる 必要なモジュールが⾒つからなくても、独⾃に開発することも、オープンソース コミュニティの成果物を活⽤することも可能

20.

⼀カ所での全般的 Observability(可観測性) エンドユーザーの体験とアプリケーション レベルの監視をスタックに追加 RUM

21.

例︓Elastic APM for Python コードの変更は不要 - - Python 2.7, 3.5, 3.6, 3.7, 3.8, 3.9 Frameworks Django, Flask, Aiohttp server, Tornado, Starlette/FastAPI Modules Elasticsearch, SQLite, MySQL db, mysql-connector, Cassandra, etc … より多くのモジュール登場予定!

22.

Logs Metrics APM

23.

サイロ化されたツールのコレクションの状態 開発 チーム Ops: モニタリング チーム Ops: モニタリング チーム Ops: ログ チーム APM ツール 稼働時間ツール メトリックツール ログツール リアルユーザーモニタリング Txn の監視 分散トレース アップタイム 応答時間 コンテナのメトリック ホストメトリック データベースメトリック ネットワークメトリック ストレージメトリック Web ログ アプリログ データベースログ コンテナログ

24.

ソフトウェアの開発⽅法とデリバリは常に進化 CI / CD サーバレス コンテナ オーケストレーション マイクロサービス クラウド

25.

65 10 % の組織は 種類以上の 監視ツールを使⽤

27.

統合 Observability ツールとしての Elastic Dev & Ops チーム APM データ 稼働時間データ メトリックデータ ログ データ リアルユーザーモニタリング Txn の監視 分散トレース アップタイム 応答時間 コンテナのメトリック コンポーネントメトリック ホストおよびネットワークのメトリック データベースとストレージのメトリック Web ログ アプリ ログ / データベース ログ コンテナログ PaaS コンポーネント ログ Kibana Elasticsearch

28.

Elastic オブザーバビリティ 単⼀のオープンプラットフォームによる完全な可視性を ⼿頃な価格で提供し、 MTTR (データ・分析結果を得るまでの平均時間) をゼロに近づけます。

29.

監視データ間の相関 Elastic Common Schema 利点 • • • 異なるソースからのデータを相関する 分析コンテンツを再利⽤する機能 弾性によって提供されるコンテンツを再利⽤する機能 地位 • • GA および公開 : github.com/elastic /ecs コミュニティのフィードバックは歓迎

30.

統合ダッシュボード KPI 概要と根本原因分析に同じ UI の利⽤

31.

統合アラート 運⽤データをトリガーして、統⼀された SLA 監視を提供

32.

統合された機械学習 (Machine Learning) 複数のデータソースを関連付けて、よりインテリジェントな異常検出を実現

33.

トレース、ログ、メトリック間のより緊密な統合

34.

Demo

36.

最新の デジタルエクスペリエンス を提供するためには Observability が重要 Modern Architecture は複雑 Elastic Observability には、これらの複雑なシステムを 1つのプラットフォームで観察可能にするために必要なものが すべて揃う 「Hipsterオンラインストアアプリは、クラウドネイティブのテ クノロジーアーキテクチャ上に構築されています。 Go、 C#、Java、.js ノード、Pythonなど、さまざまなプログラ ミング⾔語で構築された10層マイクロサービスアーキテク チャを使⽤します。メモリ内データキャッシュに Redis を使 ⽤しています。これらのすべては、Google クラウド プラッ トフォーム (GCP) で実⾏されている Kubernetes ベー スのコンテナープラットフォームで実⾏されています。

37.

APM トレースへのログデータの追加

38.

ログとトレース Response HTTP request Transaction 1 Span Span Span [07/Jan/2019:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" [07/Jan/2019:16:11:58 -0800] "Update database XYZ" [07/Jan/2019:16:20:55 -0800] "Transaction updated successfully" 38

39.

ログとトレース - ラベルを使⽤した範囲のアノテーション Response HTTP request Transaction 1 Span Span Span [07/Jan/2019:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" [07/Jan/2019:16:11:58 -0800] "Update database XYZ" [07/Jan/2019:16:20:55 -0800] "Transaction updated successfully" 39

40.

APM ラベル ラベルは Elasticsearch でインデックス付けされるため検索可能で集計可能 Span span = ElasticApm.currentSpan(); span.setLabel("customer", "J.C.Penny"); span.setLabel("order_id", "XDD669023"); span.setLabel("quantity", 12); span.setLabel("amount", 999.01); span.setLabel("currency", "AUD");

41.

APM アノテーション

42.
[beta]
APM アノテーション
これらの特別な瞬間のために:リリースバージョン、アップデート、イベント
curl -X POST ¥
http://localhost:5601/api/apm/services/opbeans-java/annotation ¥
-H 'Content-Type: application/json' ¥
-H 'kbn-xsrf: true' ¥
-H 'Authorization: Basic YhUlubWZhM0FDbnlQeE6WRtaW49FQmSGZ4RUWXdX' ¥

-d '{
"@timestamp": "2020-05-08T10:31:30.452Z",
"service": {
"version": "1.2"
},
"message": "Deployment 1.2"
}'

43.

And More!

44.

機械学習 (Machine Learning) データの異常や外れ値を⾒つけたり、傾向に基づいて予測 • ボタンをクリックするだけのシンプルな操作で、Elasticsearch のデータから 新しいインサイト を抽出 • 限りなく運⽤性にすぐれた 機械学習 • Elasticsearch と Kibana で直接、簡単に使えるよう設計 簡単にメタデータを補⾜ 異常と外れ値を、瞬時に検出 教師あり機械学習を⼿軽に運⽤

45.

機械学習 (Machine Learning) APM からの機械学習とのワンクリック統合 • APM から応答時間ベースの ML ジョブを作成する機能 ‒ ‒ 異常を計算するためのプロファイル 応答時間 シーズナリティを考慮する

46.

分散トレーシング 複数サービス間でのトレースとマッピング • エンドツーエンドの表⽰を確認し個々の トランザクションに移動 • サービス間のエンドツーエンドのトレース ID の概念に依拠 • Open Tracing API との互換性 • W3C トレースコンテキスト仕様との整 合性

47.

分散トレース OpenTelemetry, OpenTracing, Jaeger…オープンスタンダードのサポート

48.

統⼀された Observability トレース データをコンテキスト内のログおよびメトリック データに関連付ける

49.

コンテキスト対応リアルタイム検索 データストリームを迅速に結び付けて回答を得る

50.

同じレスポンス、 異なるエクスペリエンス ブラウザでの動作 • 要求がエンドユーザーのデバイスに到達すると どうなるか︖ • ユーザーエクスペリエンスがビジネス成果に 与える影は︖ • サードパーティ製の Java スクリプトは︖ • 稼働していますか? 機能していますか?

51.

柔軟なデプロイメントオプション オンプレミス、クラウド、クラウド ネイティブ、マルチクラウド セルフ マネージド Elastic Cloud 単⼀のパッケージを インストールする AWS、Azure、 または Google Cloud に 即座にデプロイ Elastic Cloud Enterprise Elastic Cloud on Kubernetes インフラ上で 複数のデプロイメントを ⼀元管理

52.

柔軟な Agent のデプロイメント • 7 つの異なる⾔語⽤のネイティブ ライブラリ ‒ • フルスタック技術(フロントエンドからバック エンド)を含むさまざまなエコシステムに わたる広範な計測サポート OpenTracing, Jaeger, OpenTelemetry のサポート

53.

DevOps コラボレーション パフォーマンスの問題をデプロイメントに結び付ける • • • コード配置を使⽤してアプリケーションの パフォーマンスを追跡する すべての APM チャートのアノテーション により、 パフォーマンスの変化を迅速に ⾒つけ出し、 新しいデプロイを⾏う バージョンを除外する検索

54.

ITSM コラボレーション 既存のインシデント管理プロセスへの統合

55.

7.13 アップデート APM 最初のスタートにおける改善 • Cloud Instrumentation – – – • エージェント固有の機能強化 – – – – – • Go、Ruby、および Python Agent は、AWS DynamoDB、S3、SNS、および SQS のサポート追加 .NET Agent は、Azure ストレージ、キュー、およびサービスバスのサポートを追加 .NET、Go、Ruby の Agent は Azure App Service のサポートを改善、追加のメタデータを収集 Java: Cassandra 実装 .NET: MongoDB 実装 Node.js: パフォーマンス改善 PHP: support for PHP 8、中央構成のサポート .NET and Node.js:スパン・バイ・タイプと依存関係の内訳 (フィーチャー・パリティ) エージェントのゼロコンフィギュレーション (Fleet との将来の統合)

56.

7.13 アップデート 例: Azure バックエンドを呼び出す .NET サービス

57.

7.13 アップデート Fleet Server の概要 • • • • Fleet Server は新しいスタックインフラストラクチャコンポーネント Elastic Agent を⼀元的に⼤規模に管理 Kibana の⼀部だった以前よりもスケーラブル セグメント化されたネットワークのサポートを強化し、より安全に Standard/Basic Enterprise Platinum Gold OSS Beta GA

58.

7.13 アップデート APM と Fleet への アップグレード どのように役⽴つか ➔ ユーザーは Fleet をすぐに使い始めることができ、 Elastic へのデータの取り込みが容易に ➔ デフォルトで提供され、新しい Elastic Cloud デプロイメントにおいて無料で提供 技術的詳細 ● Fleet Server を既存 APM インスタンスに追加 ● Fleet を通じて APM を管理することが可能に Standard/Basic Enterprise Platinum Gold OSS Beta GA

59.

Google Cloud Day:Digital ʻ21 → d2-gl-27 「クラウド ネイティブへの移⾏における Elastic APM の概要」 https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21?talk=d2-gl-27

60.

Elastic APM のログ活⽤法 https://www.elastic.co/jp/webinars/learn-more-from-your-logs-with-elastic-apm

61.

Elastic 7.13 Update ダイジェスト版(6/24) 今回のWebinarの詳細は以下の通りです。 ========================== ===================== ■開催⽇時 6/24(⽊)19:30〜21:00 ■内容 登壇 1. ⽇本マイクロソフト 惣道 哲也さん 2. Elastic 鈴⽊章太郎さん 3. 募集中 ========================== ===================== 以上 https://www.meetup.com/ja-JP/Tokyo-Elastic-Fantastics/events/278466633/

62.

Elastic on Microsoft Azure: インテグレーション強化による価値の創出 https://www.elastic.co/jp/webinars/elastic-on-microsoft-azure-accelerate-time-to-value-with-enhanced-integration

63.

Elastic x LAC Web セミナー セキュリティー DX : 効果的な基盤構築と運⽤法 https://www.elastic.co/jp/webinars/effective-infrastructure-construction-and-operation-methods

64.

Microsoft Open Tech Night #14 Dapr 勉強会(7⽉14⽇) https://msdevjp.connpass.com/event/215108/

65.

ElasticON Solution Series Japan (7⽉毎週) https://www.elastic.co/elasticon/solution-series/asia-pacific-jp

66.

Thank you for your attention!