為了分析某些儲存在 MySQL 的 log,敝單位在兩年前(2017)導入 Logstash;當時我們用最新的 5.5.1 版,運作狀況還不錯,所以就沒什麼人理它…
最近冒出問題,救完火後寫個紀錄。
第一個問題是這個:
[WARN ][logstash.inputs.jdbc ] Exception when executing JDBC query {:exception=>#<Sequel::DatabaseError: Java::ComMysqlJdbcExceptionsJdbc4::MySQLDataException: ‘2.147483727E9’ in column ‘1’ is outside valid range for the datatype INTEGER.>}
資料的第一個欄位是 auto-increment 的 ID,看到 ‘2.147483727E9’ 就聯想到是 32 位元正整數溢位問題。
我們先換 MySQL Connector/J (& 改用 OpenJDK);換完之後,看到的錯誤訊息變成這樣:
[WARN ][logstash.inputs.jdbc ] Exception when executing JDBC query {:exception=>#<Sequel::DatabaseError: Java::JavaSql::SQLDataException: Value ‘2147483727’ is outside of valid range for type java.lang.Integer>}
於是我們就開始升版 Logstash;目前最新的版本是 7.2.0,但 官方的 migration guide 說要先升版到 6.7。
最後我們順利升上 7.2.0,在過程中也發現 6.7.2 已無 32 位元正整數溢位問題。
第二個問題發生在升版後:
DATETIME 欄位存放的 ‘2019-07-23 14:18:59’ 抓成 ‘2019-07-23T19:18:59.000Z’。
沒人能保證系統/伺服器會跨多少時區,為免夜長夢多,我們的解決方式是轉成 UNIX timestamp。
(Year 2038 problem? 以後再說! )
7 月 24 2019
Logstash 筆記
為了分析某些儲存在 MySQL 的 log,敝單位在兩年前(2017)導入 Logstash;當時我們用最新的 5.5.1 版,運作狀況還不錯,所以就沒什麼人理它…
最近冒出問題,救完火後寫個紀錄。
第一個問題是這個:
資料的第一個欄位是 auto-increment 的 ID,看到 ‘2.147483727E9’ 就聯想到是 32 位元正整數溢位問題。
我們先換 MySQL Connector/J (& 改用 OpenJDK);換完之後,看到的錯誤訊息變成這樣:
於是我們就開始升版 Logstash;目前最新的版本是 7.2.0,但 官方的 migration guide 說要先升版到 6.7。
最後我們順利升上 7.2.0,在過程中也發現 6.7.2 已無 32 位元正整數溢位問題。
第二個問題發生在升版後:
DATETIME 欄位存放的 ‘2019-07-23 14:18:59’ 抓成 ‘2019-07-23T19:18:59.000Z’。
沒人能保證系統/伺服器會跨多少時區,為免夜長夢多,我們的解決方式是轉成 UNIX timestamp。
(Year 2038 problem? 以後再說! )
No related posts.
By Joe Horn • Computer Software 0 • Tags: JDBC, Logstash, MySQL