Browse Month: December 2016

2016年の自分と Datadog

このエントリは、Datadog Advent Calendar 2016 の 10 日目のエントリです。

2016年を振り返ってみると、Datadog をフル AWS の本番システムに導入して本格稼働している年でした。
実はまだまだすべての設定は完了していないのですが、2016年の自分と Datadog について、どのような関わりがあったのか、このエントリで振り返ってみたいと思います。

2016年2月
フル AWS のシステム向けのモニタリングツールで Datadog を導入することが正式に決まりました。
そこで、チーム向けに Datadog について簡単に紹介してしほしいと相談されたので、まずは Datadog 入門編のスライドで紹介しました。

このスライドでは、Datadog の一通りの機能を紹介しています。

2016年8月
こうして、Datadog Agent を導入していたのですが、いくつか使いにくい部分があったのでDatadog Agent にいくつかプルリクエストを送ってみました。Python は、あまり本格的には書いたことがなかったのですが、やりたいことベースだったので、とても楽しく変更することができました。

今日時点で3件ほど、DataDog Agent に無事マージされました。なかなか時間がかかったものがありましたが、OSS へ貢献するという貴重な体験ができました。

それでは、プルリクエストの内容を振り返ってみたいと思います。

バージョン 5.9.0 では、HTTP/HTTPS URL を監視するための http_check である URL がリダイレクトコードを返すかどうか確認したいことがあったので、”allow_redirects” パラメータを追加しました。このパラメータを false に設定すると、実際にリダイレクトはしないため、その時点の HTTP ステータスコードを監視することができます。これで、302 などを監視することができるようになりました。

バージョン 5.10 では、SSH 接続を監視するための ssh_check に SSH キータイプ ECDSA を追加しました。最近では、Ed25519 というキータイプが主流になっているので、このキータイプも対応したいことですが、内部で使っている paramiko がどうも対応していないらしく、Issue にあげて

もう一つ、プロセスを監視する process に PID ファイルを指定することができるようになりました。今までの process はプロセス名の文字列のみでしか指定できなかったので、PID ファイルを指定することで、さらに便利にプロセスの監視ができるようになりました。

あと一点 MySQL の監視でクエリー数が 20 に制限されている理由を聞いてみたのですが、無視されているため、とりあえずこの制限を外したもので本番システムは監視していますね。

まだまだ、微妙に改善したいところがあるので、来年以降も順次プルリクエストを投げていきたいと思います。

もう一つ Ruby のクライアントのdogapi-rb ですが、なんとなく CI が警告をはかないように修正のプルリクエストを投げました。最初はまったく返信がなかったのですが、プルリクエストを修正して再度提出したところすぐにマージしてくれました。

2016年11月
#dd_sushi 〜 Datadog and Sushi の秋が開催されたので参加してきました。Sushi はわずか 5 分ほど?で完売してしまったらしいのですが、勝手に飛び込み LT をしようと思って資料を準備したのですが、けっこうお堅い雰囲気で LT をすることができませんでした。

いちお、スライドを公開しておきます。

こんな感じで、2016年の自分と Datadog との関わりを振り返ってみました。
早く、Datadog APM も試してみたいですし、その他の新機能も続々とリリースされる様子なので、もっと手軽に楽に夜も安眠できるように Datadog を使って効率的にシステムのモニタリングを行っていきたいと思います。

Codenize Meetup で LT してきました

Codenize Meetup で LT 枠が急遽空いたので LT をしてきました。

少し前に作って、今でも業務でバリバリ使っている Kumogata のラッパーツール kumogata-template について紹介しました。

個人的には、業務で AWS だけを使うなら、Terraform よりも CloudFormation だなと思います。少し前までは、最新のリソースに追いついていないことがあったのですが、今ではあまりそんなことはない印象です。

Kumogata は、CloudFormation の JSON 変換ツールなので、実際には CloudFormation で簡潔しているので、最悪の場合 JSON を直接変更できるし、change set という機能で dry-run 的なこともできます。

今回の Meetup でも、Terraform で消耗しているお話がありましたが、CloudFormation ではあまり消耗することもないです。商用サポートもあるところも、業務で使うには、重要なところだと思います。

とても素晴らしい実りのある Meetup でしたので、第2回に期待です。

あと、個人的にもできる限り Codenize には貢献していきたいです。

久しぶりに LT というアウトプットをしましたが、やっぱりアウトプットすることで学びがあるので、今後も定期的にアウトプットをしていきたいと思います。