WEBサイトがダウンした時の確認ポイント

サイトダウン時の確認ポイントWEBサイトが突然見られなくなった!と、昨日、クライアントさんから連絡をいただきました。

そんな時、何をしたらよいのでしょうか。

そのような時に、確認すべき事は大きく分けて2つあります。

  1. サーバーの各種ログ確認
  2. ワードプレスなどのアプリケーション側のログ確認

ログを見た後の対処方法は、ログ自体に非常に多くのパターンがあり、個別対応が必要ですので、この記事内では説明を割愛します。

Linuxサーバーの場合のログ確認までの手順

ftpではなく、sshでサーバーにログインします。そしてLinuxの場合 コマンドを使って/var/logまで移動してください。

Windowsの場合、TeraTerm、Cygwin、WinSCP、putty、あたりです。人によってはgit bashなどの人もいるかもしれません。Power Shellを利用してLinux接続する猛者も稀にいると思います。

以下、LinuxではないLiteSpeedなどの場合、もしくはLinuxのディストリビューションによってログファイルの保管場所が異なります。

この後からが少し難しいのですが、sshでログインした際のlinuxの一般ユーザーからrootユーザーにユーザー切替をしないと閲覧できないログファイルがあります。慎重な操作が必要になりますが、sudo su – などでルートに成っておいたほうが楽です。

rootパスワードがわからないと、root権限のユーザーに変更できません。再起動でrootパスワード再発行がセオリーだったと思います。使っているサーバーの種類に応じたrootパスワード再発行の作業をしましょう。レンタル共有サーバーはroot権限による使用不可です。専門職の人がVPSやクラウドを選ぶ理由はroot権限の有無です。レンタル共有サーバーでは、有料企業認証SSLは導入出来るかもしれませんが、セキュリティ向けに、SELinux(ワードプレスの場合はWP-CLIも)、改ざん検知の導入、(D)DOS攻撃の様なサーバー処理量の負荷対策など、問題発生に対策を打つ事ができません。

catやlessコマンドなどを使って実際にログを確認して、サーバーに何が起こったのか追及します。色々なログがありますが、最初に見るのは下記のあたりです。

おそらくログローテーションによって生成されたファイルも周辺に配置されていますので、日付で追ったりします。基本的にやりたくないですが目視で頑張る場合、ApacheLogViewerなどを使います。問題が起きた際のログ解析は、セキュリティ脆弱性に起因する事もあり、手法も解析も比較的に求められる専門度が高いため、WEB制作/運営の見積時に有料であることを必ず伝える必要があります。線引きを知らない日曜プログラマーの方は、ルールを決めず、知人から安請け合いの実験台WEB制作を行い、無料でログ解析まで大量の時間を使って行う羽目に陥ります。間抜けな赤字にならないためにも、ルール決めは厳格に!クライアントとの馴れ合いは最もダメなパターンです。WEB制作業界内出身の独立でない限り、ノウハウや積み重ねが無い場合、体験して赤字を出しながら覚えるしかありません。WEB制作やシステム開発会社の組織化や事業参入障壁の一つです。ログ解析が必要な時=『何かのトラブル』や『集客向けのデータ収集』で、結果が出てきた後、対策で手間暇必要な新たな作業発生も考えられます。顧客のITリテラシーが低いほど、安請け合いの責任範囲は広く、赤字になりやすく、win-win-winが遠のく。コンテンツを自主的に読んでもらえる体制を作る事は、コスパや品質を上げるために非常に大切。

root権限のパスワードがわからなくなるパターン

前任の担当者が各種のアカウント関連を引き継がなかった。
前任者に責任を問いましょう。専門性云々ではなく、人として無責任です。
サーバーへのssh接続というものがあること自体を知らなかった。
WEB担当者として努力不足です。集客やセキュリティを本気で考える場合に絶対に通る道です。
sshによるサーバー接続の鍵認証方式やコマンドの黒い画面は苦手、いつもftpを使っている。
ネットショップや会員制サイトの様に個人情報や決済を取り扱うサイトの場合、セキュリテイとして最も行ってはいけない。サイト訪問者(顧客)に対する背任行為です。今すぐ、ssh/sftp等に変えてください。情報漏えい裁判で、わかりやすいマイナス要素となるでしょう。
外注業者に任せきりで、何かあるたびに全て発注している。
根本的な運用体制から、お金を使って見直しましょう。
レンタル共有サーバーを使っていて、根本的にroot権限の譲渡を受けることが不可能。
隠れたサーバーダウンが無いか?近い将来に大きなアクセス増の可能性は無いか?確認して、必要な場合はサーバーのスケールアップ(スペックアップ)やNginxへの変更、スケールアウト(サーバー台数増加、負荷分散の導入)、DBサーバー分離などを考える必要があります。負荷対策は、クラウドでトリガーを設定してオートスケール(自動スケール)なども可能です。

ログへの対応は業者に任せるべきだと思いますが、WEB担当者ならサイトがダウンした時の原因を特定するためのログ確認手順は知っておくべきです。社内で唯一のWEB担当者が頼りにならない、というのは致命傷です。誰も問題に対応できる人が居なくなり、お金をかけて作った会社のWEBサイトが窮地に追い込まれます。役に立たないWEB担当者には、給与を支払う気が失せます(口には出しませんが)。

会社のホームページやブログサイトなどではなく、会員制サイトやネットショップなど、お金や個人情報を扱うWEBサイトの場合はレンタル共有サーバーではなく、root権限を取得できるVPSやクラウドを使い、SSL(https)の暗号化やクラウド型WAF(IPS含む)も導入しましょう。当然、普通のブログサイトよりも管理費用は上がります。普通のブログサイトに対してネットショップや会員制サイトの敷居の高さが全く異なる、天地の差ということを知らない方も非常に多いです。WEB制作の費用も開発規模が変わり、セキュリテイ責任も増大する為です。

ワードプレスなどのCMSや各種のアプリケーション側のログ確認

位置づけとしてアプリケーションとなるワードプレスのphpのログ確認方法をご案内します。CMSを使っていない場合も、phpやその他言語のログ確認方法も存在します。調べると色々あります。sshでサーバーに接続した後にワードプレスのルートデイレクトリ(windowsではフォルダと言いますが、Linuxではデイレクトリと言います)までいきます。DocumentRootやホームフォルダの階層まで進んでください。以下のようにwp-admin,wp-includes,wp-content が配置されているデイレクトリです。wp-config.php

そして、上記のwp-config.phpを notepad++ などの utf-8 BOM無し対応エディタで開きます。

メモ帳でファイルを開くと、文字コードの設定が変更され、wp-config.phpが文字化けを起こして、ワードプレスが真っ白画面になるなど、トラブルのもとになるのでメモ帳でソースコード編集をすることは避けてください。

wp-confg.phpには以下を追記します。

そして、debug.logを見て各種のエラーを確認しましょう。

この設定をずっと継続すると、ログファイルがサーバー内で大量に増え続ける可能性があります。

エラー確認が不要な時は、wp-confg.phpファイルを元に戻してログが出ないようにしておきましょう。

WEBサイトダウンの監視方法

アクセスアラームが便利です。

時間帯別流入数(TOP10)、参照元別流入数(TOP10)、ページ別流入数(TOP10)を毎日メールで決まった時間にお知らせしてくれるので、訪問が集まりやすい記事の傾向などをつかみやすくなります。

さらに、サーバーがダウンした時もメールで教えてくれます。設定も簡単で2サイトまで無料で登録が出来ます。

「踏み台」にされてしまった場合は、他人(他社のサーバー)に攻撃を与え、他人を巻き込むことになります。ワードプレスであれば、xmlrpc.phpなどへの攻撃が有名です。

監視ツール

ネットショップなどの様に決済機能や会員の個人情報を管理するWEBシステムの場合、多面的にサーバー情報を掴んでサーバーの健康チェックをするために、zabbix等の監視ツールを別サーバーで立ち上げて独自監視します。セキュリティ対策としてのPCI DSSの順守範囲最大化です。

ログ収集管理

ログ収集管理のFluentdもおススメです。交差点の中央に立っている警察の様に、ログの交通整理を行ってくれます。サーバー内の各種サービスなどで発生したイベントのログを取得し、データベース、ファイル、別のサーバーのfluentdなど、様々なアウトプット先を設定出来ます。

オススメはクラウド活用

Microsoft Azureでは、Azure 診断(仮想マシン)やApplication Insights(Azure Web Service)、アマゾンAWSではCloud Watchなど、いろいろな監視サービスがあります。クラウドサービスを使ってWEB運営を行う場合は、クラウドサービス提供元がIaasやPaasに対して標準提供している監視ツールのクオリティも高く、Zabbixで監視サーバーを立ち上げるほど大袈裟にしなくてもいいという場合など、オススメです。クラウドの場合、監視だけでなくオートスケール(急激な負荷増加に対してサーバーのスペックアップや台数増加を自動で行う)やフェールオーバー(サーバーデータセンターが地震などの災害で停止した場合に、事前に準備しておいた別地域データセンターのサブシステム環境に自動でシステムを引き継ぐ)などもできます。弊社としてもイチオシです。信頼性確保はビジネスの根幹です。

Nginxは502 bad gatewayのエラーがイレギュラーに発生するかも

php-fpmやHHVMなどに問題があるのかもしれません。

AWSであれば、ログ監視を行い、502が出てきたら再起動するなどの対策が出来ます。

Nginxの502 bad gatewayエラーは結構目立つ機会損失なので注意が必要です。

メモリが少ないロースペックな仮想マシンで起こりやすい気がします。

コメントを残す