はじめに 本記事では、Datadog の設定方法を解説しながら、どのようにフロントエンド開発に活用できるかを話していきます。Datadog とは SaaS 型で提供されている監視サービスです。システムやアプリケーションの監視ができ、収集したログを分析するのに役立つ機能をたくさん提供しています。 こんにちは、株式会社LegalOn Technologiesで Software Engineer(Frontend)をしている山越 ( @yukishinonomeIT ) です。弊社では2024年4月に『LegalOn Cloud』というプロダクトを提供開始しました。Datadog は既存のプロダクトでも使っていたので、この新しいプロダクトでも活用することになりました。そこで、『LegalOn Cloud』における Datadog の運用を担当することになったので、実際にどのような活用をしている
エブリーで小売業界向き合いの開発を行っている @kosukeohmura です。 昨年、エブリーではネットスーパーの事業を株式会社ベクトルワン様から引き継ぎました。引き継いだシステムを運用していく中で、ネットスーパーの各種サイトや API に使用している 20 個超の SSL 証明書の有効期限を切らさないように更新していく必要があり、そのために監視を導入したお話をします。 引き継ぎ作業の概観については以前公開しました ゼロからはじめるシステム引き継ぎ - every Tech Blog に書きましたので、合わせて御覧ください。 背景とモチベーション システムを引き継いだ時点では SSL 証明書の更新の運用は素朴なものでした。具体的にはエンジニアが有効期限を切らさないようにたまにそれぞれのサイトの有効期限をチェックし、有効期限が近づいたものを発見次第手動で更新作業を行うというものです。抜け漏
エンジニアの大矢です。 Datadog を利用して KARTE の管理画面のパフォーマンスの監視および改善を行いました。 KARTEには計測したエンドユーザーの分析や、計測ユーザーへの配信管理を行う管理画面がありますが、大量のデータを扱うためパフォーマンスが問題になることがしばしばあります。ナビゲーションメニューからページ遷移した時の読み込み速度や、ボタンをクリックした時の反応速度が課題として挙げられます。 この記事ではパフォーマンスの監視をするにあたって考えたことや Datadog の活用のポイント、改善で取り組んだことについて紹介します。 パフォーマンス監視の方針PLAID ではモニタリングツールとして Datadog を活用しているため、まず Datadog を利用してパフォーマンスの監視をする方法を調べました。 KARTE はマイクロサービスアーキテクチャで構築されているため、分散
🚀 10x easier, 🚀 140x lower storage cost, 🚀 high performance, 🚀 petabyte scale - Elasticsearch/Splunk/Datadog alternative for 🚀 (logs, metrics, traces). OpenObserve (O2 for short) is a cloud-native observability platform built specifically for logs, metrics, traces, analytics, RUM (Real User Monitoring - Performance, Errors, Session Replay) designed to work at petabyte scale. It is straightfor
バクラク事業部 Platform Engineering 部の uehara です。2023年4月に入社しました! この記事では、直近で取り組んだ Datadog のコスト最適化の取り組みを紹介します。 概要 大きく2つの施策によって、Datadog の月額料金を 30% ほど削減しました。 毎月の利用量を事前コミットすることで単価を下げた ログ運用を見直すことでコストを約半分にした 利用量の事前コミット Datadog の一部機能では利用量を事前コミットすることで単価を下げることができ、価格表も公開されています。BILLED ANNUALLY が年契約、BILLED MONTH-TO-MONTH が月契約の単価です。 www.datadoghq.com オンデマンド料金と比較すると2割から3割ほど安くなっていることが分かります。 直近の利用実績から毎月必ず利用する分を算出し、MONTH-
プロダクト { this.openCategory = category; const productMenu = document.querySelector('.product-menu'); window.DD_RUM.onReady(function() { if (productMenu.classList.contains('show')) { window.DD_RUM.addAction(`Product Category ${category} Hover`) } }) }, 160); }, clearCategory() { clearTimeout(this.timeoutID); } }" x-init=" const menu = document.querySelector('.product-menu'); var observer = new Mutati
これは Livesense Advent Calendar 2022 DAY 20 の記事です。 はじめに 株式会社リブセンスの転職会議事業部Webエンジニアの @ishitan-liv です。 今回は、過去に転職会議でも導入しようとして挫折してきたE2Eテストについて書きます。 E2Eテストを自作するか、SaaSを使うのかで比較した結果と、Datadog Synthetics Testsの使い方を軽く紹介したいと思います。 なお、この導入については完全に個人プロジェクトとしてやっております。 リブセンスではエンジニアの権利として毎月10%の技術投資枠確保というものがあり、Googleの20%ルールのようなもので、約20日勤務だと想定して2日間は興味のある技術的なことに使えます。 grow.google はじめに このブログ記事を読むと得られる(と思われる)もの 今回書かないこと 導入検討
機密情報が間違ってログ出力されたことを検知する仕組みを、Datadogのセンシティブデータスキャナーで作る#Security#Datadog 概要 秘密鍵やAPIトークンなどの機密情報が含まれやすい場所として、ソースコードを管理するリポジトリがあります。 PLAIDでは、ソースコードへの機密情報のハードコードは原則として禁止していて、Secretlintを使い機密情報のコミットを検出しています。 リポジトリ以外の場所にも機密情報は含まれることがあります。 たとえば、KARTEはさまざまなSaaSと連携しているため、連携するSaaSのAPIを利用するためのAPIトークンなどをデータベースなどに保持しています。 これらのAPIトークンは、お客さんがプロジェクトに対して設定でき、トークンもお客さんの環境のものを利用するケースもあります。 オプション一覧 | CX(顧客体験)プラットフォーム KA
不正アクセスの中でも、アカウントへの不正ログインはもっとも基本的な攻撃になります。 なぜならログイン画面はどのサービスでも公開されていることが多く、 最近は外部サイトから流出したパスワードリストを使ったCredential Stuffingといった攻撃も行われます。 そのため、アカウントへの不正ログインは、攻撃者にとってはどのサイトでも共通の攻撃ができる比較的安易な攻撃方法となります。 この問題への根本的な対策は難しいですが、KARTEでも実装している多要素認証やアカウントロック機能といった対応が考えられます。 一方で、このような攻撃が実際に行われているかを監視する仕組みは、直接的な対策とは別途必要になります。 なぜなら、対策に抜け道がある可能性や外的要因で攻撃が突発的に発生する可能性があり、それに気付く仕組みと組み合わせることが重要となるためです。 KARTEではログのモニタリングにDa
Datadog はモニタリング関連の SaaS ではおそらく最も利用されているサービスでしょうが、公式ドキュメントが豊富にある割には何から読み始めれば良いかわかりにくく、慣れるまでの道が険しい印象です。 本エントリーでは、Datadog が既に導入されている組織で、Datadog モニターを使って監視をしたいけど、モニターの設定方法がよくわからないといった方を対象に、メトリクスモニターの作成に焦点を絞って解説していきます。なお、あくまで Datadog の使い方についての解説であり、どのようなモニターを設定すべきかについては触れません。 メトリクスの収集についても触れたかったんですが、力尽きたので、メトリクスの収集については気が向いたら別エントリーを書きます。 アジェンダ メトリクスモニターの作成方法の基本 クエリの定義について クエリの評価期間・評価方法・アラート条件の指定 クエリの結果
I am trying to create a widget on my Datadog dashboard but having a hard time understanding what is going on. I have a metric that is a counter for successful queries and I want to get a time series that graphs the total count within a 1min period over time in order to visualize any significant drops in the count that would signify a problem with a server handling those queries. The query that I'v
フロントエンドのダッシュボードを作ってみたらいい感じだったので紹介です。 作ったもの zx と Datadog、GitHub Actions を使って以下画像のように、フロントエンドのコードベースの各指標を可視化するダッシュボードを作りました。 値はデモ用に書き換えています 現在、計測している指標はこちらです。 Vue SFCファイルにしめるTypeScriptの割合 Vue SFCファイルにしめるComposition APIの割合 strict: trueにした場合のType Errorの数(tsc & vue-tsc) Jestの各種カバレッジ 各指標は毎朝9時に更新していて、時系列での推移も確認できます。 なぜ作った? 技術的負債解消等コードベースのリファクタリングの活動は、機能追加に比べ進捗を把握しにくい、成果が伝わりにくいという問題があり、それを解消したいと考えたからです。 こ
Datadog is a popular cloud monitoring service which operates at scale in all three major cloud providers, ingesting 10s of GB/s of points across many billions of timeseries into PiBs of hot and cold storage. Naturally, reliability is paramount. In this talk, we'll show how our very large distributed system works today, and how it grew from a very small not-distributed system. We'll share the most
こんにちは。ECプラットフォーム基盤SREブロックの高塚と巣立(@tmrekk_)です。 ZOZOTOWNはクラウド化・マイクロサービス化を進める中で、監視SaaSのDatadogを採用しました。この数年で多くの知見が蓄積され、今では様々なシーンでDatadogを活用しています。この記事ではそのノウハウを惜しみなく公開します。 ※本記事は、先日開催されたDatadog Japan Meetup 2022 Summerにて発表した内容を書き起こして再構成したものです。 当日の発表資料 speakerdeck.com 目次 当日の発表資料 目次 はじめに マイクロサービス基盤に必要な監視の要件 第1部 ZOZOTOWNにおけるDatadogの活用 1. どこで障害が起こっているのか分からない → APM 2. アラートやダッシュボードや外形監視が欲しい → Monitors, Dashboar
2023年8月更新 この調査は、2022年 6月に公開された本記事の前回版を基にしています。各実証に関するグラフはこちらからダウンロードでき、レポート本体はこちらをクリックしてダウンロードできます。 サーバーレスは現代のコンピューティングの主流となっています。今日、企業は増え続けるサーバーレスサービスを利用し、新しい革新的な方法でアプリケーションの構築と管理を行っています。チームはコンテナ化された関数やフルマネージド型のコンテナベースアプリケーションを利用することで、従来の FaaS (Function-as-a-Service) ソリューションを超えてシステムを拡張できるようになっています。AWS、Google Cloud、Azure などの主要なクラウドプロバイダーや、Vercel、Cloudflare などの新興プラットフォームは、開発者の期待するワークロードに対応するように設計され
深夜の定期バッチの監視 Webサービスのオフピーク時に重たい処理を実行させるというのは一般的なプラクティスといえます。 特に深夜〜早朝は多くのサービスでバッチ処理を実行させているのではないでしょうか。 Webサービスだけではなく、当然バッチ処理も監視して失敗したらそれを発見し対処したいです。 しかし、失敗を発見しても即座にユーザ影響がないので対応は後でも良いという場合、素朴に監視ルールを作るとバッチが失敗した深夜・早朝にアラートが発報されることになります。 発報されたアラートを見て「これは今すぐに対応してなくても良いな」と判断するのであれば、それは狼少年アラートといえるのではないでしょうか。 悪貨が良貨を駆逐すると言われるように、狼少年アラートがはびこれば良貨のアラートもいずれ無視されるようになってしまうことは容易に想像できます。 Datadogの timeshift 関数でアラートの発報
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く