開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この
UNIX系OSのシステムロギングをおよそ20年の長きにわたって支えてきた「syslogd」にも、限界が見えつつあります。その限界を打ち破る機能を備えた新しいシスログデーモンを紹介します。（編集部） 前回までの2回にわたり「syslog-ng」のインストール方法と特徴を解説しました。syslog-ngはキャリアクラスの信頼性や豊富な機能を持ちますが、それと引き替えにsyslogdとの互換性を犠牲にしていました。一方、今回紹介する「rsyslog」は、syslog-ng同様、多くの機能と高い信頼性を実現しながら、syslogdの設定をそのまま使用することができます。 今回から2回にわたり、次世代syslogデーモンのもう1つの候補「rsyslog」を取り上げます。まず今回は、rsyslogのインストール方法を解説します。 rsyslogの特徴 「reliable（信頼できる）シスログデーモン」
※ご注意 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 前回は、UNIXのログ管理の基本となるsyslogの仕組みと設定方法について述べた。今回は、syslogによる別のサーバへのログ転送について説明する。 syslogによるログの一元管理 前回説明したとおり、syslogには、ログを別のsyslogサーバに転送する機能がある。syslogでは、その機能を使って各サーバのログを1カ所に集めることで、ログの一元管理を実現できる。 syslogによるログの転送 syslogによるログの一元管理を実現させるためには、ログを受信するサーバ（ここではログ・サーバと表記）にて514/udpポートを待機状態（listen）にしておく必要があ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
