【NIC x Ops(にこぷす)通信】(Instana編)実際の画面で徹底解説!IBM Instanaが持つ3つの強力な特長
投稿者:高巣
目次
- はじめに:今回のテーマ
- そもそも「Observability(可観測性)」とは?
- 実際の画面で解説!Instanaの3つの強力な特長
- まとめ
皆さま、こんにちは!
このテックブログでは、IT運用に関する内容を連載、「にこぷす通信」をお届けしています。
「NIC x Ops(にこぷす)」とは?
『NIC x Ops(にこぷす)』とは、
私たちの会社であるNTTインテグレーション(NI+C)の運用ノウハウと、
IBMさんの強力なソリューションを
Collaboration(コラボレーション)させた、IT運用高度化シリーズ(Ops)のニックネームなんです。
現代のIT運用の現場は、システムの複雑化や人手不足など、課題が山積みです。そんな現場を少しでも楽に、そしてエンジニアの皆さんが笑顔で「攻めの運用」ができるように支えたい。そんな想いがこの「にこぷす」には込められています。
「にこぷす」には、Instana(可観測性)のほかにも、Turbonomic(リソース最適化)やTerraform(インフラ自動化)など、IT運用を劇的に変える製品がたくさんあります。
これからもこの通信を通して、「IT用語は難しいけれど、中身を知ればこんなに便利で面白いんだ!」というテクニカルな内容をご紹介していきますので、どうぞよろしくお願いします。
1.はじめに:今回のテーマ
みなさま、改めましてこんにちは!IBM Instana担当の高巣です。
第1回では、「Linuxって何?」という超初心者状態の私が、AWS環境にInstanaエージェントを導入する手順をお届けしました。
第2回となる今回のテーマは、「実際のInstana画面から解説するInstanaの特長」です!
「そもそもObservability(可観測性)ツールって何ができるの?」「従来の監視ツールの画面と何が違うの?」という疑問をお持ちの皆様に向けて、実際のダッシュボードやUI(ユーザーインターフェース)の画面イメージを交えながら、Instanaの具体的な機能とメリットを紐解いていきます。
2.そもそも「Observability(可観測性)」とは?
みなさまにとって「システム監視」や「APM(アプリ性能管理)」はお馴染みの言葉だと思いますが、従来の監視と、Instanaが提供する「Observability(可観測性)」には決定的な違いがあります。(※Observabilityには、APMの機能も内包されています!)
具体的に何が違うのか、まずは分かりやすく表で比較してみましょう。
| 従来のシステム監視 | InstanaによるObservability(可観測性) | |
| 目的 | 「何かが異常であること」を知らせる | 「なぜ問題が発生したのか」を即座に特定する |
| アプローチ | 死活監視をはじめ、CPUやメモリといった個別のしきい値超過をトリガーにする | システム内部(リクエストのライフサイクル全体)をエンドツーエンドで追跡する |
| 障害時の対応 | エラーの「事実」は分かっても、原因特定のために分散したログの追跡が必要となり、特定に数時間を要する | インフラからアプリケーション、DB、エンドユーザー体験までを一気通貫で紐付け、問題の「根本原因(コード行)」を瞬時に可視化 |
クラウドネイティブな最新技術やマイクロサービス化、コンテナ環境への移行によって、今のシステムは非常に複雑に絡み合っています。ユーザーが画面のボタンを1つ押しただけでも、裏側では何十個もの小さなプログラムやサーバーが「バケツリレー」のようにデータを渡しながら動いている状態です。もし不具合が起きて手動で原因を探そうとすると、各担当者が深夜までログを睨み合ってエラー探しをするような大惨事になりかねません。数千台のサーバーログからエラー箇所を人力で探すのは不可能です。
こうした「人間には追いきれない複雑すぎるシステムの落とし穴」を解消し 、24時間自動で健康状態を『見える化』してくれるAI搭載のシステム健康診断ツールが、このInstanaなのです。
※より詳しい用語の定義や技術的な背景は、IBMの解説記事「オブザーバビリティとは?」をご参照ください
3.実際の画面で解説!Instanaの3つの強力な特長
ここからは、実際のInstanaの管理画面(UI)でどのようなデータがどのように見えるのか、画面のポイントを交えながら3つの特長を解説します。
特長①:サービスの品質とユーザー体験(UX)をリアルタイムに把握することが可能
サービスの品質

上記の画面は、Instanaを導入した監視対象のサーバーから収集している情報です。
- 左側:サーバーへのリクエスト数(呼び出し)
- 中央:サーバー応対におけるエラー発生数(エラーのある呼び出し率)
- 右側:サーバーからの応対時間(待ち時間)
ユーザー体験(UX)

上記の画面は、システムの利用者のWebブラウザなどから収集したデータに基づいて情報を表示しています。
- 左側:利用者のアクセス数(ページ・ビュー)
- 中央:利用者への応答におけるエラー発生数(JSエラー)
- 右側:利用者への応答時間(onLoad時間)
このように、サーバー側の「リクエスト数」「エラー発生数」「応答時間」と、ユーザー側の「アクセス数」「エラー発生数」「応答時間」を、それぞれリアルタイムに収集できるのがInstanaの特長です。
従来のシステム監視のようにサーバーの状態だけを見るのではなく、ユーザー側の状態も同時に把握することができます。
従って、「エラー応答の増加」や「応答時間の劣化」といったシステム側の状態変化をいち早く捉え、障害の早期検知を実現することが可能です。
特長②:依存関係とアプリケーション内部の可視化することが可能
現代のシステムは、ユーザーが画面のボタンを1つ押した裏側で、何十個もの小さなプログラムやコンテナが「バケツリレー」のようにデータを渡しながら動いています。
Instanaはこの通信のバケツリレーを、以下の2つの強力な画面で完全に可視化(可観測)します。
依存関係の自動マッピング

上記の画面は、監視対象のサーバーから収集している情報で、Instanaのエージェントを1つ展開するだけで、内部で動いているソフトウェア、データベース、プログラムといったシステム間の連携を自動的に収集し、トポロジーマップ(関係図)を自動生成します。どこでエラーが起き、どこに影響が及んでいるかが視覚的に一発でわかります。
アプリケーション内部の処理フロー

ユーザーのリクエストを受け付けてから応答を返すまでの一連の処理をタイムライン形式で表示します。「どのモジュールが呼ばれたか」「それぞれの処理で何ミリ秒費やしたか」を追跡(トレース)できるため、エラーが発生した場合は「最初にエラーを吐いたコード行(根本原因)」をピンポイントで特定できます。
従って、Webサーバー、APサーバー、DBサーバーのログを1台ずつ順に解析していくような、ベテランスペシャリストのスキルと時間(時には数時間〜数日)を要する作業は不要になります。このトレース画面を見るだけで、誰でも迅速な原因特定が可能になります。
特長③:多様な情報提供と担当者間のコラボレーション
システム運用には、「インフラ運用担当者」「アプリ開発担当者(Dev)」「事業部門(サービスオーナー)」など、異なる役割のメンバーが関わっており、それぞれ見たい情報が異なります。
Instanaは、これらの異なる要望を「カスタムダッシュボード」機能によって1つの画面に集約します。
- インフラ運用者担当向け: システムのリソース状況、稼働状況(SLO指標など)
- アプリ開発担当者向け: パフォーマンス劣化のリスト、エラー状態
- 事業部門向け: サービスの利用者数、利用者満足度(APDEXなど)
さらに強力なのが、「今見ている画面そのものをボタン一つで他の担当者に共有できる機能」です。
従来のように、インフラ担当が「インフラに問題がない証明」としてグラフのキャプチャを撮ってメールやチャットでアプリ担当に送る……といった手間の不文律はもうありません。全員が同じツール、同じダッシュボード画面を見ながら会話できるため、情報の分断を防ぎ、部門を越えたシームレスなコラボレーションを強力に後押しします。
まとめ:Instanaで変わる私たちの運用保守スタイル
第2回となる今回は、InstanaのダッシュボードやUIの画面イメージを交えながら、その具体的な機能をご紹介してきました。実際に画面を見ていく中で、Instanaの強力な機能が私たちの現場をどう変えてくれるのか、改めてそのメリットを振り返ってみましょう。
- 🔄 サービス品質とユーザー体験(UX)のリアルタイム可視化:
サーバー側の状態だけでなく、ユーザー側の「JSエラー」や「応答時間(onLoad時間)」まで同時に見られるのが大きな強みです。「エラー応答が増えている」「応答時間が遅くなっている」といった、ユーザーからクレームが来る前の障害の早期検知のシチュエーションでは、Instanaの「ユーザー体験(UX)とサービスの品質把握」機能が大いに利用できそうです。いち早く状態変化を捉えることで、先回りしたプロアクティブな対応に役立ちます。 - 📍自動マッピングとタイムライン(トレース)機能:
Instanaには、エージェントを1つ入れるだけで複雑に絡み合った「通信のバケツリレー」のようなシステム間の連携を自動収集し、関係図を自動生成してくれる機能があります。この機能は、これまでWebサーバーやAPサーバー、DBサーバーのログを1台ずつ順に解析していたような、ベテランのスキルと多大な時間を要するトラブルシューティングの脱属人化・高速化に大いに役立ちそうです。これにより、誰でも迅速な原因分析と特定の早期対応が可能になります。 - 🤝 カスタムダッシュボードと画面共有機能:
インフラ担当、アプリ開発担当、事業部門など、それぞれに必要な情報が一元化され、担当ごとに異なるツール利用と情報の分断を防げます。特に、インフラ運用担当とアプリ開発担当(Dev)の間で障害の発生箇所や影響範囲を調査するシチュエーションでは、Instanaの「画面共有」機能が大いに利用できそうです。「今見ている画面そのものをボタン一つで共有できる」ため、グラフのキャプチャを撮ってチャットで送り合うような手間の不文律を解消し、部門を越えたシームレスなコラボレーションを強力に後押ししてくれると思います。
これまでの運用保守は、アラートが鳴ってから「画面をポチポチして多くの時間をかけてログを探す」という、事後対応になりがちでした。しかしInstanaを使えば、特定の人材に頼ることなくシステムの「現状」を常に把握し、事後対応型からプロアクティブ(前向き)な運用へとシフトすることができます。トラブルシューティングに費やしていた不毛な時間を最小限に抑え、そこで生まれた時間を、私たちエンジニアが本来やりたい「新しい価値創造」や「攻めの運用」へと充てていきましょう!
💡Instana の実際の導入事例もありますので、是非ご覧ください。
【鼎談記事/鼎談動画】お客様・日本IBM・NI+Cの3社が語る、障害対応・状況把握・情報共有の変革の“リアル”を徹底解析。
次回予告
「【実践編】テストアプリで検証、「依存関係マップ」の自動生成機能」(予定)
今回はInstanaの概念と特長についてお勉強しましたが、やっぱりエンジニアたるもの、実際の画面がどう動くのかが一番気になりますよね!
次回の第3弾では、第1弾で構築した環境をさらに掘り下げ、「実際にアプリケーションを入れて監視してみた!」をお届けします。
アプリを1つ入れただけで、噂の「依存関係マップ」は本当に自動生成されるのか?データが流れ込んで画面がどのように賑やかになっていくのか、その感動の瞬間を実際の画面を交えて徹底レポートします!「これなら自社システムでも使えそう!」とイメージが湧く内容をお届けしますので、次回もぜひチェックしてくださいね!
「にこぷす通信」について
「NIC × Ops(にこぷす)通信」は、隔週で皆さまに情報をお届けします。
このシリーズでは、Instana(可観測性)をはじめ、Turbonomic(リソース最適化)やTerraform(インフラ自動化)など、IT運用を劇的に変える製品をピックアップしていきます。
これからも最新の技術検証をチームで継続し、皆さまの現場ですぐに役立つ「有益な知見」を全力で共有していきます。 次回の連載もお楽しみに!