ELKスタックの後継なるか、influxdbのTICKスタックをさわってみた
結論から言ってしまうと、ならない。
というかそもそもELKスタックか目指してるものとは別物でしょ。どちらかと言えば、re:dashとELKスタックを比べるべき。なのでここからはTICKスタック単体の話です。
まだ半日ぐらいしかいじってないので、感想は後々変わるかも
TICKスタックとは
時系列データベースのinfluxdbでお馴染みの、influxが出しているログを収集して活用するための一連の製品群とその構成。
Telegraf、InfluxDB、Chronograf、Kapacitorからなり、それぞれ以下の役割を担っている。
- Telegraf
- InfruxDBをはじめとする時系列DBへの挿入に特化したコレクタ。InfluxDBだけでなく、PrometheusとかGraphiteとか、もろもろのものにつっこめるようになってるらしい。CPU使用率等のシステムリソースを収集できるように初期設定されていて、設定を有効化するだけで、InfluxDBにつっこめる。
- InfluxDB
- 時系列DB。RESTでデータを簡単につっこめて、SQLライクな構文でデータを取得できる。
- Chronograf
- 収集したデータを可視化するためのWebダッシュボードを提供する。以前は、InfluxDBのデータの可視化はGrafanaが担当してたと思うけど、自前でもいつのまにか作ってたのね。見た目はGrafanaにかなり似ていて、折れ線グラフしか表示できないところもかわらない。Kibanaみたいに柔軟な表示ができればもっと嬉しいのだけども。
- Kapacitor
- 収集したデータに関して、監視し、トリガーでアラートを出せるらしい。TICKスタックさわってみたといいつつ、これは特に触ってない。
目的
もともとVPS一台運用だったので、たいした監視は必要なかったんだけど、リソースに余裕があるかは把握しておきたかった。ただ、一時期ELKスタック(正確には、fluentdを使ってたのでEFKスタック)も使ってたけど、どうしてもElasticsearchがメモリをバカ食いするせいで、1台運用には荷が重すぎて、muninを使ってた。ただ、muninは今は表示できても、複雑な計算は苦手なので、もうちょっとパワーのあるやつが欲しかった。
最近だと、re:dashあたりがはやってて、「re:dashは軽量なので、AWSのmicroインスタンスでもいけるよ」、と聞いていたので期待してたのだけど、さすがに他の機能ももたせたサーバで動かすのには苦しい(1Gぐらいはメモリをどうしても食ってしまう。VPSだとメモリがいちばんコストに響いてくるので、1Gはきつい)ということもあり、もうちょっとシャレオツかつ軽量のもので、リソースを可視化できるようにしたかった。
インストール
https://portal.influxdata.com/downloads
を参照のこと。各OSごとにインストール方法が記載されてる。
自分の環境はCentOSだったので、たとえば
# yum install https://dl.influxdata.com/telegraf/releases/telegraf-1.2.1.x86_64.rpm # service telegraf start
などとするだけだった。
CentOSの場合は、/etc/telegraf/telegraf.confにTelegrafの設定ファイルができるので、必要に応じてコメントを解除
# [[inputs.nginx]] ← コメント解除でnginx情報の収集有効化 # ## An array of Nginx stub_status URI to gather stats. # urls = ["http://localhost/status"] ← nginxのステータスページのURLに変更
とするだけで簡単に収集することができた。また、CPU使用率のような一般的なものは自動で収集してくれる。
そして、収集後、Chronografにアクセスすると、こんな感じでおしゃれにグラフ表示してくれる。
InfluxDBなんで、期間内の最大値とか平均値とか、微分とかいろいろ出してくれるはずだけど、そこまではまだ手を出していない。
TICKスタックは、golangで書かれていて、プラグインも作りやすそうなんで、せっかくだからなんか作ってみたい。
さわってみて
クエリをWebで簡単に構築できて、自分のダッシュボードを作れるというところがよい。なにより軽量(現時点では、300Mバイトぐらいしか消費していない)のがよい。本当はKibanaのようにGeoIPを使って、地図で表現できたりするともっと良いのだけども。。
これまで、InfluxDBは数値データを格納するためのデータベースと誤解してたけど、どうやらテキストデータも入れれて検索もできるらしいので、そちらも今後収集してみたい。(以前使ったときは0.7.0ぐらいだったので、いろいろと進化しててびっくり。Webインタフェースも最近なくなってしまったみたいだし)
keyfreq.elでEmacsのキーバインドを効率良く使えているか振り返る
はじめに
人の.emacs.elを読んでたり、パッケージを漁ってたりすると、これいいじゃんって設定やイケてるキーバインドがいろいろと出てきます。そうするとやはりマネするというか自分のにも取り込みたくなるのが人情というものですが、はたして設定したっきりになってないでしょうか。
keyfreqは、emacsのキーバインドの利用状況を記録して振り返ることができます。
(といいつつ、実際のところはコマンドの実行状況ですが)
MELPAに登録されているので、
M-x package-install keyfreq
するだけで簡単に導入可能
使いかた
上記レポジトリに書いてある通りですが、
(require 'keyfreq) (keyfreq-mode 1) (keyfreq-autosave-mode 1)
するだけ。
で、普通に使っていて、気になったときに
M-x keyfreq-show
すると、以下の感じで使ったキーバインドの統計情報(というか集計情報に近いかも)が表示されます。
自分の場合、next-line使いすぎなので、C-vとか、ちゃんと使おうよ、って思える結果に。
あと、avyせっかく導入してみたのに、全く使ってないことがわかってしまった。
キーバインドを設定したいけど、かぶってて、、、という場合なんかにも、「でも実際のところ使ってないじゃん」というのがわかる、あるいは毎度毎度M-xしてるのであれば、キーバインド設定してもよかない？というのがわかるので、非常におもしろいパッケージだと思います。
問題点
BUGとしてissueにも登録されてますが、複数のemacsを起動したときにファイルロックが競合してうまく動かない(記録できないだけで実害は無いがロックかかってるよってメッセージがうっとうしい)のが難点。emacsclientで複数の場合にどうなのかは不明。
Jenkinsでgo言語のプロジェクトをCIする方法を調査した
はじめに
Golangをちまちまプライベートで触っていて、バックエンドサーバを試しにgolangで書いてみてるんだけど、Jenkinsのpipelineでgoを扱う方法が、調査しても断片的にしか出てこなかったので、本腰を入れて調査してみた。
pipelineでなければ、もっと簡単そうだけど、BlueOceanも1.0リリースされたしね。
- 作者: 松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太,稲葉貴洋
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/09
- メディア: 大型本
- この商品を含むブログ (3件) を見る
対象
ソースコードはこちら
単なる足し算を実装しただけの簡易なもの。
しかも明らかにミスってる(もちろんわざと)
func Sum(a int, b int) int { return a + a }
これをJenkinsでTestしてみる。
事前準備
プラグインの導入、初期設定
Go pluginを導入しておく
Go Plugin - Jenkins - Jenkins Wiki
次にプラグインの設定をする。
日本語メニューの場合、「Jenkinsの設定」→「Global Tool Configuration」にGoの設定があるはず。(http://JenkinsのURL/configureTools/ にアクセスしてもよい)
インストール済Goというのに適当な名前(ここではGo1.8とした)をつけて、必要なGoのバージョンを設定しておく。これは必須ではないが、これをやっておくと、Jenkins専用のGoを設定しておくことができる。CentOSのepelリポジトリが1.6までしかなくて、depが使えなかったので、このやりかたで導入した。
Jenkinsfileを書く
pipelineは、Jenkins上で書くこともできるけど、ファイルとして切り出して管理することもできる。バージョン管理もできるし、そちらの方が推されてるはず。
というわけで、Jenkinsfileをごりごり書いた。
書いてみたのがこんな
node {
def root = tool name: 'Go1.8', type: 'go'
ws("${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/src/github.com/grugrut/golang-ci-jenkins-pipeline") {
withEnv(["GOROOT=${root}", "GOPATH=${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/", "PATH+GO=${root}/bin"]) {
env.PATH="${GOPATH}/bin:$PATH"
stage 'Checkout'
git url: 'https://github.com/grugrut/golang-ci-jenkins-pipeline.git'
stage 'preTest'
sh 'go version'
sh 'go get -u github.com/golang/dep/...'
sh 'dep init'
stage 'Test'
sh 'go vet'
sh 'go test -cover'
stage 'Build'
sh 'go build .'
stage 'Deploy'
// Do nothing.
}
}
}
重要(というか自分が詰まった)なのが前半部分。
def root = tool name: 'Go1.8', type: 'go'
必要なバージョンのGoを利用するための設定がこちら。
nameのところに先程のプラグイン設定で名付けたものを入れる。
はじめに利用するときに、goが自動でダウンロードされるので、始めの一回はそこそこ時間がかかるけど、次からはすぐに使える。ちなみに、このGoのインストール先は、${JENKINS_HOME}/tools/org.jenkinsci.plugins.golang.GolangInstallation/Go1.8/
となっているようだ(最後のGo1.8は自分がつけた名前)。
ws("${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/src/github.com/grugrut/golang-ci-jenkins-pipeline") { withEnv(["GOROOT=${root}", "GOPATH=${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/", "PATH+GO=${root}/bin"]) { env.PATH="${GOPATH}/bin:$PATH"
Goに入ってはGoに従えの格言の通り、Golangらしいファイル配置になるように設定している。
1行目のwsは、カレントディレクトリを設定している。普通は${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/が、カレントディレクトリになるところを、src配下に配置するようにしている。詳細は以下のページで。
Goコードの書き方 - The Go Programming Language
次に2行目は、GOROOTとGOPATHの二つの環境変数を設定している。PATH+GOで、goのバイナリの箇所を設定しているらしいけど、詳しいドキュメントが見付からず、ここは見様見真似でやってる。
GOPATH配下のbinもPATHに含めたかったのだけど、withEnvでやろうとすると、(おそらく)Jenkinsとしての変数展開と、shellの変数展開が競合してうまくいかなかったので、3行目に別途いれてる。
あとは、ソースコードの通り、チェックアウトして、depをインストールした上で、依存関係を解決、その後go vet, go testと来て、とおればbuildしておしまい。(とはいえtestでこけるのでbuildまで行かないのだけど)
結果
こんな感じで、testにこけてることが確認できた。
なんとなく動いてる気はするけど、もっと効率の良いやりかたがありそうなので、ご存知の方いたら教えてください！！
書籍の情報を検索して挿入するためのHelmインタフェースを作ってみた
やりたかったこと
org-modeで本の記録を取るのに、いちいち著者情報を手入力するのがきつすぎるので、検索していいかんじにバッファに挿入させたかった。
で、それを実現するのにHelmインタフェースで作るのが、それっぽいかんじで良さそうだったので、そうした。
HelmインタフェースもAnythingインタフェースも作ったことなかったので、やってみたかったというのもある
できたもの
使いかた
requireして、M-x helm-booksするといつものHelmインタフェースが表示される。
そして入力すると入力した文言に対してgoogle books apiに対してクエリが発行されて結果がリストとして表示される。
Actionとしては、挿入する文章を変数"helm-books-custom-format"で設定することができる。
org-modeとの統合
org-captureでは、テンプレートに
(setq org-capture-templates '(("b" "book memo" entry (file (concat org-directory "book.org")) "* %(helm-books)" ))))
のように、%(sexp)とすることで、S式を埋め込むことができる。
これを利用することで、このテンプレートを呼び出すと、自動でhelm-booksが呼ばれ、本を検索し、必要な情報をプロパティとして設定したメモを簡単に取ることができる。
これはすごい
今後
- 作者: るびきち
- 出版社/メーカー: 技術評論社
- 発売日: 2011/11/26
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 220回
- この商品を含むブログを見る
本の情報を取得するためのHelm拡張を作ってみた(途中)
続きを書いた
grugrut.hatenablog.jp
init.el読書会で、org-modeのメモを読書記録にするための、org-captureのテンプレートがあって、やりたかったのだけど、いちいち本の情報をプロパティに手打ちするのは面倒だと思った。
例
* ゼロから作るDeep Learning :PROPERTIES: :Author: 斎藤 康毅 :Year: 2016 :Publisher: オライリー :END:
なんか皆やってそうなので、こういう情報を簡単に挿入できるような良いパッケージが無いか探してみたのだけど、みつけられなかったので、Helm拡張として作ってみることにした。
作るにあたっては、
helm拡張を書く - Qiita
Developing · emacs-helm/helm Wiki · GitHub
を超参考にした。
Helm拡張書いてみての感想
まだsourceの定義の一部しか終わってないけど、はじめとっつきにくい印象(公式documentもそこまで充実してないし)だったけど、ちょっとずつ書いてみたら、意外とあっさり書けた。
actionの定義はもっと簡単そうな気がするので、この調子でちゃんと完成させたい。
- 作者: るびきち
- 出版社/メーカー: 技術評論社
- 発売日: 2011/11/26
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 220回
- この商品を含むブログを見る
気象庁の時系列データをRで遊んでみた
はじめに
最近時系列データの解析に興味があって、いろいろと調べてたけれども、実データでないといまいちピンとこないので、いろいろとRの使いかたを調べつつ遊んでみた。emacsでもessをセッティングしているからいくらでもできるのだけど、せっかくなのでRStudioを使ってみた。
現場ですぐ使える時系列データ分析 ~データサイエンティストのための基礎知識~
- 作者: 横内大介,青木義充
- 出版社/メーカー: 技術評論社
- 発売日: 2014/02/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (6件) を見る
元データ
気象庁が過去の天気データを公開してくれているので、こちらを利用した。
いろいろとデータの種別やら期間やらあるけど、今回は1877年から2006年までの東京の月平均気温を使っている。
とりあえず読み込む
> tokyo <- read.csv("data.csv") > View(tokyo) > tokyo 年月 平均気温 1 1877/1 3.2 2 1877/2 3.6 3 1877/3 6.2 4 1877/4 13.6 5 1877/5 16.5 6 1877/6 22.0 7 1877/7 26.5 8 1877/8 25.9 9 1877/9 21.3 10 1877/10 15.9 11 1877/11 9.6 12 1877/12 5.8 13 1878/1 2.3 (後略)
本来は、csvにコメント部分や他の列もあるけど、そこは先に加工したものを取り込んだ。read.csvでそのへんはカバーできるので実は不要であるが。
とりあえずデータテーブルだと扱いづらいので、平均気温を年ごとに扱えるように分割しておく。
はじめ2次元配列に分割しようとして、なんかうまくいかないと悩んでたけど、3次元配列にしてみたらうまくいったのでよかった。
> splited_tokyo = array(tokyo$平均気温, dim=c(1,12,140)) > splited_tokyo[1, 1:12, 1:3] [,1] [,2] [,3] [1,] 3.2 2.3 3.2 [2,] 3.6 2.5 5.4 [3,] 6.2 7.2 8.0 [4,] 13.6 11.5 12.6 [5,] 16.5 18.3 18.0 [6,] 22.0 20.0 21.4 [7,] 26.5 26.0 26.1 [8,] 25.9 24.6 26.6 [9,] 21.3 22.8 21.3 [10,] 15.9 15.8 15.0 [11,] 9.6 9.7 9.7 [12,] 5.8 5.1 8.0
とりあえずグラフ化してみる
複数の時系列データをグラフ化するなら、ts.plotを使うのが簡単
> ts.plot(splited_tokyo[,,], type ="l")
140年分のデータをまとめてみると、やっぱり毎年同じように気温は変化する(1月2月が一番寒くて、8月が一番暑い)ということがわかるね。
20年ごとの相関も見てみた。
> pairs(splited_tokyo[1,1:12,c(1,21,41,61,81,101,121,140)])
細かいところをみると違うところもあるけど、ほぼ一直線上にプロットされており、かなり相関係数は1に近いといえそう(計算して出せよ、というのは正しいがやってない)
過去と比べてみる
温暖化温暖化っていうけど、本当に昔に比べて気温はあがってるのだろうか。
とりあえず時系列データということで、tsで時系列データに変換する
> ts_tokyo <- ts(data=tokyo$平均気温, start=c(1877, 1), frequency=12) > plot(ts_tokyo)
なんとなく上昇傾向にある気はするけど、よくわからない
> plot(stl(ts_tokyo, s.window="periodic"))
トレンドは確かに上昇傾向にあるけど、残差も多いのではなかろうか、これ。ただ、残差はプラスマイナス両方に散らばってるので、全体としては上昇傾向にある気がする。
ARIMAモデルによる推定もしてみた。
> library("forecast") > arima_tokyo <- auto.arima(ts_tokyo, trace=T, stepwise=F, seasonal=T) > plot(forecast(arima_tokyo, c(95), h=480)) [f:id:grugrut:20170226210851p:plain] これは、2050年には1年中16度ぐらいの過ごしやすかちょっと肌寒いぐらいの気温になる、ということであろうか。 * 別アプローチ 1877年から1976年までの平均、標準偏差に対し、1977年から2016年までの値がどれぐらいの範囲にいるかを調べてみた。 >|r| > m <- apply(splited_tokyo[1,1:12,1:100], 1, function(v){return (mean(v))})[1:12] > m [1] 3.482 4.183 7.277 12.951 17.226 20.815 24.694 26.057 [9] 22.367 16.403 10.982 5.873 > s <- apply(splited_tokyo[1,1:12,1:100], 1, function(v){return (sd(v))})[1:12] > s > ts.plot(splited_tokyo[,,101:140], type ="l") > lines(m-3*s, type = "l", col="red", lwd="3") > lines(m-2*s, type = "l", col="yellow", lwd="3") > lines(m-s, type = "l", col="green", lwd="3") > lines(m, type = "l", col="blue", lwd="3") > lines(m+s, type = "l", col="green", lwd="3") > lines(m+2*s, type = "l", col="yellow", lwd="3") > lines(m+3*s, type = "l", col="red", lwd="3")
赤が3σ、黄色が2σ、青が1σなので、気温が全体的に高くなってるように見える。
計算ミスでないことを角煮するために、1877年から1916年までの40年間で同様に確認してみると、
と、だいたいが1σ、外れ値っぽいところでもほぼ2σの範囲にはおさまってるので、データとしては問題なさそう。とはいえ最近寒くて閉口してるけどね。
まとめ
Rたーのしー！！
以下の本も買ったけど、見た目によらずかなり教科書教科書してて読みきれてない。
- 作者: 田中孝文
- 出版社/メーカー: シーエーピー出版
- 発売日: 2008/06
- メディア: 単行本
- 購入: 12人 クリック: 113回
- この商品を含むブログ (19件) を見る
zenburnテーマのregionのbackgroundが見辛かったのでテーマを少しいじった
はじめに
しばらくmisteriosoをテーマとして使ってたけど、最近はzenburnを使ってる。
理由は簡単で、Emacs Theme Gallaryで最も人気が高かったから。
https://pawelbx.github.io/emacs-theme-gallery/
落ち着いた色合いが気に入っているといえばそうなんだけど、気になるところもいくつかあり、そのひとつが色が弱々しくて視認性が悪いところ。
特に範囲選択したところ、リージョンの背景が色の違いがなさすぎてつらい。
これならまだわかる
単語レベルでmultiple-cursors使おうとすると、もうダメ
色のカスタマイズ
zenburnテーマは、zenburn-with-color-variablesマクロで各faceの設定をしてるので、init.elにこんな感じの設定をいれてみた。
(zenburn-with-color-variables (custom-theme-set-faces 'zenburn `(region ((t (:background ,zenburn-bg-2))))))
zenburn-bg-2は、いってしまえば、#000000と、完全なる黒なのだけど、これぐらい極端にやったほうがよい感じ。
くっきり表示される。
単語レベルでもこの通り。
おまけ
zenburnのissueには、「他のテーマは、regionが通常の箇所より明るい色が普通だから、もっと明るい色使おうぜ！」って提案されてるものの「そんなんしたら見辛くなるじゃん」と一蹴されてた(issueだけに)。
その通りだと思うけど、デフォルトも十分見辛いと思う。スタイリッシュさが失なわれるのは確かなので、おとなしく他のテーマに移ることも検討しよ。
