ナビゲーション全体を読み込み中です。

Elevate 2026へのカウントダウンが始まりました。 今すぐ登録 シカゴ、ロンドン、またはシドニーで私たちと一緒に過ごしませんか。

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

APIモニタリング

マイクロサービスの監視戦略とベストプラクティス

マイクロサービスは、導入速度と障害発生範囲の両方を増大させます。ここでは、分散システムの可視性と信頼性を維持するための監視戦略を紹介します。

11〜16分
デントン千倉

章

    ニュースレター

    最新情報のメール配信を登録

    最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

    シェア

    クイックダウンロード:

    マイクロサービスは複雑さを軽減するのではなく、分散させる。適切な監視戦略がなければ、何らかの問題が発生するまで、その複雑さは目に見えないままになってしまう。

    • 分散システムでは、単一のユーザーリクエストが数十ものサービスに影響を与える可能性があります。分散トレーシングは、その経路を可視化し、デバッグ可能にするものです。

    • サービスメッシュのテレメトリ、コンテナレベルのメトリクス、アプリケーションレベルのログはそれぞれ全体像の一部しか示していません。いずれか1つのレイヤーだけに頼っているチームは、手探り状態で進んでいるようなものです。

    • ユーザーエクスペリエンスに関連するサービスレベル目標に基づいてアラートを発し、個々のマイクロサービスの健全性チェックに基づいてアラートを発するべきではありません。目標は正常に動作する製品であり、緑色のダッシュボードではありません。

    • 可観測性は、後付けではなく、デプロイ時に各マイクロサービスに組み込むべきです。後から計測機能を追加するコストは、サービスを追加するたびに増大します。

    現代のソフトウェアアーキテクチャにおいて、モノリシックシステムからマイクロサービスへの移行は革命的な出来事でした。しかし、この移行に伴い、相互に依存する多数の小規模サービスを監視するという複雑さが増しています。

    効果的なマイクロサービス監視は、最適なパフォーマンス、迅速な問題解決、そしてシステム全体の堅牢性を確保し、今日のデジタルビジネスにとって極めて重要です。簡単に言えば、全体像とそれを構成するすべての小さな点までを詳細に見るために、ズームインするようなものです。マイクロサービスアーキテクチャでは、各マイクロサービスは、より大きなシステムの小さな独立したコンポーネントとみなすことができます。各マイクロサービスは、システム全体の健全性を維持するために、応答時間、エラー率、リソース使用量などの特定の特性について監視する必要があります。

    この記事では、マイクロサービスの監視戦略と、効率性と有効性を向上させるためのベストプラクティスについて解説します。

    マイクロサービス監視の主要概念の概要

    マイクロサービスの監視戦略 製品概要
    個々のサービス監視における粒度を重視するOpenTelemetryまたは代替の監視ツールを使用して、個々のサービスおよびトランザクションレベルで詳細な監視を実施します。応答時間やエラー率などの指標を分析し、ユーザー向けサービスの問題点を特定します。
    細部へのこだわりと効率性のバランスシステムの状態に基づいて詳細レベルを変化させる適応型サンプリングを使用し、選択的かつインテリジェントな監視を適用する。
    監視を動的に調整するIaaCと構成管理ツールを活用して、特定の条件に基づいて監視レベルを自動的に変更するスクリプトを作成します。
    異常検知を優先するマイクロサービスアーキテクチャにおいて、主要なユーザー行動を監視する仕組みを導入し、Apache Kafkaなどのツールを用いたリアルタイムデータ分析によって、異常を迅速に検知・対処します。
    容量計画とインフラストラクチャのスケーリングを監視するパフォーマンスデータを分析して傾向を把握し、キャパシティプランニングに役立てます。予測分析を活用し、メトリックのしきい値に基づいて自動スケーリングを設定します。
    包括的なセキュリティ監視エンドポイントの監査、WAFの設定、定期的なセキュリティテストの実施、および機械学習を用いた動的な脅威検出によって、各マイクロサービスを保護します。
    サービスメッシュの統合管理性と可観測性を向上させるために、Istioのようなサービスメッシュを導入します。リクエスト数やエラー率などのメトリクスを収集し、メッシュを使用してトラフィックの制御と管理を行います。

    従来型監視とマイクロサービス監視の比較

    従来のアプリケーション監視は、一般的にサーバー全体の健全性、データベースのパフォーマンス、アプリケーションの稼働時間などに焦点を当て、システムを一つの統一されたエンティティとして監視します。例えば、ウェブページの読み込み時間やデータベースへのアクセス状況などを追跡します。一方、マイクロサービス監視は、類似のウェブサイトを構成する個々のサービス（製品カタログ、ユーザー認証、決済処理など）を詳細に分析します。

    従来のアーキテクチャからマイクロサービスアーキテクチャへの移行に伴い、監視手法は大きく進化する必要がありました。各マイクロサービスは異なる環境で実行される可能性があり、個別の健全性チェックが必要です。この変化に伴い、各サービスのパフォーマンスを追跡し、サービス間の通信や影響関係を理解することが求められます。従来の監視ではウェブサイトがダウンしていることしか分からないかもしれませんが、マイクロサービス監視では、問題の原因が決済サービスとユーザー認証サービスの通信障害にあることを具体的に特定できます。そのため、分散トレーシングのような高度なツールが必要となります。

    側面従来型のモニタリングマイクロサービス監視
    アーキテクチャモノリシックな構成要素は相互に接続され、相互に依存している。分散型で、小規模な独立したサービス群から構成される。
    フォーカスより大規模な単一アプリケーションシステムにおいて。複数の小規模で独立したサービスが連携して機能する。
    複雑比較的構造がシンプルで、可動部品も少ない。多数のサービスとそれらの間の相互作用により、コストが高くなっています。
    規模スケーラビリティは、多くの場合、アプリケーション全体に限定される。個々のサービスレベルでの拡張性。
    データ収集アプリケーション全体から集計されたデータです。サービスごとに集計され、多くの場合、より詳細なデータが含まれる。
    監視ツール従来のAPMツールは、サーバーとアプリケーションの健全性に重点を置いていました。動的かつ分散型のトレーシングとリアルタイム分析をサポートするツール。
    エラー検出一枚岩のような構造のため、時間がかかる場合があります。独立したサービスと詳細なモニタリングにより、処理速度が向上しました。
    透明性アプリケーションのパフォーマンスと問題点の概要。各サービスのパフォーマンスと課題に関する詳細な分析。
    トレーサビリティトレースは通常、単一のアプリケーションの範囲内で行われます。トレースは複数のサービスにまたがるため、分散トレーシングが必要となる。

    モニタリングプロセスの概要

    モニタリングでは、サービスが望ましいパラメータ内で動作していることを確認するためのベンチマークとなるパフォーマンス指標に関するデータを収集します。各サービスのパフォーマンスを綿密に監視することが不可欠です。そのプロセスは以下のとおりです。

    ● 各マイクロサービスについて、応答時間、エラー率、スループットなどの主要業績評価指標（KPI）を特定します。

    ●一定期間にわたってパフォーマンスを追跡し、基準値を確立する。

    ● ベースラインとSLOに基づいて、パフォーマンス指標のしきい値を設定します。

    指標は、ビジネス目標とユーザーエクスペリエンス目標に合致している必要があります。例えば、マイクロサービスの平均応答時間を1週間観察してみましょう。サービスの平均応答時間が100msの場合、120msで警告アラート、150msでクリティカルアラートを設定することができます。 

    すべてのサービスにわたって一貫してデータを収集し、指標のパターンと傾向を分析します。根本的な問題を示唆する可能性のある逸脱や異常を探します。すべてのマイクロサービスとそのパフォーマンス指標を統合的に表示するダッシュボードを使用します。

    マイクロサービス監視エコシステム

    上記の図は、以下のように動作するマイクロサービス監視エコシステムを示しています。

    ● マイクロサービスは、データ収集と分析のために、監視ツールであるOpenTelemetryおよびCatchpoint（現在はLogicMonitor社の一部門）と統合されています。

    ● これらのサービスからのメトリクスとトレースは、意思決定プロセスによって制御される適応型サンプリングおよびログ記録メカニズムを通じて伝達されます。

    ● 監視インフラストラクチャの管理には、構成管理ツールであるAnsibleとTerraformが使用されます。

    ● 高度なデータ分析のために、機械学習（ML）モデルが組み込まれています。

    これらのプロセスの結果は視覚化され、エラー率、リクエスト率、応答時間などの主要なパフォーマンス指標を表示することで、マイクロサービスアーキテクチャの健全性と効率性を監視できます。

    マイクロサービス監視における分散トレーシングの役割

    分散トレーシングは、リクエストがさまざまなサービスをどのように通過するかを明確に可視化します。

    まず、お使いのテクノロジースタックと互換性のあるトレーシングシステムを選択します。ツールを選択したら、次のステップはアプリケーションを計測することです。OpenTelemetryなどのライブラリは、さまざまな言語用のAPIとSDKを提供しており、サービスを通過するリクエストに注釈を付けて追跡できます。各リクエストには、サービス境界を越えて渡される一意の識別子が含まれていることを確認してください。この識別子は「トレースID」と呼ばれることが多く、さまざまなサービスにわたるリクエストのパス全体をつなぎ合わせるのに役立ちます。トレーシングツールは通常、バックエンドシステムにデータを集約し、そこで分析します。バックエンド（Elasticsearch、Apache Cassandra、Clickhouse、Hydrolixなど）の選択は、スケーラビリティ、クエリ機能、既存のインフラストラクチャなどの要因によって異なります。

    複数のマイクロサービス（ユーザー認証、商品カタログ、ショッピングカート、チェックアウト）で構成されるオンラインショッピングアプリケーションを考えてみましょう。分散トレーシングを実装することで、ログインからチェックアウトまで、各ユーザーリクエストに一意のトレースIDが付与されます。リクエストが各サービスを通過する際、スパン（データベースへのクエリや外部APIの呼び出しなど、個々の作業単位）がこのIDとともに記録されます。チェックアウト中にユーザーが遅延を経験した場合、エンジニアはリクエストの正確なパスをトレースして遅延の原因となっているサービスを特定し、デバッグ作業を集中させることができます。

    アプリケーションの計測から可観測性バックエンドへのデータフロー。

    コード例

    以下のコードサンプルは、Google Cloud Traceを追加するものです。 

    Javaアプリケーションの**pom.xml**ファイルを開き、以下の依存関係を追加してください。

    <dependency>
  <groupId>com.google.cloud.opentelemetry</groupId>
  <artifactId>exporter-trace</artifactId>
  <version>0.15.0</version>
</dependency>

    Javaコードを開き、以下のスニペットを追加してスパンを作成します。

    TraceExporter traceExporter = TraceExporter.createWithConfiguration(
  TraceConfiguration.builder().setProjectId("MY_PROJECT").build());

 
private static OpenTelemetrySdk setupTraceExporter() {
	// Using default project ID and Credentials
	TraceConfiguration configuration =
    	TraceConfiguration.builder().setDeadline(Duration.ofMillis(30000)).build();
	SpanExporter traceExporter = TraceExporter.createWithConfiguration(configuration);
	// Register the TraceExporter with OpenTelemetry
	return OpenTelemetrySdk.builder()
    	.setTracerProvider(
        	SdkTracerProvider.builder()
            	.addSpanProcessor(BatchSpanProcessor.builder(traceExporter).build())
            	.build())
    	.buildAndRegisterGlobal();
  }
private static void myUseCase(String description) {
	// Generate a span
	Span span =
   openTelemetrySdk.getTracer(INSTRUMENTATION_SCOPE_NAME).spanBuilder(description).startSpan();
	try (Scope scope = span.makeCurrent()) {
  	span.addEvent("Event A");
  	// Do some work for the use case
  	for (int i = 0; i < 3; i++) {
    	String work = String.format("%s - Work #%d", description, (i + 1));
    	doWork(work);
  	}
  	span.addEvent("Event B");
	} finally {
  	span.end();
	}
  }

    アプリケーションを起動してエンドポイントにアクセスすると、Cloud Traceに以下のような出力が表示されます。

    マイクロサービス監視におけるベストプラクティス

    次に、マイクロサービスのモニタリングを成功させるための上位6つの戦略を見ていきましょう。

    #1 個別サービス監視における粒度を重視する

    トランザクション追跡機能を備えたツールを使用して、個々のサービスおよびトランザクションレベルでの監視を実装し、マイクロサービス全体にわたるリクエストの経路を追跡します。

    ユーザー向けサービスでレイテンシが増加している場合を考えてみましょう。分散トレーシングレポートや、平均応答時間（所要時間÷リクエスト総数）やエラー率などの特定のメトリクスを調べることで、エンジニアは問題の原因がサービス自体にあるのか、それとも下流の依存関係にあるのかを迅速に特定できます。平均応答時間の急激な増加やエラー率の上昇は、サービス固有のボトルネックを示している可能性があります。測定すべきメトリクスには以下が含まれます。

    ●  リクエストレート: 単位時間あたりのリクエスト数。負荷を示す指標となる。

    ●  エラー率: 全リクエストのうち、エラーが発生したリクエストの割合（エラー率＝総エラー数／総リクエスト数×100）。

    ●  反応時間： 応答を返すまでの時間。これはサービス速度を示す指標である。

    例えば、決済処理サービスで一貫して高いエラー率が見られる場合、APIエラーやサービスタイムアウトなどの問題が発生している可能性があり、APIの状態、データベースの応答時間、その他の下流サービス／APIについてより詳細な調査が必要となる。

    #2 細部へのこだわりと効率性のバランス

    システムの効率性を維持しながら、得られる知見の質を損なわないよう、選択的な監視とインテリジェントなデータ収集を実施してください。トレースデータに対して適応型サンプリングを実装すると効果的です。通常運用時には、トラフィックのごく一部（例えば1～5%）をサンプリングして詳細なトレースを行います。異常発生時やエラー発生時には、この割合を増やして分析に必要なデータをより多く取得します。

    ユーザー認証サービスを考えてみましょう。このサービスは、通常時は必要最低限​​の情報（例えばINFOレベル）のみをログに記録し、集計されたパフォーマンス指標を収集します。しかし、応答時間の急激な増加などの異常が検出された場合、サービスは自動的に詳細なログレベル（例えばDEBUGレベル）に切り替わります。監視チームは、通常運用時に大量のログを精査することなく、問題を診断できます。

    #3 状況に応じて監視を動的に調整する

    インフラストラクチャ・アズ・コード（IaaC）と構成管理ツール（Terraform、Ansibleなど）を使用して、監視レベルを変更する条件をスクリプト化し、自動化します。

    例えば、eコマースアプリケーションでは、決済サービスはスループットやエラー率といった標準的な指標に基づいて監視されます。監視データに基づいて動作する機械学習モデルが異常（例えば、スループットの急激な低下）を検知すると、アラートが発せられます。このアラートによってスクリプトが実行され、決済サービスのログ記録とトレースの粒度が向上することで、迅速な診断と問題解決が可能になります。

    #4 異常検知を優先する

    マイクロサービス監視における異常検知は、システムの信頼性とユーザー満足度を維持するために不可欠です。システム動作やパフォーマンスの異常を早期に検知することで、問題が深刻化してユーザーエクスペリエンスやシステムの安定性に影響を与える前に、積極的に対処することができます。

    まず、サインアップ、ログイン、チェックアウトなど、アプリケーション内の重要なユーザー行動をマッピングすることから始めましょう。これらの行動経路を理解することで、どのマイクロサービスをより綿密に監視する必要があるかを優先順位付けできます。すべてのサービスにわたる主要業績評価指標（KPI）を収集する監視ソリューションを実装してください。これには、エラー率や応答時間だけでなく、トランザクション量、同時接続ユーザー数などのより詳細な指標も含まれます。

    リアルタイムのデータ分析には、Apache KafkaやApache Flinkなどのストリーミングデータ処理フレームワークを使用してください。データストリームを分析することで、異なるサービス間で発生する異常をリアルタイムで関連付け、システム全体の健全性への影響を迅速に把握できます。

    各マイクロサービス内に診断ツールを統合し、異常発生源を効果的に特定できるようにします。これには、オンデマンドまたは特定の異常トリガーに応じて起動できる詳細なログ記録およびトレースシステムの構築が含まれます。

    例:

    ユーザー認証、商品検索、在庫管理、決済処理にマイクロサービスを使用するeコマースプラットフォームを考えてみましょう。異常検知システムは、決済処理サービスにおけるエラー率の異常な急増を検知するかもしれません。システムは自動的に詳細なトレースを開始し、詳細なレベルで膨大なログとパフォーマンス指標を収集します。これらのログには、データベースクエリ、外部API呼び出し、内部処理ステップに関する詳細情報が含まれます。また、検知によってアラートがトリガーされるため、エンジニアはデータを迅速に分析し、データベース応答の遅延や外部APIとのやり取りの失敗など、問題が発生した正確なステップを特定できます。

    #5 パフォーマンス監視を使用してキャパシティプランニングとインフラストラクチャのスケーリングを行う

    まず、マイクロサービスの現在および過去のパフォーマンスデータを分析し、使用パターンと成長傾向を把握します。CPU使用率、メモリ使用量、ネットワークI/Oなどの指標における長期的な傾向を調べ、ピーク使用時間と通常の運用基準値を特定します。

    予測分析を用いることで、将来のキャパシティ要件を予測できます。Google CloudのAI Platformのようなツールは、過去のデータに基づいて将来のトラフィックを予測するのに役立ちます。予測結果は、クラウド環境における自動スケーリングポリシーの設定にも活用できます。例えば、CPU使用率が一定期間70%を超えた場合に、新しいサービスインスタンスを起動するといったことが可能です。このように対象を絞ったスケーリング手法は、アプリケーションスタック全体をスケーリングするよりも効率的です。

    #6 マイクロサービスの管理と可観測性を向上させるためにサービスメッシュを統合する

    マイクロサービスアーキテクチャにサービスメッシュを組み込むことで、トラフィック管理と可観測性の実現方法に革命をもたらすことができます。この統合により、各マイクロサービスのパフォーマンスと健全性に関する可視性が向上するだけでなく、サービス間の通信に対する高度な制御も可能になります。

    まず、既存の監視ソリューションと容易に統合できるIstioなどの適切なサービスメッシュプラットフォームを選択します。次に、マイクロサービス全体にサービスメッシュをデプロイします。通常、これには各マイクロサービスの横にサイドカープロキシ（Envoyなど）をインストールし、すべてのネットワーク通信を処理することが含まれます。

    サービスメッシュを設定して、各サービスのパフォーマンスと健全性に関連するメトリックを収集およびエクスポートします。これらのメトリックが監視ツールに確実に取り込まれるようにしてください。設定が完了したら、次の操作を実行できます。

    ● サービス利用に関する詳細なデータにアクセスできます。

    ● サービスメッシュのトラフィック制御機能を使用して、これらの相互作用を実験し最適化します。

    ● サービスメッシュのログ記録およびトレース機能により、エラーとその発生源を迅速に特定します。

    例えば、Istioのテレメトリ機能を使えば、特定のサービスパスによって発生する遅延を把握したり、ネットワークを介したリクエストの流れを追跡したりできます。カナリアデプロイメントやA/Bテストといった手法は、サービスメッシュを通して直接管理でき、変更が主要な指標にどのような影響を与えるかを監視できます。

    セキュリティのためのマイクロサービス監視

    マイクロサービスというパラダイムでは、サービスは疎結合でありながらも連携して機能するため、個々のコンポーネントや相互作用を保護する必要性がより一層重要になる。

    まず、各マイクロサービスの公開エンドポイントすべてを監査します。これらのエンドポイントの性質（REST、GraphQLなど）、目的、および既存のセキュリティ対策を文書化します。次に、各エンドポイントの特定のニーズに合わせてカスタマイズされたWebアプリケーションファイアウォール（WAF）とネットワークファイアウォールを実装します。その後、エンドポイントの使用パターンと脆弱性評価に基づいて、カスタムセキュリティルールを設定します。脅威の状況の変化に応じて、ファイアウォールルールとネットワークポリシーを定期的に更新および改善します。

    マイクロサービスアーキテクチャ向けにカスタマイズされた侵入検知システム（IDS）と侵入防御システム（IPS）を統合することで、継続的なセキュリティ監視を実現します。ネットワークセグメンテーション、転送中のデータに対するTLS暗号化、および各サービス間のやり取りにおける堅牢な認証・認可メカニズムを使用します。

    監視すべき指標には、以下のようなものがあります。

    ● マイクロサービス間の通信で検出されたセキュリティインシデントの数と種類（例：不正アクセス試行、データ漏洩）。

    ● 遅延とスループットの指標。セキュリティ対策がサービス間通信に与える影響を示します。

    ● 侵入試行の成功率と失敗率。

    ● 検出された脅威や脆弱性に対応して行われるポリシーの更新やルール変更の頻度と内容。

    ● 検出された脅威に対するインシデント対応時間。

    ● 不審または悪意のあるトラフィックとしてフラグ付けされたトラフィックの割合。

    ● 事前に定義されたセキュリティ基準およびプロトコルへの準拠率。

    結論

    マイクロサービスアーキテクチャのダイナミクスにおいて、モニタリングは運用上の卓越性の基盤を形成し、サービスの最適な実行と問題の迅速な解決を保証します。リクエストレート、エラーレート、応答時間などの主要なメトリクスは、ボトルネックやサービスタイムアウトなどの問題を特定するために不可欠です。LogicMonitorは、サービス全体にわたるリクエスト経路に関する詳細なインサイトを提供します。最終的に、マイクロサービスのモニタリング戦略とベストプラクティスは、サービス指向がますます強まる世界において、デジタルビジネスの堅牢性、効率性、セキュリティを向上させるという包括的な目標を反映しています。

    あらゆる規模のマイクロサービスにわたるリクエストを、リアルタイムで追跡します。

    LogicMonitorは、分散チームにサービス、コンテナ、インフラストラクチャ全体にわたるエンドツーエンドの可視性を提供し、障害がサービス境界を越えて隠蔽されることがないようにします。.

    よくあるご質問

    マイクロサービスの監視は、なぜモノリシックアプリケーションの監視よりも難しいのでしょうか？

    モノリス型システムでは、リクエストは1つのプロセスで実行され、1つのログストリームを生成します。一方、マイクロサービス型システムでは、1つのユーザーリクエストが数十ものサービスを経由する可能性があり、それぞれのサービスには独自のログ、メトリクス、および潜在的な障害ポイントが存在します。これらのシグナルをサービス境界を越えて関連付けるには、分散トレーシング、集中ログ集約、およびサービスレベルのメトリクス収集が必要ですが、これらはモノリス型システムでは不要です。

    サービスメッシュとは何ですか？また、マイクロサービスの監視にどのように役立ちますか？

    サービスメッシュは、サービス間の通信を処理するインフラストラクチャ層です。コードの変更を必要とせずに、すべてのサービス間のやり取りに関するテレメトリ（レイテンシ、エラー率、トラフィック量）を自動的に収集します。これにより、すべてのサービスにわたって一貫した可視性が確保され、各サービスを個別に計測することなく、大規模なマイクロサービス環境で可観測性を構築するための強力な手段となります。

    SLOとは何ですか？また、マイクロサービスの監視においてSLOが重要な理由は何ですか？

    サービスレベル目標（SLO）とは、サービスがどのように動作すべきかを示す測定可能な目標です。例えば、リクエストの99.9%が200ミリ秒以内に完了する必要があります。SLOを設定することで、監視の目的が明確になります。あらゆる変動に対してアラートを発するのではなく、ユーザーに影響を与える閾値を超えるリスクがある場合にのみアラートを発するようになります。マイクロサービスにおいては、SLOに基づいたアラートによって、個々のサービスメトリクスを個別に監視することによって生じるアラート疲労を防ぐことができます。

    マイクロサービスを高頻度でデプロイする場合、どのように監視を行うべきでしょうか？

    すべての監視データをデプロイメントメタデータ（サービス名、バージョン、デプロイメントタイムスタンプ）と関連付けることで、パフォーマンスの変化が特定のリリース後に発生したかどうかを即座に判断できます。フィーチャーフラグとカナリアデプロイメントを使用して影響範囲を限定し、監視プラットフォームがバージョンごとにデータをセグメント化して、特定のデプロイメントの前後のパフォーマンスを比較できるようにします。

    デントン千倉著

    テクニカルライター

    デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

    免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

    © LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。