こんばんは。最近の一日の始まりは雪かきからな照井@さっぽろです。今冬は12月から雪が多く寒いので、厳冬な予感がして今からツラい気持ちです。

この記事は、Datadogアドベントカレンダーの19日目です。

「DatadogにおけるMonitoring as Code」ということで、MSPという沢山のお客様の環境を監視して支える立場上欠かせない、コード化による効率化や適切な管理のための取り組みをご紹介したいと思います。

全体的な話と流れ

実際のお申込みから監視導入までを流れに沿って取り組みをご紹介していきたいと思います。また、ここから先に書かれている内容は検討中のものも含みます。今後変わる可能性もありますのでご了承ください。

運用代行のご契約からアカウント登録まで

さっそく微妙に本題からはズレますが、まず運用代行のお申込みをいただいて始めに必要な作業として、お客様へご提供するDatadogのアカウントやサポート窓口(Zendesk)のアカウントやテナントの登録という作業が必要になります。

弊社ではこういった定型的なワークフローをQuestetraというSaaSを使って管理しており、Datadogについても洩れなくこれに乗ってきます。

また、Questetraにはワークフローの中でHTTPリクエストを投げる機能があるので、これを利用して自動化出来る部分は自動化し、定形作業を効率化していきます。

Datadogでこの部分がどのように効率化できるかはまだ見えていない部分はありますが、コード化を進めることでそういった連携はしやすくなるので、お申し込みから各種設定が投入済みの環境のお引渡まで、必要項目さえ入力すればあとは最低限の人手で最小のリードタイムでご提供できるようになれば良いなーと、今のところ妄想だけしています。

エージェントのインストール・設定

監視導入の基本であるDatadogエージェントのインストールと設定の投入については、Datadogの公式Cookbookが非常に品質が高くコードの見通しも良いので、それを利用します。

LinuxはAmazon Linuxを含む主要なディストリビューションをカバーし、Windowsにも対応しており、かなり緻密にテストが書かれている上にCIのステータスもGreenが保たれていて、Chefのヘビーユーザである私（最近はさすがに使う機会も減りましたがｗ）としては非常に好感度が高いです。

中身も極端にトリッキーなことはせず、RubyおよびChefがある程度分かれば挙動も把握できる感じなのがまた良い感じです。高度だったり良く出来てるベンダー公式のCookbookは他にもありますが、正直バランスの良さで言えばDatadogが今まで見た中で一番良いような感じがしています。

また、エージェントの更新や設定のアップデートはEC2 Systems Managerからの遠隔実行で行います。設定内容はChefで管理されているため、Systems Managerは新しい設定内容のJSONをS3等から取得し、Chef ClientをLocal modeでキックするだけです。これだけなら単純ですが、その他運用代行業務においてSystems Managerの活用するには、実行内容を定義するDocumentの管理が煩雑になりがちなので、なんらかのコード化を検討中です。これは少し本筋からもズレるので、もう少し形になった段階で別途ご紹介できればと思います。

Systems Managerについて詳しく知りたい方はこちらの弊社ブログをご参照ください。

各種インテグレーションの設定

エージェントのインストールができない、AWSのマネージドサービス群を監視する上で欠かせないAWSインテグレーションはもちろんのこと、アラートのハンドリング等を別のSaaSに連携して行うためのインテグレーションを設定します。

ですが、残念ながらこのインテグレーション設定についてはDatadogでAPIが公開されておらず、残念ながら手動でポチポチやるしかありません。この部分はインテグレーションは種類によって設定項目が千差万別なので難しい部分はあるでしょうが、APIが提供されると嬉しいなーと思うところです。

監視設定の導入

エージェントのインストールとインテグレーションの設定が終われば、あとはそれらによって収集したデータを監視して、異常時に通知をする設定を投入すれば、基本的な設定としては完了です。こちらについては、偉大なるCodenize.toolsによってBarkdogというツールでコード化がサポートされています。

また、Datadogでは、メタデータの概念があり、その単位でグルーピングや集約をして監視対象を決められ、一つの監視設定を投入すればメタデータが該当するものだけを監視対象とすることが可能であるため、ベースとなる監視設定を一つメンテナンスしておけば、様々なケースで対応が可能です。もちろん、その後は要件に応じてカスタマイズが必要な場合はありますが、初期設定の部分のメンテナンスの手間がかからないのは非常に楽です。この部分はDimensionという単位でしかデータが分別できず、かつ監視対象のDimensionの明示的な指定が必要なCloudWatchに決定的に欠けている部分であり、Datadogを使う大きな理由の一つです。

また、同ツールには既存の設定のエクスポートが出来る機能があるので、似たような案件の設定を移植することが非常に簡単になります。

ダッシュボードの提供

ダッシュボードも顧客別・プロジェクト別に提供が必要な関係上、コード化が重要になってきます。こちらについては、Codenize.toolsではありませんが、それをインスパイアして生まれたServerworks謹製OSSのDashdogを利用します。

また、こちらも既存の設定のエクスポートが出来る機能があるので、似たような案件の設定を移植することが非常に簡単になります。

Dashdogについて詳しく知りたい方はこちらの弊社ブログをご参照ください。