Sardineでは、安定性を非常に重視しています。より多くの加盟店やさまざまなユースケースへとスケールしていく中で、モニタリングとアラートの重要性はますます高まっています。私たちはホスティングにGCPを使用していますが、GCPは基本的な機能しか提供していないため、モニタリング体制をより高度なものにするためにdatadogを導入することにしました。
datadogを使うメリットには、以下が含まれます。
- カスタムラベルによってログを動的にフィルタリング・グループ化できる。GCPでもある程度は可能ですが、実質的には難しいです。
- 同じモニターに対して警告とアラートの両方を設定できる。
- 異なるしきい値で、異なるGCPプロジェクト(本番環境とステージング環境)間でモニター定義を共有できる。
- 異なるGCPプロジェクト間でダッシュボード定義を共有できる。
- 全体的によりクリーンで直感的なUIと、バグの少なさ。
Datadogはオンラインガイドを提供しており、GCPとの統合方法が説明されています。私たちはインフラ管理にterraformを使っているため、すべてterraformで設定したいと考えました。
datadogからGCP連携を設定する
最初のステップは、datadogで「integrations」>「Google Cloud Platform」を選択し、プロジェクトを追加することです。これには、適切な権限を持つサービスアカウントが必要です。
resource "google_service_account" "datadog-connect" { account_id = "datadog-connect" display_name = "Service Account for datadog connection"}resource "google_project_iam_member" "datadog-connect" { for_each = toset([ "roles/cloudasset.viewer", "roles/compute.viewer", "roles/monitoring.viewer", ]) role = each.key member = "serviceAccount:${google_service_account.datadog-connect.email}"}
さらに、特定のタグを持つホストに限定してメトリクス収集を行うこともできます。開発プロジェクトでは開発者がいつでも何でも作成できてしまうため、監視対象のホストに「datadog:monitored」という特定のラベルを設定し、これらのホストからのみメトリクスを収集するようにしています。
さらに重要な点として、datadogコネクタはGCPが提供するすべてのメトリクスを収集するわけではありません。例えば、以前は監視にgcp.loadbalancing.https.backend_latenciesメトリクスのp95値を使用していましたが、2021年8月時点でdatadogが収集できるのはavgとsumsqdevのみでした。そのため、アプリケーションレベルで独自のカスタムメトリクスを定義する必要がありました。
ログ収集
GCEやGKE上で動作するアプリケーションについては、Datadog Agentを使ってログをローカルで収集できます。それ以外のログについては、log sinkとpubsubを使ってログを転送する必要があります。
resource "google_pubsub_topic" "export-logs-to-datadog" { name = "export-logs-to-datadog"}resource "google_pubsub_subscription" "datadog-logs" { name = "datadog-logs" topic = google_pubsub_topic.export-logs-to-datadog.name message_retention_duration = "604800s" retain_acked_messages = false ack_deadline_seconds = 60 push_config { push_endpoint = "https://gcp-intake.logs.datadoghq.com/v1/input/${var.datadog_key}/" }}resource "google_logging_project_sink" "datadog-sink" { name = "datadog-sink" destination = "pubsub.googleapis.com/${google_pubsub_topic.export-logs-to-datadog.id}" filter = "" unique_writer_identity = true}resource "google_project_iam_member" "pubsub-publisher-permisson" { role = "roles/pubsub.publisher" member = google_logging_project_sink.datadog-sink.writer_identity}
ログの構造がdatadogのログUIに正しく反映されるように、カスタムログパイプラインを定義する必要がある場合があります。以下は私たちのパイプラインです。
カスタムメトリクス(datadog agent)
追加のメトリクス、ログ、カスタムメトリクスを収集するには、datadog agentをインストールする必要があります。agentはDockerイメージとしても、ほとんどのOS向けのパッケージとしても提供されているため、通常は非常に簡単にインストールできます。
私たちにとって一つの難点は、(当時は)まだGKEを使用していなかったことです。私たちはコンテナ最適化OSを使ったmanaged instance groupを利用していました。アプリケーションの大部分にgolangを使用しているため、アプリケーションのDockerイメージは非常にシンプルで、単にscratchイメージにgolangアプリケーションをコピーするだけです。つまり、datadogパッケージをインストールするためのOSが存在しないということになるため、コンテナ最適化OS上で2つのDockerイメージ(アプリケーションイメージとdatadog agentイメージ)を実行する方法を見つける必要がありました。
あまりドキュメント化されていませんが、実はVMのstartup_script内でDockerを起動できることが分かりました。
module "managed_instance_group_template" { source = "terraform-google-modules/vm/google//modules/instance_template" ...startup_script = "docker run -d --name dd-agent ...."
以上です!まだ設定の途中ではありますが、すでにdatadogの価値を実感しており、とても満足しています!