‘サーバトラブル’ カテゴリーのアーカイブ

完全ではなかったサーバー監視、ホームページに繋がらないのにhttpの監視ステータスOKって何故?

サーバトラブル | by 管理者
4月 17日 2013 年

先月サーバーが落ちて17時間ホームページに繋がらない障害が発生したばかりなので、サーバーに障害が発生したらメールで連絡する無料のサービスに加入したばかり。

これで安心だ!・・・ってほど楽天的な人間じゃないので、取り敢えず朝起きた時と寝る前はホームページを見て大丈夫であることを確認しています。

 

 

今朝も、メールに異常を知らせる連絡が無かったので、サイトは大丈夫と思い込んでホームページにアクセスすると・・・繋がらない。

リモートでサーバにアクセスするとCPUの負荷が異常に高くなっており、サーバを再起動したら元通りになりました。

 

さて、午前1時40分に障害が発生してホームぺージが繋がらなくなったにもかかわらず、サーバー監視ログの80ポートのステータスはOKになっています。

障害発生から1時間後に3秒の遅延が発生していますが、それでもOKのステータスです。

ここのサーバー監視は、2回続けてエラーにならないとメールが送られない仕組みになっており、監視時間の閾値を弄っても無意味。

というか、そこそも無料の監視サービスなので監視時間の閾値の変更すら出来ません。

さて、どうしたものか・・・

 

単なる高付加になって応答するのに時間がかかっているだけじゃないのか?って思ってサーバのシステムログを見ましたが、そうじゃなさそうです。

何故、http(80ポート)のステータスがOKになるのか良く分かりません。

サーバーの監視ログ

サーバーに障害が発生すると、サーバー復旧後に検索順位は落ちるのか?

サーバトラブル, SEO | by 管理者
4月 05日 2013 年

先月17時間に渡ってサーバーが落ちてしまい、ホームページが繋がらないときがありました。

サーバーが何年間も問題なく動いていると油断してしまい、まさかサーバーが落ちているなんて夢にも思っていなかったため、こんな事になってしまった訳です。

 

webmastertool error

 

 

サーバーに障害が発生してホームページが繋がらなくなると、Googleの検索順位は落ちるのでしょうか?

サーバーを再起動する数分の間なら大丈夫です。これは何度も確かめています。

しかしネットで検索すると、繋がらない時間が1日~2日は大丈夫と言ってる方がおり、「その根拠はどこに?」と突っ込みたくなりますが、私の場合は17時間繋がらなかっただけで検索順位やアクセス数は10~20%位落ちました。

もちろん、すぐに回復することはありません。

このような検索順位やアクセス数の下落はアフェリエイト目的のサイトを運営している方にとって深刻な影響があると思います。

 

 

サーバー復旧後、暫くしてからの検索結果がいつもと違っていました。

例えば、普段5~6番目に検索されたキーワードが1位になり、サーバーに障害が発生したのに順位が落ちる事があっても上がることは考えられないので、この結果を不可解に思っていました。

すると、その翌日に順位がストンと落ちてしまいました。

おそらく、Googleがサイトの安定度をマイナス側に評価した上で、検索順位を再評価しているのではないかと思われます。

 

 

記事を投稿しても、すぐにインデックスしてくれない。

また、普段ならブログを投稿してから数分間でインデックスされるのに、インデックスに数日かかるようになりました。

これはおかしいと思ってアパッチのアクセスログを調べると、GoogleのBotが来ているのにインデックスされていないことが分かりました。

これはBotが何度もサーバーを訪れて、サーバーの安定度を再評価しているのではないかと思われます。

 

*** 2013年4月12日 追加  ***

結局、5日経ってもインデックスしてくれなかったので、ウェブマスターツールのFeach as googleを使ったところ、翌日インデックスされました。

といってもBotが既に来ているので効果は良く分からないですが、暫くの間、記事の投稿したらFeach as googleを使った方が良さそうです。

 

feach as google

****   ここまで   *******

 

計画的にサーバーを停止するのであれば、HTTPステータスコード503を返すようにすれば良いですが、今回のように予期できないトラブルの場合は503を返すことはできません。

サーバーが繋がらない時間が数分間なら大丈夫ですが、今回のように17時間も繋がらないのは非常に不味いです。

そのため、サーバーが繋がらなくなると、携帯にメールが届くように無料のサービスに加入しました。

これで何時間もサーバーが落ちていることを知らなかったなんてことは無くなるはずです。

サーバ管理者にできることは、一刻も早くサーバを復旧して繋がらない時間が1分でも少なくするように努力するしかないです。

 

 

また、これはサーバー管理者だけに限定した話ではなく、ホームページやブログのサイト管理者(運営者)も同じことです。

例えば、Wordpressのプラグインのアップデートでブログが繋がらなくなったとか、バックアップ中にブログが繋がらなくなったとか、ホームページやブログを管理しているだけでも今回と同様のことが起こる可能性があります。

※ 今回の障害はブログの自動バックアップがきっかけになっているみたいです。・・・あなたのサイトも自動バックアップしていませんか?

ホームページやブログのサイト管理者もサイトに障害が発生したら、速やかに復旧できるように何らかの対策を考えておいた方が良いでしょうね。

3月24日にホームページが数時間閲覧できませんでした。(自宅サーバ管理者が行う障害対策)

サーバトラブル | by 管理者
3月 25日 2013 年

昨日(3月24日)の昼はいろいろあって、夜になってからホームページを閲覧したら、アレッ繋がらない。

すぐにリモートでサーバにログインして再起動したら復旧しました。

 

障害が発生した理由はともかく、サーバの調子が悪くなったら即座に「調子が悪い」って知らせて欲しいですよね。

そこそこお金をかけたシステムなら、別のPCから定期的にPingを飛ばして「起きてるか?」って聞いてやるのですが、個人ではそうはいかない。

そこで何かその代わりになるような物が無いか調べたところ、ありました。

このサービスもPingを打ってサーバーから応答があるかどうかを確認して、応答が無いとメールで知らせてくれるサービスのようです。

しかも無料で利用できます。

http://www.cman.jp/network/

サーバー監視

 

 

監視する項目です。ホームページが生きているのか確認したいので、80(http)にチェックを入れます。

監視項目の指定

 

 

この設定を行ってから、暫くしてホームページを見ると、7回Pingを打って全て正常だったという調査結果が表示されました。

もちろん、これだけでなく、異常があればメールで連絡してくれます。

監視結果

 

1つのIPで沢山のホームページやブログを運用するレンタルサーバであれば、サーバの運用はその会社任せで良いでしょうが、自宅サーバやVPSサーバの場合は自分でサーバを管理しないといけないので、無料で利用できるこのサービスはお勧めです。

 

また、詳細はお話しできませんが、サーバーに障害が発生した時刻に怪しいIPアドレスがログに記録されていたため、念のためブログのデータを前日に戻すと同時にそのIPアドレス(190.196.5.82)をアクセス禁止にしました。

悪夢ふたたび?、ウェブマスターツールで自サイトのIPアドレスによる「サイトへのリンク」が急増

サーバトラブル | by 管理者
8月 09日 2012 年

しばらく前に収束したはずの自サイトのIPアドレスによるリンクですが、最近また復活してきました。

ふと気が付くと191個もあります。

ちなみに下画面の219.94.0.251はIPアドレスの3桁目と4桁目が入れ替わり、3桁目が0になるウェブマスターツールのバグと思われます。

 

わずか3ヶ月前のことですが、このときはgoogleから警告をもらったため対策して審査請求し、現在は解決済みです。

詳細は以下のリンクをご覧ください。

http://it.trend-ai.com/?p=5303

 

 

前回完全に修正したはずなのに、どうしてだろう?

※ 再度、Wordpressの全てのテーブルに対してMySQLからIPアドレスで検索してみましたが、1件もヒットしません。・・・当然です。

 

 

丁度googleがパンダアップデートやペンギンアップデートを適用したばかりなので、おそらくその影響だと思いますが、本当にgoogleが犯人なのか憶測だけで答えを出すわけにはいかないので、アパッチのログを調査しました。

するとhttp://123.123.123.123/hogehogeのようにIPアドレスでアクセスしている奴の正体は予想どおりgoogleでした。

IPアドレスでサイトへアクセスできれば、リンク数としてカウントしているのでしょうか?

 

下の画面の74.125.16.○○○はgoogleのIPアドレスです。

じゅうたん爆撃さながらgoogleのIPアドレスでログが埋め尽くされています。

 

 

 

googleはホスト名からIPアドレスを調べてURLを調べたIPアドレスに置き換えて見に来ている、もしくは過去に警告を受けたことのあるサイトはパンダアップデートやペンギンアップデートで念入りにチェックしている可能性があります。

 

本来なら何も対策する必要は無いはずですが、このままにしておくと、ドメイン名を使ったURLとIPアドレスを使ったURLで同じページを参照するため、タイトルタグの重複にカウントされる可能性があり、IPアドレスでアクセスがあったらドメイン名に変換するように.htaccessを修正(正規化)しました。

現在は、googleがhttp://123.123.123.123/hogehogeでアクセスしてもhttp://www.trend-ai.com/hogehogeに自動変換されます。

 

サイト直下の.htaccessの内容

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^123.123.123.123$
RewriteRule ^(.*)$ http://www.trend-ai.com/$1 [R=301,L]

 

WordPress直下の.htaccessの内容

Options +FollowSymLinks
# BEGIN WordPress
RewriteEngine On
RewriteCond %{HTTP_HOST} ^123.123.123.123$
RewriteRule ^(.*)$ http://it.trend-ai.com/$1 [R=301,L]
# END WordPress

 

私の環境ではWordPressとホームページが同一階層だったため、当初リダイレクトできませんした。

そこで、httpd.confを見直して以下を追加しました。

<Directory ”WordPressの階層”>
Options FollowSymLinks
AllowOverride All
</Directory>

主要なキーワードの検索順位を見ると、ようやくパンダアップデートの呪縛から開放される兆しが見えてきたので、これ以上のトラブルはマジに簡便して欲しいです。

台風が原因かな? ホームページが見れるようになったことのお知らせ。

サーバトラブル | by 管理者
6月 20日 2012 年

今日の午後8時頃に出先からホームページにアクセスするとホームページが表示されないことが判ったため、サーバが落ちているのだろうとサーバの状態を確認したところ「稼働中」になっており、DNSを疑って調査してみましたが問題なし。

取りあえずリモートでサーバを再起動したところホームページが見れるようになりました。

今日の午前0時事頃からサーバに異常が発生していたようですが、出先からサーバのログを確認することができないのでホームページが見れなくなった原因は判りません。

昨日の台風の影響でしょうか?

レンタルサーバーにはUPSが付いているはずなので、このようなときこそ安全だと思っていたのですが、違うのかな?

今日は帰ることが出来ないため、明日原因を調査します。

 

 

 

それにしても、昨日の台風は凄かったですね。

私が住んでいる愛知県豊橋市は台風に直撃されましたが、テレビを見ていると、テレビのテロップに愛知県豊橋市植田地区 2万XX世帯避難って表示されており、まさに私が住んいるところだったので、「おいおい」って感じでしたが、サイレンも避難の連絡も無かったし、何より避難場所はここより低い場所なので避難しませんでした。

今年は1発目の台風に直撃されたので、これ以上の台風は勘弁して欲しいです。

 

 

*** 2012/06/21 追加 ***

帰宅してからホームページが繋がらなくなった件の原因調査を行いました。

サーバの/var/log/messagesを見ると、以下のようなメッセージが記録されていました。

 

Jun 19 18:20:59 www kernel: httpd invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0, oom_score_adj=0

 

oom-killer:を調べると、

「OOM Killer(Out of Memory Killer)は,システムが実メモリーと仮想メモリー空間(スワップ領域)を使い切り,必要なメモリー領域を新たに確保できない場合に,プロセスを強制 終了させて空きメモリーを確保する,Linuxカーネルの仕組みです。」

とあるので、何からの原因でこうなったのでしょうね。

アクセス数の増加が原因でれば嬉しい限りですが・・・

 

アパッチのアクセスログを見ると、このメッセージが出た後もIPアドレスが記録されていたので、サーバーが動き続けており、ブラウザから接続は出来ていたみたいですが、ホームページが表示されなかったみたいです。

さくらインターネットのVPS 1Gの格安プランですが、スペック的に厳しいのだろうか?

(備忘録)Linuxで同じ型番のマザーボードに交換しただけなのにネットワークが使えないときの対処方法

サーバトラブル | by 管理者
10月 18日 2011 年

自宅サーバの予備のマザーボードを中古で手に入れた話をしましたが、保障期間が1ヶ月しかないので、動作確認が必要です。

それを本日の深夜に行いました。

マザーボードを入れ替えるだけなので、大したこと無いなんてタカを括っていたらとんでもない。

Linuxは起動するのですが、ネットワークが使えない。

写真を撮っておけば、後々の資料になるのですが、写真を撮る余裕なんて無かったです。

申し訳ありません。

 

24時間稼動のウェブサーバなので、ネットワークのトラブルシューティングしている余裕は無く、元のマザーボードに戻したら今度は起動すらしない。

ここでパニック・・・顔から血の気が引くとは正にこのこと。

 

ここで頭を整理し、ネットワークだけが使えないなんて故障は考え難い、もしネットワークが故障しても新規にLANボードを増設すればネットワークを使うことは出来るはずと考え、再度マザーボードの入れ替えを行いました。

ここで、何故ネットワークだけ使えないのか調べました。

原因は、以前ハードディスクを入れ換えて、データを戻しても使えないことがあったのですが、それと同じことが起こっていました。

Linuxはハードウェアアドレスを管理していて、例え型番が同じマザーボードを入れ換えても内臓Lanのハードウェアアドレスが違うとネットワークが使えないのです。

 

ここでトラブルシューティングを順当に

# ifconfig -a を実行すると、eth1 とloの2つのデバイスが認識されており、eth0が無い。

# ifconfig eth1 up を実行するとeth1の起動はできる。

本来eth0で起動するように設定してあったが、何かの原因でeth0がeth1に置き換わってしまったみたい。

 

そこで、以下の設定ファイルを見るとeth0 とeth1の両方の記述がありました。

このファイルのeth0の記述をコメントアウトし、eth1をeth0に変更してリブート

# vi /etc/udev/rules.d/70-persistent-net.rules

 

これでもネットワークが使えなったので、以下の設定ファイルを見ると、こちらにもハードウェアアドレスの記述がありました。

そこで、ハードウェアアドレスを書き換えてリブートしたら今度はネットワークが使えるようになりました。

ここで書き換えるハードウェアアドレスは、# ifconfig -a であらかじめ確認しておきます。

# vi /etc/sysconfig/network-scripts/ifcfg-eth0

 

作業を始めたのが午前0時、作業終了が午前4時

とんでもない目にあいました。

 

※ 今サーバで動いているマザーボードは今回手に入れた予備の方です。

起動しなかったマザーボードを改めて別のパソコンから部品を剥ぎ取って電源を入れ直したら起動できたので壊れていませんでした。

良かった。  ε-(´。`*)ホッ

3回目のサーバー障害でgoogleからペナルティ?アクセス数は落ちるのか?

サーバトラブル, SEO | by 管理者
9月 02日 2011 年

自宅でサーバを構築し、ホームページを開設していると何かと問題が発生します。

8月22日には、Diceが間違ったIPアドレスでDNSを更新したため、8月22日の朝7:00~夜7:00までの間ホームページが見れませんでした。

googleは数十分程度の短時間サーバに繋がらないのであれば問題ないようですが、これほど長時間に渡り、何度(3回)も繰り返すとペナルティが有るみたいで、未だにアクセス数が2割ほど落ちたまま元に戻っていません。

※インデックスの数は変わっていないみたいですが、検索順位が落ちたようです。

 

 

 

このグラフは、google analysticsのページビューを切り出したものですが、見事に8月22日からガクっと落ちています。

これは、自分の管理責任の致すところなので仕方ないことですが、これと同様のことが1ヶ月前もあり、そのときはすぐに回復したのですが何故か今回はダメ。

おそらく今回が3回目なので、何度も繰り返すとペナルティになるみたいです。

ところで、また台風が近づいています。

本当にうっとうしい。

雷が鳴り始めると停電対策としてサーバーを落としたいのですが、こんなことがあると簡単には落とせないですね。

安いUPSでも買おうかな。・・・前回の台風の時と同じことを言ってるにわかサバ管でした。

Diceが間違ったIPアドレスでDNSを更新する件、解決しました。

サーバトラブル | by 管理者
8月 24日 2011 年

題記の件ですが、DiceのIP確認で「IPアドレスチェック」が タイムアウトしていたのが原因でした。

Diceのevent.logが文字化けして見れないので、いつも個別のid000001.log~のログを見ていましたが、

#  nkf /usr/local/bin/DiCE/log/events.log | more

を実行すると、event.logが文字化けしないで見れるようになったため、ようやく理由がわかりました。

こんな事なら、さっさとevent.logを見れるように調査すれば良かった。

 

DiceのIP確認で「IPアドレスチェック」が タイムアウトすると、dice.iniの「CheckIPAddress」に記載されたIPアドレスで更新するようです。

その時、「CheckIPAddress」のアドレスが間違っていると、間違ったIPアドレスでDNSが更新されます。

タイムアウトするときとタイムアウトしないときがあって、成功したり失敗したりするみたいです。

そのため、信頼性の無いDiceのIPアドレスチェックを止めて、外部のスクリプトに変更しました。

# /usr/local/bin/DiCE/diced

:setup
IPアドレスの検出方法を指定してください
(0) 自動検出
(1) ローカルのネットワークアダプタから検出
(2) 外部のスクリプトから検出
<現在:0>
(N)変更しない (P)戻る
>2
-------------------------------------------------
スクリプトのURLを入力してください
<現在:>
(N)変更しない (P)戻る
http://www.dyndns.org/cgi-bin/check_ip.cgi

 

確認の為、dice.iniの「CheckIPAddress」を0.0.0.0に変更して

:ex イベント番号

を実行したところ、正しいIPアドレスでDNSが更新され、dice.iniの「CheckIPAddress」も正しいIPアドレスで更新されました。

ようやく解決しました。

めでたし、めでたし。

 

*** 記事追加 2011/8/25  ***

今まで1年間問題が発生していなかったのに、突然DiceのIPチェックがタイムアウトするようになりました。

思い当たることは、電話番号を2回線使えるように光モデムを変更したこと。

グローバルIPの確認はルータだけでなく、光モデムまで見に行くのでしょうか?

でないとつじつまが合わない。

再発、Diceが間違ったIPアドレスでDNSを更新する。

サーバトラブル | by 管理者
8月 23日 2011 年

しばらく調子良かったのですが、Diceが今朝の定期更新で間違ったIPアドレスをDNSに書き込んだため、ついさっきまでサーバー接続できませんでした。

申し訳ありませんでした。

Lan内からは問題なく接続できていたので気が付きませんでした。

原因は良く分かりません。

Diceのコマンド「setup」でIPアドレスを自動検出すると問題なく正しいIPアドレスを取得するのですが、「ex イベント番号」を実行すると、dice.iniに記載された間違ったIPアドレスを取得してDNSを更新してしまいます。

取りあえず、dice.iniに正しいIPアドレスを入れておきましたが、単なる時間稼ぎにしかならないので。

前回は、 「ex イベント番号」で即時実行したら正しいIPアドレスで更新、スケジュール実行すると間違ったIPアドレスで更新していたので、前回と若干違っています。

困ったものです。

Diceが間違ったグローバルIPアドレスでDNSを更新してしまう。・・・続報

サーバトラブル | by 管理者
7月 26日 2011 年

6月30日にDiceが違ったIPアドレスでDNSを更新するため、ホームページが見えなくなるという報告をしましたが、その続報です。

「ex  イベント番号」で「手動」でイベントを実行すると正しいIPアドレスでDNSが更新されますが、スケジュールで更新すると失敗します。

スケジュールは「IPアドレス変化時 (7日毎)」に設定してあるので、7日ごとにホームページが見えなくなっていました。

そこで、/var/log/messagesを見ると、スケジュールでイベントが実行されたときに、IPv6関連でエラーが出ていました。

こんなエラーです。

error (network unreachable) resolving './NS/IN': 2001:xxx:xx#xx

この障害が初めて発生したのがケーブルモデムの取替えとほぼ同時だったので、ケーブルモデムを疑っていましたが、どうやらIPv6のアドレスが影響していそうです。

よって、/etc/sysconfig/namedにOPTIONS="-4"を追加し、Bindを IPv4専用モードで再起動してみました。

本来のDiceの次回の実行スケジュールは7日後ですが、すぐに確認したかったので10分後にスケジュールを変更してイベントを実行したところ、今度は正しいIPアドレスに更新されました。

これで解決だと良いのですが。

 

*** 記事追加 2011/8/3  ***

スケジュールどおり、8月2日に無事正しく更新されました。

解決しました。