Elastic Stack を採用する事にした

目的は自社製品の統計とログの解析がしたい。自社製品がパッケージ製品ということもあって、サポート時にログを貰う事が多い。

最近では自社製品のアップデートの際にログを送ってもらう仕組みを用意した事もあり、お客様のログが集まりつつある。パッケージ製品は実際の運用で得られるログは本当に価値がある。これらのログを気軽に解析したいと考えてる。

また、自社で運用しているテストサーバやデモサーバも溜め込んで解析したかった。特にロードテストやロングランテストを自社でやる場合にデータを溜め込み解析をしたいと考えていた。

そこで、知り合いがいることもあり Elastic Stack をいろいろ調べて見ることにした。

結論

結論は先に書く派なので。

一社の製品でまとまっていて、とても良い。自社の解析基盤に採用する事にした。

運用をお金で解決できるのというのがまず良い。そして何より Kibana による可視化。そして Beats を自作することで好きな情報を気軽に放り込める。ログの解析部分は Logstash が活躍してくれそうだが、まだ調査できていない。

Elasticsearch

Docker でさくっと動いた、素晴らしい。本番は Elastic Cloud を検討している。Vultr で上げてみてもいいかなとは思っているが、要検討。

Elasticsearch 自体はあまりいじることはなさそうで基本的には Kibana で触ることになりそうというイメージを持ってる。実際 Docker で上げてみて試してみたときも Elasticsearch 自体になにかすることはなかった。

Kibana

データを溜め込んだら基本的にあとは見るだけ。ということで Kibana がある。クエリーを書いてさくっといけるっぽい。

まだ全然使いこないしていないが、とりあえずさくっと動いて凄い。

Beats

実は Elastic Stack を見て、とても気に入ったのがこの Elastic Beats だ。

Elastic Beats はサーバにインストールして統計情報を Elasticsearch に送りつける仕組み。公式で用意されている metricbeat と packetbeat の2つが自分の要件にマッチしてた。

  • metricbeat はサーバの CPU 使用率やメモリなどの情報を送る仕組み
  • packetbeat はサーバのネットワーク情報を送る仕組み

自社製品用の beat を自作する必要はありそうで Go で作る必要があるが、基本的には HTTP API を叩いて JSON を取得して Elasticsearch に送るだけなので簡単にできそうだ。

metricbeat と packetbeat を macOS で動かしてみたところ、とても簡単に動かせた。

Logstash

ログ解析に使いそうだなと思ってみているが、まだログ解析には手を出せてない。

ログ自体は JSON なこともあり、相性は良いと思っている。

Written by

Erlang/OTP / 時雨堂 / WebRTC / E2EE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store