WEB問題集
解説
【正解: A】の理由
Azure Monitor は Azure リソース / アプリ / インフラの Metrics と Logs を統合収集する中核観測プラットフォームです。Alerts / Dashboards / Workbooks / Auto-scale を提供し、Application Insights / Sentinel / Defender for Cloud / Container Insights の基盤として機能します。
【他選択肢が違う理由】
- B. VM 起動 / 停止管理のみ: VM 電源制御は Azure Automation の領域で、Monitor は観測に特化したサービスです
- C. リレーショナル データベース: RDB 機能は Azure SQL Database / Cosmos DB の役割で、Monitor とはカテゴリが異なります
- D. 廃止された機能: Azure 全体の可観測性を担う現役の中核プラットフォームで、観測の三本柱 (Logs / Metrics / Traces) を統合提供します
解説
【正解: A】の理由
Metrics は時系列の数値データで 1 分解像度で収集され、低レイテンシのリアルタイム アラート / Auto-scale に最適です。Logs は構造化レコードで KQL による複雑分析 / トラブルシューティング / 長期保管に向き、両者は補完関係で組み合わせて完全な可観測性を実現します。
【他選択肢が違う理由】
- B. 完全に同じもの: Metrics と Logs はデータ構造 / 保持期間 / クエリ方式 / 用途が異なる別カテゴリです
- C. オンプレ / クラウド分離: 両者とも Azure クラウド サービスで、オンプレ / クラウドという区分ではありません
- D. Metrics が廃止: Metrics は Azure Monitor の中核機能として現役で、Auto-scale の判断基盤としても必須です
解説
【正解: A】の理由
Log Analytics workspace は Azure Monitor のログを集中保管 / クエリするコンテナで、Diagnostic Settings / Application Insights / Sentinel / Defender for Cloud などからのログを集約します。KQL で柔軟な検索 / 集計 / 可視化が可能で、保持期間は最大 730 日 (Archive で 12 年) まで設定できます。
【他選択肢が違う理由】
- B. 物理ハードウェアの保管庫: クラウド上の論理サービスで、物理ストレージ装置ではありません
- C. OLTP リレーショナル DB: ログ専用のクエリ基盤で、トランザクション処理用の RDB ではありません
- D. 廃止された機能: Sentinel / Defender / Container Insights の基盤として機能する現役の中核コンポーネントです
解説
【判定: はい】の理由
Application Insights は Web アプリの APM ツールで、Auto-Instrumentation により .NET / Java / Node.js のコード変更なしで Request / Exception / Dependency / Distributed Tracing を自動収集できます。Application Map で依存関係を可視化し、一つ目の APM 観測要件を満たします。
【「いいえ」が違う理由】
Application Insights は Live Metrics で 1 秒解像度のリアルタイム監視、Smart Detection で AI 異常検知、Profiler / Snapshot Debugger で本番分析を提供します。OpenTelemetry 準拠でマイクロサービスの分散トレーシングにも対応し、Microsoft 推奨の APM ベスト プラクティスです。
解説
【判定: はい】の理由
Diagnostic Settings は Azure リソースの Activity Log / Resource Logs / Metrics を Log Analytics workspace に転送する標準機能です。VM は Azure Monitor Agent + Data Collection Rule、SQL Database は SQLInsights / Errors、Storage は読み書きログを集約でき、二つ目のインフラ層メトリクス + ログ集約要件を満たします。
【「いいえ」が違う理由】
Diagnostic Settings は KQL で統合分析が可能で、アプリ + インフラ + セキュリティのクロスレイヤー分析を実現できます。Application Insights と同じ workspace に集約することで、相関分析やトラブルシューティングが効率化され、可観測性の中核として機能します。
解説
【判定: はい】の理由
Azure Monitor Alerts と Action Group の組み合わせは即時通知 + 自動応答を実現します。Alert は Metrics / Log / Activity Log / Smart Detection の 4 タイプ、Action Group は Email / SMS / Webhook / Logic Apps / Functions / Automation Runbook で多様な応答を実行でき、三つ目の要件を満たします。
【「いいえ」が違う理由】
例として VM CPU 95% 超え 5 分継続で Alert 発火、Action Group が Logic Apps を起動し VM 再起動 / VMSS スケールアウト / Slack 通知 / ServiceNow チケット作成を実行できます。これにより MTTR を 50-80% 削減でき、SaaS 監視のベスト プラクティスとなります。
解説
【正解: A】の理由
Application Insights は Request / Dependency / Exception テレメトリの自動収集、Application Map による依存関係可視化、Smart Detection の AI 異常検知、Live Metrics の 1 秒解像度リアルタイム監視、Distributed Tracing の OpenTelemetry 準拠相関分析を提供します。
【他選択肢が違う理由】
- B. 物理ハードウェアの管理: Application Insights は SaaS の APM ツールで、物理機器管理機能はありません
- C. リレーショナル データベース: RDB 機能は Azure SQL Database の領域で、APM とは別カテゴリです
- D. ロード バランサ: 負荷分散は Azure Load Balancer / Application Gateway の領域で、観測機能ではありません
解説
【正解: A, B, C】の理由
Azure Monitor の中核構成要素が該当します。Application Insights が APM テレメトリ (Request / Dependency / Exception / Distributed Tracing) を自動収集、Log Analytics workspace がログを集中保管し KQL 分析基盤を提供、Alerts + Action Group が Metrics / Log ベースのアラートと Email / Logic Apps / Functions 等の多様な応答を実行します。
【他選択肢が違う理由】
- D. Microsoft Excel: 表計算ソフトウェアで、Azure Monitor の構成要素ではありません
- E. Azure DNS: 名前解決サービスで、観測 / 監視機能とは別カテゴリのサービスです
次の各ステートメントについて、Azure 監視 / 観測性に関する記述として正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。
注: 正解 1 つにつき 1 点が与えられます。
| ステートメント | はい | いいえ |
|---|---|---|
Azure Monitor の Metrics は時系列数値データで即時アラート / Auto-scale 向け、Logs は構造化レコードで KQL 分析向け。両者は補完関係。 正しいです。Metrics は 1 分解像度の時系列数値データで Auto-scale や即時アラートに最適化されており、Logs は構造化レコードで KQL による複雑分析 / トラブルシューティング / セキュリティ調査に向きます。両者は補完関係にあります。 | ||
Application Insights は Web アプリ専用で、VM や DB のメトリクス / ログは扱えない。 誤りです。Application Insights は APM 層に特化しますが、Diagnostic Settings 経由で VM / SQL DB / Storage 等のインフラ ログを同じ Log Analytics workspace に集約でき、KQL でアプリ + インフラの統合分析が可能です。 | ||
Azure Monitor の Action Group は Alert 発火時に Email / SMS / Webhook / Logic Apps / Functions / Automation で多様な応答を実行できる。 正しいです。Action Group は通知 (Email / SMS / 音声通話 / Push) と自動応答 (Webhook / Logic Apps / Functions / Automation Runbook / ITSM 連携) を統合し、VM 再起動 / VMSS スケール / Slack 通知 / ServiceNow 連携を実装できます。 |
次の各ステートメントを完成させるために、最も適切な Azure Monitor 構成要素を選んでください。同じ選択肢は 2 回使用できません。
| ステートメント | 選択 |
|---|---|
Web / モバイル / API アプリの Request / Exception / Dependency テレメトリを自動収集し、Application Map で依存関係を可視化する機能は [ ] である。 Application Insights が該当します。APM ツールとして Auto-Instrumentation で .NET / Java / Node.js を自動計測し、Request / Dependency / Exception / Distributed Tracing を収集、Application Map で依存関係を可視化、Smart Detection で AI 異常検知を提供します。 | |
Azure リソースから収集された全ログを集中保管し、KQL で柔軟な分析を実行する基盤は [ ] である。 Log Analytics workspace が該当します。Diagnostic Settings / Sentinel / Defender for Cloud / Container Insights / VM Insights のログをすべて集約し、KQL でアプリ + インフラ + セキュリティのクロスレイヤー分析を実現する観測スタックの中心です。 | |
メトリクス / ログ ベースのアラート ルールを定義し、発火時に Email / Logic Apps / Webhook で多様な応答を実行する機能は [ ] である。 Alerts + Action Group が該当します。Metrics / Log / Activity Log / Smart Detection の 4 タイプのアラート ルールと、Email / SMS / Webhook / Logic Apps / Functions / Automation Runbook / ITSM 連携の応答先定義で MTTR を 50-80% 削減できます。 |