<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Monitoring on Margrop Blog</title>
    <link>https://blog.margrop.net/en/tag/monitoring/</link>
    <description>Recent content in Monitoring on Margrop Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <lastBuildDate>Sun, 24 May 2026 08:10:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/en/tag/monitoring/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Do Not Waste Your Codex Quota Before the Reset: Meet Codex Reset Radar</title>
      <link>https://blog.margrop.net/en/post/codex-reset-radar-quota-reset-guide/</link>
      <pubDate>Sun, 24 May 2026 08:10:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/codex-reset-radar-quota-reset-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;The short version&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Codex resets have recently become more important to watch. Sometimes the reset is part of the normal usage cycle. Sometimes it is a compensation reset after an incident. Sometimes it follows a fix for abnormal limit consumption. For heavy Codex users, the painful part is not that the quota resets. The painful part is discovering that you still had useful weekly quota left, but you did not use it before the reset overwrote the old window.&lt;/p&gt;&#xA;&lt;p&gt;&lt;code&gt;Codex Reset Radar&lt;/code&gt; is a small public dashboard that turns scattered public signals into a practical warning: if a Codex quota reset window is likely or already open, it tells you to use your remaining weekly quota on valuable work before it expires.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;This article discusses only public pages, public status signals, and public references. It does not include private accounts, tokens, internal systems, private network details, or personal usage data. Any discussion of quota, reset windows, and early warnings is a user-side workflow analysis, not an official statement about OpenAI billing, subscription policy, or service guarantees.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Adding Proxmox VE local-lvm Usage and Link-Speed Monitoring to Uptime Kuma</title>
      <link>https://blog.margrop.net/en/post/proxmoxve-lvm-link-speed-uptime-kuma/</link>
      <pubDate>Tue, 05 May 2026 17:20:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/proxmoxve-lvm-link-speed-uptime-kuma/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;Short version&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Proxmox VE &lt;code&gt;local-lvm&lt;/code&gt; is usually an LVM-thin pool, not a normal mounted directory, so &lt;code&gt;df -h&lt;/code&gt; is not enough to catch it before it becomes full. Network link speed is another quiet failure mode: services may stay online while a NAS or router uplink falls back to 100 Mb/s and turns large file transfers into a crawl. A practical fix is to feed both checks into the Uptime Kuma you already use: expose a small HTTP health endpoint for &lt;code&gt;local-lvm&lt;/code&gt;, and push link-speed status from the Proxmox host with an &lt;code&gt;ethtool&lt;/code&gt; script.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;This article walks through the design, the problems in a naive implementation, improved scripts, systemd units, Uptime Kuma configuration, verification steps, and safety notes. All addresses, tokens, host names, and environment-specific values are placeholders. Replace &lt;code&gt;&amp;lt;PVE_HOST&amp;gt;&lt;/code&gt;, &lt;code&gt;&amp;lt;KUMA_URL&amp;gt;&lt;/code&gt;, &lt;code&gt;&amp;lt;PUSH_TOKEN&amp;gt;&lt;/code&gt;, and &lt;code&gt;&amp;lt;INTERFACE&amp;gt;&lt;/code&gt; with values from your own environment.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
