サーバー監視とは?目的やツールの選び方、自動化について解説
企業サイトやECサイト、顧客管理や請求処理などのシステムを運用するにはサーバーが欠かせません。そのサーバーを安定稼働するためにはサーバー監視が重要になります。
この記事ではサーバー監視の種類や目的、監視項目、サーバー監視ツールの選び方についてご紹介しています。
サーバー監視の自動化・効率化を実現する方法と2つの成功事例
サーバー監視の自動化や効率化を実現する方法と2つの成功事例をご紹介した資料がダウンロードできます。どんなツールをどのように使って自動化・効率化を実現したのか?を学ぶことができます。
どのようにしてサーバー監視業務を自動化・効率化するのか、どんな事例があるのか?がわかります。
サーバー監視とは
監視とは、サーバーやネットワーク等、周辺環境の状況を定期的にチェックして、正常に動作しているかをスクリプトや監視ツールを使ってチェックをする業務です。
異常がでれば、多くは関係者へ連絡、対応を実施し、正常動作に復旧させることになりますが、最近は自動化の仕組みを利用し、復旧する事例も増えてきています。
サーバー監視の種類
サーバー監視には、「正常監視」と「異常監視」があります。
「正常監視」はサーバーが正常に稼働していることを管理者にわかるように、ステータスを表示したり通知したりする監視になります。
「異常監視」はサーバーが正常に稼働していない場合に、管理者に通知する監視になります。多くの場合、メール、音声、ランプによる通知手法が採用されます。自動化の仕組みに異常を連携する場合もあり、その際はメールやAPI連携等の手法が採用されます。
サーバー監視の対象範囲
これまではオンプレミスサーバーの利用が中心でしたが、クラウドが普及するに従い、自社でサーバーを保有せず、クラウド事業者が管理するクラウドサーバーの利用が増えてきています。
このため、オンプレミスサーバーだけではなく、クラウドサーバーの監視もする必要があり、範囲がひろがっています。
サーバー監視の目的
監視の目的は、提供しているサービス(顧客管理、料金計算処理、請求処理・・・)を安定稼働させ、ビジネスの停止を最小限におさえることにあります。
安定稼働のためには、「障害の予防」および、障害発生時の「原因特定」を素早く行うことが重要です。
障害の予防
重要なサーバーについては、複数のサーバー・インスタンス等を利用し、冗長化構成で稼働させることで、障害の予防を実現できますが、冗長化構成内の単一の構成要素(例えば冗長化構成2台のサーバー中1台)が異常な状態となっているにもかかわらず、対応がとれないようであれば限定的な予防措置にしかなりません。
構成要素が障害(冗長化構成2台のサーバー中2台が障害)を起こし、サービス提供ができなくなる前に、異常な状態を監視で事前に検知し、対応をとることが、障害の予防という点では重要になってきます。
障害原因の特定
サーバーが障害を起こす原因は、サーバー・インスタンスの過負荷、OS/ミドルウェアのメモリ不足、ディスクの物理障害・論理障害、ネットワーク通信不可、OS/ミドルウェア自身の障害等、幾通りもあります。何が原因で障害を起こしたかを突き止めないと、サーバーの復旧はできません。監視により常に必要な稼働状況を把握し、障害原因を切り分けできるようにしておくことが重要となります。
サーバー監視の自動化・効率化を実現する方法と2つの成功事例
サーバー監視の自動化や効率化を実現する方法と2つの成功事例をご紹介した資料がダウンロードできます。どんなツールをどのように使って自動化・効率化を実現したのか?を学ぶことができます。
どのようにしてサーバー監視業務を自動化・効率化するのか、どんな事例があるのか?がわかります。
サーバー監視で見るべき項目
監視項目については、オンプレミス・クラウドで大枠は変わりませんが、やはりクラウド特有で監視しなければいけない項目もあります。まずはオンプレミスでの代表的な監視項目・内容・手法について下表に記載します。
監視項目 | 内容・手法 |
---|---|
ハードウェア死活監視 | サーバー・ネットワーク機器が正常に稼働しているかを監視する。ping応答やハードウェアのメッセージ(ログ)を確認し異常を判断する。 |
ミドルウェア稼働監視 | サーバー上で稼働するミドルウェアが正常に稼働しているかを監視する。ポートの応答や、プロセスが起動していることを確認し異常を判断する。 |
ネットワークトラフィック監視 | トラフィック量が帯域制限に達している、または想定帯域の範囲内かどうかを監視する。OSのコマンドによる帯域確認や、トラフィック監視ツールを利用して異常を判断する。 |
リソース監視 | CPU、メモリ、ディスク容量が想定の使用率の範囲内で稼働しているかを監視する。スクリプトやツールで各使用率を確認し異常を判断する。 |
ログ監視 | OSメッセージやミドルウェアメッセージ、アクセスログ等に想定外のメッセージやエラーが出力されていないかを監視する。スクリプトやツールで特定のキーワードが出力されていないか確認し異常を判断する。 |
サービス監視 | サービスが正常に稼働しているかを監視する。Webサーバーの応答コード等で、実際にユーザーがサービスを利用している方法を用い、正常に応答が得られるかを確認し、異常を判断する。 |
セキュリティ監視 | 不正アクセスやサイバー攻撃を受けていないか、セキュリティに問題をきたす変更が加えられていないか等を監視する。手法はさまざまだが、セキュリティ関連のログやツールを利用し、異常を判断する。 |
オンプレミスとクラウドでの監視の違い
クラウドでは、オンプレミスとは異なり、前章「サーバー監視で見るべき項目」の表の「ハードウェア死活監視」はクラウド事業者が対応することになるので不要となりますが、クラウドであるがために必要となる監視項目があります。代表的な監視項目・内容・手法について下表に記載します。
監視項目 | 内容・手法 |
---|---|
マネージドサービス死活監視 | AWS Lambda等、マネージドサービスが正常に稼働しているか確認する。クラウド事業者が提供するサービスを利用して監視を行い、異常を判断する。 |
コスト | クラウドではアウトバウンドトラフィックやディスクへの書き込み回数等、従量課金の項目が多数ある。コストが想定の範囲内に収まっているかを監視する。クラウド事業者が提供するサービスを利用して監視を行い、異常を判断する。 |
セキュリティ | オンプレミスでも必要な監視であるが、クラウドはオンプレミスにくらべ容易にセキュリティの変更が可能であり、より重要となる。セキュリティリスクのある変更が行われていないかを確認する。クラウド事業者が提供するサービスやツールを利用して異常を判断する。 |
クラウド事業者からのメール | クラウド事業者から各アカウントに異常をしらせるメールがくることがある。都度内容を確認、異常がないかを基本的には人的に判断する。(ある程度に振り分けは自動化できる場合がある) |
クラウド事業者の公開情報 | クラウド事業者が障害情報をホームページに公開する場合がある。公開情報の更新をツール等で監視し、更新があった場合は都度内容を確認、異常がないかを基本的には人的に判断する。(ある程度に振り分けは自動化できる場合がある) |
上記の通り、クラウド事業者が提供するサービス、例えばAWSであればCloud Watch/Cloud Trail/Cost Explorerなどを利用する必要があるものが多く、各クラウド事業者の提供サービスを使いこなさないといけない点もオンプレミスとは異なる特徴となり、技術的なハードルはオンプレミスよりは上がることになります。
サーバー監視の自動化・効率化を実現する方法と2つの成功事例
サーバー監視の自動化や効率化を実現する方法と2つの成功事例をご紹介した資料がダウンロードできます。どんなツールをどのように使って自動化・効率化を実現したのか?を学ぶことができます。
どのようにしてサーバー監視業務を自動化・効率化するのか、どんな事例があるのか?がわかります。
サーバー監視ツールの選び方
監視ツールを選ぶ際、検討しなければならない代表的なポイントを記載します。
オープンソースか商用か
監視ツールは「オープンソースソフトウェア」と「商用」に分かれます。オープンソースは基本的には条件を守れば無料で利用・改変可能ですが、脆弱性が発見された場合の対応は自己責任の範囲となります。
エージェント型かエージェントレス型か
監視ツールには監視対象サーバーにモジュール(エージェント)を導入しなければならないものと導入が不要なもの(エージェントレス)に分かれます。エージェントレス型はモジュールを導入しなくてもよいので、導入・保守コストがかからず、かつ監視対象サーバーに負荷をかけない等のメリットがありますが、監視項目に制限がある場合が多く、詳細な監視を行う要件がある場合はエージェントを導入することもあります。
外部連携ができるかどうか
監視アラートはこれまではメールによる通知やTrapによる連携が一般的でしたが、ビジネスチャットへの連携・レポート送信ができるツールが主流になってきています。
統合監視と自動化で効率化を図る
クラウドの利用が進んでいるとはいえ、やはりオンプレミスにサーバーが残っている場合が多く、オンプレミス・クラウド両方を監視し、アラート対応しなければならない状況がほとんどと思われます。監視対象が増えるだけでなく、監視の手法もクラウドベンダー毎に変わるため、システム管理者の監視負荷、コストが高まってきます。
このため、クラウドベンダー毎やオンプレミスで変わる監視手法・アラート連携手法を、1つのソフトウェアで一元管理(統合監視)し、効率化を図ることが必要となってきます。
またシステム管理者には監視業務にはアラート発生時、定型的な対応ですむものと非定型対応をとらないといけないものがあり、定型的な対応については効率化することが必要となります。具体的には定型業務はツールを利用して自動化し、監視対応業務の効率化を図ることも重要となってきます。自動化すれば効率化だけでなく、属人化防止、ヒューマンエラー防止の効果も期待できます。エンジニア不足が今後より問題となってくる中、システム管理者は、効率化を行って時間を生み出し、新しいスキルを身につけることがより重要度を増してきています。
Cloud Archなら統合監視も自動化もできる
オージス総研が提供するサービスである運用自動化ソリューション「Cloud Arch」であれば、各クラウドベンダーが提供する監視サービスと連携でき、かつオンプレミスの監視もできるため、統合監視が実現できます。また、定型的な対応ですむ監視アラートであれば、アラートを取り込むことによる自動化処理も可能となり、システム管理者の業務効率化に大きく役立ちます。
自動化で運用工数を7,500時間削減。運用オペレータの15%を自動化エンジニアに変えた効率化事例
サーバー監視の自動化・効率化を実現する方法と2つの成功事例
サーバー監視の自動化や効率化を実現する方法と2つの成功事例をご紹介した資料がダウンロードできます。どんなツールをどのように使って自動化・効率化を実現したのか?を学ぶことができます。
どのようにしてサーバー監視業務を自動化・効率化するのか、どんな事例があるのか?がわかります。
最後に
統合監視・運用自動化ソリューション「Cloud Arch」は、これまで培ってきました運用実績をもとに、豊富な自動化メニューを取り揃えていることに加え、お客様環境に合わせて有資格エンジニアがカスタマイズすることも可能です。また、無料で試行いただける環境もご用意しておりますので、ご興味のある方はぜひともお問い合わせいただきますようお願いいたします。
※この記事に掲載されている内容、および製品仕様、所属情報(会社名・部署名)は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。
関連サービス
-
運用自動化ソリューション「Cloud Arch」
オンプレミスシステムやプライベート / パブリッククラウドの複数サービスを利用しているシステム環境に対し、シームレスな運用自動化と統合監視の環境をご利用いただくことで複雑化するシステム運用の負担低減を実現します。
-
Cloud Arch『障害アラート自動コール』試行版のご紹介
運用自動化ソリューション Cloud Archの『障害アラート自動コール』 試行版を無料でお使いいただけます。
関連記事一覧
- Splunk(スプランク)とは?ログの有効活用により先進的システム運用を実現
- APM(アプリケーション性能管理)とは?
必要性、APMシステムの機能・概要 - AIOpsを始めるために必要なことを解説
- AIOpsとは?システム運用のAI活用事例やユースケース、メリットを解説
- サーバーダウンの原因と対策とは?システム障害を防ぐサーバー運用について解説
- システム・サーバー運用業務の自動化が進まない理由と運用自動化を成功に導くポイント
- 運用自動化プラットフォームKompiraとは?特長と導入メリット、事例について
- 運用自動化の事例紹介-システム運用をラクにする運用自動化を実現するには?
- 運用自動化とは?メリットと進め方-システム運用をラクにする運用自動化の実現方法
- システム運用の業務と課題-システム運用をラクにする運用自動化を実現するには?