今、リアルタイムでは休暇中でフランクフルト経由ベルリン行きの飛行機の中にいる。暇すぎる。うちの会社、ってかトレタの監視系の変遷について書く。でも絵を描く気力はないので文字のみ。



今の状況です

ルフトハンザは日本線は軽食の時間に ONIGIRI が出てくるので結構好きな航空会社です。休暇中なのにラップトップ持ってくのはプロ社畜の証。まあ今会社で裏側見てるのが俺しかいないので、エエ…。しかし世の中ホント便利に便利になってる。空の上でもインターネットができる。言い方を変えると空の上でもアラートが届くっていう…。飛行機の中は暇すぎるけどさすがに仕事はしたくないね。というかこの旅行中は仕事を忘れたい。

2015-10-17 10.02.38

2014/10以前

俺が入社する前。

  • コア機能:Engineyard(OS: gentoo)。
    • プロセス異常監視、閾値監視など:monit
    • エラートラッキング、レスポンスタイム、SQL:NewRelic
サーバサイドの機能をEngineyard上に構築していて、s3やRoute53などAWSの機能も使っている構成。監視の状況は入社したらこうなっていた。初期のメンバーを責めるつもりはないが、monitでプロセス監視やらをしてはいたが、通知の設定が入ってなかったw 検知はするけど誰も気がつかないw monitはEngineyard標準の監視で、Engineyardを使うとmonitが最初から入っている。さすがにいろいろカジュアルすぎたのでまずは監視の強化から重点的に着手したのを覚えている。

2014/11〜2015/7あたり

Engineyardだけでは要件がまかなえなくなってきたこともあり、EC2やHerokuなども使い始めてサブシステムが増える。GCEも検証を兼ねて触ってみたかったので、ソーリーサーバなど平常時にユーザ影響がないものについてはGCE上に構築している。GCEにもMySQLがいるのは大人の事情。sshトンネルを掘ってEngineyard内のMySQLとレプリケーションを張っている。このMySQLはオンライン処理はさばいていないが、定期的にgoogle cloud storageにmysqldump.gzをとっている。ログはfluentd経由でBigQueryとS3に転送しており、定期的にBigQueryに転送したログを舐めて、一定時間に500番台のエラーが一定数を超えていたらslackにアラートを投げるような監視ツールも自作している。あともう一個、@aws_shのツイートを監視して、特定の文言が現れたらslackに投げるというソーシャル監視もやっている。
  • コア機能:Engineyard(OS: gentoo)。
    • メトリクス:munin, growthforecast
    • プロセス異常監視、閾値監視など:monit
    • 通知: メール、slack、電話(PagerDuty)
    • エラートラッキング、レスポンスタイム、SQL:NewRelic
    • エンドポイント監視:Pingdom
  • コア機能以外のサブシステム: AWS(OS: AmazonLinux)
    • メトリクス:datadog
    • プロセス異常監視、閾値監視など:sensu
    • 通知: slack、電話(PagerDuty)
    • エンドポイント監視:Pingdom
  • ソーリーサーバ、とある事情で作ったMySQLのスレーブなど:GCE(OS: ubuntu)
    • メトリクス:datadog
    • プロセス異常監視、閾値監視など:sensu、monit(sshトンネルを監視していて、sshが切れたら張りなおす)
    • 通知:slack、電話(PagerDuty)
    • エンドポイント監視:Pingdom
  • 自作のログ監視、ソーシャル監視ツール
監視についてはごちゃごちゃしているが、datadogに統合するつもりで考えていた。しかしEngineyardにdatadogのエージェントが入らなかったw

2015/8あたり〜

全体の構成的にはサブシステムは増えていない。監視周りはmackrelはエージェントがgolang製ということもあってプラットフォームを選ばないので、mackerelを中心にごちゃごちゃしていた監視の統合をした。
  • コア機能:Engineyard(OS: gentoo)。
    • メトリクス:mackerel
    • プロセス異常監視、閾値監視など: mackerel、monit
      (monitにはunicornのメモリ量を見て子プロセスを再起動させたり、その他プロセスの自動再起動などを担当させている)
    • 通知:slack、電話(PagerDuty)
    • エラートラッキング、レスポンスタイム、SQL:NewRelic
    • エンドポイント監視:Pingdom
  • コア機能以外のサブシステム: AWS(OS: AmazonLinux)
    • メトリクス:mackerel
    • プロセス異常監視、閾値監視など: mackerel
    • 通知:slack, 電話(PagerDuty)
    • エンドポイント監視:Pingdom
  • ソーリーサーバ、とある事情で作ったMySQLのスレーブなど:GCE(OS: ubuntu)
    • メトリクス:mackerel
    • プロセス監視、閾値監視など: mackerel、monit(sshトンネルを監視していて、sshが切れたら張りなおす)
    • 通知:slack、電話(PagerDuty)
    • エンドポイント監視:Pingdom
  • 自作のログ監視、ソーシャル監視ツール
結果、今はこうなっている。監視種別をまとめると以下の通り。メトリクスや閾値などの監視にmackerel、エンドポイント監視にPingdom、コア機能のアプリケーション寄りの監視にNewRelic、一部のプロセス自動再起動はmonitの機能におまかせ、という構成になった。通知はメールを廃止してslack(warning, critical)と電話(critical)という分け方。
  • メトリクス: mackerel
  • プロセス異常監視、閾値監視など: mackerel, monit
  • コア機能のエラートラッキング、ヤバいSQLの監視: NewRelic
  • 通知: slack、電話(PagerDuty)
  • エンドポイント監視: Pingdom
mackerelがいいかんじなので良かった。この手のエージェント型の監視ツールはサーバ管理ツールとしての側面もあるので重宝している。そしてmackerelの導入によってgrowthforecast、sensu、muninには引退してもらった。まあでも個人的にはメトリクスは正直muninのビューが一番見やすいと思う。munin最強。rrdtools最高。全サーバを俯瞰して見れるしね。台数多すぎだとアレだったりしますが。

Pingdomも相変わらず重宝している。DNSで名前解決できるかどうかのチェックであったり、SESやSendgridやらのメールサービスの監視などもできるから。関連する外部システムのエンドポイント監視もPingdomで行っている。

フライト時間あと3時間…。

おわり

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Set your Twitter account name in your settings to use the TwitterBar Section.