8月13日，我發布了一篇「工具星期四」文章，指導大家如何將Telegram Bot API警報設定為代理的語音功能。我仍然堅持文章中的設定說明。但我不再堅持我在說明下方寫的那句話：
“「關鍵不在於那些綠色的勾號，而在於那些紅色的叉號。一個在你口袋裡幾秒鐘內就發出警報並失敗的代理，就是一個你可以完全忽略的代理。”
今天早上我統計了一下我自己的堆疊發送的紅色 X 的數量。自 6 月 12 日以來，已完成 1565 次計畫運行。, 66次跑步都以失敗告終，其中只有1次是這麼告訴我的。.
頻道沒壞。. Telegram Bot API 警報 他們一直在為成功而努力。而失敗者則是悄無聲息地離開，與先前的承諾截然相反。以下是我發現這一點的過程，包括我最初的評估出現錯誤的部分。.
首先，好消息是：Telegram Bot API 警報仍然正常發送。
8 月的版本仍然有效。訊息 @BotFather, 取得令牌，透過 POST 請求發送至 sendMessage 每次運行結束時都會執行此操作。它是免費的，無需 SDK，而且只有三行程式碼。 捲曲. 以下內容並非反對該工具的論點。.
但我需要知道它是否真的有效，而這卻是一個相當尷尬的問題。. Bot API 沒有「訊息已發送」端點。. 我打了電話 取得聊天 我自己的警報聊天記錄顯示：返回了十個字段，但沒有一個是計數器。.
只有一種方法可以問。那就是在私聊中。, 訊息 ID 這是一個每次聊天都對應的序號，所以你發送一條訊息後，就可以在收據上看到這個號碼：
curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \ -d "chat_id=$CHAT_ID" -d "text=probe" -d "disable_notification=true" # {"ok":true,"result":true1,605. 這就是此聊天記錄中出現過的所有訊息。我的守護程式的會話檔案記錄了 19 個操作員對話訊息，因此其餘 1586 個訊息幾乎全部都是代理警報，而成功運行次數約為 1500 次。成功路徑運作正常。 （之後刪除探測器） 刪除訊息; （我做了。）
你無法從呼叫 Telegram Bot API 的程式的日誌中審核 Telegram Bot API 警報。
我的第一個反應是搜尋運行日誌，但第一個結果大錯特錯。 1566 個日誌中有 524 個提到了警報，所以我一度認為該通道有三分之一的時間都在觸發警報。.
然後我讀了其中一句。這句話是經紀人自己寫的—— “步驟 7：已發送 Telegram 提醒” ——不是腳本的輸出。所以我檢查了是否 任何 命令輸出是否會到達這些日誌：
- 包含警報腳本實際標準輸出（成功或失敗）的日誌： 0/1,566
- 包含日誌 任何 工具呼叫產物－可以是 curl 指令、API 主機名，任何東西： 0
- 包含確切字串的日誌
Telegram提醒已發送。.: 239, 它們中的每一個模型都描述了預期會發生什麼。
調度員只記錄特工的最終書面總結，不記錄其他任何內容。. 警報腳本本身的判定結果從未被記錄到日誌檔案中。. 兩者都沒有故障：零日誌包含 失敗的 分支和零包含腳本在缺少令牌時列印的警告。.
這很重要，因為 telegram-alert.sh 寫給 出口 0 當憑證未設定時，它稱之為“優雅地跳過”。從容器內部來看，, 正確配置的警告通道和完全未配置的警告通道產生的證據相同：沒有。. 那與失效形狀相同 一次運行正常退出，且不報告任何內容。 沉默被解讀為成功。.
⚡ 取得人工智慧優勢
每週提供真正省時省錢的AI小技巧。沒有廢話，沒有誇大其詞——只有切實有效的方法。.
紅色 X：66 次錯誤運行，1 次警報
雖然航拍日誌不能作為有關航路的證據，但它們仍然是有關航程運行的有效證據。已完成1565次航程發送：
- 1,499 退出次數為 0——每次退出都以提示訊息結束，聊天計數器也證實了這一點。
- 50 退出 1
- 16 調度員還來不及寫退出頁腳就過世了。
所以，66次跑壘失誤了。現在，真正能說明8月那篇文章問題的數字是： 這 50 次失敗的運行中，沒有一次包含 a 技能結果 線。. 它們沒有一個到達過自己管道的盡頭。.
這是結構性問題，而不是程式錯誤。. 我把故障警報寫在出錯程式碼的最後一行了。. 如果一個程式在第一次 API 呼叫時就崩潰了，它就永遠不會到達應該告訴我它崩潰的步驟。綠色對勾錶示程式自動崩潰；紅色叉號表示需要進行一些檢查。 外部 注意到跑步。.
我確實用過類似的東西——調度器裡有一個響應式分類器，它會在非零退出後搜尋日誌，如果錯誤看起來像是認證相關的，就發出警報。它確實捕獲到了。 66人中的1人.
根本原因是詞序問題。
以下是這 50 個失敗案例的實際情況，以及我的分類器模式是否相符：
| 失敗家族 | 跑 | 警報已觸發 |
|---|---|---|
| 身份驗證失敗（401） | 21 | 1 |
| 組織訂閱存取權限已停用 | 21 | 0 |
| 容量/529 超載 | 5 | 0 |
| 已達到速率限制 | 3 | 0 |
二十一次真實身份驗證失敗。一次警報。我寫的模式包含了備選方案。 身份驗證失敗, 這段文字讀起來完全合情合理。命令列介面輸出：
身份驗證失敗。 API 錯誤：401 OAuth 存取令牌無效。.“「身份驗證失敗」並不等於「身份驗證失敗」。” 同樣的詞語，順序錯誤，匹配失敗。唯一觸發警報的那條警報是透過另一種方式發出的。, oauth.*expir, 因為那一次運行恰好顯示「OAuth 會話已過期」。“
當我寫偵測器時，用的就是我當時面前的那串字串。同一供應商針對相同情況所使用的其他所有措詞— 無效的, 撤銷, 無效憑證 ——徑直走了過去。而最大的一個家庭，21次跑步因訂閱權限被關閉而中止，這句話在我編寫正則表達式時根本沒見過。.
我已將此風險標記出來。 9月1日發布的貼文 經歷了一個糟糕的夜晚後，我建議預設警報，而不是根據模式觸發。我從未更改過程式碼。 37天后，統計數據表明，這個軼事如果說有什麼誇張之處，那就是它造成的損失更大了。.
今天就做這件事
三張帳單，每張都只夠喝杯咖啡的時間：
- 查看您的聊天記錄。. 發送一個探測訊號，記錄結果
訊息 ID, 刪除它。將其與您計劃的運行次數進行比較。如果運行次數遠低於計劃運行次數，則表示您的警報未收到，而日誌中不會有任何相關記錄。. - 將故障警報移到運作之外。. 如果只有崩潰的進程才能報告崩潰，那麼你就是在依賴一個已經死亡的進程來發出訊號。啟動任務的包裝器應該在檢查任何內容之前，就對任何非零退出值發出警報。.
- 警報 未被識別, 不，不是在 已確認. 每次失敗都要立即處理，把那些無關緊要的錯誤列入允許清單。模式清單只能捕捉你已經克服的錯誤——而真正讓你失敗的錯誤，根據定義，是你還沒克服的錯誤。.
重點在於，與其說是建議，不如說是糾正： 如果你從未見過某個警告通道發生故障，那麼你就沒有關於該通道故障的證據。. 我的機器完美地完成了大約 1500 次綠色勾選，吞下了 66 次紅色叉號中的 65 次，這兩件事持續了 118 天，而我把這種平靜視為好消息。.
如果您想要此圖層下方的日程安排圖層，, cron 的詳細說明 是姊妹篇，而且 自動化前的監控 這就是先做這件事的理由。如果你希望有人第一次就把告警路徑正確連接好，, 預約策略諮詢 我們將逐一檢查您的堆疊。.
📥 免費：《人工智慧劇本》
我用來經營一人代理公司的所有工具和工作流程。 25 年的行銷經驗濃縮成一份實用指南。免費贈送。.
人工智慧與數位行銷策略師
Jon Jones擁有超過25年的數位行銷、電子商務、銷售和國際商務經驗，是一位資深企業家，致力於透過創新的人工智慧解決方案賦能小型企業。他的職業生涯始於華爾街的投資銀行，曾指導企業完成資本募集和應對複雜的市場環境。如今，他的專業領域已拓展至網站開發、品牌設計、產品開發以及課程培訓。.
Jon精通普通話，並在金融和科技領域擁有深厚的功底。他創立了JonJones.ai，旨在為小型企業提供易於使用且具有變革意義的工具，幫助他們簡化營運、拓展客戶並實現永續成長。他對人工智慧、自動化和數位化策略的精通，已幫助許多企業彌合了傳統模式與現代技術之間的鴻溝，確保它們在當今的數位化環境中蓬勃發展。.
