クックパッドを退職して株式会社リスタを立ち上げました

しばらく前にいろいろあってクックパッドを退職し、
諸事情によりリスタという会社の立ち上げをやっていました。

クックパッドを退職したのは完全になりゆきと勢いです。
クックパッドはめちゃめちゃちゃんとしたリーダー陣とあきれるくらい優秀な同僚たちのいるすごくいい職場でした。

いやーもういい歳なのでそろそろ落ち着きたいと思っているのですが、
なかなか縁が無いですね。。。安定と嫁。。。

で最近はRailsとかCSSをオラッと勉強して、
JOBLISTという求人サイトをオラッと立ち上げてました。

でも気がついたらgithubのissueが70個とかになってて、
なんかもう1人じゃダメそうなのでエンジニア募集します！

興味ある人、ぜひメッセージ下さい！
twitterでもfacebookでもなんでもokです！

なかなかすごい経営陣が揃ってるので面白い経験が出来ると思います。

WEB系各社で使われている監視ツールまとめ

次世代 Web カンファレンスで監視について話すことになったので、ネタとしてWEB系各社で使っている監視ツールを調査中。

うちはこれ使ってるよ！！！ってのがあったら@にメンションください！

Cookpad

  • Zabbix
    • 昔はNagios+muninだけど台数増えて性能的に破綻した
    • ビューはそのままじゃ辛いのでmunin風に表示するのを自作
  • StatusCake
  • DataDog。サービス系、サーバに紐付かない系の監視に。DashBoard便利
  • waker。通知用。PagerDuty高い、と言ってryot_a_raiが秒で作ったらしい
  • Kibana
  • imon。独自のリアルタイムなサービス稼働状況表示ツール
  • NewRelic
  • 試し中なもの
    • Real-User Monitoring : JSでbeacon飛ばしてfluentd -> BigQuery。Google SpreadSheet+GoogleAppsScriptでBIツールっぽく
    • ログ監視 : graylog

DeNA

  • nagios
  • ganglia
  • cloudforecast
  • pagerduty
  • haikanko

GREE

  • AWACS。自作の監視ツール
  • Ganglia。いろいろ魔改造されているそうだ
  • 昔はNagios, Cactiだったっぽい
  • ネットワーク監視でCactiも残っている
  • AWS系はまた別？
  • 他にもいろいろ周辺ツールがあるらしい

CyberAgent

  • 部署、グループごとに違ってて全貌を知るのは困難
  • Zabbix派とそれ以外派で宗教がわかれている
  • Zabbix以外で多いのはnagios+mon?
    • 一部で、作業時にmon監視外すのがダルい -> sensu
    • 一部で、sensuダルい -> Mackerel
  • muninも多いらしい
  • datadog, stackdriver, makarel
  • NewRelic, Cacti
  • kibana, sensu, proteus-monitor
  • CloudWatchMetrics, BigQuery, Norikra
  • ミドルウェア特化系 : clouderamanager(hadoop)、opscenter(cassandra)、amc(aerospike)
  • Grafana+InfluxDBを昔使っていた
    • InfluxDBがインデックス貼れないバージョンで1週間分のグラフ表示しようとすると3分ぐらいかかってて使い物にならない。0.9からはインデックス貼れるっぽいが
  • Mackerel月1ぐらいで5分ほど障害起きたりするので少しだけ不安

mixi

  • nagios
  • kibana/Fluentd/GrowthForecast
  • NewRelic
  • PagerDuty
  • CloudForecast
  • Zabbix
  • サービスごとに違うらしい

はてな

  • Mackerel
  • Nagios。過去の経緯、捨てたい
  • Kibana
  • Cacti(ネットワークのみ)

ペパボ

  • nagios, munin
  • mackerel
  • NewRelic
  • consul-alerts
  • Fluentd、kibana、TD、GrowthForecast

VOYAGE

  • Hobbit
  • Pandra FMS
  • cloudwatch
  • NewRelicを使ってるチームもある

CROOZ

  • hobbit
  • 一部、Elasticsearch＋grafana。Zabbix

カヤック

  • Zabbix
  • 自社サービス系はzabbixで統一。受託はnagiosとかだけどmackerelにして行きたい気持ち

ドリコム

ハートビーツ

  • nagios, cacti
  • ラッパーとか中心に自作も進めてる

SmartNews

  • DataDog。サーバ監視他
  • NewRelic
  • PagerDuty

Gunosy

  • OS外cloudwatch
  • OS内datadog
  • プロセスmonit/supervisord
  • ログpapertrail/kibana
  • 通知pagerduty
  • railsプロジェクトでnew relic

トレタ

ヒトメディア

  • pagerdutyとnewrelicとmuninとsensu。proteus-monitor
  • 今後はdatadogとpagerdutyとnewrelicに？

リブセンス

  • Nagios　日々の設定変更に伴うメンテナンスに苦労している
  • Munin 14系。ほぼ自動設定で動くので運用が楽な一方、台数と利用者が多いため動作にもたつきがある
  • Mackerel+PagerDuty
    • Nagiosに代わってこの組み合わせを採用するメディアが増えてきている。
    • グラフ表示も軽快な上に日々機能が進化しているので期待している。
  • Fluentd + 独自モニタリングツール アプリエラーログを収集してHipChatなどに通知する

メルカリ

  • Zabbix
  • Kurado
  • Mackerel
  • 『zabbixはグラフが見辛いので、グラフ専用のツールとしてkuradoを使ってます。mackerelはnorikraの出力のグラフ化とアラート設定に使ってます』
  • Kibana
  • NewRelic
  • Norikra

Kaizen Platform

  • 情報元。ちょっと古いから変わってるかも
  • Pingdom
  • Sensu
  • Mackerel
  • StatusPage.io
  • PagerDuty

Retty

TreasureData

  • Datadog + Fluentd(カスタムメトリクス) べったり
  • pingdom
  • statuspage.io
  • pagerduty
  • NewRelic

Quipper

  • Pingdom
  • Sentry
  • Datadog
  • NewRelic
  • fluentd+BigQuery+re:dash

グラニ

  • NewRelic
  • CloudWatch -> Librato
  • SLAB(ETW) fluentd的なもの。マイクロソフトのロギングライブラリ
  • ログ分析・可視化に BigQuery、Domo
  • Redis のコマンド実行可視化に Glimpse、MySQL のクエリの調査に JetProfiler

ドワンゴ

  • ブコメより
  • xymon
  • nagios
  • zabbix

pixiv

  • nagios
  • Fluentd, kibana, 独自ビュー。slide
  • pixiv以外のプロジェクトはMackerelとかいろいろ使ってる？

レアジョブ

  • Zabbix
  • Cacti(Zabbixに移行中)
  • MySQL のクエリの調査に JetProfiler
  • 自作の監視シェル（Bash Shell）

Gloops

  • 元情報。古すぎて信ぴょう性薄い
  • icinga
  • pnp4Nagios

これから聞いたり調べたり出来るといいなと思っているところ

  • mixi 知りたいけど知り合いいない
  • LINE 大人の事情で聞けなそう？
  • Freakout どっかに公開されてた気がする
  • その他、情報募集中！

InnoDBのウォームアップに別サーバでdumpしたib_buffer_poolを使ってみる

MySQLでスレーブを複数台並べている。
負荷増加やサーバ障害で新規スレーブを追加したい。
で、構築したばかりのMySQLスレーブをいきなりサービスに突っ込むとどうなるか。

それなりの規模のサービスであれば、buffer_poolが空っぽのDBだとIOがつまって応答遅延が発生します。

というわけでサービス投入前にbuffer_poolのウォームアップが必要で、方法としてはいくつか考えられます。

基本的にサービス投入前の完璧なウォームアップは無理ゲーなので、
普段は主要テーブルのIndexを読み込んでから、低い振り分け比率でサービス投入、ディスクIO見ながら徐々に振り分け比率を上げていく、ということをしていました。

しかししばらく前にとあるエンジニアから『稼働中DBでdumpしたib_buffer_poolを新規DBでloadする』というかなりびっくりなウォームアップ手順を聞きました。

どういうことかというと、MySQL5.6から使える以下の設定はよく知られていて、

innodb_buffer_pool_load_at_startup = 1
innodb_buffer_pool_dump_at_shutdown = 1
#innodb_buffer_pool_dump_pct  = 100

この設定があるとMySQL停止時にバッファプールの状態をダンプし、起動時にそれを読み込むことでバッファプールの状態を復旧出来ます。
このダンプファイル(ib_buffer_pool)は稼働中のDBでも取得可能なので、それを新規構築したDBで読み込めばバッファプールを本番稼働中の既存DBと同じ状態に出来ると。

これはなかなか怪しい手順です。
ダンプファイルに入っているのは、主キー値などではなくtablespace ID and page IDで、細かいことよくわかってないですが取得したDBとは別のDBでそれを使うのはかなり乱暴な気はします。

ただ今自分が主に使っている環境では、バックアップDBがあって、新規スレーブのデータは全てこのDBのEBSのスナップショットから作っています。
つまり元データは完全に同じもので、その後の更新クエリも同じもの。
なんかいけるような気もする・・・

まぁとりあえず試してみよう、ということでやってみました。

ウォームアップ手順

稼働中のスレーブでdumpを取る。

> SET GLOBAL innodb_buffer_pool_dump_now = 1;

以下のコマンドを実行してcompletedになってれば完了。
これはあっという間に完了して、サービス影響は全く無さそう。
ダンプファイルもすごく小さいです。

> SHOW STATUS LIKE 'innodb_buffer_pool_dump_status';
+--------------------------------+--------------------------------------------------+
| Variable_name                  | Value                                            |
+--------------------------------+--------------------------------------------------+
| Innodb_buffer_pool_dump_status | Buffer pool(s) dump completed at 150723 15:22:44 |
+--------------------------------+--------------------------------------------------+

出力されたダンプファイルを新規DBにコピーする。

$ ls -lh /var/lib/mysql/ib_buffer_pool
-rw-rw---- 1 mysql mysql 28M Jul 23 15:22 /var/lib/mysql/ib_buffer_pool

innodb_buffer_pool_load_at_startup =1が設定されていれば、mysqlを起動するだけでダンプファイルの読み込みが始まります。

# service mysql start

既にmysqlが起動済みであれば以下のコマンドでloadを開始してもOK。
※別のloadが走ってたらinnodb_buffer_pool_load_abort=1で止めてからのほうがいいかも。

> SET GLOBAL innodb_buffer_pool_load_now = 1;

以下のコマンドでcompletedになれば完了。

> SHOW STATUS LIKE 'innodb_buffer_pool_load_status';
+--------------------------------+---------------------------+
| Variable_name                  | Value                     |
+--------------------------------+---------------------------+
| Innodb_buffer_pool_load_status | Loaded 1537/2679699 pages |
+--------------------------------+---------------------------+

> SHOW STATUS LIKE 'innodb_buffer_pool_load_status';
+--------------------------------+--------------------------------------------------+
| Variable_name                  | Value                                            |
+--------------------------------+--------------------------------------------------+
| Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 150723 18:51:30 |
+--------------------------------+--------------------------------------------------+

検証

とある本番環境でざっくり効果を検証してみました。
どうせ環境依存がデカイので細かいことは置いといて、1回ずつだけウォームアップ時間、サンプルクエリの実行時間を測定しました。

  • r3.2xlarge (EBS最適化オプションつけ忘れてた)
  • MySQL 5.6
  • buffer_pool_size = 45G
  • mysql用EBS : gp2 600G。全部同じスナップショットから作成

サンプルクエリは本番サーバでtcpdumpしてとった50万行のSELECTです。

$ egrep '^SELECT' /tmp/select.sql | wc -l
504316

実行時間は単純に1並列で流し込んで測定しました。

$ time mysql -uxxx -p'xxxx' db_name < /tmp/select.sql > /dev/null

比較として、いつもやってる主要テーブルのIndexの読み込みウォームアップも合わせて実施します。

$ innodb-warmer -u xxx -p 'xxxxx' -d db_name -t comments,articles,...

innodb-warmerコマンドは@songmuさんのMySQL::Warmerを@sgwr_dtsさんがrubyで書きなおしたものです。公開されてたっけな・・・

結果

warmup済みのEBSで検証してみるとこんな感じ。

ウォームアップ サンプルクエリ実行
既存稼働中サーバを振り分け外して - 2m36s
ウォームアップ無し 0 8m42s
innodb-warmerで主要テーブルを温める 66m14s 4m15s
別サーバからbuffer_poolをdumpしてload 33m と少々(dump&scp) 2m38s

別サーバからbuffer_poolをdumpしてloadした場合のウォームアップ時間は30分強で、検証クエリの実行時間は本番稼働中のサーバと同程度に速かったです。
どちらもIndex読み込み方式に比べるとかなり優秀。

wamup無しのEBSだとどうなるか

ウォームアップ サンプルクエリ実行
innodb-warmerで主要テーブルを温める 4h9m 24m41s
別サーバからbuffer_poolをdumpしてload 7h37m 2m49s

ウォームアップの時間がものすごくかかる・・・
この状態のDBを実際にサービスに投入してみます。

レプリケート取りつつほんの少しクエリ流したところから、50%->100%と振り分けに入れていくと、

f:id:mikeda:20150921140239p:plain

読み込みのIOPSはこうなる。

f:id:mikeda:20150921140308p:plain

青がサービス稼働中の既存DB、赤が『innodb-warmerで主要テーブルを温める』のやつ、緑が『別サーバからbuffer_poolをdumpしてload』。
緑のディスク読み込みが短時間で本番DBと同程度になるのに対し、赤はだいぶ時間がかかっています。

んー、こっちの結果はEBSのウォームアップはたいへんだなという意味しかないかな。
EBSのウォームアップ、もうちょっとなんとかなんないかなぁ・・・

まとめ

検証した条件では、ib_buffer_poolを別サーバから持ってきてloadするのはInnnoDBのウォームアップ手順としてなかなか優秀なように見えるので、状況に応じて使っていこうと思います。
ただこの方法が汎用的に使えるのかというと疑問があるので、ツッコミや別の検証結果があればぜひ見たいです。

GoogleスプレッドシートからAWSを操作する

最近、TerraformやCloudFormationみたいに、JSONや独自DSLなどでかっこよくAWSを管理するツールがいろいろ出てきてます。

こういうツールは便利そうだなとは思うんですが、なんかふと、ユーザがホントに求めているものはコレなんだろうか？と思いました。
なんだかんだ言って、一番多く使われているサーバ管理ツールは『Excelサーバ一覧』なのではｗ？
じゃあExcelで同じようなことが出来ればそれが一番いいのでは？と。

というわけで、Excelは手元になくてキツイので、今回はGoogleスプレッドシートでAWSのサーバ構成管理をやってみました。

使い方

事前準備

サンプルのスプレッドシートをコピーする

『ツール』 -> 『スクリプトエディタ』 -> config.gsを編集

f:id:mikeda:20150908092822p:plain

AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYにAWSのアクセスキーを、 SPREADSHEET_URLにはコピーしたスプレッドシートのURLを貼り付けてください。
あとはテキトウに。

アクセスキーの権限は、EC2とCloudWatch系のが必要です。あとでもうちょい丁寧に書こう・・・

サーバ一覧の取得

コピーしたシートに戻って

『AWS』 -> 『AWS -> SS』を選択すると、

f:id:mikeda:20150908092857p:plain

『ec2』シートにEC2の情報が読み込まれます。

f:id:mikeda:20150908092943p:plain

※初回実行は権限の承認が必要です。

サーバ一覧からインスタンス起動

ec2のシートに新しい行を追加して(instanceId、stateは未記入)、『AWS』 -> 『SS -> AWS』を選択すると、

f:id:mikeda:20150908093005p:plain

インスタンスを起動していいかの確認画面が出て、

f:id:mikeda:20150908093036p:plain

シートが更新されます。

f:id:mikeda:20150908093112p:plain

新しいインスタンスが起動されているので、Console等で確認してください。

f:id:mikeda:20150908093200p:plain

ついでにサーバの監視

『AWS』 -> 『Monitoring』を選択すると、

f:id:mikeda:20150908093436p:plain

稼働中のインスタンスごとに名前がインスタンスIDのシートが作成されて、直近24時間のCPU使用率の推移がグラフで確認出来ます。
閾値を超えているとアラートも飛んできます。

f:id:mikeda:20150908093859p:plain

スクリプトエディタの『リソース』からこんな感じでトリガーを設定してやると、10分間隔で自動で監視してくれます。

f:id:mikeda:20150908093453p:plain

コードについて

今回はデモ用の最低限の機能しか実装してませんが、main.gsにあるようにこんな感じでaws-sdk-jsっぽくAWSのAPIを叩けるようにしています。

  // running状態のEC2インスタンスのinstanceIdを列挙する

  AWS.config({
    accessKeyId: AWS_ACCESS_KEY_ID,
    secretAccessKey: AWS_SECRET_ACCESS_KEY,
    region: AWS_REGION
  });
  var ec2 = new AWS.EC2();
  var params = {
    Filter: [
      { Name: 'instance-state-name', Value: ['running'] }
    ]
  };
  ec2.describeInstances(params, function (err, data) {
    // if(err) return; エラー処理は未実装です
    for(var i=0;i<data.reservationSet.length;i++){
      var instance = data.reservationSet[i].instancesSet[0];
      Logger.log(instance.instanceId);
    }
  });

そもそもaws-sdk-jsをGoogle Apps Scriptで動かせればよかったのですが、やりかたがわかりませんでした。

まとめ

なんかそれっぽいのが出来ましたｗ

いちおうコードはgithubにもあげときました。
ただ個人的にはrubyでコードかいてそこからスプレッドシートいじるほうがはるかに楽だし確実なので、たぶん仕事で使うことはないでしょう・・・

でも本家SDK使わずにAWSのAPI叩くの初めてでいろいろ勉強になったので、使いたいって人がいれば機能追加やバグ修正はするかもです。

自宅マンツーマン英会話レッスンを始めてみた

@oinumeさんがDMM英会話を初体験というのを始めたようだ。
自分も全く同じタイミングで別の方法で英会話の勉強を始めてたので、自分のほうも簡単にレポート書いてみる。
@oranieさんや@kenjiskywalkerさんは普通の英会話教室通い始めたみたいで、タイミングが近いのでいろいろ比較ができそう。

ちなみに自分は今は英語が全く出来ません。
英語ドキュメントを読むのも出来ないし、gitのコミットコメントを英語で書くのも辛いしたまに英語おかしいとツッコまれる。
過去に会社の金でベルリッツのマンツーマンレッスン40分60回を受けたことがあるけど、8年前の話でその後は全く英語使わなかったので完全に忘れました。

目的

基本的には仕事用です。

まずは勢いでAWS re:Invent 2015行くことになったので、 それまでに去年の発表聞いて理解できるようになりたいんだけど、
https://www.youtube.com/watch?v=ZPbM2qGfH3s
今はほとんど全く聞き取れない。

選んだところ

テキトウにググったら出てきたここを使ってみることにしました。 http://www.teacher-student.com/

講師が自宅近くのカフェ(自分の場合は自宅)まで来てくれて、そこでマンツーマンレッスンを受けられる。
ある程度会話が出来るようになればDMM英会話とかも考えるけど、最初はコストかけて手厚くやろうと。

料金は講師ごとに違って、恵比寿だと1時間で300円~3500円が多い。
http://www.teacher-student.com/s/%E6%81%B5%E6%AF%94%E5%AF%BF.en.html

DMM英会話とかと比べるとかなりお高いけど、ベルリッツのマンツーマン(40分で6000円~8000円)と比べると安いし、近くまで来てくれるので移動時間がかからない。

実際どんな感じか

講師と受講スケジュールの希望を書いて申し込むと、近くのカフェで説明とデモレッスンがセッティングされた。
希望した講師はスケジュールが合わずに別の講師を紹介された。

カフェはちょっとイヤなのでレッスンは自宅で、と希望したけど、最初は駅から遠い(10分ちょっと)から難しい言われた。
なので「時間単価を+500円します」と言ったら次のレッスン予定に支障を来さない場合は自宅OKとなった。
というわけでレッスン価格は1時間3000→3500円に。この辺りは交渉次第そう。
レッスン時間は平日の出社前(8:00~9:00)と休日の空いてるところで随時調整とした。

最初に入会金と半年分の会費、35000円を払った。

http://www.teacher-student.com/price/

継続は会費がだいたい月1000円ぐらい。

あとはもうほとんど講師まかせな感じです。

レッスンは特に決まったテキストはなく、自分の担当の人が使うのはiPadのみ。
お題(1回目は自己紹介、2回目はお金について)があって、簡単なメモや写真を準備してるぐらいで、あとはiPadでメモを取りながら会話ベースで進んでいきます。
メモはあとでPDFにして送ってくれます。

スケジュール調整とかも講師と直接メールでやります。お金もその場で毎回払います。

と、内容についてはかなり講師次第な感じです。他の講師を試したり、並行してレッスンを受けたりも出来るようなので自分で合う講師を探せという感じですね。
逆に言うと決まったテキストとかないのでこういうレッスンしたいというのがあれば交渉できそう。

英会話に慣れるのにはいいけど、語彙や文法については別途個人で勉強したほうが良さそう。
今のところ少しキャッチボールが成り立たなすぎてつらい。

というわけで

もうしばらく続けてみる。

Akamaiの月間転送量をrubyで取得する

AkamaiのReport Groupごとの月間転送量がほしいなと思ったらAPIが合ったので、rubyで取得してみた。

https://github.com/mikeda/akamai-open-api

Akamai管理画面から設定 -> API管理 -> Luna APIsで『コレクション』、Billing CenterのREAD-ONLY権限を付けた『クライアント』を作成してサンプルを実行すると、

$ bundle install
$ export AKAMAI_API_BASEURI='https://akab-xxxx.luna.akamaiapis.net/'
$ export AKAMAI_API_CLIENT_TOKEN='akab-xxx-xxx'
$ export AKAMAI_API_CLIENT_SECRET='/xxxxx'
$ export AKAMAI_API_ACCESS_TOKEN='akab-xxx-xxx'
$ bunde exec ruby sample/show_measures.rb 2015 6
propterty001
  Object Caching
    95/5 Mbps : 4.315 Mbps
    Peak Mbps : 9.867 Mbps
    Total Hits : 5337 Hits
    Total MB : 5962.453 MB
...

Report Group、プロダクトごとの月間使用量が取得できる。

基本的に本家のPythonのサンプルをrubyに書きなおしただけです。

んー、なんかAPI使いづらい・・・
APIはやろうと思ったら他にもいろいろできそうだけど、とくに予定はない。

Railsでpt-query-digestのexplainがエラーになるので雑に対応した

MySQLのクエリ解析をやろうとDBサーバでtcpdumpでパケットキャプチャとって、

tcpdump -s 65535 -x -nn -q -tttt -i eth0 port 3306 > /tmp/mysql_pcap.txt

explainオプション付きでpt-query-digestを実行してみたんだけど、

pt-query-digest --type tcpdump --explain "h=localhost,u=root,p=xxxxx" /tmp/mysql_pcap.txt

なんかexplainがコケる。

# Tables
#    SHOW TABLE STATUS LIKE 'users'\G
#    SHOW CREATE TABLE `users`\G
# EXPLAIN /*!50100 PARTITIONS*/
SELECT `users`.* FROM `users`  WHERE `users`.`id` IN (57297, 205043)\G
# EXPLAIN failed: DBD::mysql::st execute failed: No database selected [for Statement "EXPLAIN /*!50100 PARTITIONS */ SELECT `users`.* FROM `users`  WHERE `users`.`id` IN (57297, 205043)"] at /usr/bin/pt-query-digest line 7678.

ちゃんと処理を追ってないけど、Railsはコネクション張りっぱなし系だからdatabaseが特定出来てないのかな。
databaseが1つだけの場合はオプションで接続先を指定してやればいけそう。

pt-query-digest --type tcpdump --explain "h=localhost,u=root,p=xxxxx" --database dbname /tmp/mysql_pcap.txt

しかし別のところでまだエラーが。

# Tables
#    SHOW TABLE STATUS FROM `dbnamemysql_native_password` LIKE 'items'\G
#    SHOW CREATE TABLE `dbnamemysql_native_password`.`items`\G
# EXPLAIN /*!50100 PARTITIONS*/
SELECT `items`.* FROM `items`  WHERE `items`.`id` = 847928\G
# EXPLAIN failed: DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 [for Statement "USE `dbname at /usr/bin/pt-query-digest line 7675.

database名にmysql_native_passwordとかってよくわからん文字列がくっついている。
tcpdumpを使うとかなんかの条件下でパースがうまくいってないのかな。

レポート処理のところで余計な文字列を削除してみる。(もっといい方法がありそう)

--- /usr/bin/pt-query-digest 2015-04-01 09:03:13.779851851 +0900
+++ /usr/bin/pt-query-digest    2015-04-03 08:30:11.688998565 +0900
@@ -6878,6 +6878,7 @@
          }
       }
 
+      $sample->{db} =~ s/\W.*$// if $sample->{db};
       $item_vals{default_db} = $sample->{db}       ? $sample->{db}
                               : $stats->{db}->{unq} ? keys %{$stats->{db}->{unq}}
                               :                       undef;

細かいことはよくわからんけど、とりあえずエラーは消えた。