Prometheus で独自メトリクスを用意する - Carpe Diem
概要 Metric types | Prometheus で定義されているようにPrometheusでは大きく４つのメトリクスタイプがあります。 Counter Gauge Summary Histogram 今回はGoのPrometheusクライアントライブラリを用いて各メトリクスを独自で用意する方法を説明します。 環境 Prometheus 2.11.1 Golang 1.12.7 prometheus/client_golang 1.0.0 expose まずはPrometheusが監視対象のメトリクスをPullできるよう/metricsのエンドポイントを用意します。 公式クライアントとしてpromhttpというライブラリが提供されているのでそれを使います。 package main import ( "log" "net/http" "github.com/prometheus/c
Prometheus でカスタムコレクタを用意する - Carpe Diem
概要 以前↓の独自メトリクスを作る方法を紹介しました。 christina04.hatenablog.com これはdirect instrumentation（直接計装）というやり方で、アプリケーションサーバ自体がstatsを持ちprometheusにデータを渡すやり方です。 今回はそうではなく別プロセスや別サーバ、ホストOSのstatsを取り込んでコレクタとして登録する方法を紹介します。 イメージ的には各stats情報をprometheusフォーマットに変換するproxyを作る感じです。 環境 prometheus/client_golang 1.5.0 Collectorインタフェース GoではCollector interfaceを実装することでCustom Collectorを作れます。 Collector interfaceは以下の2つのメソッドを持っています。 Describ
Go で実装した Web アプリケーションと Prometheus の連携
はじめに Go で Echo を使用した Web アプリケーションと Prometheus を連携させ、アプリケーションで独自に定義したメトリクスを Prometheus でスクレイプする実装を行ったので、手順についてまとめます。 実装 今回は、クライアントからのリクエストをカウントするメトリクスを定義します。その際にクライアントから指定されたリクエストパラメータ number が偶数か奇数かでメトリクスに付与するラベルを変更するような実装を行います。 Go の実装 はじめに Go の実装を行います。まず必要なライブラリをインストールします。具体的には以下のコマンドを実行します。また、今回使用した Go のバージョンは 1.16 となります。 $ go install github.com/labstack/echo/v4@latest $ go install github.com/la
Metric and label naming | Prometheus
Getting startedInstallationConfigurationConfigurationRecording rulesAlerting rulesTemplate examplesTemplate referenceUnit Testing for RulesHTTPS and authenticationQueryingBasicsOperatorsFunctionsExamplesHTTP APIRemote Read APIStorageFederationHTTP SDManagement APICommand LineprometheuspromtoolMigrationAPI StabilityFeature flags VisualizationExpression browserGrafanaConsole templates InstrumentingC
Prometheusでの監視データ活用マニュアル
2023/04/17 開催された、Kubernetes Novice Tokyo #24 にて話したスライドです。 https://k8s-novice-jp.connpass.com/event/278196/
TimescaleDB 雑感
TimescaleDB を自社サービスに採用して 1 年以上過ぎたので振り返ってみます。 前提 著者は SQL に関して TimescaleDB を採用を決めたタイミングから勉強した初心者です Managed Service for TimescaleDB を採用しています まとめ TimescaleDB の利用で不満は今のところない sqlc との組み合わせは最高 開発会社が提供するマネージドサービスは最高 なぜ TimescaleDB を採用したのか 統計情報のため込みと集計 自社製品であるミドルウェアパッケージソフトウェアのクラウド版を提供するにあたり、何よりも重視したのは統計情報の提供です。それもサーバーの統計情報ではなく接続単位での接続情報を顧客に提供することです。 自社製品はリアルタイムに音声や映像を配信する製品ということもあり、一定間隔での統計情報の収集が重要になります。ネッ
Debugging Prometheus Memory Usage – blog.dasrecht.net
When you put workloads on Kubernetes, most of your debugging and hunting for errors can quickly escalate into a murder mystery. Not much to a surprise, this was also the case for parts of our Prometheus stack. A few words on Prometheus: Once you start out using Prometheus, it might be a bit cumbersome and high initial investment, but as soon as you gather the data, you will be able to do a lot of
システム管理ツール「Prometheus」が「Prometheus Agent」モードを提供、エッジ環境やIoTなど限られたリソースでも利用可能に
システム管理ツール「Prometheus」が「Prometheus Agent」モードを提供、エッジ環境やIoTなど限られたリソースでも利用可能に Kubernetesをはじめとするクラウドネイティブを実現するオープンソースソフトウェアの開発を推進する「Cloud Native Computing Foundation」は、システム管理ツール「Prometheus」の新機能「Prometheus Agent」モードを発表しました。 Introducing the Prometheus Agent, a new operating mode from the @PrometheusIO team which enables new workflows such as low-resources environments, edge networks, and IoT Read more on
Introducing Google Cloud Managed Service for Prometheus | Google Cloud Blog
Get planet-scale monitoring with Managed Service for Prometheus Editor’s note, March 01, 2022: We are pleased to announce that Managed Service for Prometheus has now reached General Availability! For more information, see our announcement blog or visit the website. Prometheus, the de facto standard for Kubernetes monitoring, works well for many basic deployments, but managing Prometheus infrastruc
10年もののメトリクス収集機構をリプレースした話 | GREE Engineering
インフラのいわほり（@egmc）です。 久々のエントリとなりますが、今回はインフラのMonitoring Unitとして長期的に取り組んでいた監視システムのリプレースについてのお話になります。 背景含めて長いエントリとなりますが、監視システムの長期的な運用の考え方、リプレースにあたって考慮した点などなにがしか参考になる点があれば幸いです。 何を移行したか？ グリーのインフラ環境では冒頭で述べたMonitoring Unitというインフラ横断で監視システムを提供するチームが商用環境向けの共通システムの提供/運用を行っています。 監視システムにおけるリソースモニタリングシステムの構成として、オンプレ環境ではGanglia、AWS環境ではPrometheus/Grafanaスタックを採用、運用してきました。 規模感としてはざっくりと監視対象ノードがオンプレサーバが約1500台、AWS側は台数変動
sysload exporterを実装してみた - ださろぐ@はてな
タイトルままということで。 github.com goでゼロからexporterを書こう、sysloadの実装を今更ながら把握しておこうというモチベーションのもとsysloadをprometheusのexporterとして実装してみました。 dashboard image Dashboardも公開しているの動かして見るぜーという方はこちらもどうぞ。 クエリみて頂ければわかりますが、設計上sysloadの値は単純なgaugeなので既存のノード用ダッシュボードに組み込むのも簡単だとおもいます。 grafana.com sysload is 何 labs.gree.jp 詳細はこちらの記事とgithubレポジトリを参照頂ければとおもいます。 もともとLoad Averageの不具合を起因としてサーバ負荷（システムリソースのsaturation）を0-100で表す指標として開発されたものです。 単
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Michael Hausenblas on Twitter: "Happy to announce that you can now directly request features and share feedback for our observability offerings Ama… https://t.co/yHBUvz48tL"
Prometheus metrics syntax for Vi/Vim/NeoVim
GitHub Prometheus Export
Announcing Query Builder to supercharge your PromQL | Chronosphere
Dynamic alert routing with Prometheus and Alertmanager
Prometheus definitive guide part III - Prometheus operator | Cloud Native Computing Foundation
Release v1.67.0 · VictoriaMetrics/VictoriaMetrics
How we use Grafana and Prometheus to monitor the traffic of our many GitHub repositories | Grafana Labs
Kubernetes Monitoring with Prometheus Workshop
