実稼働用の構築:Webアプリケーション—一元化されたロギング
序章
これで、本番アプリケーションのセットアップ用に集中ログを設定する準備が整いました。 一元化されたロギングは、サーバーのログを収集して視覚化するための優れた方法です。 一般に、複雑なログシステムを設定することは、確実なバックアップと監視を設定することほど重要ではありませんが、アプリケーションの傾向や問題を特定する場合に非常に役立ちます。
このチュートリアルでは、ELKスタック(Elasticsearch、Logstash、およびKibana)をセットアップし、関連するログをログサーバーに送信するようにアプリケーションを構成するサーバーを構成します。 また、ログを解析および構造化する Logstashフィルターをセットアップして、ログを簡単に検索およびフィルター処理し、Kibanaの視覚化で使用できるようにします。
前提条件
ドメイン名を介してログダッシュボードにアクセスする場合は、[X118X]loggingを指す「logging.example.com 」のように、ドメインの下に ARecordを作成します。 サーバーのパブリックIPアドレス。 または、パブリックIPアドレスを介して監視ダッシュボードにアクセスすることもできます。 HTTPSを使用するようにロギングWebサーバーを設定し、VPNの背後に配置してアクセスを制限することをお勧めします。
ロギングサーバーにELKをインストールする
次のチュートリアルに従って、 logging サーバーにELKをセットアップします: Ubuntu 14.04 にElasticsearch、Logstash、およびKibana4をインストールする方法。
名前解決にプライベートDNSを使用している場合は、[SSL証明書の生成]セクションのオプション2に従ってください。
Logstash Forwarderのセットアップセクションに到達したら、停止します。
クライアントにLogstashForwarderを設定する
クライアントサーバー上にログシッパーであるLogstashForwarderをセットアップします。 ELKチュートリアルのLogstashForwarderのセットアップセクションに従って、db1、app1、app2、およびlb1を実行します。
終了すると、 logging サーバーのパブリックネットワークアドレスを介してKibanaにログインし、各サーバーのsyslogを表示できるようになります。
収集するログを特定する
正確なアプリケーションと設定に応じて、さまざまなログをELKスタックに収集できます。 この場合、次のログを収集します。
- MySQLの低速クエリログ(db1)
- Apacheアクセスおよびエラーログ(app1およびapp2)
- HAProxyログ(lb1)
これらのログを選択したのは、トラブルシューティングや傾向の特定を試みるときに役立つ情報を提供できるためです。 サーバーには、収集したい他のログがある場合がありますが、これは開始に役立ちます。
MySQLログを設定する
MySQLの遅いクエリログは通常/var/log/mysql/mysql-slow
にあります。 これは、「遅いクエリ」と見なされるのに十分な時間実行されるログで構成されているため、これらのクエリを特定すると、アプリケーションの最適化またはトラブルシューティングに役立ちます。
MySQLの低速クエリログを有効にする
遅いクエリログはデフォルトで有効になっていないので、これらのタイプのクエリをログに記録するようにMySQLを設定しましょう。
MySQL構成ファイルを開きます。
sudo vi /etc/mysql/my.cnf
コメント付きの「log_slow_queries」行を見つけてコメントを外し、次のようにします。
/etc/mysql/my.cnf
log_slow_queries = /var/log/mysql/mysql-slow.log
保存して終了。
変更を有効にするには、MySQLを再起動する必要があります。
sudo service mysql restart
これで、MySQLは実行時間の長いクエリを構成で指定されたログファイルに記録します。
MySQLログファイルを出荷する
MySQLの低速クエリログをログサーバーに送信するようにLogstashForwarderを構成する必要があります。
データベースサーバーdb1で、LogstashForwarder構成ファイルを開きます。
sudo vi /etc/logstash-forwarder.conf
既存のエントリの下の「ファイル」セクションに以下を追加して、MySQLの低速クエリログを「mysql-slow」タイプとしてLogstashサーバーに送信します。
logstash-forwarder.conf —MySQLの遅いクエリ
, { "paths": [ "/var/log/mysql/mysql-slow.log" ], "fields": { "type": "mysql-slow" } }
保存して終了。 これにより、Logstash ForwarderがMySQLの低速クエリログを送信し、後でフィルタリングに使用される「mysql-slow」タイプのログをマークするように構成されます。
Logstash Forwarderを再起動して、ログの送信を開始します。
sudo service logstash-forwarder restart
マルチライン入力コーデック
MySQLの低速クエリログは複数行形式です(つまり、 各エントリは複数行にまたがっています)。したがって、このタイプのログを処理できるようにするには、Logstashの複数行コーデックを有効にする必要があります。
ELKサーバーのloggingで、Lumberjack入力が定義されている構成ファイルを開きます。
sudo vi /etc/logstash/conf.d/01-lumberjack-input.conf
lumberjack
入力定義内に、次の行を追加します。
codec => multiline { pattern => "^# User@Host:" negate => true what => previous }
保存して終了。 これにより、Logstashは、指定されたパターンを含むログに遭遇したときに複数行のログプロセッサを使用するように構成されます(つまり、 「#User @Host :」で始まります)。
次に、MySQLログのLogstashフィルターを設定します。
MySQLログフィルター
ELKサーバーのloggingで、新しいファイルを開いて、MySQLログフィルターをLogstashに追加します。 11-mysql.conf
という名前を付けるので、Logstash入力構成(01-lumberjack-input.conf
ファイル内)の後に読み取られます。
sudo vi /etc/logstash/conf.d/11-mysql.conf
次のフィルター定義を追加します。
11-mysql.conf
filter { # Capture user, optional host and optional ip fields # sample log file lines: if [type] == "mysql-slow" { grok { match => [ "message", "^# User@Host: %{USER:user}(?:\[[^\]]+\])?\s+@\s+%{HOST:host}?\s+\[%{IP:ip}?\]" ] } # Capture query time, lock time, rows returned and rows examined grok { match => [ "message", "^# Query_time: %{NUMBER:duration:float}\s+Lock_time: %{NUMBER:lock_wait:float} Rows_sent: %{NUMBER:results:int} \s*Rows_examined: %{NUMBER:scanned:int}"] } # Capture the time the query happened grok { match => [ "message", "^SET timestamp=%{NUMBER:timestamp};" ] } # Extract the time based on the time of the query and not the time the item got logged date { match => [ "timestamp", "UNIX" ] } # Drop the captured timestamp field since it has been moved to the time of the event mutate { remove_field => "timestamp" } } }
保存して終了。 これにより、Logstashは、match
ディレクティブで指定されたGrokパターンでmysql-slow
タイプのログをフィルタリングするように構成されます。 apache-access
タイプのログは、デフォルトのApacheログメッセージ形式と一致するLogstash提供のGrokパターンによって解析されますが、apache-error
タイプのログは、一致するように作成されたGrokフィルターによって解析されます。デフォルトのエラーログ形式。
これらのフィルターを機能させるために、Logstashを再起動しましょう。
sudo service logstash restart
この時点で、構成エラーによってLogstashが失敗するため、Logstashが正しく実行されていることを確認する必要があります。
また、KibanaがフィルタリングされたApacheログを表示できることを確認する必要があります。
Apacheログ
Apacheのログは通常、「access.log」および「error.log」という名前の/var/log/apache2
にあります。 これらのログを収集すると、Apacheが報告しているエラーメッセージに加えて、サーバーにアクセスしているユーザー、サーバーが要求しているもの、使用しているOSおよびWebブラウザーのIPアドレスを確認できます。
Apacheログファイルを出荷する
Apacheアクセスログとエラーログをログサーバーに送信するようにLogstashForwarderを構成する必要があります。
アプリケーションサーバーapp1およびapp2で、LogstashForwarder構成ファイルを開きます。
sudo vi /etc/logstash-forwarder.conf
既存のエントリの下の「ファイル」セクションに以下を追加して、Apacheログを適切なタイプとしてLogstashサーバーに送信します。
logstash-forwarder.conf —Apacheアクセスおよびエラーログ
, { "paths": [ "/var/log/apache2/access.log" ], "fields": { "type": "apache-access" } }, { "paths": [ "/var/log/apache2/error.log" ], "fields": { "type": "apache-error" } }
保存して終了。 これにより、Logstash ForwarderがApacheアクセスログとエラーログを送信し、ログのフィルタリングに使用されるそれぞれのタイプとしてマークするように構成されます。
Logstash Forwarderを再起動して、ログの送信を開始します。
sudo service logstash-forwarder restart
現在、HAProxyリバースプロキシはインターネットからアプリケーションサーバーにアクセスする唯一の方法であるため、すべてのApacheログにはHAProxyサーバーのプライベートIPアドレスと一致するクライアントソースIPアドレスが含まれます。 これを変更して、サイトにアクセスしている実際のユーザーのソースIPを表示するには、HAProxyが送信するX-Forwarded-For
ヘッダーを使用するようにデフォルトのApacheログ形式を変更できます。
Apache構成ファイル(apache2.conf)を開きます。
sudo vi /etc/apache2/apache2.conf
次のような行を見つけます。
[Label apache2.conf — Original "combined" LogFormat] LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
%h を%{X-Forwarded-For} i に置き換えると、次のようになります。
[Label apache2.conf — Updated "combined" LogFormat] LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
保存して終了。 これにより、HAProxyサーバーのプライベートIPアドレスではなく、実際のユーザーの送信元IPアドレスが含まれるようにApacheアクセスログが構成されます。
Apacheを再起動して、ログの変更を有効にします。
sudo service apache2 restart
これで、ApacheログフィルターをLogstashに追加する準備が整いました。
Apacheログフィルター
ELKサーバーのloggingで、新しいファイルを開いて、ApacheログフィルターをLogstashに追加します。 12-apache.conf
という名前を付けるので、Logstash入力構成(01-lumberjack-input.conf
ファイル内)の後に読み取られます。
sudo vi /etc/logstash/conf.d/12-apache.conf
次のフィルター定義を追加します。
12-apache.conf
filter { if [type] == "apache-access" { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } } } filter { if [type] == "apache-error" { grok { match => { "message" => "\[(?<timestamp>%{DAY:day} %{MONTH:month} %{MONTHDAY} %{TIME} %{YEAR})\] \[%{DATA:severity}\] \[pid %{NUMBER:pid}\] \[client %{IPORHOST:clientip}:%{POSINT:clientport}] %{GREEDYDATA:error_message}" } } } }
保存して終了。 これにより、Logstashは、それぞれのmatch
ディレクティブで指定されたGrokパターンでapache-access
およびapache-error
タイプのログをフィルタリングするように構成されます。 apache-access
タイプのログは、デフォルトのApacheログメッセージ形式と一致するLogstash提供のGrokパターンによって解析されますが、apache-error
タイプのログは、一致するように作成されたGrokフィルターによって解析されます。デフォルトのエラーログ形式。
これらのフィルターを機能させるために、Logstashを再起動しましょう。
sudo service logstash restart
この時点で、構成エラーによってLogstashが失敗するため、Logstashが正しく実行されていることを確認する必要があります。 また、KibanaがフィルタリングされたApacheログを表示できることを確認する必要があります。
HAProxyログ
HAProxyのログは通常、/var/log/haproxy.log
にあります。 これらのログを収集すると、ロードバランサーにアクセスしているユーザーのIPアドレス、ユーザーがリクエストしているもの、リクエストを処理しているアプリケーションサーバー、および接続に関するその他のさまざまな詳細を確認できます。
HAProxyログファイルを出荷する
HAProxyログを送信するようにLogstashForwarderを構成する必要があります。
HAProxyサーバーlb1で、LogstashForwarder構成ファイルを開きます。
sudo vi /etc/logstash-forwarder.conf
既存のエントリの下の「ファイル」セクションに以下を追加して、HAProxyログをタイプ「haproxy-log」としてLogstashサーバーに送信します。
logstash-forwarder.conf —HAProxyログ
, { "paths": [ "/var/log/haproxy.log" ], "fields": { "type": "haproxy-log" } }
保存して終了。 これにより、Logstash ForwarderがHAProxyログを送信し、ログのフィルタリングに使用されるhaproxy-log
としてマークするように構成されます。
Logstash Forwarderを再起動して、ログの送信を開始します。
sudo service logstash-forwarder restart
HAProxyログフィルター
ELKサーバーのloggingで、新しいファイルを開いて、HAProxyログフィルターをLogstashに追加します。 13-haproxy.conf
という名前を付けるので、Logstash入力構成(01-lumberjack-input.conf
ファイル内)の後に読み取られます。
sudo vi /etc/logstash/conf.d/13-haproxy.conf
次のフィルター定義を追加します。
filter { if [type] == "haproxy-log" { grok { match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} %{SYSLOGPROG}: %{IPORHOST:clientip}:%{POSINT:clientport} \[%{MONTHDAY}[./-]%{MONTH}[./-]%{YEAR}:%{TIME}\] %{NOTSPACE:frontend_name} %{NOTSPACE:backend_name}/%{NOTSPACE:server_name} %{INT:time_request}/%{INT:time_queue}/%{INT:time_backend_connect}/%{INT:time_backend_response}/%{NOTSPACE:time_duration} %{INT:http_status_code} %{NOTSPACE:bytes_read} %{DATA:captured_request_cookie} %{DATA:captured_response_cookie} %{NOTSPACE:termination_state} %{INT:actconn}/%{INT:feconn}/%{INT:beconn}/%{INT:srvconn}/%{NOTSPACE:retries} %{INT:srv_queue}/%{INT:backend_queue} "(%{WORD:http_verb} %{URIPATHPARAM:http_request} HTTP/%{NUMBER:http_version})|<BADREQ>|(%{WORD:http_verb} (%{URIPROTO:http_proto}://))" } } } }
保存して終了。 これにより、Logstashは、それぞれのmatch
ディレクティブで指定されたGrokパターンでhaproxy-log
タイプのログをフィルタリングするように構成されます。 haproxy-log
タイプのログは、デフォルトのHAProxyログメッセージ形式と一致するLogstash提供のGrokパターンによって解析されています。
これらのフィルターを機能させるために、Logstashを再起動しましょう。
sudo service logstash restart
この時点で、構成エラーによってLogstashが失敗するため、Logstashが正しく実行されていることを確認する必要があります。
Kibanaビジュアライゼーションを設定する
中央の場所でログを収集しているので、Kibanaを使用してログを視覚化することができます。 このチュートリアルは、それを始めるのに役立ちます:Kibanaダッシュボードとビジュアライゼーションの使用方法。
Kibanaにある程度慣れたら、このチュートリアルを試して、ユーザーを興味深い方法で視覚化してください。GeoIPとELKを使用してユーザーの場所をマッピングする方法。
結論
おめでとう! これで、本番Webアプリケーションのセットアップチュートリアルシリーズが完了しました。 すべてのチュートリアルに従った場合は、概要チュートリアルで説明したようなセットアップ(プライベートDNSとリモートバックアップを使用)が必要です。
つまり、バックアップ、監視、および集中ログコンポーネントによってサポートされる、分離されたコンポーネントを備えた動作中のアプリケーションが必要です。 必ずアプリケーションをテストし、すべてのコンポーネントが期待どおりに機能することを確認してください。