並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 203件

新着順 人気順

Observabilityの検索結果41 - 80 件 / 203件

  • 「オブザーバビリティ・エンジニアリング」という本が出版されました #o11yeng - YAMAGUCHI::weblog

    はじめに こんにちは、Cloud Operations担当者です。このたび私が翻訳として関わった「オブザーバビリティ・エンジニアリング」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。 オブザーバビリティ・エンジニアリング 作者:Charity Majors,Liz Fong-Jones,George MirandaオライリージャパンAmazon www.ohmsha.co.jp 電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。 www.oreilly.co.jp また上記書籍情報ページに質問は報告を行うための連絡先も記載されておりますので、なにかありましたらそちらよりお問い合わせください。 TL;DR 「オブザーバビリティ・エンジニアリング」はオブザーバビリティ

      「オブザーバビリティ・エンジニアリング」という本が出版されました #o11yeng - YAMAGUCHI::weblog
    • GCPで理想の構造化ログを出力する方法

      はじめに この記事では、GCP のマネージドサービス(Google App Engine[1]/Cloud Run/Cloud Functions/GKE)から Cloud Logging に良い感じの構造化ログ(理想の構造化ログ)を出力する方法について紹介します。 良い感じのログの例 前提条件 この記事で紹介する構造化ログの実装は基本的に以下の仕様にそって実装しています。重要な仕様なので興味のある方は一度読んでみることをおすすめします。 構造化ペイロードの特殊フィールド 用語の解説 本編に入る前に、この記事で使われるログ出力まわりの用語をまとめておきます。以下の用語については前置きなく使いますのでよろしくお願いします。 構造化ログ[2] プレインテキストではなく、JSON等のデータ形式で出力されたログのこと GCPのCloud Logging(旧Stackdriver Logging)で

        GCPで理想の構造化ログを出力する方法
      • Istio、サイドカーパターンを不要にする「Ambient Service Mesh」機能をメインブランチに統合、正式な機能へ

        Istioは、サービスメッシュを実現する新たな仕組みとして試験的に開発していた「Ambient Service Mesh」をメインブランチに統合し、正式な機能として組み込んで行く方針であることを発表しました。 現在のIstioは、各サービス(≒KubenetesのPod)ごとにプロキシを配置し、サービス間のネットワークをプロキシ経由で構成することによってサービスメッシュを構築しています。これによりサービス間の通信のトラフィックコントロール、暗号化、可観測性(オブザーバビリティ)などの機能が実現されるわけです。 この仕組みは、サービスの隣にプロキシを配置することから、「サイドカー」パターンなどと呼ばれています。 しかしPodごとにサイドカーをデプロイする必要があるため、これにかかる手間やリソースの消費が課題でした。 eBPFを用いたサイドカーフリーなCiliumへ注目が集まる そうした中で最

          Istio、サイドカーパターンを不要にする「Ambient Service Mesh」機能をメインブランチに統合、正式な機能へ
        • 実践OpenTelemetry - Classi開発者ブログ

          こんにちは・こんばんは・おはようございます、エンジニアのid:aerealです。 この記事では筆者が開発に参加しているサービスの監視フレームワークをOpenTelemetryへ移行した際の体験を紹介します。 OpenTelemetryとは OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. What is OpenTelemetry? サイトの説明にある通り分散トレースやメトリクス、ログなどの指標を扱う監視フレームワークです。 OpenTracingやOpenCensusなどを継承・統合したプロジェクトと言うと合点がいく方も多いのではないでしょうか。 OpenTelemet

            実践OpenTelemetry - Classi開発者ブログ
          • 「New Relic実践入門」感想、あるいはなぜ監視SaaS使うんだっけという話 - Kengo's blog

            New Relic アニキこと清水さんから共著書「New Relic実践入門」をいただきました。ありがとうございます。清水さんにはかつてRDBMSの性能調査をいかに効率的かつ実践的にするかご教示いただいた恩があるのですが、今もその道を追求し活躍されていると知れて嬉しく思います。 破壊的イノベーションを現場の「あたりまえ」にする本書 さて本書は「Part 1. New Relicを知る」「Part 2. New Relicを始める」「Part 3. New Relicを活用する」の3部で構成されていますが、特に「Part 1. New Relicを知る」が割り切った構成になっています。「監視とは何か?」「既存手法にはどのような限界があったか?」「近年の技術革新による新たな課題は?」といった背景をすべてすっとばし、いきなり「オブザーバビリティとは何か?」の説明から入っているのです。まるでTyp

              「New Relic実践入門」感想、あるいはなぜ監視SaaS使うんだっけという話 - Kengo's blog
            • データ分析基盤におけるオブザーバビリティの取り組み

              GMOペパボ株式会社では主にGoogle Cloud Platformのサービスを利用してデータ分析基盤を構築し運用しています。その中心となるのがデータウェアハウスのBigQueryとワークフローエンジンのCloud Composerです。また、社内向けのデータ可視化(ダッシュボード)システムではCloud Runを利用しています。 データ分析基盤から得られる情報を重要な意思決定に用いるためには、ユーザーに提供しているインフラと同様に、可用性を明らかにし、継続的に可用性を高める Realiability エンジニアリングが必要となります。本講演ではGCPで構築されているデータ分析基盤を題材として、データ分析基盤に求められる可用性や、小規模なチームにおけるオブザーバビリティへの取り組みについてご紹介します。

                データ分析基盤におけるオブザーバビリティの取り組み
              • 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 #cndt2019 #osdt2019 #keynote

                決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 #cndt2019 #osdt2019 #keynote

                  決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 #cndt2019 #osdt2019 #keynote
                • Open-Source Observability | SigNoz

                  Out-of-box charts for application metrics like p90, p99 latency, error rates, request rates, etc.Monitor RED metrics for key operations in any serviceMonitor database and external calls made by any serviceService maps to show application topology Get end-to-end visibility of your services with rich contextual tags and attributes.Run aggregates on trace data like sum, avg, p99 latency, etc.Group yo

                    Open-Source Observability | SigNoz
                  • How eBPF will solve Service Mesh - Goodbye Sidecars - Isovalent

                    Service mesh is a concept describing the requirements of modern cloud native applications with regards to communication, visibility, and security. Current implementations of this concept involve running sidecar proxies in each workload or pod. This is a pretty inefficient way of solving these requirements. In this post, we will look at an alternative to the sidecar model that provides a transparen

                      How eBPF will solve Service Mesh - Goodbye Sidecars - Isovalent
                    • [CNDT2020]Linux Observability with BPF Performance Tools

                      Admission Webhookで快適なSecret管理 / Berglas Secret Admission Webhook

                        [CNDT2020]Linux Observability with BPF Performance Tools
                      • One Observability Workshop

                        This workshop is aimed at providing an hands-on experience for you on the wide variety of toolsets AWS offers to setup monitoring and observability on your applications.

                          One Observability Workshop
                        • マイクロサービスの効率的な監視〜不安定な依存先との闘い〜

                          DMM.go #6 の登壇資料です。 https://dmm.connpass.com/event/295065/

                            マイクロサービスの効率的な監視〜不安定な依存先との闘い〜
                          • Web VitalsとJavaScriptエラーの可視化 - フロントエンドにおけるObservabilityとは / visualize-web-vitals-and-javascript-error

                            Node学園 35時限目 オンライントライアルでの発表資料です。 Webアプリ・サイトの開発におけるObservabilityは、ユーザー体験(UX)の低下がいつどこで発生するかを検出し、開発者が改善にかかる時間を短縮するのに役立つ原因を把握することです。 構築をするには下記の3つのステップに区切ることができます。 ログを集める ログの詳細を可視化する ログの詳細から、改善に必要な意味合いだしを行う 最後の意味合だしを行うステップでは、情報を下記の3つのレベルに分類します。 エラー:空白ページの原因 警告:50ミリ秒を超えるハングアウト その他:デバッグなどの情報 この資料では、上記のステップを元に、AmplifyとQuickSightを活用したフロントエンドにおけるObservability向上の基盤を実装する方法を紹介しています。Observabilityの獲得により、フロントエンド開

                              Web VitalsとJavaScriptエラーの可視化 - フロントエンドにおけるObservabilityとは / visualize-web-vitals-and-javascript-error
                            • Google Cloud Operations Suite で実現する "頑張らないオブザーバビリティ" - KAYAC engineers' blog

                              SRE チームの市川恭佑です。 先日、CloudNative Days Tokyo 2023 のプロポーザルを提出したのですが、残念ながら採択に至らなかったので、今回は宇宙最速の(?)供養エントリになります。 シェア・投票など、ご応援をくださった皆様にはこの場でお礼を申し上げます。ありがとうございました。 event.cloudnativedays.jp 背景とか、経緯とか 筆者は、カヤックの SRE チームにちょうど2年ほど在籍しています。とは言っても半年ぐらいは学生アルバイトだったので、正社員としては1年半ほどです。カヤックに入る前も、いくつかの会社で IT エンジニアとしてインターンやアルバイトをしていました。 という訳で、何だかんだ仕事で使うプログラムを書き始めてトータル4年半ほどになりますが、そのうち3年半ほどは全て Amazon Web Services(AWS)でホストされる

                                Google Cloud Operations Suite で実現する "頑張らないオブザーバビリティ" - KAYAC engineers' blog
                              • Why is observability so expensive?

                                It’s no secret that observability costs are top of mind for many organizations in the post-zero interest rate phenomenon (ZIRP) era (see here, here, and here for example discussions, though similar sentiments can be found far and wide). Organizations are frustrated with the percentage of infrastructure spend (sometimes > 25%!) allocated towards logging, metrics, and traces, and are struggling to u

                                • Web VitalsとJavaScript Errorの可視化

                                  こんにちは、@watilde です。Amplifyの開発者体験体験の向上をすべく、ツイートのウォッチやGitHubでの反応などしています。もう去年のことですが、最近はcliの改善としてcreate-react-appのようにinitの実行時にREADMEの生成を行うPRなど作ったりしてます。参考: aws-amplify/amplify-cli#5808 この記事は英語で書いた Improve UX by observability in front-end with Amplify and QuickSight を自分で日本語に意訳してみたものです。Node学園 35時限目 オンライントライアル でも同様の内容を発表予定です。 JavaScriptのエラー例 JavaScriptは100%動いているのか 私達の作るWebアプリ・Webサイトが様々なデバイスで100%動作しているかは、実態

                                    Web VitalsとJavaScript Errorの可視化
                                  • あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 - Findy Tools

                                    公開日 2024/01/23更新日 2024/02/15あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 ユーザーや顧客へ信頼性を担保した価値提供をしていく中で、監視・オブザーバビリティの取り組みは非常に重要です。 今回の特集記事では、合同会社DMM.com、株式会社MIXI、株式会社マネーフォワード、パイオニア株式会社、Sansan株式会社、株式会社ZOZOの6社の各サービスを支える監視・オブザーバビリティの仕組みとして各社がどのようなアーキテクチャを組んでいるのか、またそのアーキテクチャにしている背景や意図についてお伺いしました。 自社に近いアーキテクチャやどのようにツールを活用しているかについて、実際の事例を元に参考になれば幸いです。 なお、後編も近いうちに公開させていただきますのでお楽しみに。 合同会社DMM.com(DMMブックス) アーキテクチャ設計の背景・意

                                      あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 - Findy Tools
                                    • TetragonでeBPFとセキュリティオブサーバビリティ入門 | フューチャー技術ブログ

                                      CNCF連載 の4本目です。 はじめに数年前にクラウドネイティブ注目技術として挙げられたeBPFにかねてよりキャッチアップしたいなと思っていたので、この連載のタイミングでeBPFとその関連プロダクトに入門してみることにしました。 CNCFプロジェクト傘下のeBPFを活用したプロダクトとしてはCilium, Falcoなどが挙げられます。CiliumはKubernetesなどのクラウドネイティブな環境でネットワーク、オブサーバビリティの機能を提供するOSSなのですが、今回はそのいわばサブプロジェクト的な位置づけのセキュリティツールである、Tetragonに触ってみます。 Cilium, Tetragonの開発をメイン行っているIsovalent社は、書籍やハンズオンラボなどで自社の製品・eBPFについての学習リソースを多く提供しています。 https://isovalent.com/reso

                                        TetragonでeBPFとセキュリティオブサーバビリティ入門 | フューチャー技術ブログ
                                      • CloudNativeな監視とは?今日から始める監視 / What is Cloud Native Monitoring. Let's try Monitoring!

                                        Developers Boost 2019で発表した「CloudNativeな監視とは?今日から始める監視」のスライドです。 Cloud Nativeな監視を始めるための、主要なキーワード「Observability」や「Telemetry」について触れました。 CloudNativeな監視とは? 今日から始める監視 - Developers Boost 2019 https://event.shoeisha.jp/devboost/20191130/session/2239/

                                          CloudNativeな監視とは?今日から始める監視 / What is Cloud Native Monitoring. Let's try Monitoring!
                                        • DWH改善に生かす! 入門elementary - yasuhisa's blog

                                          前提: これは何? dbtを使ったデータプロダクトを作っている社内のチームメンバー向けに書いた勉強会用のドキュメントです 社外に公開できるように少し抽象化して書いてます DWHに限らずdbtを使ったデータプロダクトで生かせる話ですが、分かりやすさのためにDWHを題材にしています 3行まとめ elementaryはdbtを利用しているデータパイプラインに対してData Observabilityを強化するツールであり、付属のリッチなレポートやSlachへのアラート通知が便利です しかし、実はelementaryが内部で生成している成果物はDWHの改善に役に立つものがたくさんあります 本エントリではelementaryの成果物や役に立つ実例を多めに紹介します 前提: これは何? 3行まとめ 背景: DWHとデータ品質 Observability / Data Observabilityについて

                                            DWH改善に生かす! 入門elementary - yasuhisa's blog
                                          • `*sql.DB` を観察する #golang | Wantedly Engineer Blog

                                            Photo by Abo Ngalonkulu on UnsplashPeople tribe / Backend squad の @izumin5210 です。もう12月ですね。自分は Advent Calendar に登録しすぎて後悔するのが得意です。 この記事は Go3 Advent Calendar 2019 の4日目です。 TL;DRSQL のメトリクス・トレースを収集したいは driver.Driver をラップするのが常套手段コネクション取得までの待ち時間まで見たい場合は、DBStats を見るのがよさそうことの発端Wantedly では Application Performance Monitoring に New Relic を利用しています。New Relic APM には様々な機能が存在しますが、例えばエンドポイントごとに「どの処理でどれくらいの時間がかかっているか

                                              `*sql.DB` を観察する #golang | Wantedly Engineer Blog
                                            • anyをunknownに変える - 西尾泰和のScrapbox

                                              TypeScriptで手抜きしてanyを使っている箇所って「自分の書いたコードだけど型をきちんと書くのが面倒だからanyにしてる」って場合と「サードパーティのライブラリからやってくる値で、型がなんなのか調べるのが面倒だからanyにしている」ってケースがある。 例えば後者の例で、Firestoreから取ってきたドキュメントオブジェクトの型がよくわからないのでanyにしていた。 code:ts (doc: any) => { ... } これをunknownに変えると… code:ts (doc: unknown) => { ... } unknownにexistsが生えてるからどうか知らないぞ、と指摘される。 きちんとした型をつける必要があるのだが、どうすれば良いか? code:ts if (doc.exists) { // ERROR: Object is of type 'unknown

                                                anyをunknownに変える - 西尾泰和のScrapbox
                                              • OSSでオブザーバビリティを実現する (Elastic Stack x OpenTelemetry on Kubernetes) - RAKUS Developers Blog | ラクス エンジニアブログ

                                                こんにちは。インフラエンジニアの gumamon です! 最近はSRE的なことも ちょこちょこ やらせて頂いています。 NewRelic、Datadog、モダンな監視(オブザーバビリティ)って良いですよね。 弊社もKubernetes(k8s)等を利用した環境が増えてきた折、そろそろ必要になってきた(と思っている)のですが、NewRelic、Datadog等のクラウドサービスはランニングコストが安くない。 そこで内製できないかやってみよう!ということになり、試行錯誤をした結果どうにか表題の構成で作ることができたのでご紹介をしたいと思います! この記事では、k8sを観測対象とし、オブザーバビリティを実現した際のアーキテクチャ構成、並びに四苦八苦する中で得た観測の勘所(私見)についてご紹介します。 目次 目次 オブザーバビリティとは オブザーバビリティ(OSS)の実現事例 全体構成 Elast

                                                  OSSでオブザーバビリティを実現する (Elastic Stack x OpenTelemetry on Kubernetes) - RAKUS Developers Blog | ラクス エンジニアブログ
                                                • OpenTelemetryをざっくり学んだ - yigarashiのブログ

                                                  OpenTelemetryについての情報を見聞きする頻度がどんどん上がっており、各種サーバー監視サービスやクラウドでも対応が進んでいることから、そろそろ自分の引き出しに入れたいと感じました。概要を自分で説明できるくらいを目指してざっくり学んだログを自分用に残します。 OpenTelemetryとは opentelemetry.io 公式トップページにある以下が全てを物語っているとは思います。メトリック、ログ、トレースはお馴染みのObservability三銃士ですね。 OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you

                                                    OpenTelemetryをざっくり学んだ - yigarashiのブログ
                                                  • Vector

                                                    A lightweight, ultra-fast tool for building observability pipelines

                                                      Vector
                                                    • オブザーバビリティの成熟度を表す4つのステップについて解説

                                                      Observability(可観測性)に関するオンラインイベント「Observability Japan Online」の第1回が2020年3月17日に開催されました。最初のセッション「オブザーバビリティ成熟モデルについて。」では、New RelicでSenior Customer Success Managerを務めるkatzchang氏が、オブザーバビリティの成熟度合を4段階で表したモデルについて説明。オブザーバビリティとモニタリングの違いや、オブザーバビリティが成熟することによって何ができるようになるのかについて、段階を追って解説しました。 Observability成熟モデルについて katzchang氏(以下、katzchang):では、話をしていきます。今日は、New RelicでObservability成熟モデルというのがあるので、その話をします。New Relicのことは

                                                        オブザーバビリティの成熟度を表す4つのステップについて解説
                                                      • OpenTelemetry Go Deep Dive

                                                        はじめに この記事はGo 言語 Advent Calendar 2023及びOpenTelemetry Advent Calendar 2023 8 日目の記事です。 今まで OpenTelemetry に関する記事をいくつか書いてきました(App Runner にデプロイしたアプリからトレースを X-Ray や Jaeger で可視化する記事やコンテナでデプロイした Lambda から X-Ray に OpenTelemetry でトレースを送る記事など)。今までの記事はどちらかというとインフラ観点のものが多く、アプリのサイドカーで OpenTelemetry Collector を動かしてマネージドサービスや OSS のツールにトレースを送る設定だったり、コンテナで動かして docker compose でローカルでも動かせるようにするだったりにフォーカスした内容が多かったです。一方で

                                                          OpenTelemetry Go Deep Dive
                                                        • New RelicからDatadogに乗り換えした話 - インゲージ開発者ブログ

                                                          明けましておめでとうございます。 2023年9月にINGAGEにジョインしたSREチームのanecho108です。 さっそくですが本記事の内容に入りたいと思います。 弊社のサービスは、AWS上のオブザーバビリティを獲得する方法としてNew Relic を利用していましたが、 そこからDatadogに乗り換えました。 Datadogの導入は僕が主体で行っていましたので、その時に考えていたことや反省点をまとめました。 なお、Datadogを肯定するわけでも、New Relicを否定するわけでもございませんのであしからず。 なぜ乗り換えしようとした? New Relicのコスト問題 日本語テクニカルサポートが受けられていなかった "僕"がオブザーバビリティの獲得に至っていなかった 周りにDatadogを使ってます勢が多い 日本リージョンがある そんなところへDatadogから営業メール Data

                                                            New RelicからDatadogに乗り換えした話 - インゲージ開発者ブログ
                                                          • Introducing arcticDB: A database for Observability

                                                            ATTENTION: ArcticDB has been renamed to FrostDB. Check out the blog post.End of last year we announced the Parca Open Source project and today we are excited to introduce arcticDB, an embedded columnar database written in Go building on top of Apache Parquet and Apache Arrow, powering Parca going forward. This blog post describes why we built it and what drove specific features and requirements, b

                                                              Introducing arcticDB: A database for Observability
                                                            • Netflix End of Series 1

                                                              Recent posts: 24 Mar 2024 » Linux Crisis Tools 17 Mar 2024 » The Return of the Frame Pointers 10 Mar 2024 » eBPF Documentary 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan@Intel.com 15 Apr 2022 » Netflix End of Series 1 09 Apr 2022 » Te

                                                              • GitHub - quickwit-oss/quickwit: Cloud-native search engine for observability. An open-source alternative to Datadog, Elasticsearch, Loki, and Tempo.

                                                                You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                  GitHub - quickwit-oss/quickwit: Cloud-native search engine for observability. An open-source alternative to Datadog, Elasticsearch, Loki, and Tempo.
                                                                • OpenTelemetry Casual Talk - コンセプトのおさらいと実践入門!を開催しました! - Mackerel お知らせ #mackerelio

                                                                  こんにちは!Mackerel CRE の id:KGA です。 2024年3月25日(月) に「OpenTelemetry Casual Talk - コンセプトのおさらいと実践入門!」を はてな 東京オフィスにて開催し、盛況を博しました!本記事では発表資料や配信動画のアーカイブとともに、イベントのレポートします。 OpenTelemetry Casual Talk - コンセプトのおさらいと実践入門! OpenTelemetry Casual Talk とは Mackerel のイベント初!ライブ配信を行いました 盛りだくさんのトーク内容 OpenTelemetry実践 はじめの一歩 by id:taxintt サービスメッシュ環境における OpenTelemetry 活用 by 逆井さん、柏原さん OpenTelemetry のサービスという概念について by id:azukiazus

                                                                    OpenTelemetry Casual Talk - コンセプトのおさらいと実践入門!を開催しました! - Mackerel お知らせ #mackerelio
                                                                  • Building Netflix’s Distributed Tracing Infrastructure

                                                                    “@Netflixhelps Why doesn’t Tiger King play on my phone?” — a Netflix member via Twitter This is an example of a question our on-call engineers need to answer to help resolve a member issue — which is difficult when troubleshooting distributed systems. Investigating a video streaming failure consists of inspecting all aspects of a member account. In our previous blog post we introduced Edgar, our t

                                                                      Building Netflix’s Distributed Tracing Infrastructure
                                                                    • 運用を可視化するためのダッシュボードの構築 | Amazon Builders' Library

                                                                      今日、多くの人がノートパソコン、タブレット、スマートフォンでアプリケーションを使用しています。デバイスに電源が入っているかどうか、Wi-Fi ネットワークが接続されているか、簡単に確認できます。画面には、空き容量不足の警告といった重要な通知が表示されます。実際に、ユーザーインターフェイス (UI) の全般的な速度や応答性は、アプリケーションにメモリや CPU などの十分なリソースがデバイスにあるかどうかを示す良い指標となります。 家族をリモートで技術的に手助けしたことのある人なら誰でも、デバイスを見ながら直接操作できないと、問題の検出や診断が少々難しいことをご存知でしょう。クラウドベースのサービスを実行する場合、同様の問題に直面します。これらのリモートサービスをどうモニタリングすればいいか? お客様が満足しているかを確認するにはどうすればよいか? 単一ホストサービスを監視するには、そのホス

                                                                        運用を可視化するためのダッシュボードの構築 | Amazon Builders' Library
                                                                      • シスコがSplunkの買収を発表、約4兆円で。同社の歴史上最大規模の買収

                                                                        シスコシステムズは、ログの収集解析ツール大手として知られるSplunkの買収を発表しました。 買収金額は280億ドル(1ドル145円換算で4兆600億円)。ブルームバーグの報道によると、これは同社の歴史上最大規模の買収とのこと。 シスコはネットワーク機器大手として知られていますが、現在ではサーバ分野でも存在感を示し、2017年にはモニタリングツールベンダのAppDynamicsを買収するなど、データセンターにおけるネットワーキングとサーバ、セキュリティ、そしてそれらを統合し運用管理するソフトウェアや基盤となるソフトウェアなどを提供するベンダとなっています。 参考:シスコ、AppDynamicsの買収を完了。アプリケーションやビジネスレイヤのモニタリングにも取り組みをはじめるシスコ Splunkは、サーバやネットワーク機器などあらゆるマシンやセンサー、ソフトウェアなどから生成されるログデータ

                                                                          シスコがSplunkの買収を発表、約4兆円で。同社の歴史上最大規模の買収
                                                                        • GoプロジェクトへのOpenTelemetry計装でeBPF自動計装を採用しなかった話

                                                                          既存GoプロジェクトにOpenTelemetryを計装する機会がありました。eBPFによる自動計装ではなく、手動計装を選んだ理由を説明します。 GoアプリケーションへのOpenTelemetry計装手段 Goにおいては、OpenTelemetryの自動計装が公式で用意されていません。公式サイトにAutomaticの章がないことからわかります。おそらく、ランタイムの制約で実行時にアプリケーションの挙動を変えることが難しいのでしょう。 トレースに十分なスパンを含めるために、現状では以下の2つの計装手段があります。既存のGoアプリケーションに導入する手間や影響範囲をイメージいただくために、概要に絞って解説します。 手動計装 eBPFによる自動計装(Work In Progres) 1. 手動計装 まず、OpenTelemetryのSDKをインストールし、セットアップをします。 func main

                                                                            GoプロジェクトへのOpenTelemetry計装でeBPF自動計装を採用しなかった話
                                                                          • おうち電力の Observability: parser combinator をガリガリ書いてスマートメーターとおしゃべりする - NTT Communications Engineers' Blog

                                                                            この記事は、 NTT Communications Advent Calendar 2023 6日目の記事です。 こんにちは。 SDPF クラウド・仮想サーバーチームの杉浦 (@Kumassy_) です。 普段は OpenStack の開発・運用をしており、最近は Observability まわりを取り組んでいます。 この記事では、以前私が Tech-Night という社内 LT 会で発表した以下のプロジェクトのご紹介します。 Tech-Night については以下の記事をご覧ください。 きっかけ 今年は不安定な世界情勢と円安、猛暑により電気代を気にする機会が多かったのではないでしょうか。 私もあるとき 7-9 月の電気代を確認したところ、電力使用量が 330 kWh、電気代が 10,000 円を超えていました。これは私のチームの 4 人家族のご家庭と比べても多い値でした。 なぜ私の家では

                                                                              おうち電力の Observability: parser combinator をガリガリ書いてスマートメーターとおしゃべりする - NTT Communications Engineers' Blog
                                                                            • Fargate Spotを本番運用するための監視の実践 - KAYAC engineers' blog

                                                                              SREチームの橋本です。SRE連載の3月号となります。 Amazon ECSのコスト最適化においてはFargate Spotが有効な手段となりますが、いつ中断されるか分からない性質上、その監視も併せて実施していく必要があります。今回はそのFargate Spotを本番環境で運用しているプロジェクトにおける取り組みを紹介します。 背景 Fargate (Amazon ECS on AWS Fargate) を用いると負荷に合わせた容易なスケーリングが可能になる一方、このときCPU使用率の安全マージンや予測のブレなどにより、リソースがやや過剰になってしまうこともあります。 Fargate Spotの代表的なユースケースと言えばユーザーに露出しない開発環境ではないかと思いますが、このような場合にコストを考えると、タスクの中断をある程度許容しての本番環境でのFargate Spot運用も可能な選択

                                                                                Fargate Spotを本番運用するための監視の実践 - KAYAC engineers' blog
                                                                              • Observabilityをはじめよう!(後編) 〜Metrics/Logs/Tracesチュートリアル〜 | さくらのナレッジ

                                                                                  Observabilityをはじめよう!(後編) 〜Metrics/Logs/Tracesチュートリアル〜 | さくらのナレッジ
                                                                                • オブザーバビリティにおけるプロファイルの重要性 pprofを活用するメリットをGoogle CloudのDeveloper Advocateが語る

                                                                                  可観測性に関するオンラインイベント「Observability Japan Online #1」が2020年3月17日に開催されました。Google CloudでDeveloper Advocateを務める山口能迪(ymotongpoo)氏は、「オブザーバビリティについて」という講演テーマで、プロファイラーを活用するメリットや利用方法について語りました。当日のスライドはこちら。 Observabilityにおけるプロファイルの重要性 山口能迪氏(以下、ymotongpoo):山口です。Google CloudでDeveloper Advocateをしていて、担当はObservabilityとGoです。 つい最近までは「Stackdriver」と呼ばれている製品群があったのですが、名前が変わりまして「Cloud Operations」という名前になっています。「Stackdriver」という

                                                                                    オブザーバビリティにおけるプロファイルの重要性 pprofを活用するメリットをGoogle CloudのDeveloper Advocateが語る

                                                                                  新着記事