作った・喋ってきたまとめ振り返り的なやつです。去年の振り返りはこちらです。ともにISUCON9の予選出題をやらせていただいた。7月から9月にかけて圧倒的に手を動かした。解説と講評のほか、ローカル環境で予選問題を動かす方法についての記事を書かせてもらった。isucon.netisucon.net参加していただいた方、出題メンバー、各言語への移植をやっていただいた皆様、さくらインターネットの皆様、アリババクラウドの皆様、そして941さんをはじめLINEの皆様、改めて感謝です。作ったpercentilegithub.com説明はないが、簡単にpercentileを求められるようにするコマンドです。0.0030grep、jqやlltsvと組みあわせると便利mackerel-plugin-axsloggithub.commackerel-plugin-accesslogで少し足りない機能があったので作った。一度つくった上で、より速いやつが書けそうだと思って書き直したら速くなった。blogも書いているkazeburo.hatenablog.com「秒間2万req、1分間で120万行のログが記録される、よくある環境」はほんの少し盛っているppdpgithub.com某DBサーバへの通信のログを取りたいということで作った。protocol対応を行なった。mysqlのように使う。組み合わせて使うことを考えていた。アプリケーションのログが爆発したときに書いた。Go言語の初期状態のbufio.Scannerは1行の長さが65kを越えると、すぎゃんをやめてしまう仕様なのだが、その中で1MBを越えるログが発見された思ひでもmackerel-plugin-postfix-loggithub.comメール送信をインストール型のソフトウェアからクラウド型のサービスに切り替えたので、中継サーバとしてのpostfixの監視重要性が高まったので書いた。メトリクスはいくつか増えるが、役に立っているかどうか聞かれると、そんな役に立ってない。consul-service-has-ipgithub.com指定したconsulのサービスに、任意のIPアドレスが含まれるかどうか確認するのを簡単にするAPIサーバ。Slaveサーバの分散・切り離しに必要になって作ったが、もっと良い別の方法を発見し、3日ぐらいでお蔵入り。書いたからってそこにしがみつかないことも大事。mackerel-plugin-pinginggithub.comデータセンター間の通信を普段からモニタリングしていくために作った。アドベントカレンダーの記事として紹介しているkazeburo.hatenablog.com成功失敗だけではなく、RTTのパーセンタイルもでるので、便利。mypsgithub.comMySQLのprocesslistをgrepしたり、思いの強いクエリKILLするのに便利なコマンド。便利ツールはいざと言う時に思い出さず、やくに立たないので、作ったことを自分で忘れないようにblogも書いた。kazeburo.hatenablog.comgrepとlltsvで別の監視に使うことも考えている。10/28検索まわりのこれまでストーリーを短めに紹介させてもらった。12/23ここ1年で作ってきたプラグインやDB周りの監視について課題を交えながら紹介した。見事に時間オーバーした。--先日、10年ぶりぐらいにデータセンターにて、1Uサーバのハードウェアを増設する作業を行なった。以前は作業していると手がいつのまにか赤くそまっているようなことがあったが、サーバもサーバをマウントするレールもラックも非常に精度が高く作られており、スムーズにきっちりと動くことに非常に感動した。いった機器を設計、製造する方々のおかげで我々の業務が成り立っているとの思いを新たにした。PROCESSLISTをみて、クエリをKILLするなんてことは、あったりなかったりします。この時にクエリが数十個となると、手作業ではやりきれませんので、コマンドを駆使して対応することになります。killは複数個のidを受け取れるのでGROUP_CONCATが使うのがおしゃれですねこの手のコマンドでも使い慣れているし、その場にあわせて変更していけるという強みはあるのですが、流石になんとかしたいと思い、ちょっとしたコマンドを作りました。mypspgrep、pkillのようにprocesslistをgrepしてkillできることを目指しました。あると教えてもらいました。そっちを使ってもいいかと思います。info(クエリ)が利用できます。sleep(360)grepをkillに書き換えるとKILLクエリが発行されます。出力はすべてltsvで、ターミナルでは色もつきます。見やすく、間違いにくくなるのではないかと思います。ワイルドカードが使えるのは時間以外はすべて、LIKE文を使って検索しているからなのです。?NULLは空っぽ文字列として扱ってます。このあたり使い勝手に影響するか、まだこれから使ってみないとわからないところです。xargsなどを組み合わせることになりがちですが、全てのDBサーバにいれて、ブログも書いたので、いざという時に使おうと思います。ついてこの記事はMackerelアドベントカレンダー9日目の記事です。pluginの数がとても少なかったのでショックを受けているMackerelアンバサダーのkazeburoです。この記事ではそのうちの一つを紹介します。mackerel-agent-pinginggithub.com公式のpluginとして、check-pingがありますが、こちらはmetricsを取得するためのpluginとなります。ありますが、こちらとは取得しているメトリクスが異なります。1575852276実行には、SUIDを設定またはroot権限が必要になります。RTTのMax、Min、平均と90%tileを出力します。タイムアウトやpingを送出する間隔はオプションにて変更できます。データセンター間のレイテンシや、ネットワーク上の問題を検出するために使っています。このグラフから某所から某所へのRTTは18msec、pingの失敗は観測されていないことがわかります。NAT経由での外部との通信品質の監視、マルチクラウド環境でのVPNやinterconnectの監視にも利用できるかと思います。機会があればご利用ください。紹介MackerelアンバサダーになりましたMackerelアンバサダーになったので、グッズ頂いた。2019ということで、新しいmackerel-pluginの紹介です。いうとても便利なプラグインがあります。公式のブログに詳しく解説があります。mackerel.ioこれを使うと、アクセスログのファイルサイズを記録しながら差分を読み、ステータスコードごとのアクセス数や割合、レイテンシなどを集計、可視化できます。レコメンドされているラベルで固定であり、某所でレスポンス速度を記録しているものと異なるため、使うことができませんでした。Anotherなmackerel-pluginを作りました。公式にもあるログローテート対応あたりを中心に改善に取り組んで、バージョンv0.0.6まできております。結果としとして、上記2つの課題は解決し、毎秒数千以上のリクエストを捌く環境でもアクセスログの集計と可視化が安定してできるようになりました。ベンチマーク秒間2万req、1分間で120万行のログが記録される、よくある環境を想定し、ベンチーマークを行いました。ログファイルのサイズは287MBになりました。0m0.126sここではaccesslogの7.843sに対して、axslogは0.393sなので、約20倍高速に動作することが確認できました。benchmarkに利用したscriptは、axslogのrepositoryのdemoディレクトリ以下にあります。Pro上で実行しました。改善の余地がある状態これくらいです。監視のツールなので、複数のcpuに処理を分散するような手法はいまのところとっていません。まとめぜひ使って見てくださいませ。動作優先で全く綺麗なコードではないですが、さらになにかできそうなことがあれば、教えてください。作った・喋ってきたまとめ振り返り的なやつです。O_EXCLを取り除いてみるもの。前夜祭で喋ったspeakerdeck.comrelaxlogsgithub.comdaemontoolsで動かしているデーモンのログをもう少し長くとりたいということで書いたもの。lestrratさんのfile-rotatelogsをコマンドにしたものとも言えるwsgate-servergithub.comなんらかの汎用的な認証を通して、MySQLに繋ぎたいということで書いていたもの。WebSocketはインターンにきていた優秀な若者がだしたアイディアからきている。wsgate-clientgithub.comwsgate-serverのclient。いえば某productionでMySQLに対してコンテナから接続するために動き始めている。この2つに関してはblog書いていた。kazeburo.hatenablog.commackerel-plugin-linux-process-statusgithub.comプロセス単位のCPU使用率をとるために書いた。statusと言いつつCPU使用率しかとれないので名前負けしている。とあるリリースでMySQLのCPU使用率があがっていたが、昼間に気づかずアクセスの上がる夜間にサービスに影響がでてしまった障害があり、影響が出てしまう前に検知するためにつくった。サーバのCPU使用率で十分じゃないかと思うが、backupやログの圧縮でCPU使うことがあり、単純な監視では誤検知が多くなりそうということで、この監視プラグインを作成した。現在は全てのMySQLサーバに導入済み。sabogithub.com毎日0時に動くとある処理に、複数のDBからデータをmysqldumpなどでかき集めて、処理に適したフォーマットに変換して、S3にアップロードするというものがあるのだが、その際にネットワークを使いすぎて、サービスに影響が出ているかもしれないということで作った。(サービスへの影響は別の原因だったわけだが)throttleというコマンドがあり、これはpipeで挟み込むことで処理の速度を制限するものがある。production環境でも巨大なログの転送などで利用している。linux.die.netcgroupsを使うというアイディアもチームで話をしたときにあったが、ピンポイントで帯域制限ができるthrottle形式でやってみた。&waitsaboはwork-dir内にファイルをつくり、flockをかける。一定間隔でwork-dir内のflockがかかったファイルの数を数え、max-bandwidthをそれで割る。2つのmysqldumpのうち、一つが終われば残った方は最大の帯域が使えるようになるということ。production環境でも落としてくるデータのサイズはバラバラなので、等しく帯域制限をかけてしまうと無駄が多くなる。名前は「みいつけた」からとった。Deployしたいと思って書いたもの。blogも書いていた。starterという環境でproductionで某某が動き始めている。starterには、新しいプロセスが正しく起動してなくても、古いプロセスを止めてしまうという問題があった。こちらは修正済みになる。GitHubちなみに名前は「みいつけた」からとった。--6/7がGo言語、のこり一つがC言語。社内のrepoにしかないものでもGo言語が増えている。Perlで書くのはmackerelの監視プラグインぐらいだ。2018speakerdeck.com--仕事ではSREに新メンバーが増え、MySQL、検索、データセンターのプロジェクトなどチームとしてできることがかなり広がってきました。その一方で北海道での地震の影響、外部のネットワークトラブル、データベースへの負荷などお客様にご迷惑をおかけしてしまうこっとも多くありました。お客様に信頼性や価値を届けるためにできることはまだまだあると考えており、来年以降も取り組んでいきます。proxyに対応したものが欲しかったので、作ってみた。accountで認証して接続するイメージとしては以下のようになる。対してforwardするproxyが起動するclient側serverと同じようにmapファイルをつくる。map-client.txtこれで各サーバにログインできるようになる。設定し、IAPを有効にする。accountで認証しつつ、任意のサーバと通信ができるようになる。wsgate-clientには簡単な公開鍵認証と、任意のヘッダがつけれる仕組みがあるので、認証しつつ任意のプロトコルで通信することが簡単に実現できる。WebSocket、去年の夏にインターンに来てくれた若者がアイディアを出してくれて、それ以降少しずつ使っているところが増えている。portをlistenして、proxyを開始するものです。ラベルがついたコンテナが複数個あると、必ず一番新しいものだけにproxyするようになってます。Deployができます。80をlisten開始しています。すれば素敵なnginxのページがでます。対してHUPを送ります。33022コンテナも入れ替わりました。apiに1秒ごとにアクセスし、portの変更を検知して、proxy先を変更します。deployには使えなかったので新しく作った次第です。