クラウド利用が広がる一方で、運用現場には次のような課題が生まれています。
- クラウドの監視は CloudWatch / Azure Monitor / Stackdriver に分散
- リソース増減が激しく、運用が追い付かない
- タグ運用がうまく機能していない
- サーバーとクラウドサービスを横断した監視ができない
- そもそも「クラウドを誰が監視するのか」問題が発生する
OpsRampは クラウドプロバイダー3社（AWS・Azure・GCP）の監視を一つの画面に統合 し、“オンプレもクラウドもまとめて見える世界” を実現します。
本記事では、OpsRampがどのようにクラウド監視を統合するのかを解説します。
1. OpsRampのクラウド監視とは？
OpsRampのクラウド監視は、Cloud Discovery + メトリクス収集 + タグ連動のポリシー設定 を組み合わせた仕組みです。
クラウドAPIを通じて、以下を自動で取り込みます：
- インスタンスの一覧（EC2 / Azure VM / GCE など）
- 容量・スペック情報
- メトリクス（CPU、ディスクIO、ネットワークなど）
- タグ（Environment, Owner, Service など）
- LB / DB / Functions / Storage の情報
- 状態（Running / Stopped など）
クラウドネイティブサービスも対象に含まれるため、IaaSだけでなくPaaSまで監視を伸ばせる のが最大の特徴です。
2. AWS監視 — CloudWatch依存からの脱却
OpsRampがAPI経由で取得する主なAWSリソースは以下の通り：
- EC2
- EBS
- RDS
- ELB / ALB / NLB
- DynamoDB
- Lambda
- ECS / EKS
- CloudFront
- S3（容量/リクエスト等）
CloudWatchのメトリクスを取り込みつつ、OpsRampとして以下を実現します。
① EC2監視：OSレベル＋クラウドレベルの統合監視
EC2には2種類の監視が存在します：
- クラウドレベル（CloudWatch）
- サーバーレベル（CPU/メモリ/プロセスなど）
OpsRampは両者をまとめて管理できます。
オンプレサーバーと同じ画面でEC2の詳細監視が可能になるため、
「運用チームをクラウドとオンプレで分ける必要がない」という強いメリットがあります。
② タグ連動自動監視（Environment=Prod → ポリシー適用）
AWSでは以下のようなタグ運用が一般的です：
- Environment = Production
- Owner = ApplicationTeam
- Service = WebAPI
OpsRampはタグを読み取り、
タグに基づいて自動的に監視ポリシーを適用できます。
例：
Environment=Production → 厳しい閾値＆通知あり
Environment=Dev → 閾値緩め＆通知なし
クラウドのスケールアウト環境において、これは大きな武器になります。
③ AWSへのRunbook Automation実行
OpsRampからAWSに対して以下の操作を自動実行できます：
- EC2再起動 / 停止 / 起動
- ASG の Desired 数変更
- Lambda実行
- S3操作
- IAM情報チェック
- ECSタスク再起動
「アラート → 自動復旧」という流れをAWS上でも構築できます。
3. Azure監視 — Azure Monitor + OpsRamp のハイブリッド
OpsRampがAzureから取得する主な対象：
- Azure VM
- Managed Disk
- Storage Accounts
- Azure SQL
- App Service
- Load Balancer
- Kubernetes (AKS)
- Cosmos DB
- Virtual Network
Azure MonitorとOpsRampが補完し合うイメージです。
① Azure VM監視（Linux/Windows問わず）
- OSのリソース監視
- ブート診断ログ
- VMの状態
- NIC/ディスクの性能
OpsRamp Agent を使えば、オンプレ同様に詳細監視が可能になります。
② Azure Tags との連動
AWSと同様に、Azureタグとの連動が可能です。
- CostCenter=100 → 通知オン
- Stage=Prod → メモリ監視を厳しく
- Owner=SRE → チケットの自動アサイン
タグを起点に監視の標準化ができます。
4. GCP監視 — Stackdriverからのメトリクス収集
OpsRampが取得できるGCPリソース：
- Compute Engine（VM）
- Cloud SQL
- Load Balancer
- Kubernetes Engine（GKE）
- Cloud Storage
- Pub/Sub
GCPはAPI構造がシンプルなため、設定時間が短く済みます。
① Compute Engineの監視
- OSレベル監視（Agent有り/無し）
- CPU/ディスクIO/ネットワーク
- 自動発見（ゾーン・リージョンごと）
- ラベル連動した監視ポリシー
OpsRampが得意な「オンプレ + GCP の混在環境」の運用がとても楽になります。
5. クラウド特有の監視に強いポイント
クラウドは“サーバー監視だけ”では片付かないため、OpsRampは以下の領域もカバーします。
① LB（ロードバランサ）の健全性
- リスナー
- ヘルスチェック
- バックエンド状態
- 接続数
「クラウドLBは監視が抜けがち」なため、とても価値があります。
② マネージドDB（RDS / Azure SQL / Cloud SQL）
- 接続数
- レイテンシ
- ストレージIO
- スロークエリ
- 失敗した接続
DBAがいない現場では特に効果的です。
③ Kubernetes（EKS / AKS / GKE）
- Pod / Node の状態
- リソース消費
- オートスケールの状況
- 構成ドリフト
コンテナ運用環境では OpsRamp の価値が跳ね上がります。
6. プリセールスが押さえておくべき「刺さるポイント」
① オンプレとクラウドを“本当の意味で”統合監視できる
→ ツール乱立を一掃できる
② タグ連動の自動監視は、OpsRampの強力な武器
→ クラウドスケールに最適化された運用が可能
③ RunbookでAWS/Azureを操作できる
→ 自動化提案に繋がりやすい
④ ネイティブのCloudWatch/Azure Monitorよりも“運用目線で見やすい”
→ 運用センターの標準画面として使える
まとめ：クラウド時代の統合監視基盤としてOpsRampは強力
- AWS/Azure/GCP をAPI経由で自動検出
- タグ連動で監視ポリシーの自動適用
- CloudWatch/Azure Monitorと連携
- IaaSだけでなくPaaSまでカバー
- 自動復旧（Runbook Automation）が使える
- オンプレとクラウドを同時に可視化できる
これにより、クラウド監視・VM監視・ネットワーク監視を単一画面で統合するという、現場の悲願が実現します。