移至主內容

Lambda + CloudWatch:監控你的工業感測器數據管線健康度

工廠IT技術人員專用AWS CloudWatch資料管線監控ATLANTIS 自有品牌

Lambda + CloudWatch:監控你的工業感測器數據管線健康度

台灣31年工業儀錶製造商 ATLANTIS 昶特有限公司系列教學文章第八篇:前七篇我們建立了完整的資料管線——發布、訂閱、Lambda運算、封包解析、SNS告警、DynamoDB歷史記錄與規則引擎多動作路由。但一個關鍵問題還沒解決:如果這整條管線本身「靜靜地」故障了,你怎麼會知道?本篇教你用CloudWatch監控管線本身的健康度,包含偵測「感測器停止回報數據」這種最容易被忽略的沉默故障。

「Re-Atlantis」的品牌精神,是重現古代理想文明對精密秩序的追求——而真正的秩序,不只是系統運作正常時的精準,更是系統本身出問題時,你能立刻察覺。過去工廠依賴人工巡檢確認儀錶是否正常運作,如今我們同樣需要一套機制,確認雲端監控系統本身是否「還活著」。詳見 ATLANTIS 品牌故事

一、「監控監控系統」:為什麼這是最容易被忽略的一環?

第二篇的案例分享中,我們提到「打通雲端不是終點,而是持續驗證的開始」。到了本系列第八篇,這句話要進一步延伸:持續驗證,不能只靠工程師偶爾打開主控台檢查,而必須是系統自動化的一部分

沉默故障
感測器停止回報
系統卻沒有任何錯誤訊息
4種
貫穿整條管線的
核心監控指標類別
自訂指標
CloudWatch可記錄
業務邏輯層級的數據
1個儀表板
彙整所有服務指標
提供單一檢視畫面

什麼是「沉默故障」?

與第五篇討論的「溫度異常告警」不同,本篇要處理的是另一種更難察覺的問題:當感測器、閘道器或網路故障導致資料完全停止送達時,系統本身不會產生任何「錯誤」——因為根本沒有資料可以判斷異常。Lambda不會被觸發、規則引擎不會有訊息通過、CloudWatch日誌一片空白,一切看起來「風平浪靜」,但實際上監控系統早已失效多時。這種故障,我們稱為「沉默故障(Silent Failure)」,也是本篇要重點解決的問題。

二、架構總覽:從服務原生指標到自訂心跳監控

IoT Core 原生連線/訊息指標 Lambda 原生錯誤/執行時間指標 DynamoDB 原生容量/節流指標 CloudWatch Metrics彙整 Logs集中儲存 Alarm 門檻觸發告警 Dashboard 單一檢視畫面 SNS通知 值班工程師 排程Lambda:定期檢查DynamoDB最後回報時間,寫入自訂心跳指標

整條架構分成兩層:上半部是各AWS服務「原生提供」的監控指標(IoT Core、Lambda、DynamoDB各自的執行狀態),下半部則是我們額外建立的「自訂心跳監控」——用一個排程執行的Lambda函式,定期檢查每個裝置最後一次回報數據的時間,這正是偵測「沉默故障」的關鍵機制。

三、各服務的核心原生監控指標

在建立自訂監控之前,先了解每個AWS服務已經內建提供哪些指標,這些指標不需要額外撰寫程式碼,只需要在CloudWatch設定對應的警報即可使用。

服務關鍵指標代表意義
AWS IoT CorePublishIn.Success成功接收的MQTT發布訊息數量
AWS IoT CoreRuleMessageThrottled因超出配額而被節流的規則觸發次數
AWS LambdaInvocations函式被呼叫的總次數
AWS LambdaErrors函式執行時拋出例外的次數
AWS LambdaDuration函式執行所需時間,可用於偵測效能異常
AWS LambdaThrottles因併發限制而被節流的呼叫次數
DynamoDBConsumedWriteCapacityUnits實際消耗的寫入容量
DynamoDBThrottledRequests因超出容量而被節流的請求次數
Amazon SNSNumberOfNotificationsFailed通知發送失敗的次數

對工廠IT技術人員而言,最需要優先設定警報的三個指標是:Lambda的Errors(函式本身壞了)、DynamoDB的ThrottledRequests(寫入被拒絕,資料可能遺失)、以及IoT Core的RuleMessageThrottled(規則引擎處理不過來)——這三者都代表管線的某個環節正在「悄悄地」出問題。

四、自訂心跳監控:偵測「感測器停止回報」的沉默故障

前一節的原生指標,只能反映「已經抵達雲端的訊息」的處理狀況,卻無法回答一個關鍵問題:「某支感測器已經多久沒有送資料上來了?」這需要額外建立自訂邏輯,以下範例延續第六篇的DynamoDB歷史記錄,用一個排程執行的Lambda函式檢查每個裝置的最後回報時間。

範例一:排程檢查裝置心跳,寫入自訂CloudWatch指標

import time
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 空氣用差壓傳送器

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

AT-THM80系列 高精度工業溫濕度傳送器

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

ATM-DC5H-TC 5位數微電腦型熱電偶溫度顯示控制錶

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

DVC-X008 數位負壓控制器

DVC-X008 數位負壓控制器 —— 集負壓測量、顯示、控制於一體,適合搭配CloudWatch自訂指標監控真空系統的長期穩定運作狀態

八、案例分享:某高雄石化廠周邊設備的沉默故障事件

以下案例經匿名化處理,客戶為高雄一家石化廠周邊設備供應商,曾發生過一次典型的沉默故障事件,促成後續導入本篇的心跳監控機制。

事件時間軸發生狀況發現方式影響
故障發生現場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()寫入自訂指標需要授權嗎?
需要,Lambda執行角色需要授權cloudwatch:PutMetricData動作,這是一個帳號層級的動作,通常不需要限定特定資源範圍,但仍建議遵循最小權限原則僅授權必要的動作。
3. EventBridge排程規則和IoT Core規則有什麼不同?
IoT Core規則是「事件驅動」,由MQTT訊息抵達觸發;EventBridge排程規則是「時間驅動」,依照設定的時間間隔(如每5分鐘)定期觸發,本篇的心跳檢查函式適合用EventBridge排程觸發,而非等待訊息抵達。
4. 心跳監控的檢查頻率該設多久?
建議略短於裝置正常回報間隔的一半,例如裝置每30秒回報一次,心跳檢查可設定每5分鐘執行一次,並將告警門檻設為正常回報間隔的3倍左右(如15分鐘),在及時發現異常與避免誤報之間取得平衡。
5. 為什麼要監控Lambda的Duration(執行時間)?
執行時間逐漸增加可能反映下游服務(如DynamoDB)回應變慢,或程式邏輯效能劣化,及早發現這類趨勢可以在函式真正逾時失敗前介入排查,避免演變成更嚴重的問題。
6. DynamoDB的ThrottledRequests出現,代表資料一定遺失了嗎?
若程式端有妥善的重試機制,被節流的請求可能在重試後成功寫入而不會遺失;但若沒有重試邏輯,被拒絕的寫入請求就會直接遺失,這也是為什麼建議監控此指標並搭配應用層重試設計。
7. CloudWatch Dashboard會產生額外費用嗎?
CloudWatch對Dashboard數量與自訂指標數量有相應計費,且有一定免費額度,實際費率請查閱AWS官方定價頁面,一般工廠監控規模通常費用有限。
8. 我可以監控多個裝置的心跳,而不需要為每個裝置寫重複程式碼嗎?
可以,如本文範例一所示,只需在MONITORED_DEVICES清單中維護裝置ID,程式邏輯會自動迭代檢查每一個裝置,新增裝置只需要在清單中新增一筆設定。
9. CloudWatch Alarm可以同時通知SNS和觸發另一個Lambda嗎?
可以,CloudWatch Alarm的動作設定支援多種目的地,包括SNS通知、Auto Scaling動作或透過SNS再轉發至Lambda做進一步自動化處理,可依需求組合設定。
10. 我該監控原始IoT Core指標,還是自訂心跳指標就足夠了?
建議兩者並行,原生指標能反映「已抵達訊息」的處理狀況(如是否被節流),自訂心跳指標則能反映「訊息是否根本沒有抵達」,兩者互補才能涵蓋管線的完整健康狀況。
11. Alarm的「評估週期」和「資料點數量」該怎麼設定?
建議依指標特性調整,例如錯誤類指標可設定「1個評估週期內任何非零值即觸發」以求即時性;心跳類指標則可設定「連續2~3個週期都超過門檻才觸發」,避免單一次的短暫延遲造成誤報。
12. 自訂指標的Namespace命名有什麼建議?
建議使用具識別性的命名空間(如本文範例的ATLANTIS/FactoryIoT),方便與AWS原生服務的指標(如AWS/Lambda)區分,也便於未來擴充其他自訂指標時維持一致的命名慣例。
13. 如果心跳監控的Lambda函式自己故障了,誰來監控它?
可以額外監控該Lambda函式自身的原生ErrorsInvocations指標,並設定「若在預期時間內完全沒有被呼叫」的告警,這是一種簡單的「監控監控者」的做法,但需注意避免過度複雜化監控鏈本身。
14. CloudWatch Logs Insights可以用來做什麼?
Logs Insights提供類SQL的查詢語法,可以對大量CloudWatch日誌進行篩選、聚合與分析,適合用於排查特定時間範圍內某類錯誤的發生頻率或模式,是進階除錯的實用工具。
15. 監控指標的資料保留多久?
CloudWatch對不同解析度的指標資料有不同的預設保留期限(較細顆粒度的資料保留較短時間,較粗顆粒度的資料保留較長時間),實際保留規則請查閱AWS官方文件,長期趨勢分析建議額外將關鍵指標匯出保存。
16. 我可以用CloudWatch取代DynamoDB做歷史數據儲存嗎?
不建議,CloudWatch主要設計用於監控指標與日誌,不適合作為業務資料的主要儲存系統;歷史感測器數據仍應如第六篇所述存入DynamoDB或S3,CloudWatch僅用於監控管線本身的運作狀態。
17. 告警觸發後,CloudWatch會自動嘗試修復問題嗎?
不會,CloudWatch Alarm本身只負責偵測與通知,若需要自動修復(如自動重啟某個服務或重試失敗的操作),需要另外透過Lambda或其他自動化工具實作對應的修復邏輯並由Alarm觸發。
18. 我需要對每一支感測器都個別設定心跳監控嗎?
不一定,可依重要性分級,關鍵製程的感測器建議個別監控,次要或備援用途的感測器則可考慮聚合監控(如監控某產線是否有任何裝置超過心跳門檻),依實際治理需求權衡監控的顆粒度與維護成本。
19. 心跳監控的邏輯,可以套用在第五篇的告警抑制機制上嗎?
可以互相搭配,心跳監控解決「完全沒資料」的問題,第五篇與第六篇提到的狀態變化觸發則解決「資料異常但重複告警」的問題,兩者是資料管線健康度的不同面向,建議一併納入完整的監控設計。
20. 學會管線健康度監控後,這系列文章接下來還有什麼主題?
建議接續學習如何用API Gateway搭配Lambda,把DynamoDB中累積的歷史數據包裝成REST API,供工廠儀表板查詢使用,這是本系列文章後續篇章的主題,也是把整條資料管線價值真正呈現給使用者的最後一步。

十一、下一步:讓 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,串接工廠儀表板」。