VectorA lightweight, ultra-fast tool for building observability pipelines
O11y実践の話で盛り上がりたい
Dress Code Advent Calendar 2025 の 13 日目の記事です。 遅刻です。 TL;DR はじめに：この記事で伝えたいこと この記事では、O11y / SREの一般論や文化論はあんまりしません。 「実務で障害調査が進まない理由」と「どう計装設計に落とすか」 を、デバイス棚卸しレポートのドメインイベントを題材に、具体的な設計・実装パターンとして書きます。 なお、内容は試行錯誤中のものとなっています。 この記事のゴール 「計装を始める上で最初に整理するべきもの」と「実装パターン」など具体的な話で盛り上がりたい 前提：プラットフォームとドメインの二層構造 本記事で扱うシステムは、以下のような構造を持っています： プラットフォーム層：ワークフロー実行、タスク管理、状態遷移を司る共通基盤 ドメイン層：デバイス棚卸し、入社手続きなど、業務固有のロジック この二層構造が、後述す
OSS監視ツール徹底比較【2025年版】：あなたの環境に最適な選択はどれか - Qiita
これにより、柔軟なクエリとアグリゲーションが可能になります。 強み 1. Kubernetes / マイクロサービスへの最適化 ネイティブ統合: Kubernetes環境では、PodやServiceの自動検出が可能 動的環境対応: コンテナの追加・削除に自動で対応 高カーディナリティ: 大量のラベルを持つメトリクスを効率的に処理 2. 強力なクエリ言語（PromQL） PromQL（Prometheus Query Language）により、複雑な集計・分析が可能： 3. 豊富なExporterエコシステム 公式Exporter: Node Exporter、Blackbox Exporter、HAProxy Exporter等 サードパーティ: MySQL、PostgreSQL、Redis、Nginxなど、あらゆるミドルウェアに対応 カスタムExporter: 独自アプリケーションのメト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ClickStack: High-Performance Open-Source Observability | Logs, Metrics, Traces with ClickHouse
