https://www.splunk.com
  • Splunkサイト
    • Splunk Answers
    • ブログ
    • Community
    • .conf
    • Developers
    • Documentation
    • Splunk.com
    • Splunkbase
    • サポート
    • トレーニング
    • User Groups
    • ビデオ
https://www.splunk.com
  • ブログ
  • カテゴリー
    カテゴリー
    • .conf & SplunkLive!
    • お客様 & コミュニティ
    • DevOps
    • 業種・業界
    • IT
    • 経営陣
    • Learn
    • パートナー
    • データプラットフォーム
    • セキュリティ
    • Splunk Life
    • Tips
    Category Spot Image
    電子書籍
    外形監視のベストプラクティス Synthetic Monitoringの紹介

    Webサイトのパフォーマンスが広告収入、ユーザーエンゲージメント、SEOランキングに与える影響、外形監視を使ったソリューションを紹介

    詳細はこちら
  • ライター
    ライター
    • Splunk
    • Guest
    • 江藤 愛
    • 大谷 和紀
    • 甲斐 逸郎
    • 加藤 教克
    • 塚本 政彦
    • 仲間 力
    • 野村 健
    • 村田 達宣
    • 矢崎 誠二
    • 山内 一洋
    • 山村 悟史
    • 横田 聡
    • Gary Steele
    • Spiros Xanthos
    • Garth Fort
    • Simon Davies
    • Ryan Kovar
    • Jane Wong
    • ライター一覧
    Author Spot Image
    電子書籍
    SIEM導入ガイド

    適切なSIEMソリューションがどのように役立つかを解説した最新版

    電子書籍を読む
  • メール配信
  • 無料トライアル
https://www.splunk.com 無料トライアル
ブログ
カテゴリー
  • .conf & SplunkLive!
  • お客様 & コミュニティ
  • DevOps
  • 業種・業界
  • IT
  • 経営陣
  • Learn
  • パートナー
  • データプラットフォーム
  • セキュリティ
  • Splunk Life
  • Tips
ライター
  • Splunk
  • Guest
  • 江藤 愛
  • 大谷 和紀
  • 甲斐 逸郎
  • 加藤 教克
  • 塚本 政彦
  • 仲間 力
  • 野村 健
  • 村田 達宣
  • 矢崎 誠二
  • 山内 一洋
  • 山村 悟史
  • 横田 聡
  • Gary Steele
  • Spiros Xanthos
  • Garth Fort
  • Simon Davies
  • Ryan Kovar
  • Jane Wong
  • ライター一覧
メール配信
Splunkサイト
  • Splunk Answers
  • ブログ
  • Community
  • .conf
  • Developers
  • Documentation
  • Splunk.com
  • Splunkbase
  • サポート
  • トレーニング
  • User Groups
  • ビデオ
DEVOPS

オブザーバビリティのトラブルシューティングと進化した監視方法

Share:

前編ではログ監視を取り巻く状況と、新しい監視アプローチとしてオブザーバビリティをご紹介しました。後編では、オブザーバビリティを使用した場合のトラブルシューティング方法、オブザーバビリティを実践する場合の主なチャレンジ、そしてオブザーバビリティ以外の進化した監視方法を見ていきます。

オブザーバビリティによるトラブルシューティング

それでは、問題発生時にはどのようにアクションを起こすべきでしょうか。それは前編の「オブザーバビリティの3つの柱」で触れたメトリクス、トレース、ログを使用します。

メトリクス:特定の時間間隔で測定された統計値です(例: アクセス数、エラー率、CPU使用率、売上)。

SLO/SLIを始めとして、インフラやアプリケーション、フロントエンド(ユーザーエクスペリエンス)の各重要な値をリアルタイムで可視化することで「問題は起こっているか」を可視化します。

メトリクスの例:レイテンシーやレスポンスタイム

メトリクスの例:SLOやユーザーエクスペリエンスに問題はないか

トレース:依存関係がある一連のリクエストフローをエンドツーエンドでエンコードしたものです。

「問題はどこで起こっているか」を可視化します。

トレースの例:リクエストフローの可視化

トレースの例:あるユーザのセッションで、どのサービスで問題が発生しているか

ログ:発生した個別のイベントをタイムスタンプ付きで記録したものです(例: アクセスログ、例外トレースのログ)。

「問題はなぜ起こっているか」を可視化します。

ログの例:問題のあるサービスでどのようなエラーが発生しているか

ログの例:対象セッションの問題のあるサービスでどのようなエラーが発生しているか

これらのデータを使用することにより、メトリクスにより問題を検出し、トレースによりどこで問題が発生しているかを特定し、ログにより原因を特定し、アクションを行います。

最も重要なことは、これらのデータを一つのプラットフォームで管理することです。特に、トレースとログの紐づけが重要です。上の例では、トレースで問題が発生しているサービスを特定し、そのサービスで発生したログをドリルダウンできるようにしています。

それはどのように実現しているのでしょうか?

鍵は、ログにメタデータとしてTrace ID、Span IDというものを埋め込んでいます。これはリクエストIDやトランザクションIDのようなものです。分散システムにおいて複数のサービスをまたがった処理が行われる場合に与えられるIDです。これによりログにコンテキストが生まれトラブルシューティングが容易になります。

ちなみにTrace ID、Span IDはデータ収集エージェント(OpenTelemetry)で分散トレーシングという技術を用い自動的に付与されます。

ログに与えられたTrace ID、Span ID

ログに与えられたTrace ID、Span IDでコンテキストを得る

なお、オブザーバビリティによりログ監視が無くなるわけではありません。明確にアクションが必要な事象(例えばクリティカルなジョブの失敗)が発生したときにはSLOは関係なく対応する必要があります。

チャレンジ

このようなオブザーバビリティはグローバルでは主流になっています。

しかしチャレンジがあるのは確かです。

  • SLO/SLIの定義

定義は運用チームだけでできるものではありません。開発チームはもちろん、サービスオーナーなどステークホルダーの合意が必要です。ステークホルダーへの丁寧な説明と議論を要します。例えばSLOという性質から、ある程度のエラーは見落とすことを前提とします。これを嫌うステークホルダーは「100%」というSLOを要求するかもしれません。ですが、100%を満たすITシステムというものは、大変な高コストであり、また変更が一切できないITシステムです。どこまでエラーを許容するかの合意が必要です。

しかし、サービスレベルを定め、それを基準に運用、開発を行うということは誰しもが同じ基準を持てるという点で大変重要です。

また、前編でもご紹介した『SLO/SLIとは』のページにSLO/SLIの導入方法が紹介されていますので是非ご参考になさってください。

  • トラブルシューティング

これまでは定められた手順に従い対応していましたが、トラブルシューティングのスキルが必要になります。一次切り分け、エスカレーションを行ってきた人材は減少し、代わりに運用、開発の知見をもって対応にあたる人材(SREと呼ばれます)が必要です。そのような人材の確保、育成であったり組織変更を要します。

これは現在もエスカレーションを受けた開発チームが対応していたりと、実は大きな変わりはなく、オブザーバビリティによるトラブルシューティングの効率化でメリットが大きいかもしれません。

一足飛びにオブザーバビリティの実践を図るのは困難かもしれません。しかし来たるべき変化に備えるため、運用も変化しなければならないことは確かだと考えます。

オブザーバビリティの実践はすぐには困難だがログ監視を効率化したい、というニーズもあります。そういった場合に何ができるかを見ていきます。

アラート集約

運用や組織を大きく変えずに効率化する手法として考えられるのはアラート集約があります。

例えばSplunk IT Service Intelligence (ITSI)では同一のアラートメッセージはもちろん、同一ホスト、同一サービス、または類似するアラートなど、様々な方法で集約することができます。また、Splunkのデータ分析プラットフォームをベースにしているため、ログのフォーマットはどのようなものでも構いません。

Splunkによるアラートの集約

認証サービスのエラーとリソースに関するアラートを集約している

これにより、類似アラートを集約し対応数を減らすということはもちろん、コンテキストも得られます。例えばログ監視の他、リソース監視やその他のアラートも集約することにより、問題発生の前に何か先行事象が発生していないかを確認することでトラブルシューティングをスムーズに行うことができます。先ほどのアラートストームの例では特に有効です。

(それ以外にもITSIにはトラブルシューティングのための様々な機能があります!)

これによりMTTRを削減し、人的リソースの有効活用を目指します。

インシデントレスポンス自動化

ログ監視において対応するアクションが明確になっている場合、それを人が対応するのではなく自動化できるものは自動化する仕組みを採用すべきです。自動化には以下のようなものがあります。

  • 適切な担当者の自動アサイン
  • 担当者への自動コール(電話、モバイルアプリによる通知など)
  • 対応手順の参照
  • 関係者間でのコミュニケーションのためチャットツール、ITSMツールとの連携
  • 構成管理ツール(Ansible、Puppetなど)との連携による処理の自動化

インシデントレスポンスの例

インシデントレスポンス例:対象ITシステムの担当者へ自動コールし、同時にServiceNow、Slackにも通知している

このようなインシデントレスポンスの自動化により余裕ができたリソースを更に自動化に投資していくことで、人に依存した運用から脱却し、運用高度化を促進します。

どこから手を付けるべきか

改めて申し上げたいのは、ログ監視はこれまでも、これからも重要であり続けます。

しかしながら、来たるべき変化に備えて新たな監視アプローチの有効性をご認識いただければと思い、この記事を書きました。

今後の第一歩としてお勧めするのはオブザーバビリティの試験適用です。例えば新たに開発するクラウドネイティブのITシステムでパイロットプロジェクトとして試すケースが多いです。もちろん既存ITシステムでもログ監視に限界を感じているものがあれば、どのように可視化できるかを試すのもよいと思われます。オブザーバビリティを適用したからと言って既存の運用に影響があるものではありません。

もしSplunkのオブザーバビリティソリューションにご関心がある場合は是非お問い合わせいただくか、Splunk Observabilityの製品ページをご覧ください。

ITシステムに関する状況が変わりつつある現在におけるログ監視の課題と、それにどう対応していくべきかを解説している前編も合わせてご覧ください。

長文となってしまいましたが、お付き合いいただきましてありがとうございました。

February 08, 2023
山村 悟史
Posted by

山村 悟史

データに翻弄されることなく価値を引き出すSplunkのData-to-Everythingの思想に共感し2020年Splunk Services Japan合同会社入社。現在は幅広いお客様へSplunkとは?を知って頂くためプリセールス活動として提案、検証、ワークショップなどを実施。
入社前は主にITサービスマネジメントプラットフォーム構築、データセンタ管理などを経験。

TAGS
DevOps
Show All Tags
Show Less Tags

Related Posts

SPLUNK ON TWITTER
  • @Splunk
  • @splunkanswers
  • @SplunkforGood
  • @SplunkDocs
  • @splunkdev
  • @splunkgov
SPLUNK ON FACEBOOK
  • @Facebook
SPLUNK ON INSTAGRAM
  • Follow us on Instagram
SPLUNK ON LINKEDIN
  • Follow us on LinkedIn
SPLUNK ON YOUTUBE
  • Subscribe to our Channel
SPLUNK ON SLIDESHARE
  • Follow us on SlideShare
Splunk製品
  • Splunk Cloud Platform
  • Splunk Enterprise
  • Splunk IT Service Intelligence
  • Splunk On-Call
  • Splunk Enterprise Security
  • Splunk SOAR
  • Splunk Infrastructure Monitoring
  • Splunk APM
ソリューション
  • オブザーバビリティ
  • セキュリティ
  • プラットフォーム
お客様事例
リソース
  • 電子書籍
  • アナリストレポート
  • ホワイトペーパー
  • ウェビナー
  • ビデオ
お問い合わせ
  • サポート
  • 営業へのお問い合わせ
Splunk Sites
  • Splunk Answers
  • 日本語ブログ
  • Community
  • .conf
  • Developers
  • Documentation
  • Splunkbase
  • SplunkLive!
  • T-shirt Store
  • トレーニング
  • User Groups
Splunk
Sitemap | Privacy
© 2005-2023 Splunk Inc. All rights reserved.
Splunk、Splunk>およびTurn Data Into Doingは、米国およびその他の国におけるSplunk Inc.の商標または登録商標です。他のすべてのブランド名、製品名、または商標は、それぞれの所有者に帰属します。