サーバ監視、結局のところ”お金事情”が気になりますよね

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/614998/0c9b7523-dd21-42f0-cbe7-132c1538fc82.png)


1. はじめに
2. 企業向けサーバ監視
3. 社内サーバー監視の代替案
    - AWS Clowdwatch
    - MetricFire
    - Grafana Lab
    - Datadog
    - New Relic

#1. はじめに

現代のIT環境では、サーバーと関連するインフラを積極的に監視することがとても重要です。しかし、監視ソリューションにはさまざまな種類があり、それぞれに長所と短所があります。プラットフォームに特化したものもあれば、オンプレミスのサーバーに適したものもある一方で、クラウド・プラットフォーム上で最適に動作するものもあります。そのほかにも、他のソリューションよりも導入が簡単で、データソースとの統合範囲が広いものもあれば、他のソリューションよりも理解しやすい洗練されたUIが特徴のものもあるなど様々です。そして、ユーザーが最も気にすることはコストであり、ソリューションによってコストに大きな差があるということです。

この記事では、人気のあるサーバー監視ソリューションを比較して行きます。プラットフォームにとらわれず、費用対効果が高く、使いやすいソリューションがあるのでしょうか？

#####始めに述べておきます。その答えは「はい」です 
[MetricFire](https://try.metricfire.com/japan/?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Budget%20Guide%20to%20Server%20Monitoring)ではユーザーの求める機能を保持した上に、格安でツールを提供しています。[無料デモ](https://calendly.com/metricfire-chatwithus/chat?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Budget%20Guide%20to%20Server%20Monitoring)と[無料トライアル](https://www.hostedgraphite.com/accounts/signup-metricfire/?signup=japan&utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Budget%20Guide%20to%20Server%20Monitoring)が準備されていますので、是非実際に使用して確認してみましょう。

#2. 企業向けサーバ監視
まず、「サーバー監視」とは何か、何を対象としているのかを明確にすることから始めましょう。非常に基本的なレベルでは、サーバー監視を、可用性、運用、パフォーマンス、セキュリティ、その他の運用関連プロセスのレビューと分析を目的とした一連のプロセスとアクションとして定義することができます。

この記事では、主にサーバの実際のハードウェア（物理ハードウェアと仮想ハードウェアの両方）のパフォーマンスについてお話しさせて頂きます。アプリケーションのパフォーマンスが基礎となるサーバーリソースのパフォーマンスに直接関連し、影響を受ける場合を除き、 アプリケーションのパフォーマンス（APM)は除外しています。

サーバ監視がAPMにどのように関与するかを説明するために、予約サーバ・メモリ量に依存するアプリケーション・メトリクスを考えてみましょう（インメモリ・データベースなど）。この場合、サーバのメモリが定期的に一杯になり、予約されたメモリを割り当てることができない場合、アプリケーションメトリックは明らかに悪影響を受けますよね？　この場合、サーバのメモリ制限やメトリクスを設定する際に、アプリケーションの予約メモリの必要量を基準とすることができます。

限られた人的資源で増え続けるサーバーを管理することは、サーバーやアプリケーションを監視する際に克服しなければならない課題です。サーバーの増加に伴い、監視に専念するITエンジニアの人数を増やすことは、賢明でも現実的でもありません。必要なのは、サーバー監視のためのスケーラブルなソリューションです。IT監視担当者が監視対象のサーバーの最も重要なペインポイントを迅速に特定できるソリューションには大きな利点があルはずです。

この課題を完全に解決すれには、自社内でのソリューションとして、または専門のサードパーティのツールやサービスにアウトソーシングすることで実現することができます。この記事では、この2つの異なる方法を見て、予算内でサーバー監視を拡張するための最善の方法を分析します。

この分析では、それぞれの方法が以下のメトリックの監視をどのように処理するかを見ていきます。これは網羅的なリストではありませんが、大多数のIT部門が監視したいと思うであろう、最も一般的で最も有用なメトリクスをカバーしています。

- Requests per second (Average Load)
- Average response time
- Server error rates
- Peak response time
- Total server uptime
- Average CPU utilization
- Thread counts
- Memory utilization
- Disk I/O rates

#自社開発のサーバ監視の良い点、悪い点

前述したように、サーバー監視はすべて社内で処理するというのも一つの方法です。以下を参照にしてみてください。

1. サーバー監視に使用する特定のソリューションをリストアップして選択します。Prometheus、Grafana、Nagiosなどの人気のあるサーバー監視ソリューションのオンプレミス版が可能性としてあげられると思います。あるいは、仮想的にホストされたサーバーやクラウドサーバーを使用している場合は、AWSのCloudWatchのようなクラウドプロバイダーのサーバー監視ソリューションを利用することができます。これらのソリューションは複雑な性質を持っていることが多いため、特に最初のセットアップや設定の段階では、外部のコンサルタントやベンダーに支援を依頼する必要となりますのでご注意ください。

2. 自社でのサーバー監視には十分な訓練を受け、知識を持ったITエンジニアが必要になります。そのため、サーバー監視に関する社内のITスタッフを訓練する、またはその経験を持つエンジニアを面接して採用するということが必要になります。

3. しかし、上記の理由から監視を処理するITエンジニアの冗長性が必要になるので、もし彼らが去ったり、突然利用できなくなった場合は、代わりのバックアップが必要になります。自社内サーバ監視は「ITエンジニアのセット」ということを覚えておいてください。

4. 監視するメトリクスを正確に定義し、特定のサーバー上で絞り込む必要があります。これには、もちろん、サーバーだけでなく、その上で実行されているアプリケーションやサービスの完全な知識が必要です。例えば、ディスク I/O とサーバーのアップタイムは、クラスタ化されたWebサーバーよりもデータベースサーバーの方が重要であるかもしれませんし、CPU スレッド数は、フロントエンドアプリをホストしているサーバーよりも Javascript のミドルウェアアプリをホストしているサーバーの方が関連性が高いかもしれません。

上記のポイントを読んでお気づきかもしれませんが、社内でサーバーを監視するには、実際に使用しているソフトウェアの費用だけでなく、ITエンジニアの人的資源の面でも非常に高価になりやすいです。さらに、サーバー監視ソリューションをホストするための新しいサーバー、ITエンジニアのトレーニング、追加のコンサルティングサービスなど、単発的な費用と定期的な関連費用の両方が発生する可能性があり、なんだかんだ高額になってしまうことは理解しておく必要があります。

また、このように多額の投資をした場合の弊害としては、一度セットアップしてしまえば、少なくとも今後数年間は社内ソリューションに縛られることになります。それは、選択したソリューションが最善ではないことが判明した場合、次の行動に変更しづらいということになりますので、最適ではない選択をしたままで立ち往生することになります。

これらの事実を考えると、社内でのサーバー監視は理想的なソリューションではありません。社内ソリューションのコストと頭痛の種を避けることができる大規模なIT部門、または絶対に社内ソリューションを使用しなければならない組織では、通常、セキュリティ上の理由から、防衛関連の請負業者や高セキュリティのバイオテクノロジー企業などに任せるのがベストでしょう。

#3. 社内サーバー監視の代替案（アウトソーシング）
社内サーバ監視の代替として、いくつかのクラウド監視ソリューションを詳しく見ていきましょう。

#AWS CloudWatch
その1つ目は、AWSの監視ソリューションであるCloudWatchです。ユビキタスなAWSプラットフォーム上でサーバーをホスティングしているユーザーにとって、CloudWatchは明らかなソリューションの一つです。しかし、サーバーインフラが完全にAWS上でホストされているユーザーにとっても、CloudWatchには3つの主な制限があります。

1. 第一に、CloudWatchは非常に高価になる可能性があります。特に多くのサーバーを保有している場合や、サーバーごとにいくつかのメトリクスを持っている場合が高価になるケースです。[CloudWatchの価格設定ページ](https://aws.amazon.com/cloudwatch/pricing/)で説明されているように、10台のサーバーインスタンスを7つの標準的なメトリクスで監視するだけで、月に約21ドルを支払うことになります。そして、これにはAPIリクエストやカスタムメトリクス、ログのアーカイブは含まれていませんので、それらを監視しようとなるとさらに高額になります。

2. 第二に、AWS（そして他の多くのプロプライエタリなクラウドプラットフォーム）は、一度サービスを利用するとそのエコシステムから離れることを意図的に困難にしている点です。CloudWatchを使用していて、サーバーインスタンスと監視機能を新しいクラウドプロバイダーに移行したいとします。これは現在、手動での移行かカスタム、サードパーティ製の移行ソリューションのどちらかを使用しないと困難です。しかし、これはなぜでしょうか？結局のところ、Linuxサーバインスタンスとそのメトリクスは、AWS上では、MicrosoftのAzureやGoogleのクラウドプラットフォームと全く同じです。このようなベンダーのロックインの可能性は、クラウドプロバイダーへの移行を検討しているIT部門にとって大きな頭痛の種となっています。これに対抗するために、[MetricFire](https://try.metricfire.com/japan/?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Budget%20Guide%20to%20Server%20Monitoring)はAWSユーザーがAWSのデータをより有効に活用できるように[統合機能を開発](https://www.metricfire.com/aws-cloudwatch)しました。
3. 最後に、AWSのCloudWatchは、AWS上にサーバーがある場合にのみ利用可能です。そうでない場合は、オンプレミスのサーバーにエージェントをインストールするために、インストールと設定のリストを確認する必要があります。

後ほど説明しますが、MetricFireの監視ソリューションは、これらの制限を克服するように設計されています。

#MetricFire

[MetricFire](https://try.metricfire.com/japan/?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Budget%20Guide%20to%20Server%20Monitoring)は、Prometheus、Graphite、Grafanaを組み合わせたホスティングサービスです。MetricFireは、あらゆるソースからの時系列データの収集、保存、可視化を支援する完全なインフラストラクチャとアプリケーションのモニタリング・プラットフォームを提供します。MetricFireの監視プラットフォームは完全にクラウドホスティングされており、監視エージェントはオンプレミスとクラウドサーバーの両方に展開することができます。

[MetricFire](https://try.metricfire.com/japan/?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Budget%20Guide%20to%20Server%20Monitoring)のサポートエンジニアは、アラートの設計、分析、監視全般についていつでもサポートします。また、フル機能のWeb UIを搭載しており、プラットフォーム上で直接メトリクスを送信したり、データを可視化したりすることができます。GitHub、PagerDuty、Slack、Heroku、CircleCIなどのプラグインを使用して、製品の機能を拡張することができます。

代表的なユースケースとしては、サーバー、アプリケーション、ITネットワーク、その他のインフラストラクチャの監視などが挙げられます。MetricFireの最も重要な強みは、そのコストです。[価格ページ](https://www.metricfire.com/pricing0で説明されているように、MetricFireの監視ソリューションは、データ量によってはDatadogの約4分の１のコストであり、サービスや機能をバンドルしているため、CloudWatchなどと比べてもはるかに手頃な価格となっています。

上記の監視プラットフォームと比較して、MetricFireには以下のような追加機能やユニークな機能があります。

- 実際のセットアップに基づいた、適切な階層化された顧客プラン。New RelicやDatadogなどが提供している1つまたは2つの厳格な顧客層とは異なり、MetricFireでは、個人向けのベーシックプラン（月額85ドル）から、成長するチーム向けのラージプラン（月額1599ドル）、プレミアムアニュアルプラン（月額3849ドル）、エンタープライズプランまで、7つ以上の明確に区分されたプランを提供しています。
- 24時間365日のカスタマーサポートを提供しています。New Relicの標準プランでは8時から5時までのサポートしか提供しておらず、24時間365日のサポートを提供しているのはプレミアムプランや上級プランのお客様のみとなっていますので、その凄さが分かると思います。
- 常にオープンソースの理念を採用しているため、お客様のデータは常にお客様のものであり、ベンダーにロックインされる危険性はありません。

- データロケーションの選択 - お客様のデータは、最も便利で最も近いデータセンターでホスティングすることができます。

- コミュニティダッシュボード: MetricFireがホストするGrafanaのようなコミュニティソースのダッシュボードは、Datadogが独自に開発したダッシュボードのように、企業内の小さなチームが開発したものよりも、常にリッチで優れたものとなります。さらに、MetricFireのカスタマーサポートチームがいつでもダッシュボードのカスタマイズをサポートしてくれます。

#Grafana Labs

Grafanaは、分析とモニタリングを実行するためのオンライン・オープンソースのツールです。Grafanaは複数のデータソースと統合し、優れたダッシュボードを作成することができます。特に、より長い期間のトレンドやメトリクスを比較・分析するのに便利です。

しかし、Grafanaは複雑で、初心者が使いこなすには圧倒されてしまうかもしれません。そこで、MetricFireのカスタマーサポートがサポートします。[MetricFireのホスト型Grafanaソリューション](https://www.metricfire.com/hosted-grafana)は、すべてのMetricFireパッケージで利用可能です。

Grafana Labsは、サーバー監視のニーズに合わせてGrafanaを導入し、使用することを支援する商用のプライベートソリューションです。ニーズに応じて2つのソリューションを提供しています。Grafana Cloudは、小規模なユーザーを対象としています。Grafana Cloudには専用のGrafanaインスタンスが含まれており、PrometheusとGraphiteの両方に対応しています。

Grafana Cloudの価格設定は、標準バージョン（30日間の無料トライアル付き）が49ドル/月から、Proバージョンはカスタマイズ価格となっています。Grafana Enterpriseは、Grafana本体だけでなく、PrometheusとGraphiteのバックエンドも含めたGrafanaスタックをさらに活用したい大規模な組織向けに設計されています。これらのソリューションの詳細については、[こちら](https://grafana.com/products/cloud/)をご覧ください。

#Datadog

Datadogは、クラウドベースのインフラ＆アプリケーション監視ツールです。Datadogは、ネットワークからシステム、サーバーの監視まで、クラウド上で幅広いツールやサービスを監視する必要がある環境で主に使用されています。Datadogは、200以上のツールやサービスとの統合により、すべてをカバーしており、技術スタックのすべてのコンポーネントを簡単に監視することができます。また、APIや単一のメトリクスを使用して簡単に定義できない独自のテストを作成するための便利なレコーダーも含まれています。Grafana labと同様に、この製品の複雑さは、慣れるまでに時間がかかる事かと思います。

Datadogはもともと、ダッシュボード、アラート、メトリクスの可視化を備えた、よりシンプルなクラウド・インフラストラクチャ監視サービスとしてスタートしました。クラウドの普及が進むにつれ、Datadogは急速に成長し、Amazon Web Services（AWS）、Microsoft Azure、Google Cloud Platform、Red Hat OpenShift、OpenStackなどのサービスプロバイダをカバーするように製品の提供範囲を拡大した。Datadogはかなり最近になってアプリケーション監視サービスも開始した。PagerDutyやslackなどのアプリと連携して通知を受け取ることが可能です。

Datadogは5ホストまで無料（ただしデータ保持期間は1日のみ）で、14日間の無料トライアルを提供している。その後、顧客は月15ドル/ホストで請求され、ネットワークパフォーマンスは月5ドル/ホストで請求されます。ログ管理は100万件のログイベントごとに1.27ドル/月、セキュリティ監視は分析したログのGBごとに0.20ドル/月で課金される。Datadogインフラの更新された価格はウェブサイトで確認できますが、[Datadogの価格設定](https://www.datadoghq.com/pricing/)は、広範囲の監視メトリクスでは高額になることが明らかになっています。

#New Relic

GrafanaやDatadogに代わるもう一つの選択肢として、New Relicはリアルタイムイベントの監視に特に優れており、WebサーバーやゲームサービスなどのリアルタイムアプリケーションをホストしているIT部門や組織に役立ちます。また、Amazon Web Services、Microsoft Azure、Google Cloud Platformといったビッグ3を含む、さまざまなクラウドプラットフォームとその統合に対応するために、事前に設定されたダッシュボードを提供します。

また、New Relicの統合SDKを使用してカスタム統合を構築することもできます。しかし、その統合はやや不器用な文書化されているため、誰もが簡単に設定できるものではありません。New Relicの一般的なドキュメントやフロントエンドのUIも、主要な競合他社に比べて洗練されていないと言えるかもしれません。

価格は30日間の無料トライアルが含まれており、その後は13ヶ月間のデータ保持と最大2275件の統合イベントを含むProバージョンが月額14.40ドルで販売されています。それ以上に、New Relicは[価格設定のページ](https://newrelic.com/products/infrastructure/pricing)で「高度にダイナミックな環境下での顧客に柔軟な価格設定オプションを提供する」とだけ述べています。

#まとめ

[MetricFire](https://try.metricfire.com/japan/?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Budget%20Guide%20to%20Server%20Monitoring)は、ユーザーが懸念している分野で劣っている多くの代替製品とは異なり、非常に手頃な価格で完全なモニタリングソリューションであることは明らかです。MetricFireは、AWSやAzureなどの大手プロバイダーをはじめ、多くのデータソースと統合しています。MetricFireを使用して、インフラストラクチャだけでなく、スタック全体のシステムから送られてくるデータを監視することができます。[MetricFireのデモ](https://calendly.com/metricfire-chatwithus/chat?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Budget%20Guide%20to%20Server%20Monitoring)をチェックして、[無料トライアル](https://www.hostedgraphite.com/accounts/signup-metricfire/?signup=japan&utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Budget%20Guide%20to%20Server%20Monitoring)にサインアップして、お試しください。

それでは、次の記事で！