WEB問題集
解説
【正解: A】の理由
Azure Monitor は Azure の中核観測プラットフォームで、Metrics と Logs を統合的に扱います。Alerts / Workbooks / Dashboards / Auto-scale を提供し、Application Insights / Microsoft Sentinel の基盤としても機能します。可観測性の三本柱 (Logs / Metrics / Traces) を 1 サービスでカバーします。
【他選択肢が違う理由】
- B. VM 起動 / 停止管理のみ: VM 電源制御は Azure Automation の領域で、Azure Monitor は観測 / 監視に特化したサービスです
- C. リレーショナル データベース: RDB 機能は Azure SQL Database / Cosmos DB の役割で、Monitor とは別カテゴリです
- D. SSL 終端: TLS 終端は Application Gateway / Front Door の領域で、Monitor は SSL 機能を持ちません
解説
【正解: A】の理由
KQL は Microsoft が設計したログ / メトリクス分析向けのクエリ言語です。パイプ演算子で where / project / summarize / join を繋ぐフロー指向の構文を持ち、Log Analytics / Application Insights / Microsoft Sentinel / Azure Data Explorer の共通クエリ言語として機能します。
【他選択肢が違う理由】
- B. JavaScript の方言: KQL はクエリ言語であり JavaScript とは無関係です。Azure クラウド側で実行されブラウザ専用でもありません
- C. XML マークアップ: XML はデータ表現の形式でクエリ言語ではなく、KQL とは技術カテゴリが根本的に異なります
- D. SQL と全く無関係: KQL は SQL の影響を強く受けた構文で、SELECT / WHERE / JOIN 等の概念を共有しています
解説
【正解: A】の理由
Application Insights は Web / API / マイクロサービス向けの APM サービスです。Auto-Instrumentation で .NET / Java / Node.js のテレメトリを自動収集し、Application Map で依存関係を可視化、Smart Detection で異常を AI 検知します。Live Metrics と Distributed Tracing も提供します。
【他選択肢が違う理由】
- B. 物理ハードウェア管理: APM はクラウド サービスで、物理機器の管理機能は提供しない別カテゴリです
- C. リレーショナル DB 管理: データベース管理は Azure SQL Database / Cosmos DB の役割で、APM はアプリ層の観測に特化したサービスです
- D. ロード バランサ: トラフィック分散は Azure Load Balancer / Application Gateway の領域で、APM 機能とは別領域です
解説
【判定: はい】の理由
Azure Monitor Workbooks は柔軟な可視化キャンバスで、Metrics / Logs / Resource Graph / Application Insights のデータを 1 つの対話的ダッシュボードに統合できます。Markdown / グラフ / パラメータ式で動的レポートを構築でき、VM Insights や Container Insights の組み込みテンプレートも提供されています。
【「いいえ」が違う理由】
パラメータ式や対話的フィルタ、Tab レイアウトで動的レポートを構築できます。Metrics / Logs / Resource Graph / Alerts のデータも 1 Workbook に統合できます。Workbooks は Azure Monitor ネイティブで KQL を直接埋め込め、観測データに最適化されています。
解説
【判定: はい】の理由
Azure Monitor の Alert Rules は Metric Alert / Log Alert / Activity Log Alert / Smart Detection の 4 タイプを提供します。Action Group で Email / SMS / Webhook / Logic Apps / Functions / Automation Runbook を起動でき、通知と自動応答を一連の流れで実現します。MTTR を 50-80% 削減できる中核機能です。
【「いいえ」が違う理由】
Logic Apps / Functions / Automation Runbook で VM 再起動や ITSM 連携も自動化できます。Webhook / 音声通話 / ServiceNow 等の ITSM 連携にも標準対応しています。Logic Apps / Functions の従量課金モデルで軽量に開始できます。
解説
【判定: はい】の理由
Application Insights がアプリ層の Request / Dependency / Exception を自動収集し、Diagnostic Settings 経由で VM / SQL Database / Storage のインフラ ログを同一の Log Analytics workspace に集約できます。KQL で「アプリ遅延 → VM CPU 高負荷 → SQL DTU 不足」のクロスレイヤー相関分析が実現し、統合観測要件を満たします。
【「いいえ」が違う理由】
Diagnostic Settings の構成で同一 workspace に集約できます。同じ workspace ならアプリ + インフラを KQL で統合分析できます。KQL 1 つで全レイヤーを横断分析できるのが標準アプローチです。
解説
【正解: A】の理由
Service Health は Azure プラットフォーム全体の障害情報、計画メンテナンス通知、Health / Security Advisories を提供します。一方 Resource Health は個別リソースの Available / Degraded / Unavailable 状態と原因区分 (Customer / Platform-Initiated) を可視化します。スコープが異なる補完サービスです。
【他選択肢が違う理由】
- B. 同じサービスの別名: Service Health と Resource Health は補完関係にあり、別名ではなく異なる役割を持つ独立サービスです
- C. 説明が逆: Service Health がプラットフォーム全体で広域、Resource Health が個別リソースで局所であり、選択肢の方向性が逆です
- D. サポート契約必須: 両者とも全 Azure ユーザーに標準で無料提供され、特別なサポート契約は不要です
解説
【正解: A】の理由
Diagnostic Settings は Azure リソースの Activity Log + Resource Logs + Metrics を Log Analytics workspace / Storage Account / Event Hubs に転送する標準機能です。VM は Azure Monitor Agent + Data Collection Rule で構成、SQL Database や Storage は Portal から数クリックで有効化できます。
【他選択肢が違う理由】
- B. 物理ログ管理のみ: Diagnostic Settings はクラウド リソースのログ転送機能で、オンプレ物理機器のログは対象外です
- C. VM の起動 / 停止管理: VM 電源管理は Azure Automation の役割で、Diagnostic Settings はログ転送専用です
- D. 廃止された機能: Azure 監視の中核機能として現役で、Azure Monitor の基盤データ収集として継続提供されています
解説
【正解: A, B, C】の理由
Azure Monitor は統合観測プラットフォームです。Application Insights は APM テレメトリの自動収集、Log Analytics workspace はログ保管と KQL 分析基盤、Alerts + Action Group はアラート ルールと自動応答 (Email / Webhook / Logic Apps / Automation) を担当します。これら 3 つが組み合わさって完全な観測性を実現します。
【他選択肢が違う理由】
- D. Microsoft Excel: 表計算ソフトであり Azure Monitor の構成要素ではありません。観測データのエクスポート先としての利用は可能ですが、内部コンポーネントではありません
- E. Azure DNS: DNS 名前解決サービスでネットワーク領域です。Azure Monitor は DNS の動作を監視できますが、DNS 自体は Azure Monitor の構成要素ではありません
次の各ステートメントについて、Azure Monitor に関する記述として正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。
注: 正解 1 つにつき 1 点が与えられます。
| ステートメント | はい | いいえ |
|---|---|---|
Metrics は時系列数値データで即時アラート / Auto-scale 向け、Logs は構造化レコードで KQL 分析向け。両者は補完関係。 Metrics は 1 分解像度の時系列数値で即時アラートや Auto-scale に最適、Logs は構造化レコードで KQL による複雑分析向け。Metrics は保持期間 93 日、Logs は最大 730 日 (Archive で 12 年) と保管期間も異なり用途別に使い分けます。 | ||
Application Insights は Web アプリ専用で、VM や DB のメトリクス / ログは扱えない。 Application Insights は APM ですが、Diagnostic Settings で VM / SQL DB / Storage のインフラ ログを同じ Log Analytics workspace に集約でき、KQL でアプリ + インフラの統合分析が標準アプローチです。 | ||
Action Group は Alert 発火時に Email / SMS / Webhook / Logic Apps / Automation で多様な応答を実行できる。 Action Group は通知 (Email / SMS / 音声) と自動応答 (Webhook / Logic Apps / Functions / Automation) の両方をサポート。ServiceNow 等の ITSM 連携も可能で MTTR を 50-80% 削減します。 |