MySQLスローログ解析プッシュ
背景
これまでpt-query-digestで行ったスローログ分析のスキームを用いて,定期的にすべてのマシンのスローログを収集し,センタマシンに転送してpt-query-digestで分析し,最後に示した. pt分析に基づいて展示された結果は比較的詳細で、SQLランキング、占比などがあるが、ユーザー体験は特によくなく、一目瞭然ではない. この機能はもともと開発に見せることができますが、開発を見ることはめったにありません.遅いクエリーがあるたびに開発と協力して修正したり調整したりする必要があるとき、開発は具体的なSQLを聞くので、面倒です. は、1人あたりのポートインスタンス数が多く、監視のたびにスロー・ログに関連する深刻な問題が報告されることが多いため、暗黙的な変換のように、インスタンスへの影響がそれほど深刻でなければ、普段は発見されません.
以上の原因に基づいて、ELKを借りて、遅いログのリアルタイム分析の方案をして、しかもkibanaの上でいくつかのグラフを配合した後に開発に渡して見ることができて、毎回新しいSQLがオンラインになった後に遅いログの情報のリアルタイムの展示によって直ちに問題を発見することができます.
シナリオの決定
まずネット上で遅いログの分析展示についての方案を探して、ptツールのほかに、logstashで正則的にマッチングすることがあって、ちょうどそのログの分析処理が比較的に人気があって、ELKはその中の1つで、しかも部門の他の同僚はすでにELKサービスを構築して、ちょうど使うことができます.
ビルド logstash-all-plugins-2.1.0をダウンロードします.メリットは、自分でプラグインを入れなくても、直接使えることです. プロファイルを作成します.logstashが起動すると、プロファイルの設定とルールに従って解析とフィルタリングが行われます. nohup bin/logstash -f xxx.cnf>/dev/null 2>&1&はバックグラウンドで実行できます. は、logstashプロセスが生存しているかどうか、および再起動しているかどうかを確認するための簡単なモニタリングを書くことができる.
プロファイル
主にMySQLの遅いログの解析の正則で、ネット上のを参考にして、しかし1つが正しく一致することができることがなくて、自分で更に加工するしかありません.中にはフィールドがありますが、マッチングに失敗したものはフィルタリングすることもできます.完璧ではありませんが、使えます.
配置
現在、オンライン上には860台前後のマシンのlogstashが配備されており、1台あたり3~4個のMySQLインスタンスを走り、合計2500~3400個のMySQLインスタンスがある.ほとんどの例はスローチェック(1 s未満)がなく,小さな部分も明らかでkibanaインタフェースから直感的に見ることができる.図のように、いくつかの暗黙的な変換の問題も解決された.
に質問
欠点も明らかで、logstashはリソースを多く占めており、2.1バージョンのlogstashは構成のホットロードをサポートしていないため、修正が面倒です.
これまでpt-query-digestで行ったスローログ分析のスキームを用いて,定期的にすべてのマシンのスローログを収集し,センタマシンに転送してpt-query-digestで分析し,最後に示した.
以上の原因に基づいて、ELKを借りて、遅いログのリアルタイム分析の方案をして、しかもkibanaの上でいくつかのグラフを配合した後に開発に渡して見ることができて、毎回新しいSQLがオンラインになった後に遅いログの情報のリアルタイムの展示によって直ちに問題を発見することができます.
シナリオの決定
まずネット上で遅いログの分析展示についての方案を探して、ptツールのほかに、logstashで正則的にマッチングすることがあって、ちょうどそのログの分析処理が比較的に人気があって、ELKはその中の1つで、しかも部門の他の同僚はすでにELKサービスを構築して、ちょうど使うことができます.
ビルド
プロファイル
主にMySQLの遅いログの解析の正則で、ネット上のを参考にして、しかし1つが正しく一致することができることがなくて、自分で更に加工するしかありません.中にはフィールドがありますが、マッチングに失敗したものはフィルタリングすることもできます.完璧ではありませんが、使えます.
input {
file {
path => "/data1/mysql*/slow.log"
type => "slow-log"
codec => multiline {
pattern => "^# User@Host:"
negate => true
what => previous
}
}
}
filter {
grok {
match => { "message" => "# User@Host: (?[a-zA-Z0-9._-]*)\[(?:.*)\]\s+@\s+(?\S*)\s+\[%{IP:client-ip}*\]\s.*# Query_time: %{NUMBER:query_time:float}\s+Lock_time: %{NUMBER:lock_time:float}\s+Rows_sent: %{NUMBER:rows_sent:int}\s+Rows_examined: %{NUMBER:rows_examined:int}\s.*(?use \S*)?.*SET timestamp=%{NUMBER:ts};\s+(?(?\w+)\s+.*)\s+#?\s*.*" }
}
grok {
match => { "path" => "/data1/mysql%{NUMBER:port:int}/slow.log" }
}
}
output {
elasticsearch {
hosts => ["x.x.x.x"]
index => "%{type}-%{+YYYY.MM.dd}"
document_type => "%{type}"
}
}
配置
現在、オンライン上には860台前後のマシンのlogstashが配備されており、1台あたり3~4個のMySQLインスタンスを走り、合計2500~3400個のMySQLインスタンスがある.ほとんどの例はスローチェック(1 s未満)がなく,小さな部分も明らかでkibanaインタフェースから直感的に見ることができる.図のように、いくつかの暗黙的な変換の問題も解決された.
に質問
欠点も明らかで、logstashはリソースを多く占めており、2.1バージョンのlogstashは構成のホットロードをサポートしていないため、修正が面倒です.