<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Synthetic-Monitoring on Tarragon</title><link>https://tarrragon.github.io/blog/tags/synthetic-monitoring/</link><description>Recent content in Synthetic-Monitoring on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Wed, 14 Oct 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/synthetic-monitoring/index.xml" rel="self" type="application/rss+xml"/><item><title>Synthetic Monitoring（合成監控）</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/synthetic-monitoring/</link><pubDate>Wed, 14 Oct 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/synthetic-monitoring/</guid><description>&lt;p>合成監控（synthetic monitoring）是以排程主動發出請求、模擬使用者使用服務的監控方式：探測程式每隔一段時間對服務的網址或一段操作流程（登入、查詢、結帳）發請求，記錄成功與否、回應時間與回應內容。請求是人為製造的，所以沒有真實使用者的時段也量得到；它量到的是探測程式走的那一條路徑，探測端放在哪裡決定了量得到哪些故障。它與 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/probe/" data-link-title="Probe" data-link-desc="說明平台如何透過 probe 判斷服務狀態與接流量條件">Probe&lt;/a> 同樣是主動發請求的探測，差別在由誰使用結果：平台用 probe 決定要不要送流量、要不要重啟，合成監控用來回答使用者看到什麼。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>探測端的位置決定它與服務共用哪些依賴。從服務同一台主機、同一個內部網路發出的探測（服務網路內的探測），請求不經過公開的 DNS、公開入口與 TLS 憑證，量得到服務程序卡住與內部路由錯誤，量不到使用者在網際網路上遇到的故障；服務所在的主機停掉時，它跟著停。從服務的 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/failure-domain/" data-link-title="Failure Domain（失效域）" data-link-desc="判斷兩個元件會不會因為同一件事一起停掉、備援或監控是否獨立於被保護的對象時，查它們共用了哪些會失效的依賴">Failure Domain（失效域）&lt;/a> 以外、在使用者連線出發的網路發出的探測，請求解析公開網域、經過 HTTPS 與公開入口，量得到 DNS、憑證與入口的故障。「外部探測」在不同資料裡可以指這兩種位置：服務網路內的探測，「外部」是相對於服務的程序；失效域以外的探測，「外部」是相對於服務的失效域。分辨的依據是探測請求經不經過公開的 DNS、入口與憑證。&lt;/p>
&lt;p>真實使用者監測（RUM，real user monitoring）的資料從使用者端蒐集：在使用者的瀏覽器或 App 裡記錄實際請求的結果與耗時，與合成監控由探測端主動發請求相反。RUM 量的是真實使用者的分布（各地區、各種裝置、各家網路業者），沒有使用者的時段沒有資料；合成監控量的是固定的幾條路徑，任何時段都有資料。兩者回答的問題不同，常一起用。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>合成監控的輸出是每一次探測的結果：成功或失敗、各階段的耗時（DNS 解析、TCP 連線、TLS 握手、等待回應）、狀態碼與回應內容是否符合預期。Prometheus 的 blackbox_exporter 是自架的做法，它對一個目標發一次請求並輸出 &lt;code>probe_success&lt;/code>、&lt;code>probe_http_status_code&lt;/code>、&lt;code>probe_ssl_earliest_cert_expiry&lt;/code>（最早到期的那一張憑證的到期時間）這類指標；Gatus、Uptime Kuma 是附帶儀表板的自架工具；UptimeRobot、Pingdom、Catchpoint 這類服務從業者在各地的探測點發請求。判斷成功只看狀態碼時，入口回一個錯誤頁也可能是 200，比對回應內容裡一段固定字串、或打一個只有服務正常時才回得出內容的端點，判斷才準。&lt;/p>
&lt;h2 id="判讀方式">判讀方式&lt;/h2>
&lt;p>看到一個合成監控的結果時，先查兩件事：探測端在哪裡、它走的是哪一條路徑。探測端與服務在同一台主機或同一個內部網路時，它的「全部正常」只代表服務程序回應正常，不代表使用者連得到。探測打的是會記錄點擊或計費的路徑時，探測請求會灌進服務的統計，要以來源或 User-Agent 排除，或改打不記錄的端點。多個地點同時失敗才通知可以排除單一探測點自己網路的問題，代價是只有某個地區連不進來時不會通知。合成監控在整個監控分層裡的位置見 &lt;a href="https://tarrragon.github.io/blog/backend/04-observability/monitoring-layers/" data-link-title="4.0 服務端監控的分層：容器與程序的自檢、服務網路內的探測、元件指標、應用層訊號、告警規則與分送、告警鏈的監看與使用者路徑的合成監控" data-link-desc="以每一層監控檢查的對象、看不到的範圍與接手的那一層，把服務端監控串成一條監控鏈，以及拿它盤點一個服務時怎麼判讀缺口的性質（檢查範圍、位置、讀取與訊號失真），涵蓋自架主機、Kubernetes 與雲端託管的情形；使用者路徑那一層另寫合成監控與真實使用者監測的差別，以及盤點時各種缺口的補法">4.0 服務端監控的分層&lt;/a>，探測端放在失效域以外的理由與做法見 &lt;a href="https://tarrragon.github.io/blog/backend/04-observability/single-host-monitoring-outside-view/" data-link-title="4.28 單台主機的監控盲區與失效域以外的觀察者：主機停機、使用者路徑中斷與告警鏈中斷，心跳監看與外部探測各自回答的問題與位置，以及與內部探測並排的判讀" data-link-desc="服務與監控放在同一台主機時監控結構上看不到的故障：主機整台停掉、使用者到主機的路徑中斷、告警鏈停掉與通知送不出去；從失效域以外送出訊號的心跳監看與外部探測各自回答的問題與成立條件，觀察者由第三方服務、另一個失效域的主機（含兩台主機互相監看）或另一個業者的排程平台提供時的差別，以及心跳監看、外部探測與主機內部探測並排時的判讀">4.28 單台主機的監控盲區與失效域以外的觀察者&lt;/a> 與 &lt;a href="https://tarrragon.github.io/blog/backend/04-observability/client-side-monitoring/" data-link-title="4.10 Client-side / Synthetic / RUM" data-link-desc="補 server-side 看不到的 user perceived 訊號">4.10 Client-side / Synthetic / RUM&lt;/a> 的〈Synthetic Monitoring〉。&lt;/p></description><content:encoded><![CDATA[<p>合成監控（synthetic monitoring）是以排程主動發出請求、模擬使用者使用服務的監控方式：探測程式每隔一段時間對服務的網址或一段操作流程（登入、查詢、結帳）發請求，記錄成功與否、回應時間與回應內容。請求是人為製造的，所以沒有真實使用者的時段也量得到；它量到的是探測程式走的那一條路徑，探測端放在哪裡決定了量得到哪些故障。它與 <a href="/blog/backend/knowledge-cards/probe/" data-link-title="Probe" data-link-desc="說明平台如何透過 probe 判斷服務狀態與接流量條件">Probe</a> 同樣是主動發請求的探測，差別在由誰使用結果：平台用 probe 決定要不要送流量、要不要重啟，合成監控用來回答使用者看到什麼。</p>
<h2 id="概念位置">概念位置</h2>
<p>探測端的位置決定它與服務共用哪些依賴。從服務同一台主機、同一個內部網路發出的探測（服務網路內的探測），請求不經過公開的 DNS、公開入口與 TLS 憑證，量得到服務程序卡住與內部路由錯誤，量不到使用者在網際網路上遇到的故障；服務所在的主機停掉時，它跟著停。從服務的 <a href="/blog/backend/knowledge-cards/failure-domain/" data-link-title="Failure Domain（失效域）" data-link-desc="判斷兩個元件會不會因為同一件事一起停掉、備援或監控是否獨立於被保護的對象時，查它們共用了哪些會失效的依賴">Failure Domain（失效域）</a> 以外、在使用者連線出發的網路發出的探測，請求解析公開網域、經過 HTTPS 與公開入口，量得到 DNS、憑證與入口的故障。「外部探測」在不同資料裡可以指這兩種位置：服務網路內的探測，「外部」是相對於服務的程序；失效域以外的探測，「外部」是相對於服務的失效域。分辨的依據是探測請求經不經過公開的 DNS、入口與憑證。</p>
<p>真實使用者監測（RUM，real user monitoring）的資料從使用者端蒐集：在使用者的瀏覽器或 App 裡記錄實際請求的結果與耗時，與合成監控由探測端主動發請求相反。RUM 量的是真實使用者的分布（各地區、各種裝置、各家網路業者），沒有使用者的時段沒有資料；合成監控量的是固定的幾條路徑，任何時段都有資料。兩者回答的問題不同，常一起用。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>合成監控的輸出是每一次探測的結果：成功或失敗、各階段的耗時（DNS 解析、TCP 連線、TLS 握手、等待回應）、狀態碼與回應內容是否符合預期。Prometheus 的 blackbox_exporter 是自架的做法，它對一個目標發一次請求並輸出 <code>probe_success</code>、<code>probe_http_status_code</code>、<code>probe_ssl_earliest_cert_expiry</code>（最早到期的那一張憑證的到期時間）這類指標；Gatus、Uptime Kuma 是附帶儀表板的自架工具；UptimeRobot、Pingdom、Catchpoint 這類服務從業者在各地的探測點發請求。判斷成功只看狀態碼時，入口回一個錯誤頁也可能是 200，比對回應內容裡一段固定字串、或打一個只有服務正常時才回得出內容的端點，判斷才準。</p>
<h2 id="判讀方式">判讀方式</h2>
<p>看到一個合成監控的結果時，先查兩件事：探測端在哪裡、它走的是哪一條路徑。探測端與服務在同一台主機或同一個內部網路時，它的「全部正常」只代表服務程序回應正常，不代表使用者連得到。探測打的是會記錄點擊或計費的路徑時，探測請求會灌進服務的統計，要以來源或 User-Agent 排除，或改打不記錄的端點。多個地點同時失敗才通知可以排除單一探測點自己網路的問題，代價是只有某個地區連不進來時不會通知。合成監控在整個監控分層裡的位置見 <a href="/blog/backend/04-observability/monitoring-layers/" data-link-title="4.0 服務端監控的分層：容器與程序的自檢、服務網路內的探測、元件指標、應用層訊號、告警規則與分送、告警鏈的監看與使用者路徑的合成監控" data-link-desc="以每一層監控檢查的對象、看不到的範圍與接手的那一層，把服務端監控串成一條監控鏈，以及拿它盤點一個服務時怎麼判讀缺口的性質（檢查範圍、位置、讀取與訊號失真），涵蓋自架主機、Kubernetes 與雲端託管的情形；使用者路徑那一層另寫合成監控與真實使用者監測的差別，以及盤點時各種缺口的補法">4.0 服務端監控的分層</a>，探測端放在失效域以外的理由與做法見 <a href="/blog/backend/04-observability/single-host-monitoring-outside-view/" data-link-title="4.28 單台主機的監控盲區與失效域以外的觀察者：主機停機、使用者路徑中斷與告警鏈中斷，心跳監看與外部探測各自回答的問題與位置，以及與內部探測並排的判讀" data-link-desc="服務與監控放在同一台主機時監控結構上看不到的故障：主機整台停掉、使用者到主機的路徑中斷、告警鏈停掉與通知送不出去；從失效域以外送出訊號的心跳監看與外部探測各自回答的問題與成立條件，觀察者由第三方服務、另一個失效域的主機（含兩台主機互相監看）或另一個業者的排程平台提供時的差別，以及心跳監看、外部探測與主機內部探測並排時的判讀">4.28 單台主機的監控盲區與失效域以外的觀察者</a> 與 <a href="/blog/backend/04-observability/client-side-monitoring/" data-link-title="4.10 Client-side / Synthetic / RUM" data-link-desc="補 server-side 看不到的 user perceived 訊號">4.10 Client-side / Synthetic / RUM</a> 的〈Synthetic Monitoring〉。</p>
]]></content:encoded></item></channel></rss>