Lambda + CloudWatch:監控你的工業感測器數據管線健康度
工廠IT技術人員專用AWS CloudWatch資料管線監控ATLANTIS 自有品牌
Lambda + CloudWatch:監控你的工業感測器數據管線健康度
「Re-Atlantis」的品牌精神,是重現古代理想文明對精密秩序的追求——而真正的秩序,不只是系統運作正常時的精準,更是系統本身出問題時,你能立刻察覺。過去工廠依賴人工巡檢確認儀錶是否正常運作,如今我們同樣需要一套機制,確認雲端監控系統本身是否「還活著」。詳見 ATLANTIS 品牌故事。
一、「監控監控系統」:為什麼這是最容易被忽略的一環?
在第二篇的案例分享中,我們提到「打通雲端不是終點,而是持續驗證的開始」。到了本系列第八篇,這句話要進一步延伸:持續驗證,不能只靠工程師偶爾打開主控台檢查,而必須是系統自動化的一部分。
系統卻沒有任何錯誤訊息
核心監控指標類別
業務邏輯層級的數據
提供單一檢視畫面
什麼是「沉默故障」?
與第五篇討論的「溫度異常告警」不同,本篇要處理的是另一種更難察覺的問題:當感測器、閘道器或網路故障導致資料完全停止送達時,系統本身不會產生任何「錯誤」——因為根本沒有資料可以判斷異常。Lambda不會被觸發、規則引擎不會有訊息通過、CloudWatch日誌一片空白,一切看起來「風平浪靜」,但實際上監控系統早已失效多時。這種故障,我們稱為「沉默故障(Silent Failure)」,也是本篇要重點解決的問題。
二、架構總覽:從服務原生指標到自訂心跳監控
整條架構分成兩層:上半部是各AWS服務「原生提供」的監控指標(IoT Core、Lambda、DynamoDB各自的執行狀態),下半部則是我們額外建立的「自訂心跳監控」——用一個排程執行的Lambda函式,定期檢查每個裝置最後一次回報數據的時間,這正是偵測「沉默故障」的關鍵機制。
三、各服務的核心原生監控指標
在建立自訂監控之前,先了解每個AWS服務已經內建提供哪些指標,這些指標不需要額外撰寫程式碼,只需要在CloudWatch設定對應的警報即可使用。
| 服務 | 關鍵指標 | 代表意義 |
|---|---|---|
| AWS IoT Core | PublishIn.Success | 成功接收的MQTT發布訊息數量 |
| AWS IoT Core | RuleMessageThrottled | 因超出配額而被節流的規則觸發次數 |
| AWS Lambda | Invocations | 函式被呼叫的總次數 |
| AWS Lambda | Errors | 函式執行時拋出例外的次數 |
| AWS Lambda | Duration | 函式執行所需時間,可用於偵測效能異常 |
| AWS Lambda | Throttles | 因併發限制而被節流的呼叫次數 |
| DynamoDB | ConsumedWriteCapacityUnits | 實際消耗的寫入容量 |
| DynamoDB | ThrottledRequests | 因超出容量而被節流的請求次數 |
| Amazon SNS | NumberOfNotificationsFailed | 通知發送失敗的次數 |
對工廠IT技術人員而言,最需要優先設定警報的三個指標是:Lambda的Errors(函式本身壞了)、DynamoDB的ThrottledRequests(寫入被拒絕,資料可能遺失)、以及IoT Core的RuleMessageThrottled(規則引擎處理不過來)——這三者都代表管線的某個環節正在「悄悄地」出問題。
四、自訂心跳監控:偵測「感測器停止回報」的沉默故障
前一節的原生指標,只能反映「已經抵達雲端的訊息」的處理狀況,卻無法回答一個關鍵問題:「某支感測器已經多久沒有送資料上來了?」這需要額外建立自訂邏輯,以下範例延續第六篇的DynamoDB歷史記錄,用一個排程執行的Lambda函式檢查每個裝置的最後回報時間。
範例一:排程檢查裝置心跳,寫入自訂CloudWatch指標
import boto3
from boto3.dynamodb.conditions import Key
dynamodb = boto3.resource("dynamodb", region_name="ap-northeast-1")
table = dynamodb.Table("factory_temperature_history")
cloudwatch = boto3.client("cloudwatch", region_name="ap-northeast-1")
MONITORED_DEVICES = ["ATL-STT-001", "ATL-STT-002", "ATL-SDPT-001"]
def get_last_timestamp(device_id: str):
response = table.query(
KeyConditionExpression=Key("device_id").eq(device_id),
ScanIndexForward=False, # 依timestamp倒序,取得最新一筆
Limit=1
)
items = response.get("Items", [])
return int(items[0]["timestamp"]) if items else None
def lambda_handler(event, context):
now = int(time.time())
for device_id in MONITORED_DEVICES:
last_ts = get_last_timestamp(device_id)
if last_ts is None:
minutes_since_last_data = 99999 # 從未收過資料
else:
minutes_since_last_data = (now - last_ts) / 60
cloudwatch.put_metric_data(
Namespace="ATLANTIS/FactoryIoT",
MetricData=[
{
"MetricName": "MinutesSinceLastData",
"Dimensions": [{"Name": "DeviceId", "Value": device_id}],
"Value": minutes_since_last_data,
"Unit": "None"
}
]
)
print(f"裝置 {device_id}:距上次回報 {minutes_since_last_data:.1f} 分鐘")
return {"statusCode": 200, "body": "心跳檢查完成"}
這個函式需要搭配Amazon EventBridge排程規則,設定每5或10分鐘自動觸發一次(就像第五篇文章使用IoT Core規則觸發Lambda一樣,這裡改用時間排程觸發)。每次執行都會為每個受監控裝置寫入一個自訂指標MinutesSinceLastData,記錄「距離上次收到資料已經過了幾分鐘」。
在CloudWatch設定警報:資料超過15分鐘未更新就通知
有了這個自訂指標後,就可以在CloudWatch Alarm設定「當MinutesSinceLastData超過15分鐘時觸發警報,並將警報動作指向第五篇建立的SNS主題」——如此一來,即使沒有任何一筆訊息抵達,系統依然能主動告訴你「有裝置已經沉默太久」,這正是解決沉默故障問題的核心機制。
五、CloudWatch Dashboard:把所有服務指標彙整到一個畫面
當監控的服務項目增加,工廠IT技術人員不會想在Lambda、IoT Core、DynamoDB、SNS各自的主控台頁面之間切換查看狀態。CloudWatch Dashboard可以把來自不同服務的指標彙整到單一畫面。
Dashboard小工具(Widget)設定範例(JSON)
"widgets": [
{
"type": "metric",
"properties": {
"title": "Lambda執行錯誤次數",
"metrics": [
["AWS/Lambda", "Errors", "FunctionName", "temperature-alert-handler"]
],
"period": 300,
"stat": "Sum"
}
},
{
"type": "metric",
"properties": {
"title": "各裝置距上次回報分鐘數",
"metrics": [
["ATLANTIS/FactoryIoT", "MinutesSinceLastData", "DeviceId", "ATL-STT-001"]
],
"period": 300,
"stat": "Maximum"
}
}
]
}
你可以把不同服務的原生指標(如Lambda的Errors)與我們自訂的MinutesSinceLastData指標,一起放進同一個Dashboard,讓值班人員每天早上花30秒瀏覽一次,就能掌握整條資料管線前一晚的健康狀況。
六、建議的告警檢查清單:工廠IoT管線至少該監控這幾項
| 監控項目 | 建議門檻 | 對應的問題類型 |
|---|---|---|
| Lambda Errors(解析/告警函式) | 5分鐘內超過3次即告警 | 程式邏輯錯誤、資料格式異常 |
| Lambda Duration接近逾時上限 | 執行時間超過逾時設定的80% | 下游服務延遲、程式效能問題 |
| DynamoDB ThrottledRequests | 任何非零值即告警 | 容量不足、寫入被拒絕導致資料遺失 |
| IoT Core RuleMessageThrottled | 任何非零值即告警 | 規則引擎處理量超出帳號配額 |
| 自訂MinutesSinceLastData | 超過裝置預期回報間隔的3倍 | 感測器、閘道器或網路的沉默故障 |
| SNS NumberOfNotificationsFailed | 任何非零值即告警(透過Email備援通知) | 簡訊/Email通知本身發送失敗 |
特別提醒最後一項:如果連告警通知本身的發送都失敗了,你需要一個「備援」的告知管道,例如同時設定Email訂閱作為SMS失敗時的備援,避免整個告警系統的最後一哩路本身出問題卻無人知曉。
七、ATLANTIS 適合建立長期穩定監控基準的量測產品

DPT-A 空氣用差壓傳送器 —— 高靈敏矽壓阻晶片設計,穩定輸出4-20mA標準訊號,適合作為長期心跳監控的可信賴資料來源

AT-THM80系列 高精度工業溫濕度傳送器 —— 三種安裝方式可選,適用於半導體無塵室與工業製程監控,長期穩定運作降低誤報率

ATM-DC5H-TC 5位數微電腦型熱電偶溫度顯示控制錶 —— 適合中高溫測量的耐候型設計,本地顯示與雲端心跳監控雙軌並行

DVC-X008 數位負壓控制器 —— 集負壓測量、顯示、控制於一體,適合搭配CloudWatch自訂指標監控真空系統的長期穩定運作狀態
完整規格請參考 ATLANTIS 產品型錄與工業4.0壓力感測器整合指南。
八、案例分享:某高雄石化廠周邊設備的沉默故障事件
以下案例經匿名化處理,客戶為高雄一家石化廠周邊設備供應商,曾發生過一次典型的沉默故障事件,促成後續導入本篇的心跳監控機制。
| 事件時間軸 | 發生狀況 | 發現方式 | 影響 |
|---|---|---|---|
| 故障發生 | 現場Modbus閘道器因電源不穩定當機 | 無 | 該產線8支感測器全部停止回報數據 |
| 故障後6小時 | 雲端監控系統CloudWatch日誌完全靜默,Lambda無任何錯誤記錄(因為根本沒有訊息觸發) | 工程師例行檢查儀表板才發現數據曲線是平的 | 期間該產線異常事件完全未被偵測 |
| 導入心跳監控後 | 模擬同樣的閘道器斷電情境 | 自訂指標MinutesSinceLastData在15分鐘後觸發告警,SNS簡訊立即通知 | 故障發現時間從6小時縮短至15分鐘內 |
資深工程師賴祥德分享:「這個案例讓客戶印象深刻的地方在於:雲端監控系統本身『表面上』完全正常運作,CloudWatch日誌乾乾淨淨、沒有任何錯誤,但實際上整條資料管線早就斷了。這正是為什麼我們常說,好的監控系統不能只監控『有資料時的異常』,更要監控『沒有資料』這件事本身。」
資料來源與延伸閱讀
本文技術架構參考 AWS CloudWatch 官方文件(docs.aws.amazon.com/cloudwatch)、AWS Lambda與DynamoDB各自的CloudWatch整合指標官方說明。自訂指標與Dashboard設定方式請以AWS官網最新文件為準。ATLANTIS產品技術規格引用自內部產品規格書。
十、20 大常見問題 FAQ(Lambda + CloudWatch 管線監控)
1. 什麼是「沉默故障」,跟一般的系統錯誤有什麼不同?
2. put_metric_data()寫入自訂指標需要授權嗎?
cloudwatch:PutMetricData動作,這是一個帳號層級的動作,通常不需要限定特定資源範圍,但仍建議遵循最小權限原則僅授權必要的動作。3. EventBridge排程規則和IoT Core規則有什麼不同?
4. 心跳監控的檢查頻率該設多久?
5. 為什麼要監控Lambda的Duration(執行時間)?
6. DynamoDB的ThrottledRequests出現,代表資料一定遺失了嗎?
7. CloudWatch Dashboard會產生額外費用嗎?
8. 我可以監控多個裝置的心跳,而不需要為每個裝置寫重複程式碼嗎?
MONITORED_DEVICES清單中維護裝置ID,程式邏輯會自動迭代檢查每一個裝置,新增裝置只需要在清單中新增一筆設定。9. CloudWatch Alarm可以同時通知SNS和觸發另一個Lambda嗎?
10. 我該監控原始IoT Core指標,還是自訂心跳指標就足夠了?
11. Alarm的「評估週期」和「資料點數量」該怎麼設定?
12. 自訂指標的Namespace命名有什麼建議?
ATLANTIS/FactoryIoT),方便與AWS原生服務的指標(如AWS/Lambda)區分,也便於未來擴充其他自訂指標時維持一致的命名慣例。13. 如果心跳監控的Lambda函式自己故障了,誰來監控它?
Errors與Invocations指標,並設定「若在預期時間內完全沒有被呼叫」的告警,這是一種簡單的「監控監控者」的做法,但需注意避免過度複雜化監控鏈本身。14. CloudWatch Logs Insights可以用來做什麼?
15. 監控指標的資料保留多久?
16. 我可以用CloudWatch取代DynamoDB做歷史數據儲存嗎?
17. 告警觸發後,CloudWatch會自動嘗試修復問題嗎?
18. 我需要對每一支感測器都個別設定心跳監控嗎?
19. 心跳監控的邏輯,可以套用在第五篇的告警抑制機制上嗎?
20. 學會管線健康度監控後,這系列文章接下來還有什麼主題?
十一、下一步:讓 ATLANTIS 協助你打造真正可信賴的雲端監控管線
31年工業儀錶製造經驗 × 長期穩定運作的量測產品線
從變送器選型、資料回報頻率規劃,到CloudWatch心跳監控與告警檢查清單設計,我們可以陪工廠IT團隊打造真正不怕沉默故障的雲端監控架構。
📞 02-2820-3405 免費選型諮詢 📧 線上快速詢價
業務一部 Ian:ian@atlantis.com.tw | 業務二部 Nori:nori@atlantis.com.tw
文章更新時間:2026年7月|作者:ATLANTIS 應用工程團隊|本文為系列教學文章第八篇,下一篇將深入「用API Gateway + Lambda打造溫度數據查詢REST API,串接工廠儀表板」。