プロジェクト

全般

プロフィール

機能 #153

完了

機能 #372: romi の撤収

監視サービスを VPS から自宅クラスタへ持ってくる

nop_thread さんが約1年前に追加. 10ヶ月前に更新.

ステータス:
終了
優先度:
通常
担当者:
開始日:
期日:
進捗率:

100%

一時中断:
いいえ
pinned:
いいえ
リマインド予定日:
前回確認日:
2024/05/26
管理外残件あり:

説明

Prometheus, Thanos, Grafana の3つを現状だと VPS で動かしており、オブジェクトストレージも外部のものを使っている。
しかしこれらは特に一般へのアクセス開放を想定しておらず、またオブジェクトストレージも自宅のものを使う方が安上がりであるため、 chuable へ持ってくることを検討する。

nop_thread さんが約1年前に更新

もともと VPS に置いていたのは、各種 VPS のメトリクスへ頻繁にアクセスし続けるのと外部のオブジェクトストレージへアクセスし続けるので自宅のネットワーク帯域を使いたくなかったのと、自宅クラスタがダウンしたときに生きてアラートを投げてほしいという理由からだった。

前者については、今や自宅に minio サーバがあることでインターネット帯域を使う必要がなくなった。
メトリクスのフェッチについても、現状では自宅から VPS へプルしていたのが VPS から自宅へプルするようになるだけなのであまり影響はない。
むしろ VPS ノードを減らしており自宅サーバ (仮想マシン、コンテナ、アプリ含む) 由来のメトリクスが増える見込みのある今となっては、むしろ自宅内で多くが完結する方がインターネット帯域の消費には貢献するだろう。

後者、アラートについても、 Grafana から投げることは難しくなるかもしれないが、そもそも VPS からは自宅クラスタへの到達性だけを気にしていればよく、自宅クラスタがオンラインでさえあれば後は自宅から適切なアラートを発信できるはずである。
(たとえば ntfy と Uptime Kuma だけを VPS に置いておくなどはありだろう。)

以上のことから、現行の構成と将来の計画・予測から考えれば、サーバ監視サービス群を VPS に置いておく意味はもはやなく、自宅クラスタに収容するのがコスト面で妥当といえる。

nop_thread さんが約1年前に更新

オブジェクトストレージに Wasabi を使っており、 compaction のせいで deleted が異常に膨らんでいるので非常によろしくない。
これを自宅にもってくると、おおよそ ¥1k/mo 程度の出費抑制が見込める。たぶん。

nop_thread さんが約1年前に更新

  • 優先度通常 から 高め に変更

nop_thread さんが約1年前に更新

  • ステータス新規 から 進行中 に変更

Grafana は chuable に持ってきた。
問題なく動いている。

Prometheus と Thanos についてはオブジェクトストレージをどうするか思案中。
ひとまず外部サービスを使った状態のまま移行するのが良いか。

nop_thread さんが10ヶ月前に更新

  • pinnedいいえ から はい に変更
  • 前回確認日2024/05/26 にセット

機能 #345: Prometheus と Thanos のサーバを立てる で Prometheus, Thanos, Grafana を立てたので、移行可能。

nop_thread さんが10ヶ月前に更新

  • 親チケット#372 にセット

nop_thread さんが10ヶ月前に更新

  • ステータス進行中 から 終了 に変更
  • 優先度高め から 通常 に変更
  • 進捗率0 から 100 に変更
  • pinnedはい から いいえ に変更

powermeter を nukobu ドメインから提供し、同じく nukobu の Prometheus から scrape できていることを確認した。
smartmeter はハードウェアの問題 (#335) で利用不可、 thermohygrometer はそもそも Bluetooth が不安定でどうにかする必要があることから一旦運用停止とする。

以上で非自明な監視対象はすべて移行完了とする。
node exporter や新規対象はそのうち気が向いたときにでも。

他の形式にエクスポート: Atom PDF