Datadog のインストールを構築する

Datadog のインストール設計とベストプラクティスを計画した後は、Datadog 自体の構築に集中し、何をインストールする必要があるのか、またそれを実現するための最善の方法は何かを理解しましょう。

IT フットプリントが拡大するにつれ、ソフトウェアのインストールと使用に関する標準を確立する必要があります。そのためには、必要な柔軟性を維持しながら、確実にソフトウェアを構成するための正確で繰り返し実行可能な手順を作成することが重要です。このセクションでは、Datadog がこれらの標準とどのように効率的に統合可能かを説明します。

環境の継続的な改善

計画のセクションでは、Datadog の設計仕様に含まれるさまざまなトピックについて検討しました。理想としては、大規模なロールアウトを実行する前に、これらの問題について一つ一つ完全に調査し、答えを見出しておきたいところです。しかし、エンタープライズ IT エンジニアリングにおいては、インストールを構築しながら、いったん立ち止まって適応を図っていくことがしばしば求められます。

機能の優先順位付け

Datadog のインストールを段階的に行い、徐々に複雑性の高いものにしていくことは可能です。早期に行うべきこともあれば、後回しにしてよいものもあります。以下では、Datadog のインストールをスケールする際に、主要なもの (ニーズ) と補助的なもの (ウォンツ) をどのように分けて考えられるかを説明します。

主要なもの:

統合サービスタグ - service:test env:prod version:1.x
製品プロファイル (インフラストラクチャー、APM、Synthetic Monitoring、RUM、ログ管理など)
主要インテグレーションの詳細 (ポート、ログイン、URL)

補助的なもの:

補助的なインテグレーション
高度またはケース固有のオプション

社内サポート

Datadog プラットフォームのオーナーとして、インストールした機能をユーザーが利用する仕組みを用意する必要があるでしょう。Wiki、ServiceNow インテグレーション、または Jira ボードを通じて Datadog を公開し、ユーザーが機能をリクエストできる手段を提供する方法も考えられます。社内ユーザーはこれをガイドとして使用して、自分の管理するアプリやインフラストラクチャーに Datadog をデプロイします。

このシステムの形は環境によって異なるものになりますが、このような仕組みの構築を迅速化するための基本的事項がいくつか存在します。

以下のような Datadog インストールタスクのリストを作成します。
- 新しいアプリケーションのオンボーディング (すべてのソフトウェアとインフラストラクチャーを含む)。
- クラウドアカウントの追加
- 新しい vSphere クラスタノードの作成
- 新しいデータベースインスタンスの作成
- 新しいサードパーティ製ソフトウェア製品のモニタリング
- Synthetic Monitoring テストの追加
- アラート/モニターの作成
- ダッシュボードの作成/更新
以下のような内容を含む最低限の情報を収集します。
- 社内コストセンターコード
- アプリの名前、オーナー、運用チーム
- ローカルの条件に固有の事項

これらの定義は、計画フェーズで作成したアーキテクチャプランの基盤をさらに強化します。もし定義に行き詰まった場合は、Datadog が管理を支援するために開発したメカニズムがあります。概要は以下のとおりです。

コンテンツの作成

Datadog は、完全に文書化されたオープンな RESTful API プラットフォームです。UI に表示されるものの大半はプログラムで構築可能です。Datadog は API の使用を歓迎し、完全にサポートしており、独自のカスタムアプリケーションのデータソースとしても使用できます。

ダッシュボード、アラート、ノートブック、パース済みのログ、クラウドインテグレーションの構成など、Datadog で作成したオブジェクトはすべて JSON としてプラットフォームに保存され、エクスポートやインポートが可能です。これにより、Infrastructure as Code (IaC) への完全準拠、構成のバックアップ、アカウントの移行、再利用性など、さまざまな管理機能を実現できます。また、Datadog は、これらの目的のために Terraform プロバイダーと CLI ツールもサポートしています。

プロビジョニング

プロビジョニングは、あらゆるエンタープライズ IT 環境の中心となるものです。Datadog を大規模に管理するには、Datadog をプロビジョニングプロセスに統合します。Datadog Agent のインストールモデルはシンプルなため、プロビジョニングへの統合をさまざまな方法で実現できます。

モジュラーアーキテクチャ

大半の企業向けソフトウェア製品と同様に、Datadog のインストールは、3 つの別々の作業に分けることができ、それぞれがファイル/パッケージ/サービスモデルと呼ばれるモジュラーアーキテクチャの一部となっています。

ファイル: 構成ファイルを含みます パッケージ: バイナリを保持し、そのデプロイを制御します サービス: OS サービスシステムを介してランタイムインスタンスを管理します

Datadog をインストールするために完了すべき基本的な作業は以下の通りです。

ファイル: コンフィギュレーションファイルの変更を保存・管理するために、ソースコード管理を使用できます。Jinja2 や Ansible などのテンプレート/IaC ソリューションも非常に有効です。

パッケージ: Artifactory や Nexus などの内部パッケージリポジトリを使用して、.rpm、.msi、コンテナ化された Agent パッケージをホストします。

サービス: IaC またはシェルスクリプトを使用します。

IaC: Infrastructure-As-Code は、洗練度と堅牢性の両面で進化しています。クラウドインフラストラクチャーでほぼ例外なく使用されていますが、古くからあるオンプレミスのインフラストラクチャーにレトロフィットされることもよくあります。そのシンプルなファイル/パッケージ/サービス構造を活用して、bash スクリプトのような初歩的な IaC ”ツール” を使った Datadog のデプロイがかなり行われています。このやり方は推奨されるものではありませんが、 IaC を利用した Datadog の早期導入を促進するものではあります。実際これを行うことにより、Datadog で Ansible、Puppet、Chef、Powershell、Bash、CloudFormations、Terraform 向けのサンプルコードとインテグレーションがしっかりと用意されていることがわかります。

推奨事項:
Datadog Agent ソフトウェアのデプロイに関しては、既存のプロビジョニングシステムをできるだけ再利用することをお勧めします。Datadog ソフトウェアの設計はフラットで、業界標準の手法に準拠しています。

サマリー

Datadog Agent はフラットな設計のため、既存のどのようなプロビジョニングシステムにも簡単にフィットします。ファイル/パッケージ/サービスを前提とした既存の機能を利用し、Datadog をそこに組み込むことができます。Datadog のプラットフォームでは有用なメカニズムが提供されていますが、ローカルの条件により、それぞれの状況に合った最適な方法が決まります。