イヤー今年は前年比2倍以上のDatadogイヤーでした。(私の稼働的に)

Datadogユーザー会(JDDUG)に入ったり、Datadog USの方々と交流したり、
Datadog Summitで新機能等を学んだり、お客様から活用方法の相談を受けたり、
時には現場に入って改善活動をしたりetc...と結構忙しかったです。

弊社はDatadog以外のオブザーバビリティ製品も取り扱っているので、
お客様には用途に合ったものを選択いただけるよう勧めており、強引にDatadogを推すことはしていないんですけど、ありがたいことに「Datadogいいね」の声は結構多かったです。
(密かには嬉しかったですが)

そんなDatadogですが、今回はDatadogを少し快適に使う小ネタを記事にしてみました。
読んですぐ使える小ネタですので是非チェックしてみてください。

１．オンラインドキュメントは英語版もチェックしよう

見ない日はないと思うぐらいお世話になってなっています！
https://docs.datadoghq.com/

Datadogのオンラインドキュメントは日本語版があり、ちょっとした調べものには十分ですが、一部更新が間に合っていない場合があったりします。

あれ？これ怪しいな。。って思った時は英語版に切り替えて確認してみてください。
たとえば、日本版だとテレメトリーの収集をOFFにする設定内容が以下になっています。

export DD_INSTRUMENTATION_TELEMETRY_ENABLED=false

これが英語版だと下記となっています。
※サポートにも確認しましたが、英語版が正しいとの事。

export DD_APM_TELEMETRY_ENABLED=false

AWSのマニュアルでも同じような事ありますし、
やっぱり、日々進化する機能を追ってアップデートするの大変なんだろうな。。
と思いを馳せつつ、余力があったら、是非、チェックしてみて下さい！

２．双子ノードはしっかり取り締まろう

インフラストラクチャー情報を見ると、同じサーバノードが２行（双子）になって出力されていた事ありませんか？私はあります

こんな感じ↓

インテグレーションやDatadog Agentの初期ロード時に見るのですが、Datadogサーバ側が「同じサーバだね」と認識するまで少し時間がかかります。（体感２時間ぐらいかな）

大概は「i-xxxx」が自然消滅するのですが、残っていたら 要注意 です。
２サーバ分課金が発生している可能性があります

これはDatadogがサーバのメタデータを正常に読み込めず、インテグレーション情報とDatadog Agent情報を上手に紐付け出来無くて、別々のサーバとしてカウントしてしまっている事で起こります。

AWSであれば、IMDSのバージョンとDatadog Agentの設定不整合で発生している事が多いので以下の設定をチェックして下さい。

## @param ec2_prefer_imdsv2 - boolean - optional - default: false
## @env DD_EC2_PREFER_IMDSV2 - boolean - optional - default: false
## If this flag is true then the agent will request EC2 metadata using IMDS v2,
## which offers additional security for accessing metadata. However, in some
## situations (such as a containerized agent on a plain EC2 instance) it may
## require additional configuration on the AWS side. See the AWS guidelines
## for further details:
## https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#instance-metadata-transition-to-version-2
#
ec2_prefer_imdsv2: true  ★EC2側で「IMDSv2 Required」の場合は「true」とする★

適切な設定による適正価格でDatadogを利用しましょう！

３．ログの保存は用途別に細かく分けよう

Datadogには用途別で以下の３つのストレージ領域が用意されています。

①Index：主にリアルタイムモニタリング用のログの保管場所。
②Flex：事後での障害調査等、分析用途ログの保管場所。（監視に使えない）
③アーカイブ（S3等）：読んで字のごとく、アーカイブログの保管場所。

https://docs.datadoghq.com/logs/log_configuration/flex_logs/

料金は高い順に Index ＞ Flex ＞アーカイブとなっています。
リアルタイム用のIndexは割高でアーカイブは安価な価格となっています。（FLEXはその中間）

https://www.datadoghq.com/pricing/list/

サーバのシスログやちょっとしたアプリログだけならデフォルト設定のまま(Indexに保管される)で良いのですが、ここ最近は全てのログをDatadogに集結させて監視検知/分析/調査を全てオールイン🐶とするのが流行って(個人の感想です）いる為、そのままIndexだけだと費用が高額になってしまいます。

とある、ユーザでリアルタイムの配信ログをIndexに大量に連携してしまい、X百万円が請求されたとかなんとか、、

そんな事になる前にログは初期の設計段階で出力先を分けてるようにしましょう！

下記は「CloudTrail」のログはFLEXへ連携（分析用）とし、それ以外をIndexに連携（監視用）としています。「Logs」-「Configuration」から簡単に設定が出来ます。

Indexの保持期間は3Day~180Dayの間で変更可能です。リアルタイムの監視用途だけだったら「3Day」でいい気がしますがそこは要件に合わせて変更してください。

また、運用中でも設定変更は可能です。ただ、監視用ログをFLEXに連携してしまい、監視が出来なくなった！等のトラブルにならないように十分注意して対応しましょう。ご安全に。。

まとめ

今回は明日使える小ネタを紹介してみました。SaaSやCloudは適切に使わないとその真価を発揮できない(オンプレの方が良かった...なんて声もたまに聞こえてくる😢)ので、こういう細かいところも結構大事だったりします。足元をしっかり固めて、より効果的なモニタリング環境を構築していきましょう。

それでは、良いDatadogライフを!