Zabbix 4.x で API を使って Active な Problem だけを引っ張ってくる方法 - その手の平は尻もつかめるさ
要旨 どうやれば Zabbix API を使って所望の機能を実現できるかを調査する際には Zabbix が実際に呼んでいる SQL クエリを tcpdump で抜き出すと手っ取り早い． 内容 色々あってZabbixを使っているわけですが，この手のものを使っているとAPIを介して Active なアラート (Zabbixでいうとproblem) を取りたくなります． というわけで，Zabbix 4系でそれをやるにはどうしたら良いかということについて記すものです． problem.get [Zabbix Documentation 4.4] さてまずドキュメントを漁っていて使えそうに思えるのはこの辺でしょう． This method is for retrieving unresolved problems. などとそれっぽいことも書いています……がこのAPIだけ使っても駄目．なぜか Reso
Kyoto.なんか #5で「AWS上に構築する メンテ容易なElasticsearch System」というタイトルで話してきました - その手の平は尻もつかめるさ
表題の通りKyoto.なんか #5で話してきました．もうかれこれ3週くらい前の話なのですね……筆不精がたたっております． kyoto-nanka.connpass.com 内容としてはここ数年ElasticsearchをAWS上で運用しているのでそのアーキテクチャのご紹介という感じの発表をしたという次第です．現状上手いこと回っております． この発表の後にElasticの@johtaniさんからのメンションで，クラスタまたぎのレプリケーションがElasticsearch 6.7以降サポートされていることを教えていただきました．ありがとうございます！ 一応補足。6.7から有償機能だけど、クラスターまたいだレプリケーションあるんです。Elastic Cloudで使えたかはパッとは出てこないけど、、、 https://t.co/89om47nkSF— Jun Ohtani (@johtani) A
HikariCP で leakDetectionThreshold を設定して connection leak を発見する - その手の平は尻もつかめ検出
HikariCP のような connection pool を利用する上で犯しがちなミスとして，connection leak (pool から connection を borrow しっぱなしで pool に返却しないこと) があると思います．connection leak を放っておくと pool 内の connection が枯渇してにっちもさっちもいかなくなるため再優先で修正しなければなりません． connection leak を修正するには，まず connection leak の発生を検出する必要があります． 以前紹介したような，JMX を使って connection の状態をモニタリングする方法 もありますが，この方法では leak が発生した瞬間を検出することが出来ませんし，どこで発生したかもわかりませんからデバッグが難しくなります． そこでどうするかというと，Hika
Karabiner-Elementsでcolonとsemicolonを入れ替える - その手の平は尻もつかめるさ
[追記] コメントで指摘がありましたが，Karabiner-ElementsのGUI上で complex modifications → Add rule → import more rules from the Internet → Exchange semicolon and colon を選択することで所望の動作の実現が可能なようです． 従って本記事はcolonとsemicolonを入れ替えるというよりも，任意のキーを入れ替える時のためのtipsとなります． [追記ここまで] MacのUSキーボードの話です． Karabinerにはcolonとsemicolonを入れ替えるという項目があり，これが大変便利だったのですが (特にvimを使っているときとかに便利)，Karabiner-Elementsではこのオプションがありません．現時点では，macOS Sierra上だとKarabin
DynamoDB LocalでもDynamoDB Streamsは使える - その手の平は尻もつかめるさ
TL;DR DynamoDB LocalはDynamoDB Streamsをサポートしている． 本物のDynamoDB Streamsのように，一定期間以上古いレコードについてはトリミングされる (具体的なトリミング期間については未調査)． ドキュメントが少ない (見つけられなかった……) のに加え，ライセンス的に逆コンパイルは不可能なのでどういう仕組みで実現されているかがわからない…… 本文 DynamoDB Localというローカル環境で動くDynamoDBがあり *1，これはDynamoDBの動作検証やテストに利用するためのミドルウェアなんですが (もちろん本番環境で使うものではない)，これがDynamoDB Streamsをサポートしていることはあまり知られていません．僕も一昨日知りました． Yes, the latest version of DynamoDB Local sup
手っ取り早くウェブアプリケーションにOAuth2認証を導入する - その手の平は尻もつかめるさ
bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--
定期的にtcpdumpをある期間だけ実行したいという時 - その手の平は尻もつかめるさ
tcpdumpの提供する-Wオプションと-Gオプション，ならびにcrontabを併用するといける． tcpdumpの-Wオプションはログローテーションを行う回数で，-Gはそのローテーション期間を秒数で指定できる． 例えば $ tcpdump -w ./%Y%m%d%H%M%S.pcap -W1 -G60などとやると，ログローテーション1回，ローテーション期間は60秒となるので，つまり60秒tcpdumpを実行した後にexitする (ローテーション1回指定なので)． ちなみに-wオプションで指定するファイル書き出し先についてはstrptimeと同じフォーマットが利用できるのでこういう時に便利． あとはcrontabでこのコマンドを仕込んでやるとOK (id:hirose31さんから「crontabでは%をエスケープする必要がある」との指摘があり修正しました)． 55 * * * * tcpd
相手のサーバにHTTP(S)で接続できるかどうかを確認するときにリトライしながらやりたいんですけどって時 - その手の平は尻もつかめるさ
例えばCIでテストのためのストレージのコンテナを上げる際，そのストレージが上がりきるまで待たなければテストには使えないわけですが「上がりきるまで何秒待てばよいのか」というのは一概に決められるものではありません． そうした際，実際にストレージに対してHTTP(S)のリクエストを投げてみて，繋がったら「上がりきった」とみなして処理を次に進めるというようなことがよく書かれます．そういった要件を満たす為には接続に失敗したらリトライをしつつ一定回数試行するという処理を書かなくてはなりません． つまりはそういう話です． wgetの場合 retry-connrefused tries waitretry を利用すると出来る． retry-connrefused が無いと connection refusedに対応できずにリトライが不可能となるので，今回のような要件を満足するためには付ける必要があります．
mcrouterはget-multiリクエストを個別のgetリクエストに分割する - その手の平は尻もつかめるさ
mcrouterという，Facebookが作っているmemcachedの為のルータがあります．「ミクルーター」と発音するようです *1． mcrouterは多機能なルータであり，シンプルなルーティング (例えば乱択やhash basedなど) からfailoverを前提とした大規模なクラスタのルーティングまで様々なルーティングを行うことが可能です (Facebook内の数千台規模のmemcachedクラスタでも運用されているようです．参照: Facebookの数千台規模のmemcached運用について - ゆううきブログ)． さて，mcrouterの詳細や使い方の説明については他の資料に譲るとして，本記事ではmcrouterがmemcachedの get-multi リクエストを各々複数の get リクエストに分解して宛先のmemcachedに送る挙動をするという話をします． どういうこと
golangで書いたツールをCircleCI上でビルドしてその成果物をGitHub Releasesにリリースする - その手の平は尻もつかめるさ
表題の通り．いくらかポイントがあったのでメモとして記す． 基本的にこの記事の内容を真似した． medium.com あらかじめ，CircleCIの側の設定でGITHUB_TOKENという環境変数を登録しておく．なおGitHubのPersonal access tokenにはrepoのpermissionを付与しておく． とは言えこれでは動かない．理由はghr (ghrについてはこちら: 高速に自作パッケージをGithubにリリースするghrというツールをつくった | SOTA) がcontextに依存しているからで，contextはgo 1.7以降でないと利用できない．しかしながらCircleCIのgolang環境は1.6系が使える内の最新なので *1 このままではghrをgo getすることが出来ない． というわけでCircleCI上でgo 1.7を使うようにしましょう，ということでそう
そして物語は何度目かのアプリ内通知再実装を迎える - その手の平は尻もつかめるさ
というタイトルでKyoto.なんか #2で発表してきました． そして物語は何度目かのアプリ内通知再実装を迎える / Reimplement in app notification // Speaker Deck スライドの内容としては，アプリ内通知 (Twitter appで言うところの「通知」タブにあたる部分) のサーバサイドを実装する際にどういう問題があって，それをどういう風に実装したかという葛藤の記録となっています． Webアプリケーションやスマートフォンアプリケーションを書いていると，そこそこの確率でアプリ内通知を書くことになると思うんですが，ところがどっこい「実際にどういう風に実装しているか」みたいな知見が共有されている感じがあまりありません．みんな実装しているはずなのに，ググってもあまり情報が出てこなくて寂しい．地味な機能だから？ という思いがあり，そこら辺アプリ内通知周辺の技
git-reviewer 書いた - その手の平は尻もつかめるさ
code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた． そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある． 従って，やはり技術で解決ということになる． Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは p
Web Application Server を動かす時の Java8 起動オプションのメモ - その手の平は尻もつかめるさ
一般的な Web Application Server *1 を Java8 で動かすにあたって，最近有効にしている起動オプションについてメモ． 何か間違っていたり，あるいは「こっちの方が良い」みたいなのがあれば教えて下さい． -server server mode で起動させる (指定しないと client mode になる可能性がある，マシンスペックによってスイッチする？)． -Djava.net.preferIPv4Stack=true If IPv6 is available on the operating system the underlying native socket will be an IPv6 socket. This allows Java(tm) applications to connect too, and accept connections from,
快適な連打機能を提供するためにサーバサイドが出来ること - その手の平は尻もつかめるさ
人間生きていると高確率で連打機能を提供するシステムを構築する必要が出てくることがあります． 例えばあるコンテンツについてボタンを連打することで「良いね」を表明するようなシステムです． 連打は楽しい！！ しかし実装する方としては純粋に楽しんでばかりはいられません． こうしたシステムは素朴に実装したとしてもある程度のトラフィックまでは耐えられるかもしれませんが，ある規模を超えると安定して機能提供する事は難しくなってくるかもしれません． ここでは，サーバサイドの話題を中心として，快適な連打機能を提供するシステムをどうすれば提供できるかを考えていきます (あくまで一例です)． 想定としては， あるコンテンツについてボタンが付いていて，そのボタンは連打が出来る あるコンテンツについてボタンが何回押されたかを取得できる というシステムを仮定します． なんとなく結論が分かる雑な図 本題 サーバを分離する
mysql Connector/J の設定で効きそうなやつ - その手の平は尻もつかめるさ
mysql Connector/J を使う時に色々効きそう (あるいは効かなそう) な設定項目を調べたのでまとめておくこととします．なお，対象としている mysql のバージョンは5.6 (以降)，Connector/J のバージョンは5.1.34 (以降) です． Connector/J は設定できる項目が多くて迷ってしまうんですが，道標となる資料も幾つかあるのでそれについてもまとめておきます． 何か追記すべき事項があったら適宜追加してゆきたいと思っています．「これも入れたほうが良いのでは無いか」というようなご指摘ありましたらご一報ください． 設定項目 characterEncoding おなじみの文字コード．要設定． ちなみに以下の様なテクがある． Driver doesn't support utf8mb4 for servers 5.5.2 and newer. The drive
HikariCP で kamipo TRADITIONAL を有効にする - その手の平は尻もつかめるさ
さて2015年も暮れになってきましたので，各位に於かれましては常識の如く kamipo TRADITIONAL を有効にしていることと存じます． kamipo TRADITIONAL とはなんぞや，という方は以下のエントリが参考になりますからご一読下さい． さて Java で kamipo TRADITIONAL を有効にするテクについては 上記のエントリで紹介したわけですが，21世紀の我々には文明があるので connection pooling というものを使う (あるいは使えと言われる) ケースが多くなっております． ということで HikariCP を使うわけですが，この時に kamipo TRADITIONAL をどう設定するのかという話題があります．connection を borrow する度に sql mode を set するというのも渋いので，以下のようにしてやるとよろしい
HikariCP のステータスを JMX 経由で取得する - その手の平は尻もつかめるさ
HikariCP を使っていると，connection の状態をモニタリングしておきたくなると思います．例えば active な connection と idle 中の connection の比率を見たかったり，あるいは connection がリーク (アプリケーションが connection を borrow するだけして返却してない状態) していないかをモニタリングしたい，みたいなケースが挙げられるでしょう． こうしたものはモニタリングしたくなるのが心情というものですし，モニタリングすべきだとも思っています． 開発中の環境だと HikariCP のデバッグログを出すことでそこから connection の情報を取得することが出来ますが，本番の環境だとそんなのは出さないし (HikariCP のデバッグログは結構量が多い) ，出したとしてもいちいちログを見てやっていくのはダルいので
Jesque を頑健に使うために RobustWorkerPool というのを書いた - その手の平は尻もつかめるさ
8/16 (日) に京都でハッカソンが催されるとの事だったので遊びに行って，表題のものを作ってきました (実際には大部分は予め作っていた)． Jesque は Resque の Java 実装版で，今やっているやつではこれを使った JobQueue - Worker なシステムの実装を進めています． しかし Jesque Core の Worker Pooling の実装は調べてみると微妙な感じで，具体的にどう微妙かと言うと「Worker を Pooling する (つまり Worker を任意個生成する)」というところまでは面倒を見てくれるのですが，その Worker 群に対して死活監視等のマネジメントの一切をしないという問題があり，これは「不慮の事故で Worker が死んでしまった時 (Worker が poll している時に例外が上げられた時とか) にその Worker を生き返ら
go-setlock - Go port of setlock - その手の平は尻もつかめるさ
[2015/08/10 12:47 追記]なんか一部のOS Xで動かないので調査中です…… [2015/08/11 10:15 追記]v1.1.0で直っています setlock は daemontools に同梱されているコマンドラインツールで，非常に便利かつ強力なツールであることが知られています．この件については以下の記事などが参考になります． Kazuho@Cybozu Labs: setlock を使って cron をぶんまわす方法 Linux - setlockを使って簡単に多重起動防止機能を実装する - Qiita そしてこの度，その setlock を golang で移植した go-setlock というものをこさえました． go-setlock は setlock と同等の機能を持っており，かつ以下の様なメリットが挙げられます． daemontools から独立しているので
plenv で stableperl を利用するの術 & stableperl の話
[追記] (旧タイトル) Perl::Build (plenv) で stableperl が利用できるようになりました & stableperl の話 色々あって方法が変わったので内容を修正します Perl::Build (plenv) で stableperl が利用できるようになりました & stableperl の話 Perl::Build 及び plenv で stableperl を取り扱うことが可能になりました． Perl::Build 1.11 以降で stableperl 対応が有効になっています． Perl::Build 側に Perl::Build->install_from_stableperl() というメソッドが追加されているので， それを利用すると stableperl の tar玉をダウンロードして展開してビルドしてインストール，という事ができます． また，
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
