2010-02-05 Zopeがエラーを返すとき
Zopeがエラーを返すとき
job | 
ウェブの動作監視でZABBIXを使っています。バックエンドで動作しているZopeインスタンスの動作をチェックするために、ZMI画面へhttpアクセスし、一定のタイムアウト時間までにHTTPコード200が帰ってきたらOK。それ以外だとNGとしてインスタンスを再起動という仕掛けをいれていました。
大体の場合はこれでうまくいくのですが、AttributeErrorとかData.fsからオブジェクトをちゃんと取り出せない場合には、HTTPとしては200で返しているのですが、アプリケーションレベルだとエラーってなケースがあるようです。
ZABBIXのウェブ監視では、特定のURLへリクエストして帰ってきたコンテンツ中に指定した文字列が入っているかどうかっていうチェックも可能なので、その設定を追加。うまくいくといいのですが。
2010-01-14 Apache2のキャッシュが怪しい動作
Apache2のキャッシュが怪しい動作
job |
私が管理しているウェブサーバではフロントエンドのApacheでリバースキャッシュをかけた上で、バックエンドにリクエストを流しています。
先日来、コンテンツの一部で404になることがあるという現象が報告されました。
Apacheのログをチェックすると、確かに404でクライアントに返しています。バックエンドの方はどうかとチェックすると、同じ時間にはバックエンドにはリクエストが来ていません。おそらくApacheでキャッシュにないってことでそれで返してしまっている模様。
そこでCacheRootを変更して、Apacheを再起動。ネガティブキャッシュ*1をクリア。それでも時折404が帰ります。大多数のリクエストは正常に処理しているのですが。
コネクション数が4桁を越えているので、httpdのパフォーマンスを調整する必要があるのかもしれません。
2010-01-08 php.iniでmemory_limitが効かない
php.iniでmemory_limitが効かない
job |
ZABBIXのサーバを1.6.4から1.8へバージョンアップしたのですが、その際に必要条件のチェックが動いて、phpのmemory_limitが引っかかった。
どうも128MB必要らしいのですが、64MBだよって表示されている。それとpost_max_sizeも16M必要らしい。
なのでphp.iniを編集。
memory_limit = 128M post_max_size = 16777216
これでApacheを再起動。post_max_sizeのチェックは通ったが、memory_limitの値が64MBのまま。編集しているphp.iniが違うわけでもない。変だなぁ。
zabbixのソースもチェックしたがよくわからない。あんまり時間を無駄にするのもしゃくなので、zabbixのソース中に少々手を入れることにした。
手を入れたのはinclude/setup.inc.phpで、memory_limitの値を取り込んでチェックしているところ。189行めあたり。
ini_set('memory_limit','128M') ; ← ここ
$memory_limit = str2mem(ini_get('memory_limit'));
$table->addRow($this->get_test_result(
$final_result,
'PHP Memory limit:',
function_exists('memory_get_usage') ? mem2str($memory_limit) : 'unlimited',
$memory_limit >= 128*1024*1024 || !function_exists('memory_get_usage'),
'128M is a minimal PHP memory limitation'));
まぁアドホックではある。今のところ支障はでてない。
2009-12-07 Ploneの認証をLDAPへ
Ploneの認証をLDAPへ
job |
先日作成したPacketiXを利用したインタネットVPN環境でせっかくOpenLDAPのディレクトリを作ったので、これを積極利用。ということでPloneサイトがいくつかあるんですが、これの認証をOpenLDAPに任せてみたい。
pythonでldapが使えるかどうかチェック
こんなワンライナーで確認。
$ python -c "import _ldap"
なにもエラーがでなければ、問題なし。インポートできないとかなんとかいってきたら、適当にインストールしてあげてください。
インスタンスへLDAP関連のプロダクトを追加
昔の本をみると、わざわざダウンロードしてプロダクトを追加なんてことをやっているみたいですが、近頃のPloneでは同梱されているみたい。Ploneプロダクトを解凍したところにPloneLDAPってディレクトリがあり、その下にPloneLDAP,LDAPUserFolder,LDAPMultiPluginの3つのプロダクトがあるのでこれをインスタンスのProduct以下へリンク。そしてインスタンスを再起動。
コントロールパネルのProductでこれらのプロダクトが有効になっていることを確認します。
Ploneのacl_userにPlone LDAP pluginを追加
Ploneサイト中のacl_usersをクリック。そこへ右上のプルダウンからPlone LDAP pluginを追加。
設定値入力
baseDNとか、LDAP中のどこ項目をuseridとして扱うかとか、サーバ情報などなど適当に入力して、OK。
ユーザオブジェクトタイプは、自分の環境だとinetOrgPersonだったのでそのように指定。
なにを有効にするか
認証とユーザとしてのエミュレーションをさせたいので、Open LDAP pluginのactivateタブで、AuthenticationとUseremulationをチェック。他は、、よくわからないな。
テスト
OpenLDAPpluginのコンテンツタブからacl_users(LDAP)をクリック、ユーザタブで任意のユーザを検索できます。
LDAPにマルチバイトのコンテンツが含まれていると、latin-1で云々てエラーが帰ってきます。
'latin-1' codec can't encode characters in position 20-32: ordinal not in range(256)
この時は、LDAPUserFolder中のutils.pyで文字コードを既定しているところがあるので、これをutf-8にすればOK。
#encoding = 'latin1' encoding = 'utf-8'
これでOpenLDAP中のユーザで認証できました。でもまだロールとかグループとかなにも設定していないので、なにもできないのだ。
2009-09-28 Zopeがフリーズする
Zopeがフリーズする
job |
先週から起きているウェブの不調。一次的な原因はバックエンドのZopeインスタンスがリクエストに対する回答を返さないこと。単純に観察していると、Zopeが沈黙したように見える。
インスタンスを再起動すると、一旦は復活するもののしばらくすると同じ現象になります。
フロントエンドを遮断して、外部からのリクエストがこないようにすると現象が発生しないことから、なにか外部からの特徴的なリクエストがトリガーになっているものと推測できるのですが、Z2.logなど眺めてみてもどれがきっかけなんだかわかりっこない。
そこでいろいろ調べてみると、Zopeが現在処理しているスレッドの内容をダンプしてくれるツールがあることを発見しました。
DeadLockDebuggerというプロダクトがそうです。このプロダクトを動作させるためにはpythonパッケージのthreadframeが必要です。
treadframeをインストール
上記サイトからダウンロード、展開して
# python setup.py install
DeadLockDebuggerをインストール
通常どおりProductディレクトリへコピー(またはリンク)。プロダクト中の custom.py を編集。
ACTIVATED=True SECRET='mysecret'
スレッドのダンプを参照
スレッドのダンプはこんなURLで見えます。
http://hostname:port_number/manage_debug_threads?mysecret
これでスレッドの状態をチェック。先週から起きている現象は、クローラが検索に該当するURLをバンバンとリクエストしてくれていることが原因と判明しました。
しかも、該当URLはCMSプロダクトのバグで検索範囲がとてつもなく広く指定されているもので、とても回答に時間がかかるものでした。このため、リクエストがどんどんたまってスレッドを食い尽くしているということが判明。
ログだけじゃ解らない情報もあるんだということを認識しました。
