この Blog は Django Mezzanine を使って構築しています。
別に Mezzanine に限ったことではないかと思いますが、ブログ運用観点で実施していること、実行 JOB について記載します。
個人で運用しながら、やったほうが良さそうなことを調べて実施しているので、ヌケモレあるかもしれませんので参考情報と考えて頂ければと思います。
前提
この Blog は以下の環境で運用しています。
環境が違うと多少やることが変わるかもしれません。
-
稼働環境
1台の VPS 上で、All 1 One 構成でブログシステムは稼働しています。 -
OS
CentOS release 6.9 (Final)
-
HTTP サーバ1
Server version: Apache/2.2.15 (Unix) Server built: Oct 19 2017 16:43:38
-
Python の Version
Python 2.7.8
-
Djagno 、 Mezzanine の Version
Django (1.10.7) Mezzanine (4.2.3)
実施していること
以下の 3点 について実施していることを記載します。
-
アプリケーションのログ設定、エラーメール通知
-
Cron ジョブの設定
-
GAS (Google Apps Script) で、Web サイトの監視、メトリクスの測定
CentOS に関係する OS レベルのセキュリティ設定
観点では記載はしていませんが、VPS 上でブログ運用する場合は、こちらの設定も必要かと思います。
CentOS の OS レベルでの設定は以下の記事が参考になりました。
アプリケーションのエラーメール通知、ログ設定
アプリケーションのエラーメール通知の設定、ログの設定についてそれぞれ記載します。
エラーメール通知
Django の Upgrate を行うと、対応していない plugin でエラーが発生することが時々発生します。
全ページで発生するエラーは検知することができますが、一部のページでのみ発生するエラー等は気づかないことがあり、エラーが発生した際はエラーメールを送付することで、検知できるようにしています。
Error reporting | Django documentation | Django を参考にして、500 エラー、404 エラーに対するメール通知を行なっています。
-
500エラーに対するのメール設定
settings.py に以下を記載することで、ADMINS に設定したメールアドレス宛に、メールが送付されます。
公開サイトでは基本的に DEBUG はFalse
かと思いますが、メールはFalse
の場合のみ送付されます。
デフォルトだと、[Django] ERROR (EXTERNAL IP): Internal Server Error:
という件名でメール送付があります。
件名に自ドメイン名を設定したかったので、EMAIL_SUBJECT_PREFIX
を変更しました。
DEBUG = False ADMINS = ( ('XXXXXXX', 'xxx@gmail.com'), ) EMAIL_SUBJECT_PREFIX = "[Django] monotalk.xyz "
-
404エラーに対するメール設定
settings.py に以下を記載することで、MANAGERS に設定したメールアドレス宛に、メールが送付されます。
こちらも、500エラーと同様にDEBUG = False
の場合のみ発動します。
また、IGNORABLE_404_URLS
に404エラーとなっても、無視する URL を指定できるので、不正アクセスが行われる URL パターンを指定し、無駄に大量にメール送信が行われるのを回避できます。ちなみに私が使用しているVPSではこの設定で、メールが送信されてきます。
root@localhost.com
設定でメールを受け取れない場合、【Django】Send Mail | MKNOD の設定を行ってアカウントを調整する必要があります。
MIDDLEWARE_CLASSES = ( ..... # For 404 errors "django.middleware.common.BrokenLinkEmailsMiddleware", ... ) MANAGERS = ADMINS import re IGNORABLE_404_URLS = [ re.compile(r'^/apple-touch-icon.*\.png$'), re.compile(r'\.(php|cgi)$'), re.compile(r'^/phpmyadmin/'), re.compile(r'^/ja/.*$'), ]
-
Gmail に送った エラーメールを Google スプレッドシート に登録する
Gmail 宛にエラーメールは送付しており、定期的に Google スプレッドシート に送信して、集計しています。
作成したスクリプトについて以下記事に記載しています。よろしければご確認ください。
Django の Admin 宛の Error Mail を無理矢理 Google Spread Sheet に書き出す スプリプトを作った | Monotalk
ログ設定
アプリケーションの動作状況を別途ログにも出力したいので、以下の通りログを設定を行っています。個人的に Django のログの設定は難しく感じるので設定には誤りがあるかもしれません。基本的に以下 2つのことを実施するための設定となります。
-
ログは、Info レベル以上をログファイルに記録、Error レベルではログで通知するが、エラーメールも送付する。
-
cron 起動のバッチ Job は標準出力にリダイレクトしてログを記録する
以下、settings.py の抜粋になります。Batch Job 向けに、mezzanine_extentions
というパッケージを作成しており、その配下のログは、標準出力のみに出力しています。
- settings.py
import sys LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'formatters': { 'verbose': { 'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s' }, 'simple': { 'format': '%(levelname)s %(asctime)s %(message)s' }, }, 'handlers': { 'console': { 'level': 'INFO', 'class': 'logging.StreamHandler', 'formatter': 'simple', 'stream': sys.stdout, }, 'app_log_file': { 'class': 'logging.handlers.RotatingFileHandler', 'filename': '/log_dir/mezzanine_app.log', 'maxBytes': 1024 * 1024 * 10, 'backupCount': 10, 'formatter': 'verbose', }, 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log.AdminEmailHandler', }, }, 'loggers': { 'django.request': { 'handlers': ['app_log_file',"mail_admins"], 'level': 'INFO', 'propagate': False, }, 'django_crontab': { 'handlers': ['app_log_file',"mail_admins"], 'level': 'INFO', 'propagate': False, }, "mezzanine_extentions": { 'handlers': ['console','app_log_file','mail_admins'], 'level': 'INFO', 'propagate': False, }, }, }
Cron ジョブの設定
djagno-crontab を使って以下の ジョブを crontab で実行しています。
ジョブの内容と、設定ファイルについて記載します。
django-crontab については、Mezzanine django-crontab をインストールしてジョブスケジュールをしてみる | Monotalk をご確認ください。
-
設定ファイル(settings.py に記載)
# CRONJOBS ########################### CRONJOBS = [ ('00 02 * * *', 'django.core.management.call_command', ['recommend_blog_post'], {}, '>> /log_dir/recommend_blog_post.log'), ('10 0-23/6 * * *', 'django.core.management.call_command', ['clear_cache'], {}, '>> /var/log_dir/clear_cache.log'), ('00 03 * * *', 'django.core.management.call_command', ['clearsessions'], {}, '>> /log_dir/clearsessions.log'), ]
-
crontab 上に記載した内容
30 03 * * * /bin/sh $SCRIPT_HOME/restart_memcached.sh &>> $LOG_DIR/restart_memcached.log # restart memcached 15 0-23/6 * * * /bin/sh $SCRIPT_HOME/domain_root_cache_warmer.sh &>> $LOG_DIR/domain_root_cache_warmer.log && /bin/sh $SCRIPT_HOME/sitemap_cache_warmer.sh &>> $LOG_DIR/sitemap_cache_warmer.log
-
ジョブの内容
-
関連記事のデータの登録
recommend_blog_post
で、関連記事のデータをアイテムレコメンドで作成しています。
レコメンド用のコマンドは、Mezzanine の Blog に 関連記事 のレコメンド表示をカスタマイズする | Monotalk で作成したコマンドを使用しています。 -
Django の session データのクリア
clearsessions
で、Django のゴミセッションを削除 しています。セッションの削除については、Django session_data を定期的に削除する | Monotalk をご確認ください。 -
Memcached の Cache のクリア
clear_cache
で、Memcached の Cache を削除しています。削除後は再起動 Job が走るように Cron を設定しています。 -
Memcached の再起動
clear_cache
後に再起動タスクを実行します。
再起動タスクは、restart_memcached.sh
でスクリプトにまとめています。
Cent OS 6.9 に Memcached をインストール、ログの設定まで実施する | Monotalk で Memcached のインストールを、Cent OS 6.9 上で稼働する Django に Memcached の Cache 設定をしてみる | Monotalk で Memcached の Django への Cache 設定を行いました。Memcached を 設定して、サイトのパフォーマンスが頗る向上しましたので、設定していない方は設定することをお勧めします。 -
Memcached の Cache の作成
Memcached を起動後に、再度 Cache を作成するため、各ページに一度アクセスしています。domain_root_cache_warmer.sh
でドメイン直下からリンクされているページを、sitemap_cache_warmer.sh
で sitemap.xml からリンクが貼られているページにアクセスしています。
-
Web サイトの監視、メトリクスの測定
Web サイトの監視、メトリクスの測定 で実施していることを記載します。基本的に、全て GAS のスクリプトで実施しています。VPS 上から実施すると、VPS 自体のリソースを使うことになるので外部から実施したいのですが、さすがにもう1台監視用途で サーバ を借りるのはどうかなと思っていました。 GAS は、スケジュール起動、HTTP/HTTPS での通信ができ、基本的には無料で使用できるので重宝しています。
Web サイトの監視
-
URL 死活監視
Google Apps Script でWEB死活監視(複数URL編) | Dozens Members’ Blog
を参考に、URL 死活監視を実施しています。5分おきに1回サイトにアクセスして、HTTP レスポンスコード 200 を返すか確認しています。 -
デッドリンクチェック
これも GAS で実施しています。Google Apps Scriptでデッドリンクチェッカーを作ってみる | infoScoop開発者ブログ を参考に作成しました。 -
Sitemap の ping 送信
これも GAS で実施しています。django の commands としても存在しますが、GAS でも実行可能だったので、スケジュール実行で1日1回 ping 送信を行っています。作成したスプレッドシートと GAS は、Sitemap の ping 送信を行う Google スプレッドシート を作る | Monotalk に記載しています。
これは、監視というか Batch Job な気がします。 -
AMP の妥当性検証
この Blog は AMP 対応をしましたが、AMP 対応した後に、CLOUDFLARE AMP validator API を叩くスクリプトを作成して、1日1回実行しています。 -
AMP の Update Cache 送信
1日1回、Update Cache を送信するスクリプトを実行しています。
メトリクスの測定
以下、Web ページのメトリクスとして取得しているものについて記載します。
設定変更や、レイアウト変更で上がったり下がったりしますので、変更を加えた後に確認して下がっているようであれば、対応するようにしています。
Page Speed Insights と、Speed Index が改善する設定を施してから測り始めたのですが、改善する前から実施したほうがどれくらい改善されているかわかってそっちのほうがよかったかなと思います。
-
Page Speed Insights の スコア測定
スプレッドシートに対象ページ、Key を設定して、1日に何回か Page Speed Insights の スコアを測定して、平均値をグラフ化しています。
Page Speed Insights の score を 定期的に計測して、DataStudio でグラフ化する | Monotalk で作ったものはまとめています。
10 URL くらい実行すると、GAS の 5分の実行制限に引っかかるので、5 URL くらいをサンプリングして実行しています。 -
Speed Index の測定
DataStudioとGASでWebPagetestの計測結果をグラフ化する | mediba Creator × Engineer Blog を参考に、スプレッドシートに Speed Index を記録して、Data Studio で 1日の平均値をグラフ化しています。
まとめ
Blog 運用観点で実施していること、実行 JOB について記載しました。
スケジュールタスク で サーバ 上で動かす必要がないものは、GAS を使うようになりました。
制限内であれば無料で使えて、時刻起動制御ができるため 便利です。
冷静に考えると、「一体、仕事から帰ってきてから何をやってるんだろう」という気持ちになりますが、そんなにやることもないし今後も続けるかなと思いました。
以上です。
-
セキュリティアップデートが 2017年12月までの予定なので、そろそろバージョンアップをしようかと思います。 ↩
コメント