NginxでWebサーバ間をトレースするrequest_id - Qiita
$request_id Nginx 1.11.0 以降に限りますが、リクエスト毎に発番されるIDの変数として $request_id が追加されたようです。 http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_id この変数を利用することにより、Nginxコアだけでサービス間のトレースを簡単に行うことが可能になります。 シンプルな例 以下のように、$request_idをログに含めるだけでリクエスト毎のIDを記録できます。 http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "
Nginx balancer_by_luaの話とupstream名前解決の話 - Qiita
balancer_by_lua_xxxxx いつの間にやら1 lua-nginx-module に balancer_by_lua_xxx という新しいディレクティブが増えていました。 以下ドキュメントより抜粋。 http { upstream backend { server 0.0.0.1; # just an invalid address as a place holder balancer_by_lua_block { local balancer = require "ngx.balancer" local host = "127.0.0.2" local port = 8080 local ok, err = balancer.set_current_peer(host, port) if not ok then ngx.log(ngx.ERR, "failed to set
Consulがたまに暴れている件について - Qiita
現象について 日に１、２回ほどこんなログが出力される。 どこか（不確定）のノードが一時的にFailし、すぐにJoinし直す。 現象としては 以前 に書いたのと似てはいるが、頻度が低い。たまに起こる程度。 2015/11/30 06:09:25 [INFO] memberlist: Marking hogenode as failed, suspect timeout reached 2015/11/30 06:09:25 [INFO] serf: EventMemberFailed: hogenode xxx.xxx.xxx.xxx 2015/11/30 06:09:25 [INFO] consul: member 'hogenode' failed, marking health critical 2015/11/30 06:09:27 [INFO] serf: EventMemberJ
consul-templateのイベント発火トリガーについて調査した - Qiita
ざっくり説明するとconsul-templateとは consulの様々なイベントを検知して 「テンプレート更新」 ＞ 「任意のコマンド実行」 してくれるツールです。 今回実現したかったのは consul-kvsの変更をトリガーにしてほげほげする ことです。 最初はconsul-templateがどういう条件でイベント発火するのかよくわからなかったのですが、 ドキュメントをよく見たらその辺りの仕様が記載されていたのでメモしておきます。 どういう条件でwatchしているのか？ 何の事はない話で、基本的には 読み込むテンプレート内で利用している値が変更されたかどうか を見ているようです。 素晴らしいですね。（※一部例外あり） 例: kvsのキーの値を監視する場合 以下のようなテンプレートで key を参照するだけでよいです。
Chef-soloからItamaeに完全移行した話 - Qiita
※2016/04/24 追記 昨年末にItamae meetupで話した時のスライドリンクを追記しました。 Databag > itamae-secret の話やConsul連携の話が追加されています。 http://www.slideshare.net/tsuyoshitorii5/itamae-meetup-vol1public 現在自分が運用管理しているChef-soloプロビジョニングの仕組み 1 を Itamaeに移行した時のお話をしようと思います。 管理規模としては大規模ではなく、小〜中規模的なところかと思います。 （ロールによってレシピ切り分けたり、環境毎にレシピ用意したりなど…） 最初に: Itamaeについて https://github.com/itamae-kitchen/itamae 軽量なChef と考えればよいでしょう。 Chefの複雑さを取り除き、必要十分な部
Docker1.3版 boot2docker+fig入門 - Qiita
Docker1.3がリリースされましたね！ それに合わせて、周辺ツールがアップデートされていて とても便利になったと感じたので紹介してみます。 Docker/boot2docker Docker 1.3: signed images, process injection, security options, Mac shared directories boot2dockerでのVolume問題が解決しそう Virtual Box Guest Additionsをサポートしたことにより、 MacOS上のファイルとコンテナ内の同期が簡単になりました。 またDockerがexecコマンドをサポートしたことにより sshインストールなしでコンテナ内でコマンド実行することが出来ます。 でかい。 figは複数のDockerコンテナをお手軽に管理するためのツールです。 シンプルなyamlファイルを用意
NginxでリバースプロキシをKeepAliveしたときの性能検証 - Qiita
Nginx + Luaを用いた、ハイパフォーマンスで動的なプロキシサーバを考察中です。 そのための施策の一つとして 上流サーバへのアクセスをKeepAliveする という方法がありますが その際、プロキシサーバにどの程度性能に変化があるのかを調査してみました。 リバースプロキシのkeepalive設定 前提条件として Nginx > 1.1.4 が必要。 upstreamに keepalive というattributeがあるのでそれを設定します。 それと同時に、プロキシヘッダーにHTTP/1.1設定などを行いましょう。 ちなみにproxy_passだけだとkeepaliveできないようです。upstream必須。 あと、もちろんバックエンドサーバ側もkeepalive設定しておきます。 upstream http_backend { server oreore.micro.service;
T2インスタンス調査結果 - Qiita
先日、新インスタンスタイプとなるT2インスタンスがリリースされましたね！ 【AWS発表】バースト可能な性能を持つ新しい低コストEC2インスタンス いままで特にお世話になっていた t1.micro/m1.small の 後継というべきインスタンスでしょうか。 しかし実際に使ってみると、T2インスタンスならではの特徴がいくつかあるようです。 これから一番お世話になりそうなT2インスタンスですし もう少し詳細に調査し、その結果をまとめてみました。 ベースライン／クレジット／バーストという概念 CPUの性能に関する概念です。 t1.microにもバーストという機能はありましたが T2では実装が大きく異なるようです。 要約すると
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
