![Datadog、東京にデータセンターを開設し、日本リージョンが利用可能に](https://cdn-ak-scissors.b.st-hatena.com/image/square/1e4abf57f0bba3e5ae3e351d09ac2cb8ac97ded4/height=288;version=1;width=512/https%3A%2F%2Fcloud.watch.impress.co.jp%2Finclude%2Fcommon%2Fp01%2Fimages%2Flogo%2Fclw.l.png)
こんにちは。ABEJAのインフラ管理してる村主 @rwle1221 です。 本ブログは Datadog Advent Calendar 2019 の8日目です。 今日は ABEJA Platform というプロダクトで、なぜ Prometheus から Datadog に変えたのか。というお話したいと思います。 一人の方でも採用基準の参考になればと思います。 第一フェーズ:実は元々Datadogを使っていた 実は Prometheus の前は Datadog を使っていました。 なぜ Datadog を使っていたかというと、Za○bix や Na○ios などは古い思想なので使う気になれなかったという単純な理由です。 ただ、 Datadog は $18/host という値段で 当初は数十台だったので数万円ほど発生していました。やはり少し高いなという印象です。 第二フェーズ:Promethe
AWSチームのすずきです。 AWSマーケットプレイス で 提供されている AMI や SaaS (Software-as-a-Service) は、 AWS経由で ソフトウェア利用費を支払う事が可能です。 今回、AWSマーケットプレイスで 「Datadog Pro (Pay-As-You-Go)」 を契約し、 月々のAWS利用費と合算する形で、Datadog の 有償ライセンスを必要とする機能(ログ監視)を利用する機会がありましたので、紹介させていただきます。 手順 AWS Marketpace AWSコンソールにログインを済ませたブラウザで、 AWS Marketpace を開き、 検索フォームを利用して「Datadog」を検索します。 プラン選択 「Datadog Pro (Pay-As-You-Go)」 を選択しました。 「Pay-As-You-Go」は前払い料金なし、従量課金でDa
This checklist contains points that must be satisfied during implementation and verified prior to release. Please note that all items in the design checklist that were verified at the end of the design phase, must still be satisfied at release time (e.g. the design doc must be up-to-date, the SLOs must be consistent, ...).
追記: GoのアプリケーションをOpenMetricsを使ってObservableにする方法については別エントリを書きました。 → https://songmu.jp/riji/entry/2020-05-18-go-openmetrics.html ECSとGoで運用しているシステムに対するDatadogの日本語知見があまり無さそうだったので書いてみる。ちなみに以下の環境です。 ECS on EC2 (not Fargate) アプリケーションコンテナのネットワークモードはbridgeモード 動的ポートマッピングも利用 背景として3月にNature Remoのインフラアーキテクチャ改善をしていて、その前にもうちょっと監視を整えたほうが良いな、ということでDatadogを導入したのがある。テストがないとリファクタリングできないように、監視がないとアーキテクチャのアップデートもやりづらいとい
ZOZOテクノロジーズ SRE部の川崎(@yokawasa)です。ZOZOTOWNのアーキテクチャをマイクロサービスで再設計してリプレイス化を推進するチームに所属しております。 本記事では、このZOZOTOWNのマイクロサービスプロジェクトで実践している継続的インテグレーション/継続的デリバリー(以下、CI/CD)についてご紹介します。 はじめに まずはじめに、本記事に登場する中心的なキーワードであるCI/CDと、Infrastructure as Code(以下、IaC)について簡単に説明します。 IaCとは、インフラ構成をコード化して、そのプロビジョニングを自動化する手法です。コード化されたファイルはコードリポジトリで管理することが多く、また、IaCを実現するためのツールやサービスの利用が不可欠になります。 CI/CDは、その名の通り、CI(継続的インテグレーション)とCD(継続的デリ
これは Datadog Advent Calendar 2019 13日目の記事です。 門脇(@blac_k_ey)です。 PYXISのデータ基盤チームでSREっぽいことを行っている傍ら、インフラチームとして横断的なインフラの管理・運用を行っています。 モチベーション 最近PYXISチームではモニタリングツールとしてDatadogの採用が進んでいます。 PYXISのインフラは主にAWSを利用しており、DatadogのAWS Integrationを導入することで各種サービスのメトリクスを取得することが可能になります。 ここで課題になるのが弊社のAWSのアカウント構成です。 PYXISチームのAWSアカウント管理は以下のような構成になっています。 このように、基幹となるAWSアカウントからAssumeRoleを使って、各プロジェクトで利用しているAWSアカウントにログインするという形を取って
こんにちは!リクルートライフスタイルの共通クラウド基盤でリードクラウドアーキテクトをしている須藤です。 この記事は AWS Advent Calendar 2018 の2日目の記事です!( リクルートライフスタイル Advent Calendar 2018 2日目の記事でもあります) リクルートライフスタイルの共通クラウド基盤では、サービスごとにアカウントを払い出して、サービス開発者がその環境を構築する、というスタイルです。クラウドアーキテクトチームはCCoE(Cloud Center of Excellence)であり、TerraformやFargateを使いたい、という開発者に対しては、ペアプログラミングやアーキテクチャレビューなど、規範的・助言的な活動を通して成長しあっていく、という活動をしています。 当然、re:Invent 2018で発表された トランジットゲートウェイ や AW
Fargate + Firelens + FluentBit + Firehose で S3(Firehose) と Datadog にログを送るAWSDockerTerraformDatadogfluentbit Firelens + FluentBit を使って Datadog と S3(Firehose) にログを送る方法です。 今までは CloudWatchLogs, Lambda, StepFuntion を組み合わせて Datadog と S3 にログを送っていたのですが、Datadog にログを送る Lambda がたまにコケるので、Firelens と FluentBit を使ってログを送るようにしました。 Terraform を使って Fargate で Nginx を動かす まず、Terraform を使って Fargate で Nginx を動かします。 ファイル全文
Kubernetes のログを見るといえば、Datadog Log Mangement が楽なのですが時々ログメッセージが適切なレベルで扱われません。 そんなときによくやる「ログメッセージからレベルになるフィールドを取り出して Log Status として認識させる」ことを見てみましょう。 Before After 目次 目次 TL;DR 問題 ログを見てみる 対処方針 パイプライン対応 Custom Pipeline の追加 Processor の追加: Grok Parserで構造化する Processor の追加: Log Status Remapperでログステータスとする Pipelineの結果を確認 REF TL;DR Custom Pipeline を使って、ログメッセージを構造化とLog Status の変更を行えばok ログメッセージがkey=value で構造化されてい
この記事はCyberAgent Developers Advent Calendar 2017 6日目の記事です。 アドテクスタジオ Dynalyst開発チームの黒崎 (@kuro_m88) です。早いもので入社して3年目になりました。今年はDatadog Logsを一部本番に導入したので紹介しようと思います。 Dynalystではサーバやアプリケーション、AWSのマネージドサービスの監視やメトリクスの可視化にDatadogを使っています。 どんな風に使っているかは以前発表した資料があるのでこちらをご覧下さい。 そして、このスライドの最後に「ログのマネジメントもできるといいなぁ…?」と書いてありますが、なんとその願いが叶った結果、Datadog Logsが11月末に発表されました!!!! 何ができるのかは公式ドキュメントの図がわかりやすいです。 https://docs.datadoghq
Motivation Prometheus には Service Discovery という機能があり、監視対象のノードを自動的に補足し対象に追加する事が可能です。 (https://prometheus.io/docs/prometheus/latest/configuration/configuration/ の **_sd_config がそれらの設定になります。) 最近は Kubernetes などの Docker orchestration tool の普及により監視対象が動的に変化する環境が多く、Auto Scaling / Self Healing に自動的に追随して監視を行ってくれるツールの必須度が高くなっています。 個人的には Datadog が好きなので、同様な機能が Datadog にもあると良いな、と思っていたのですが、 Datadog でも AutoDiscove
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く