このエントリは、Datadog Advent Calendar 2016 の 10 日目のエントリです。 2016年を振り返ってみると、Datadog をフル AWS の本番システムに導入して本格稼働している年でした。 実はまだまだすべての設定は完了していないのですが、2016年の自分と Datadog について、どのような関わりがあったのか、このエントリで振り返ってみたいと思います。 2016年2月 フル AWS のシステム向けのモニタリングツールで Datadog を導入することが正式に決まりました。 そこで、チーム向けに Datadog について簡単に紹介してしほしいと相談されたので、まずは Datadog 入門編のスライドで紹介しました。 はじめての datadog from Naoya Nakazawa このスライドでは、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 をすることができませんでした。 いちお、スライドを公開しておきます。 DATADOG TIPS […]![]()
↧
