--- title: "インフラストラクチャーとアプリケーションにタグを付けるためのベストプラクティス" description: "Datadog でタグを最大限に活用する方法をご覧ください。" author: "Mallory Mooney" date: 2019-12-11 tags: ["infrastructure monitoring", "service management", "tags", "tags"] blog_type_id: the-monitor locale: ja --- AWS や Kubernetes のような最新のプラットフォームの大半は、物理ホストよりも大幅に短い寿命を持つインスタンスやコンテナをすばやくスピンアップすることにより、動的な環境を構築します。こうした環境では、大規模なアプリケーションを複数の一時コンテナまたはインスタンスに分散できるため、サービスや基底のインフラストラクチャーの監視には[タグ付け](https://www.datadoghq.com/blog/the-power-of-tagged-metrics.md)が不可欠です。 たとえば、以下のアーキテクチャ例は、コンテナ、Lambda 関数、その他のホストされたツールなど、いくつかの異なるコンポーネントで構成されるアプリケーションサービスを示しています。 ![アプリケーションのタグ](https://web-assets.dd-static.net/42588/1776352629-tagging-best-practices-tagging-diagram.png) これらの個々のコンポーネントにタグを付けると、サービスのコンテキストが提供され、インフラストラクチャー全体を確認できるだけでなく、個々のサービスをより包括的な分析のために分離することもできます。たとえば、タグを使用して、AWS の特定のリージョンにデプロイされたすべてのサービスのメトリクスデータの概要を表示したり、特定のコンテナでホストされている単一のサービスのログを表示したりできます。適切なタグ付けを行わないと、こうした複雑なシステムの監視はすぐに効果を失ってしまいます。 この記事では、アプリケーションとアプリケーションサービスのタグ付けのベストプラクティスと、タグを使用して次のことを行う方法について説明します。 - [収集したタグでインフラストラクチャーをマッピングする](#collect-all-available-metadata-from-your-infrastructure) - [データストリームを統合して、サービスメトリクス、ログ、リクエストトレース間をピボットする](#pivot-between-request-traces-logs-and-metrics) - [所有者をサービスに割り当て、自動的にチームに通知をルーティングする有益なアラートを作成する](#assign-owners-to-services-with-tags) タグを使用すると、複雑なデータストリームを（ロール、環境、場所に関係なく）整理し、データポイント間をすばやく検索、集計、およびピボットできます。 ## インフラストラクチャーから利用可能なすべてのメタデータを収集する [タグ](https://docs.datadoghq.com/tagging.md)は通常、アプリケーションパフォーマンスデータとインフラストラクチャーメトリクスにディメンションを追加するキーと値のペアまたは単純な値（「ファイルサーバー」、「データベース」など）です。AWS、[Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)、Chef などの最新のプラットフォームと構成管理ツールの大半は、独自のタグを自動的に生成できます。Datadog は[インテグレーション](https://docs.datadoghq.com/tagging/assigning_tags.md?tab=go#integration-inheritance)を介してこれらのタグを自動的にインポートするため、Datadog で監視を開始する前に、プラットフォームが提供するタグ機能を活用することが重要です。 プロバイダーのタグの標準リストまたは推奨リストを使用すると、ホストとサービスの識別に一貫性が確保されます。Datadog によるタグの自動インポートは、システムの監視を開始するための最も強力な方法の 1 つです。これにより、ホスト、コンテナ、サービス全体の主要なパフォーマンスデータをすぐに理解して関連付けることができます。一時的なインフラストラクチャーでは、これらのタグは、作成されたリソースを自動的にグループ化および分類できます。 いくつかの例を見てみましょう。 ### AWS AWS は、すべての [EC2 リソース](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)全体でタグを構成するためのツールを提供し、各インスタンスに一連のタグを適用できます。AWS は、リソースに推奨される[タグ付け戦略](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)を提供していますが、一般的な AWS インフラストラクチャータグとしては以下が挙げられます。 - #account - #autoscaling-group - #availability-zone - #image - #instance-type - #instance-id - #name - #region 以下の例に示すように、Datadog はこれらのタグを自動的に収集してリソースに割り当てます。 ![Datadog によって取り込まれた AWS タグ](https://web-assets.dd-static.net/42588/1776352636-tagging-best-practices-aws-tags.png) AWS タグは、サービスを実行しているリソースの種類とその物理的な場所を識別するのに役立ちます。複数のリージョンまたはアベイラビリティーゾーンにわたってリソースを管理している場合、これらの識別子は非常に貴重です。たとえば、実稼働サーバーは通常、より復元力のあるシステムを構築するために、いくつかのリージョンにデプロイされます。特定のリージョン（us-west-2）でサービスプロバイダーが停止した場合、`region` タグを使用すると、そのエリアで影響を受けるリソースをすばやく検索できます。 ### Kubernetes (k8s) サービスの管理に Kubernetes を使用している場合、ポッドから主要なメタデータを収集できます。これには、次の[一般的に推奨されるラベル](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)が含まれます。 - #component - #instance - #managed-by - #name - #os - #part-of Datadogは、ラベルおよびアノテーションを自動的に[検出](https://docs.datadoghq.com/agent/autodiscovery/tag.md?tab=agent#kubernetes)してタグとして取り込み、それをポッドおよびノードが発行するすべてのメトリクス、トレース、ログに適用できます。これには、環境変数をコンテナ化された Agent のタグとして抽出することも含まれます。 Datadog が自動的に収集する他のプラットフォームタグと同様に、これにより、追加のタグを事前に適用することなく、クラスターをすばやく視覚化、監視できます。次の例に示すように、[コンテナマップ](https://www.datadoghq.com/blog/container-map.md)でタグを簡単に表示し、それを使用してログやダッシュボードデータを検索およびフィルタリングできます。 ![Datadog によって取り込まれた Kubernetes タグ](https://web-assets.dd-static.net/42588/1776352641-tagging-best-practices-k8s_tags.png) ### ホストマップを使用してインフラストラクチャーを視覚化する サービスプロバイダー（AWS や Kubernetes など）のタグを使用すると、インフラストラクチャーの概要を確認し、Datadog の[ホストマップ](https://www.datadoghq.com/blog/introducing-host-maps-know-thy-infrastructure.md)を通じて個々のホスト、コンテナ、またはクラスターにドリルダウンできます。ホストマップを使用すると、インフラストラクチャー全体のホスト関連のメトリクスをすばやく表示し、タグでグループ化およびフィルタリングすることでホストをさらに整理できます（コンテナマップはコンテナに対して同じことを行います）。たとえば、アベイラビリティーゾーン全体の自動スケーリンググループのホストの分布を確認する必要がある場合、マップをフィルタリングしてその自動スケーリンググループのみを視覚化し、次に AWS によって適用され、Datadog によって自動的に取り込まれた `availability-zone` タグを使用すればこれらのホストをグループ化できます。 ![コンテナマップでグループを自動スケーリングしてホストを表示する](https://web-assets.dd-static.net/42588/1776352645-tagging-best-practices-hostmap_az.png) インテグレーションの継承を通じて、Datadog はクラウドプロバイダー、コンテナプラットフォーム、または構成管理ツールからすべてのタグを収集することにより、インフラストラクチャーを自動的に整理します。これにより、ホストをすぐに確認し、インフラストラクチャーの各部と全体のつながりを把握することができます。 ## すべてのデータを関連付けて、より迅速にトラブルシューティングする インテグレーションの継承は、Datadog でタグを取り込み、インフラストラクチャーをすばやく分類するための推奨される方法の 1 つです。ただし、Datadog Agent の[構成ファイル](https://docs.datadoghq.com/tagging/assigning_tags.md?tab=agentv6#configuration-files)（**datadog.yaml**）および [Agent インストール](https://docs.datadoghq.com/getting_started/agent.md?tab=datadogussite#installation)の **conf.d** ディレクトリにあるインテグレーション構成ファイルにカスタムタグを追加することで、カスタムタグをインフラストラクチャーに割り当てることもできます。 Datadog が自動的に取り込むタグに加えて、カスタムタグは、動的インフラストラクチャーを整理し、こうした一時リソースから発行される**すべてのメトリクス、トレース、ログデータを統合**する上で重要な役割を果たします。Datadog は、タグを介してすべてのパフォーマンスデータをシームレスに相互接続します。そのため、組織の任意のデータポイントを関連付けたり、分析したり、アラートを発行することができます。これにより、問題をより迅速にトラブルシューティングし、個々のサービスと全体像の関係を簡単に理解できます。 ユーザーからアプリケーションの読み込み時間が遅いという報告があった場合、どの依存関係が問題の原因であるかをすばやく確認できる必要があります（ウェブサーバーやデータベースなど）。タグは、すべてのアプリケーションデータを選別し、データベースクエリが遅いなど、問題の原因を特定するのに役立ちます。次に、関連するデータベースログに簡単にピボットして、問題のあるクエリを確認できます。 次のいくつかのセクションでは、すべてのタグ（継承およびカスタム）を使用して、以下を通じてアプリケーションデータを関連付ける方法をご紹介します。 - [場所と環境によるホストのグループ化](#add-scope-to-your-applications) - [アプリケーションサービスの機能別による分類](#サービスの機能別分類) - [サービス所有者の割り当てと識別](#assign-owners-to-services-with-tags) ## アプリケーションにスコープを追加する ![アプリケーションダッシュボード](https://web-assets.dd-static.net/42588/1776352649-tagging-best-practices-app-dash-new.png) *環境やデータセンターなどのタグを使用してアプリケーションにスコープを追加して、データをすばやくフィルタリングできるようにします。* データセンターなどの環境や場所に関連付けることで、すべてのホストとサービスに[追加のスコープを提供](https://docs.datadoghq.com/tracing/advanced/setting_primary_tags_to_scope.md)できます。 グローバルな env タグは、インフラストラクチャー環境（開発、ステージング、本番など）によってデータを分離するだけでなく、インフラストラクチャーの概要を把握するのにも役立ちます。たとえば、本番環境で問題が発生した場合、関心対象はその環境のサービスとホストのみであるため、このタグを使用すると、ノイズをすばやくフィルタリングできます。`env` タグを使用すると、[本番環境での実際の問題についてのみページングされる](https://www.datadoghq.com/blog/monitoring-101-alerting.md)ようにすることもできます。 データセンターごとのタグ付け（例: `datacenter: us1.prod`）により、管理する環境のタイプをより詳細に制御できます。ホストをデータセンターごとにすばやくグループ化またはフィルタリングできることは、災害復旧計画とデータセンターのフェイルオーバーにとって重要です。さらに、クラウドプロバイダーなどの収集されたプラットフォームタグ（例: `cloud_provider: aws`）を使用すると、アーキテクチャーのスケーリングやリソースの適切なサイズ維持にも役立ちます。これは、成長するインフラストラクチャーのコストを管理するためにも重要です。 カスタムタグは即座にホストにスコープを提供します。インフラストラクチャーの概要を把握できるため、問題が単一のホストに影響するのか、クラスター全体に影響するのかをすばやく確認できます。 ### 環境と場所でホストを探索する AWS や Kubernetes などのプロバイダーから取り込まれたタグと同様に、特定の環境、場所、プロバイダーにホストのサブセットがどのように分散されているかを確認できます。2 番目のグループ化タグを追加すれば、ホストをさらに細分化できます。以下の例では、ホストは `datacenter` で分割され、さらに `availability-zone` タグでグループ化されています。このタグは Datadog によって自動的に収集されます。 ![コンテナマップで環境別にホストを表示](https://web-assets.dd-static.net/42588/1776352653-tagging-best-practices-host-map-env.png) ホストレベルのタグ（カスタムタグで、プロバイダーから自動的に収集されます）は、環境や場所を越えてアプリケーションがどのように動作するかを分類および理解するのに役立ちます。ホストのタグ付けに加えて、タグを個々のサービスに割り当てれば、特定のアプリケーションコンポーネントにすばやくドリルダウンし、関連するメトリクス、ログ、トレースを監視できます。 ## サービスを機能別に分類する ![Agent が収集したタグ](https://web-assets.dd-static.net/42588/1776352658-tagging-best-practices-datadog-agent-tags.png) ホストレベルでのサービスの分類と同様に、タグはサービスレベルでデータにディメンションを追加できるため、アプリケーションデータをさまざまな角度で確認することができます。アプリケーションをサポートするすべてのコンポーネント（ウェブサーバー、データベース、メッセージブローカーなど）を機能またはビジネスロールごとにグループ化することにより、これらをつなげることができます。以下のタグ付けスキームの例に見られるように、サービスの名前、サポートするウェブサイト、およびその主要な役割によってアプリケーションデータを分類できます。 ```text service: web-store site: web-store.staging role: webserver ``` これにより、Datadog の複数のディメンションを検索できます（サービスだけ、サイトに関連付けられているすべてのサービス、またはインフラストラクチャー内のすべてのウェブサーバー）。機能に加えて、サービスをビジネスロールで分類すれば、コスト配分を管理できます。 ```text business_unit: internal-processing cost_center: internal-processing-01 ``` サービス停止の影響を受けるユーザーのサブセットを特定するために、顧客地域に基づいてタグを作成することもできます。 ```text customer_region:eu ``` インフラストラクチャーにビジネス固有のタグを適用すれば、予算やクライアントの要求を満たすためにシステムをスケーリングすることを検討する際に、十分な情報に基づいて決定を下すことができます。これらの各タグの検索またはフィルタリング（または組み合わせ）を行えば、機能やビジネスロールに基づいてパフォーマンスデータを簡単に確認できます。続いて、Datadog でこれらのタグを使用する方法について説明します。 ### アプリケーションのアーキテクチャと依存関係を表示する サービスタグを使用すると、アプリケーションの[トレース収集を有効](https://docs.datadoghq.com/tracing/send_traces.md)にしている場合、Datadog の[サービスマップ](https://www.datadoghq.com/blog/service-map.md)を通じて特定の環境（または場所）に関連するすべてのサービスを表示できます。サービスマップは、アプリケーションを個々のコンポーネントサービスに分割し、依存関係に基づいてそれらをリンクします。 以下のサービスマップの例では、`web-store` サービスのリクエストレイテンシーとエラーカウント、および環境ごとにフィルタリングされたすべての依存関係を確認できます。このビューから、ノードをクリックすることで、各サービスの依存関係に踏み込んだり、関連するログやトレースにピボットしたりできます。 ![環境タグでサービスをフィルタリングする](https://web-assets.dd-static.net/42588/1776352662-tagging-best-practices-callout-services-map.png) 複数のサービスの主要なメトリクスを表示するには、AWS から収集されたもののような環境タグとプラットフォームタグを組み合わせれば、ダッシュボードでデータをすばやく検索できます。たとえば、`name` タグでフィルタリングし、`instance-type` でグループ化することにより、特定のホスト全体の平均 CPU 使用率を監視できます。 ![インスタンスタイプ別にメトリクスをフィルタリングする](https://web-assets.dd-static.net/42588/1776352666-tagging-best-practices-instance_dash.png) サービスマップまたはダッシュボードで問題に気付いた場合は、単一のサービスまたはメトリクスのログまたはトレースにピボットしてトラブルシューティングできます。次のセクションでは、シームレスなトラブルシューティングのために、あるデータポイントから別のデータポイントに簡単にピボットできる方法をご紹介します。 ### リクエストトレース、ログ、メトリクス間のピボット Datadog はタグを使用してデータを自動的に関連付けるため、ダッシュボード、ログ、トレース間でシームレスにピボットできます。`service` タグは各サービスのメトリクス、ログ、トレースを自動的にリンクするため、アプリケーションのパフォーマンスを監視およびトラブルシューティングできます。一方、`service` タグは特定のインフラストラクチャーテクノロジーのメトリクスと関連ログをリンクします。ダッシュボードではシステムの概要を確認できるため、サービスの異常なアクティビティを監視するのに役立ちます。ダッシュボードの 1 つでリソース使用率が急上昇していることに気付いた場合（下の例を参照）、グラフのデータポイントをクリックすると、ログエクスプローラーで[関連するログ](https://docs.datadoghq.com/graphing/dashboards/timeboard.md#correlation-between-logs-and-metrics)に簡単にジャンプできます。 ![ダッシュボードからログにピボットする](https://web-assets.dd-static.net/42588/1776352670-tagging-best-practices-view_related_logs.png) Datadog は、ダッシュボードに関連付けられた同じタグを[検索クエリに追加](https://docs.datadoghq.com/graphing/dashboards/timeboard.md#検索クエリを定義する方法)します。同様に、ログエントリを選択して、指定されたソースのホストレベルのメトリクス、サービスレベルのリクエストトレース、インテグレーションダッシュボードにジャンプできます。 または、同じタグのセットを使用して、Datadog [App Analytics](https://docs.datadoghq.com/tracing/visualization/search.md) でアプリケーション全体のリクエストトレースの傾向を検索できます。App Analytics を使用すると、サービスを流れるすべてのウェブリクエストを調査し、リクエストカウント、エラーカウント、リクエストレイテンシーなどのトップレベルのパフォーマンスメトリクスを表示できます。 Datadog は、カスタムタグに加えて、サービスプロバイダーによって生成されたタグをトレースに自動的に適用します。特定のトレースにドリルダウンし、すぐにピボットしてホストメトリクスとログの表示に戻ることができるため、問題の可視性が向上します。 システムにタグを付けると、アプリケーションデータに対する有意義なつながりが作られるため、Datadog のすべてのデータポイント間でピボットできます。また、タグは、作成するダッシュボードの数を減らし、タグフィルターを利用して 1 か所でより多くの情報を表示できるため、効率が向上します。こうしたつながりは、監視をシンプルにし、アプリケーションアクティビティの全体像を映し出すだけでなく、ダイナミックアラートに含めることができるため、インフラストラクチャーコンポーネントやサービスの問題を発生時に認識できるようになります。 ## タグを使用してサービスに所有者を割り当てる サービスが複数のチーム、部門、または事業単位でサポートされている場合、タグを使用して各サービスの所有者を指定できます。これにより、組織の各レベルでサービスを分類できます。こうしたタグを使用すれば、通知を適切なサービス所有者に動的にルーティングするアラートを作成し、特定のチームが所有するすべてのホストやサービスを検索できます。これは、問題に迅速に対処できるように、サービスオーナーに問題を警告する必要があるオンコールチームにとって有益です。 以下の例に示すように、チームまたは所有者タグを他のサービスタグに組み込むことができます。 ```text team: devops-support owner: devops business-unit: engineering ``` また、配信メールまたは Slack チャネルに基づいてタグを追加して、その配信リストまたは Slack の適切なチームに通知を自動的に送信するアラートを作成することもできます。以下の例では、**devops-distro@company.com** は配信グループのメールエイリアスで、**@devops-team** は Slack チャネルです。 ```text distribution-list: devops-distro slack: devops-team ``` こうしたタグがあると、[タグ変数](https://docs.datadoghq.com/monitors/notifications.md?tab=is_alertis_warning#tag-variables)を使用して Datadog で強力で動的なアラートを作成できます。タグ変数を使用すると、タグから動的に入力された、アラートをトリガーしたインスタンスまたはサービスに関するより詳細な情報を含めることができます。 ### チーム用の自動的かつ動的なアラートを作成する ![アラートに環境およびサービスタグを自動的に入力する](https://web-assets.dd-static.net/42588/1776352691-tagging-best-practices-alert-environment-service-tags.png) こうしたタグがあれば、トラブルシューティングの重要なコンテキストが手に入ると同時に、特定のサービス、ホスト、またはホストのクラスターに割り当てられたチームに自動的に通知が送信されます。 インフラストラクチャータグとサービスタグは、**マルチアラート**を作成する場合に特に強力になります。インフラストラクチャー内のチーム、ホスト、サービスごとに個別のアラートを手動で作成する代わりに、単一のアラートテンプレートを使用して、Datadog が適切なタグ、リンク、通知を持つ個別のアラートを自動的にトリガーするようにできます。 以下の例では、`trace.mongo.query.duration` メトリクスを報告するすべてのホストに対して[しきい値](https://docs.datadoghq.com/monitors/monitor_types/metric.md)マルチアラートを作成しています。このメトリクスが任意のホストの指定されたしきい値（アラート、警告など）に達すると、Datadog は影響を受けるホストごとに個別のアラートを自動的にトリガーします。 ![サービスタグを使用してアラートを定義する](https://web-assets.dd-static.net/42588/1776352695-tagging-best-practices-define_alert.png) タグ付けされたサービス所有者に基づいて生成されるアラートのメッセージにテンプレート化された @メンションを追加することにより、自動的に[チームメンバーに通知](https://docs.datadoghq.com/monitors/notifications.md?tab=is_alertis_warning#notification)したり、[Slack チャネルにメッセージを投稿](https://docs.datadoghq.com/integrations/slack.md)したりできます。 以下のアラートの例では、適切なチーム配信リストと Slack チャネルに通知が自動的にルーティングされます。[アラート通知](https://docs.datadoghq.com/monitors/notifications.md?tab=is_alertis_warning#overview)の詳細については、ドキュメントをご覧ください。 ![タグを使用してアラートに連絡先情報を自動的に入力する](https://web-assets.dd-static.net/42588/1776352700-tagging-best-practices-alert_contact.png) チームメンバーに問題を通知することに加えて、タグ変数を使用すれば、アラートに関連する特定のダッシュボード、ホストマップ、またはログ検索へのターゲットリンクを担当者に提供できます。以下のアラートメッセージの例では、アプリケーションダッシュボードの URL クエリ文字列のタグをタグ変数 `{{host.availability-zone}}` と `{{host.env}}` に置き換えました。 ![ダッシュボードリンクにタグを自動的に入力する](https://web-assets.dd-static.net/42588/1776352704-tagging-best-practices-alert_dash.png) アラートがトリガーされると、タグ変数値は、影響を受けるホストに関連付けられているタグに一致するように動的に埋められます。前の例では、アラートのリンクにより、ホストの環境とアベイラビリティゾーンが事前に自動スコープされたカスタムダッシュボードにルーティングされます。また、リンクでタグ変数を使用すれば、カスタムトレースやログ検索にルーティングすることもできます。 これにより、チームは問題の根本原因を迅速に特定できるだけでなく、組織にとって最も価値のあるアラートを作成できます。トリガーされた各アラートには、影響を受けるホストの関連情報が含まれます。これらの情報は、メールや Slack に加えて、[モニターステータスページ](https://docs.datadoghq.com/monitors/monitor_status.md)で確認できます。 ![通知にタグを自動的に入力する](https://web-assets.dd-static.net/42588/1776352708-tagging-best-practices-sample_alert.png) ## タグを使用してトラブルシューティングを簡単にする タグ付けは、現代の動的な環境でアプリケーションデータを監視するには不可欠な存在です。タグによって、メトリクス、ログ、トレースデータが統合されることで、ホストとそのサービスを検索したり、あるデータポイントから別のデータポイントに簡単に移動したりできるようになります。スタックの各コンポーネントにタグを付けることで（カスタムタグと AWS などのサービスプロバイダーによって生成されたタグの両方）、アプリケーションの可変部位にコンテキストが提供されます。 Datadog では、インフラストラクチャーとサービスタグのすべてを簡単に収集し、アプリケーションコンポーネントの相互作用を視覚化できます。システムにタグ付けして Datadog でそのタグを使用するこれらのベストプラクティスを活用することで、顧客に影響が及ぶ前に問題に積極的に対処できます。 に登録すれば、すぐに Datadog でアプリケーションのタグ付けと監視を始めることができます。すでにアカウントをお持ちの場合は、ドキュメントで Datadog の[タグ付け](https://docs.datadoghq.com/tagging.md)の詳細をご覧ください。