Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the ultimate-addons-for-gutenberg domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /opt/bitnami/wordpress/wp-includes/functions.php on line 6114
八寶周 - 八寶周的研究小屋

Author: 八寶周

0. 前言


隨著數位時代的快速發展,資訊安全已經成為現代社會中不可忽視的重要議題。組織乃至個人都面臨著多種潛在的資安威脅,從敏感資料的洩露到關鍵系統的攻擊,稍有疏忽便可能引發巨大的損失。

本篇文章探討資訊安全的核心目標,並延伸說明風險管理之要素與對策。相信剛接觸資安領域的讀者,都能藉此獲得更全面的概念與實務啟發,並反思個人的生活情境是否雷同。

1. 重點


CIA Triad — 保密性 Confidentiality + 完整性 Integrity + 可用性 Availability
風險評估 4 大要素 ( 資產 + 脅迫 + 弱點 >> 風險 )

2. 內容


2.1. 三大要素

「CIA 三角形」概括資訊安全的三大基本目標,並廣泛應用於設計與評估系統。

C – 保密性 Confidentiality

防止未經授權的訪問或洩漏

搶到演唱會門票興奮的將照片上傳社群媒體,忘記隱藏 QR-Code 而被別人兌換使用,導致無法入場並造成損失。
I – 完整性 Integrity

確保資料在流程中不被竄改並應能檢測到惡意的變更

wikimedia
傳統西方信件上的封蠟印章,除了表示訊息來源,同是一種保密措施。由於開封時火漆難免碎裂,因此一定程度上保證該信尚未開封。
A – 可用性 Availability

確保授權用戶在有需要時都能存取系統和資訊

wikipedia
在 2021 年 Facebook 旗下產品發生嚴重的當機事件,造成所有對外開放服務中斷約 6 小時之久,期間用戶無法進行任何動作,沒有達成此項。

2.2. 風險評估

我們今天取得一個 黃金人像,這件藝術藏品價格不斐且 變賣也有價錢,為了美觀我們將他放在 窗邊 好與夕陽融為一體,但某日半夜我們聽見 玻璃碎裂,事後發現物件被 洗劫 了。看完這段敘述不知各位做何感想,但我想要闡述是過程中的 5 個要素。

1. 資產 Asset

也就是我們所持有的資料或財產,並涉及其重要性與機密性。

2. 威脅 Threat

什麼事情能造成威脅,包括人為或天災影響。

3. 弱點 Vulnerability

資產的不易取得性,以及是否暴露或加密。

4. 風險 Risk

綜合上列三個屬性的情況之下,預估可能發生哪些事件導致我們的損失,並採取對應政策。

-默許 Acceptance

知道風險但決定默許其存在而不做任何變動調整。並不是完全說該組織懶散,但在複雜的程式中往往牽一髮而動全身,在影響不大的情況下反而默許能省下開發成本並追趕上架時間。

-轉移 Transference

將風險轉移給第三方以降低自身負擔,通常通過合同或保險等方式實現。

-緩和 Mitigation

減少風險對資產或目標的負面影響,通常包括主動識別問題或監控紀錄,並採取防範措施。

-避免 Avoidance

透過任何手段規避風險發生的可能,甚至直接關閉服務。

5. 保護 Protective Measure

評估完可能的風險後,針對對應情境或標準流程增強資料的保護行為。

3. 後話


資訊安全並非單純的技術問題,而是一個涉及策略與管理的綜合性挑戰。在了解 CIA 三角形 的基礎上,我們進一步學習了風險管理中的關鍵環節。當然安全性在本質上是一個動態過程,隨著威脅類型與攻擊手段的演進,資安策略也需不斷更新與優化。

希望本篇文章能為讀者帶來啟發,並讓各位注意日常生活中的安全實踐與提升。

4. 延伸


[1] CIA Traid 詳細介紹 — Fortinet
https://www.fortinet.com/resources/cyberglossary/cia-triad#:~:text=The%20three%20letters%20in%20%22CIA,and%20methods%20for%20creating%20solutions.

  • 讀書心得 – 田園交響曲

    讀書心得 – 田園交響曲

    書籍名稱: 田園交響曲

    原著作者: André Gide (1869-1951)

    書籍譯者: 張博

    出版廠商: 時報出版

    創作年代: 1919

    「她那些表白的天真,還有它們本身的坦率都讓我安心 … 真正的愛情不會沒有迷亂 … 說真的,那天傍晚她對我說的那些話,我感到自己的靈魂如此輕鬆愉悅 … 此前我以為類似的愛情應受譴責 … 而當時我沒有感到自己的靈魂有任何負擔,我便不認為這是愛情。」— p.86

    心智的啟蒙

    >> p. 15
    「哦!我不認為她在睡覺。不過她是個白癡,她從來不講話,而且完全不理解我們在說什麼 … 很久以來除了喝水吃飯,就不再張嘴了。」

    >> p. 36
    這與其說是一個微笑,不如說是脫胎換骨。

    在收養盲女吉特呂德後,牧師不僅成為她的引路人,更逐漸扮演了父親般的角色。他細心引導她認識周遭的世界,花費大量時間陪伴她,從最基本的事物開始,教導她如何理解這個她無法用眼看見的世界。透過描述自然的美麗與動物的聲音,試圖讓吉特呂德建立感知與思想,幫助她在黑暗中尋找生命的價值與意義。

    然而怪異的是開章提到「照顧這個貧苦孤女的念頭並沒有立刻落入我腦海中」,相對是個被動語句,讓讀者猜測過程受到外在的影響,而非最為純粹的意願。並且隨著時間推移,牧師的這種陪伴不僅是單純的教導,更在情感上變得複雜,在對吉特呂德的關懷中,似乎不自覺地摻入了更多私人的情感。

    家庭的糾葛

    牧師的妻子阿梅莉隨著初期一同經歷許多磨難,面對生活相對更加務實與理性,在筆記的敘述中妻子反而市儈庸俗;而吉特呂德初步認識世界,天真的少女配上漂亮的容顏,更是帶給牧師一道曙光與美好的象徵。然而牧師記中絲毫沒有提及自己妻子的退讓與包容,反而像是持續與自己對立的,作為倫理道德阻礙自由愛戀的旁人。

    >> p. 21
    我那些不只一次因為熱情而一時衝動產生的結果最終都壓在了妻子身上。

    >> p. 52
    「你對她做的事從來沒為你自己的任何一個孩子做過。」

    >> p. 72
    「況且,雅克旅行回來之後也許已經療癒了他的愛情。在他的年紀,到底懂不懂自己的慾望?
    「啊!即便年齡大了,有的人也不見得就能搞懂。」

    另外年輕的雅克偷偷教琴的過程中,從牧師偷聽對話開始,到最後趕走長子出外旅行,嫉妒心態若隱若現。敘述中曾提過幾次雅克的形象,還有兩人教義上的分歧,然而究竟發想點從何而來?是保護吉特呂德的防線?還是牧師個人的心聲?

    >> p. 59
    我天性不願窺私,但涉及吉特呂德的一切都讓我留心

    >> p. 59
    我悄無聲息的走下樓梯,打開教堂大門,有意讓她能夠聽見並以為我剛剛進來。

    >> p. 60
    (雅克)這一驟變不可能和我剛剛撞見的一幕無關 … 一種強烈的憤怒把我煽動起來,卻又擔心,如果我任其發作,我的兒子會從此徹底對我關閉心扉,同時也害怕言詞過激會讓自己後悔。

    >> p. 65
    「她的成長已經被耽誤了很久,對於她聽到的第一次情話,她多半會向一貫待人接物那樣堅信不疑 …」

    當我們快速閱覽時似乎並沒有任何不合理,似乎是牧師對於少女的悉心照護。但我們稍微回想,在此之前吉特呂德已經開始對於不少事物抱有懷疑,而這份有意偷聽的舉止更讓事件不太單純。

    短暫的幻想

    >> p. 81
    「您很清楚我愛的是您,牧師 …… 哦!為什麼您把手抽走了?… 那我們為什麼不能相愛?您說,牧師,您認為這是惡嗎?
    愛中從來沒有惡。

    >> p. 85
    我不得不把這本筆記擱置了一段時間。雪已經化了 … 直到昨天,我方才得到了一絲空閒。

    >> p. 85
    今天我對於自己心中長久未被言明的感情直呼其名,我幾乎無法解釋我如何能把他誤認到現在 … 當時我絕不認同在婚姻之外允許存在愛情

    本書位於此處分為兩個部分,巧妙的在於吉特呂德的告白與牧師的自我告解,此處的日期跨動也耐人尋味,唯一一次超過整個月的時長,而其他的大概都在兩周以內。在開端牧師提到雪日過後的閒暇時刻,但相對來說大雪封山的期間為何沒有紀錄?或者更是對於吉特呂德的無盡思念,由於當時已經寄住於 M 小姐的莊園中,使兩人長期無法會面,只能倚靠寫作闡述。

    關於這部分的推論則是源於後續牧師頻繁遠行拜訪對方,以及逐漸偏執不斷提到自己愛意的文句,而在此時牧師必須要面對,是否該通知吉特呂德能夠進行手術的重大選擇,當下也能發現片刻的猶豫。其所擔心的除了手術的風險之外,或許更大的現實的不合,尤其是兩人見面的時刻。

    >> p. 117
    她會認出我嗎?生平第一次我對著鏡子焦慮地端詳。如果我感到她的目光不像她的心靈那樣寬容與深情,我該怎麼辦?主啊,有時讓我覺得自己需要她的愛去愛您。

    崩塌的現實

    >> p. 124
    「我必須向您承認一件事,牧師,因為今晚我怕自己會死,」吉特呂德說道,「今天上午我對您撒謊了。那不是為了採花 …… 如果我對您說當時想自殺,您會原諒我嗎?」

    >> p. 126
    「當您給予我視力,我的雙眼朝世界睜開,世界比我夢想中存在的樣子更美 … 當我走進您的家,您知道在我面前最先出現的是什麼嗎 … 啊!無論如何我必須告訴您:我最先看到的,是我們的錯誤,我們的罪孽。不,不要抗辯 …」

    >> p. 127
    「我的朋友,我將給您造成許多痛苦,但我們之間不應留下任何謊言。當我看到雅克時,我突然明白了,我曾經愛的不是您,是他。他完完全全擁有您的面孔。我想說的是我想像中您擁有的面孔 …」

    當吉特呂德復明後,發現難以言語描述的世界確實比起想像的更加美好,但也因此發現不和諧的現實,這些並非保護為保護其心智的善意謊言,而是兩人個自內心深層隱埋的慾望。

    此時過度的擔心已不再有保護雛鳥的正當名義,甚至最後一篇與雅克的對立更為突出,對於吉特呂德改教如此重大的抉擇,等同於失去精神依賴的行為,卻歸咎於沒有證據的因素。

    >> p. 129
    似乎他們(吉特呂德與雅克)在人生中被我拆散,便計畫從我身邊逃離,然後在上帝那邊重聚。

    隨著吉特呂德的雙眼復明 → 嘗試自殺 → 最後告解 → 香消玉損,所有故事的暗文昭然若揭,或許先前我們感受到了牧師的踰矩,然而直到此時讀者才會發現,事情比起想像的更加瘋狂與複雜。

    總體的看法

    個人認為精彩之處在於角色的設定,吉特呂德的眼疾促使其純潔是如此理所當然,並且惡劣的生長環境與殷勤的學習態度,帶給讀者對於其成長無盡的同情與欣喜。再來是筆者的個人視角以及宗教元素,具備我們想像神職人員該有的生活態度,但又隱隱透漏藏不盡的自我辯解。

    >> p. 49
    「那您說 …… 從那以後您還想要騙人嗎?
    「沒有,親愛的孩子」
    「您能向我保證再也不會試圖騙我嗎?」
    「我保證」
    「那好!請馬上告訴我:我漂亮嗎?

    這個突如其來的問題讓我愣住了,尤其是直到那天為止我一直不願正視吉特呂德無可否認的美。

    如果今日我們看的是言情小說,在看到以上對話時肯定覺得是異性間的關係,然而正因為角色的設定讓我們浮想聯翩,究竟吉特呂德是純真的詢問還是萌發的愛戀,而這反而要等閱畢全書才能夠往回推敲。

    再來就是看見世界後的前後對比,手術期間能夠看出牧師對於結果也是相當焦慮,然而前文頻繁提到,相對來說看的見的人們受到種種汙染。

    最後則是文章呈現方式,是從牧師第一人稱角度陳述,人們往往能設法尋覓種種正大高尚的名義掩飾自己的卑怯行為,不只適用於牧師頻繁使用教義嘗試反駁,直到最終吉特呂德親口說出前後並非對稱的事實,赫然發現此書還有完全難以發現的異文存在,終在末尾一一浮出,整體漸進式的劇情走向突然來個 U-Turn,透漏截然不同的思考模式。

  • Grafana – 信件的來源

    0. 前言


    在正式進入到資料圖表之前,我們先來設置電子郵件,除了填補上期邀請用戶的缺口外,未來設定數據警報的接收信箱也算較為簡單的方式。

    其設定的修改略微繁瑣,希望各位還能跟上步伐並保持熱忱!

    1. 重點


    Grafana 的設定無法從網頁介面進行修改
    Gmail 經測試確認可以自訂寄信者的名稱,但無法遮蔽用戶的信箱

    2. 內容


    2.1. 檢查設定

    左側選單中找到 Adminstration >> General >> SettingsCtrl + F 搜尋 smtp,此時可以看到預設情況沒有啟用且使用本地的信箱地址,若沒有經過完善的設定是沒法發信給別人的,後續我們就以 Gmail 來做替換。

    沒有細查原因但 Grafana 即使有 Grafana Admin 最高權限也沒有辦法利用網頁介面進行修改,回到頂部也可看到提示請我們去調整 .ini 檔並重新啟動。

    2.2. 調整設定

    我們開啟 Terminal 輸入以下指令進入到容器並使用 root 權限,因為我們後續需要安裝檔案編輯相關套件。

    PowerShell
    docker exec -u root -it grafana /bin/bash

    接著移動到該設定檔的位置,檢查是否有前述的檔案存在。

    Bash
    cd /etc/grafana/
    ls
    

    找到檔案之後我們就要開始進行修改,我們首先要先安裝文字編輯器,這邊我個人習慣是用 nano。

    Bash
    apt-get update
    apt-get install nano -y
    

    接著輸入以下指令進入檔案,接著按下 Ctrl + W 並搜尋 smtp,接著敲下 Enter 應該就會到該區塊之設定。

    Bash
    nano ./grafana.ini

    我們修改以下幾個項目,過程記得刪除開頭的 ; 符號,那關於 SSL 與 TLS 安全協議的部分這邊從簡就先略過。確認完成後我們就透過 Ctrl + X >> Y >> Enter 儲存並重新啟動容器。

    Bash
    [smtp]
    # 啟用信箱功能                                                                                                                
    enabled = true
    # SMTP 伺服端口                                                                                                         
    host = smtp.gmail.com:587
    # SMTP 所屬用戶                                                                                              
    user = ${YOUR_OWN_EMAIL}                                                                                       
    # If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;"""
    # 應用程式金鑰                           
    password = ${YOUR_APP_PASSWORD}
    # 略過憑證檢查 (SSL/TLS)                                                                                            
    skip_verify = true
    # 信件顯示信箱                                                                                                    
    from_address = admin@grafana.localhost
    # 信件顯示名稱                                                                                 
    from_name = Grafana      

    這邊我會建議使用其他信箱作為來源寄送到常用信箱,若使用與 user 相同的信箱在總攬會看到 me 的字樣。

    2.3. 測試設定

    首先重複步驟 2.1 透過 Grafana 的介面確認設定是否成功套用。

    關於測試的部分不用等到未來綁定數據警報,記得上次我們談到組織用戶的邀請嗎?這次勾選寄送邀請信件並確定使用 eMail 進行登入帳戶。

    接著就到信箱看看是否收到信件,話說不太清楚是 Gmail 有改過設定還是 Grafana 的問題,雖然顯示 from_name 的假名但信箱地址沒有更換。

    3. 後話


    透過 SMTP 的設定除了警報提醒外,在邀請用戶的邀請上也不用手動傳輸網址,觀感上也更有格調。畢竟屬於系統設定,就決定先提前作示範。

    下回我們就來嘗試新增簡單的資料來源並製作儀表板吧!

    4. 參考


    [1] Configure eMail for Alerting — Official
    https://grafana.com/docs/grafana/latest/alerting/configure-notifications/manage-contact-points/integrations/configure-email/

  • Grafana – 帳戶與權限

    0. 前言


    無論是企業組織還是個人用戶,安全機制的設置都是不可忽視的課題。當涉及到系統的使用權限與資源訪問時,妥善的用戶與權限管理更顯得尤為重要。

    那關於 Grafana 針對企業的管理架構又如何呢?讓我們一探究竟!

    1. 重點


    組織 (Org) 是獨立的頻道,擁有各自的資料來源與儀表板
    系統總管 (Grafana Admin) 可以強制配發帳密,組織管理 (Org Admin) 只能邀請用戶
    團隊 (Team) 能加強組織的管理與迅速的資源發派
    金鑰 (Service Account Token) 目前還無法做到最小權限原則

    2. 內容


    2.1. 分立帳戶

    對於多數個人用戶對於帳戶分立肯定沒有感覺,畢竟就是自己操作肯定想要最高權限。但是這樣的優勢在於如果哪天 普通子用戶 被盜用,還能使用 管理員帳戶 登入並移除被侵略的帳戶。而對於組織而言該功能更加重要,畢竟多數員工不該掌握過大的權限。

    那首先點開左側選單找到 Administration >> Users and Access

    這邊可以看到總共分三個種類,User 就是通常登入到介面的帳戶,Team 則是將用戶分組方便管理,而 Service Account 則是用於 API 的憑證。

    2.1.1. 登入用戶
    2.1.1.1. 新增用戶

    首先我們就從用戶的建立開始,進入頁面後找到表格右上的 New User 並開始建立用戶。

    用來辨別的名稱 (Name) 與進行登入的密碼 (Password) 設置完成後,雖然沒有米字號但這邊 eMail 與 Username 需要至少填寫一個,那是登入時所必須的輸入資料。

    壓下建立用戶我們馬上就要來調整權限,這邊關於 Grafana Admin 的部份我就不做啟用,這項功能是讓該用戶能夠超出組織並操作整個系統,對於平常使用來說權限太高。

    另外要讓用戶能夠操作資源,我們需要指派組織資源並開通權限,這邊我們用上 Editor 權限就夠介面多數的操作。

    2.1.1.2. 邀請用戶

    如果使用組織的 Admin 權限用戶可以掌管組織內的所有人力資源,惡意人士也能偷偷塞入新的帳戶竊用資料,畢竟平常沒人會檢查用戶紀錄,再說人員一多也感覺不出來,所以一般不會隨意配與。

    另外以上介面其實與 Grafana Admin 分頁中的 Organization Users 是相同的。

    這時我們嘗試按壓 Invite,可以看到其密碼是交由受邀請者自行設定。這邊由於我們還沒設定 SMTP(下回),請先將 Send Invite eMail 取消後進行生成。

    完成後在右上角切換到 Pending Invites 分頁,此時我們能夠拿到一組網址,透過這種方式受邀請的用戶就能調整自己的密碼與個人資訊(就後者這部分不太合格)。

    2.1.2. 建立分群

    重新登入到管理員帳號,我們接著往下進到分群的部分,壓下 New Team 按鈕。

    我們輸入個團隊名稱就能進到下一步,並開始添加用戶進群。

    而團隊的概念是在組織建立區隔,就公司角度來說同是開發部門可能有不同的專案,透過這種方式能避免相互影響,也能避免逐個發派資源給予指定用戶。而隊內同樣區分管理人員與普通成員,這邊我們按下 Add Member 並選擇元戶與權限,接著 Save 新增入群。

    而設置的板塊主要則是控管偏好設定,除了樣式與首頁之外,主要考慮有些組織還有跨國的因素存在。

    2.1.3. 建立憑證

    最後來到自動化經常會用到的 API 呼叫,我們註冊一個 Service Account 進行憑證授權。

    這邊我們就先做為測試,使用基礎的 Viewer 權限且後續就會砍掉。

    在最底層我們先設定誰能取得金鑰,透過 Add Permission 還能看到這次我們分有 User 與 Team 都可選擇,而權限的部分則是 Edit 與 Admin 兩種權限,記得按下 Save 進行添加。

    接著我們按下表格右上的 Add Service Account Token 進行添增,這邊還能設置是否到期失效。滿有趣的是其預設時長是工作日 5 天而非整整 1 周。這邊金鑰記得保存起來,外來沒法再做查看。

    這邊展示另個帳號的狀態,上圖處在配與憑證之前,下圖則是配發之後,可以看到多出一個區塊。

    最後來實際嘗試看看,這邊使用該金鑰來查找其所屬的組織訊息。

    HTTP
    GET /api/org/ HTTP/1.1
    Accept: application/json
    Content-Type: application/json
    Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk

    各位稍微回想下流程是不是哪裡怪怪的?我們並沒有詳細設定金鑰有哪些權限,目前還沒法做到 fine-grained 去做最小權限原則。

    額外題下,雖然風險很高但其 API 也能透過 Basic Auth (帳密) 進行單個用戶的授權。

    2.2. 新增組織

    前面的案例我們使用的為預設的組織,那如果今天我們有外部合作夥伴,要與內部系統做區隔,又要如何新增組織呢?看到左側選單的 Administration >> General >> Organization 就能設定所有組織。

    馬上透過 New Org 快速建立一個組織,接著經過偏好設定就完成囉。

    當用戶有組織權限後,要做介面的切換只需在左上選擇組織就可以到不同的頻道囉。

    3. 後話


    儘管設置用戶和權限顯得繁瑣,但這些額外的步驟能大幅提升組織管理的效率與安全性。當資源共享需求提升時,清晰的權限管理不僅能確保內容的分隔,也能減少無意中修改關鍵數據的風險。

    隨著組織或個人逐漸擴大的規模,這些設置雖然麻煩卻能為長期的系統管理打下穩固的基礎,確保系統的高效運行與安全。

    4. 參考


    [1] Roles and Permissions — Official
    https://grafana.com/docs/grafana/latest/administration/roles-and-permissions/

    [2] HTTP API — Official
    https://grafana.com/docs/grafana/latest/developers/http_api/

  • Grafana – 簡介與安裝

    0. 前言


    在數據驅動的現代中資料視覺化已成為關鍵工具,清晰的圖表能夠幫助我們快速抓取核心問題並做出數據驅動的決策。

    促使數據不再僅是零碎的數字,而能組成實際意義的趨勢。而 Grafana 這樣的資料視覺化工具,正在資訊產業中發揮著不可或缺的作用。

    1. 重點


    注意 Docker 容器安裝有兩種 LINUX 環境~~

    2. 內容


    2.1. 基礎介紹

    Grafana 是開源的數據視覺化與監控工具,廣泛應用於系統監控以及數據分析。其特色在於強大的圖表自訂功能,使用者可以根據實際需求自行設計顯示方式,且支援多種 query 語法幫助使用者靈活地提取和處理數據。

    另外具備即時警報功能,當數據超過預設閾值時,可以透過 eMail, Webhook 等方式發送警報,提醒用戶盡早察覺異樣並做出反應。

    它的擴展性和多種整合功能使得它在現代 IT 監控和資料分析領域占據了重要地位。

    2.2. 容器安裝

    本篇採用 Docker 容器技術快速的進行安裝,但為避免後續刪除導致資料遺失,雖然 Grafana 只是視覺化的介面主體,但這些設定檔(資料來源,視覺介面)累積下來也是相當可觀,這邊建議建立 Volume 進行綁定。

    PowerShell
    docker volume create grafana-storage

    接著我們到【官網】查看最新版 Enterprise 的安裝方式,另外請讀者請自行調整最末端的映象名稱,更新為欲使用的版本與系統。以下指令會建立單個名為 grafana 的容器在 內外 3000 並綁定先前建立的磁碟空間。

    PowerShell
    docker run -d -p 3000:3000 --name=grafana --volume grafana-storage:/var/lib/grafana grafana/grafana-enterprise:11.2.0-ubuntu

    2.3. 介面登入

    接著我們到瀏覽器輸入 127.0.0.1:3000 ,或者你個人 VM 的 <私網 IP>:3000 ,應該能進到登入介面,預設的帳號密碼都是 admin

    登入之後建議更換密碼,確保資料安全避免輕易被其他用戶猜到。完成後就會導引到主控台,這樣我們就完成基礎的安裝,可以準備深入儀表板的視覺分析囉。

    3. 後話


    透過本文的介紹與安裝指南,將開啟關於資料視覺的起點。其潛力遠不止於此,未來你可以將它整合到更多資料來源,創建更加複雜的監控系統提供更深層次的支持。

    4. 參考


    [1] Container Installation Guide — Official
    https://grafana.com/docs/grafana/latest/setup-grafana/installation/docker/

  • AI 本地模型 – Stable Diffusion

    AI 本地模型 – Stable Diffusion

    0. 前言


    Stable Diffusion 在圖像生成領域長期展現卓越的成績,甚至引起繪畫市場的洗板與恐慌,如今已然到第三代。那如果只是基礎功能的使用,實際上不用費工的安裝 Web UI 並透過 API 進行呼叫。

    在本篇文章我們將探討在不安裝 AUTOMATIC1111 的 Web UI 的情況下,如何在專案中直接使用。

    1. 重點


    需要準備至少 7 GB 的磁碟空間

    2. 內容


    2.1. 準備環境

    各位可以回顧【PyTorch 環境安裝】事前在 venv 中安裝所需之環境。

    由於 SD2 與 SD3 擁有極大的 GPU 要求,範例這邊採用基礎的 SDXL 1.0,從官方的範例稍作修改增加更多的調整項目。

    Python
    from diffusers import AutoPipelineForText2Image
    import torch
    
    pipeline_text2image = AutoPipelineForText2Image.from_pretrained(
        "stabilityai/stable-diffusion-xl-base-1.0",
        torch_dtype=torch.float16,
        variant="fp16",
        use_safetensors=True,
    ).to("cuda")
    
    # The positive prompt
    pos_prompt = "Futuristic city skyline with flying cars, cutting-edge AI technology, holographic interfaces, sleek designs, vibrant and glowing, 8k, highly detailed"
    # The negative prompt
    neg_prompt = "dystopian, dark, old technology, broken machines, messy environment"
    
    # The number of denoising steps
    num_inference_steps = 20
    #
    guidance_scale = 7.0
    # The size of the result
    width = 768
    height = 768
    # The number of images generated
    num_images_per_prompt = 1
    
    
    image = pipeline_text2image(
        prompt=pos_prompt,
        negative_prompt=neg_prompt,
        guidance_scale=guidance_scale,
        width=width,
        height=height,
        num_inference_steps=num_inference_steps,
        num_images_per_prompt=num_images_per_prompt,
    ).images[0]
    
    image.save("result.png")
    

    此時我們需要另外安裝 diffusers 套件,在專案 Terminal 內輸入以下指令進行安裝 or 更新。

    Python
    pip install -U diffusers

    2.2. 嘗試生圖

    在 HuggingFace 下載模型前,由於該模型屬於受管控的,我們必須填寫頂層的表單後才擁有權限使用。

    在 CLU 有登入 HuggingFace 的情況下,複製剛才頁面上的程式實際跑一次,便會開始下載模型。設備偏弱的讀者可以另外調整圖片的寬高,減少系統的負擔,不過記得 SDXL 在 768 到 1024 pixels 的範圍效果較佳。

    當完成後就能看看最終成效如何囉!

    3. 後話


    事實上 SDXL 還是多數用戶使用的模型,不僅僅在於設備的限制,同時也歸咎於【Civitai】過往累積的大量偏旁模型可以進行調整。

    但總歸來說最基礎的引入就足以包辦許多的業務,雖然許多網頁提供免費生圖,但在開發層面則可以省下許多呼叫的生成費用。

    4. 參考


    [1] SDXL 1.0 — Official Docs on HuggingFace
    https://huggingface.co/docs/diffusers/using-diffusers/sdxl

  • AI 本地模型 – PyTorch 環境安裝

    AI 本地模型 – PyTorch 環境安裝

    0. 前言


    在 AI 萌發的世代越來越多組織投入到模型的訓練,不只企業專用還有免費開源。相對於使用網頁產品受到代幣或會費的限制,在擁有夠力的設備下,我們也能夠自己運行略為遜色但免費的服務。

    趕緊來看看如何在本地設置環境準備運行開源模型吧!

    1. 重點


    CUDA 版本建議較新版本,涉及到系統與外部程式支援的程度
    PyTorch 相容的 CUDA 稍晚於 NVIDIA 最新發布的版本
    PyTorch 不同的套件版本兼容不同的 CUDA 版本

    2. 內容


    2.1. 檢查 CUDA

    針對所使用的 NVIDIA GPU 設備,我們必須另外安裝 CUDA Toolkit 讓電腦知道顯卡的位置以進行使用,若沒有經過正確的流程則沒法正確驅動,變相使用 CPU 而非 GPU 導致很多人抱怨執行時間過長。

    關於如何選擇 CUDA 版本,我們首先到【顯卡與運算兼容】找到自己顯卡的 Compute Capability 數值,如我的設備在下圖標註處而其數值為 8.6 ,相對屬於較新的資源(本篇完成時最新為 9.0)。

    接著我們到【架構與對應版本】看到表格,找到對應的 Compute Capability 以及其支援的 CUDA 版本間距。可以看到較舊的型號不再維護,而目前多數則支援到最新的版本,但最低的支援版本各不相同。

    ArchitectureCUDA CapabilitiesFirst CUDA Toolkit SupportLast CUDA Toolkit SupportLast Driver Support
    Fermi2.0CUDA 3.0CUDA 8.0R390
    Kepler3.03.2CUDA 6.0CUDA 10.2R470
    Kepler3.53.7CUDA 6.0CUDA 11.xR470
    Maxwell5.05.25.3CUDA 6.5OngoingOngoing
    Pascal6.06.1CUDA 8.0OngoingOngoing
    Volta7.0CUDA 9.0OngoingOngoing
    Turing7.5CUDA 10.0OngoingOngoing
    Ampere8.08.6CUDA 11.0OngoingOngoing
    Ada8.9CUDA 11.8OngoingOngoing
    Hopper9.0CUDA 11.8
    CUDA 12.0
    OngoingOngoing

    版本差距不只在於系統的變動,同時有包括外部程式的兼容性,因此還是建議安裝較新的版本。比如【此篇詢問】也是我所遇到的議題,本來 CUDA 11.7 跑得好好的,由於其他程式需要更新 Visual Studio 2022 結果就導致專案錯誤,加上 Community 版沒法回朔,只好加裝新的 CUDA,順道就寫下這篇記錄。

    2.2. 匹配 PyTorch

    確認完 CUDA 版本後別急著下載最新版,畢竟涉及 CUDA 的系統變動與套件維護,PyTorch 支援的版本與 NVIDIA 最新的版本難免形成差距。

    來到【PyTorch 官網】稍微往下滾動,壓下 Get Started 進到安裝介面。

    按照自己的設備與需求設定後,底層將會產生安裝的指令。此時注意到指令末端有 /whl/cu124 字樣,在安裝過程中該 PyTorch 內建只會尋找 CUDA 12.4,因此安裝 11.8 或 12.6 都是沒法正確運行的。

    在部分 HuggingFace 或 GitHub 開源模型的安裝方式中可能存在 –index-url 之參數,此時我們就必須額外安裝其他版本的 CUDA Toolkit 避免 PyTorch 套件版本不同的差距引發錯誤。

    2.3. 安裝 CUDA

    再度回首來到【CUDA Toolkit Archive】並選擇 PyTorch 的對應版本,接著依照系統選擇並開始安裝。

    等到下載器準備好就能夠執行,過程中維持預設即可,慢慢等待安裝完成即可。

    安裝完成後我們開啟 powershell 並輸入 nvidia-smi 指令,此時應該能跳出當下的顯卡資訊。

    (卸載不完全,導致 CUDA 版本顯示為 12.6)

    2.4. 安裝 PyTorch

    建議使用 venv 進行環境的分隔,隨著專案越多雖然占用大量的儲存空間,但相對好集中管理,且避免不同專案的套件版本發生衝突。

    我們複製在 2.2 取得的指令並開始進行漫長的安裝,在等待期間我們先建立一個 Python 檔案等會用來檢測系統設備。簡單解釋一下邏輯,當 CUDA 支援時則會使用 GPU 並回報首個設備的資訊,否則使用 CPU 。

    Python
    import torch
    import logging
    
    # Set up logging configuration with a prettier format
    logging.basicConfig(
        level=logging.INFO,
        format="%(asctime)s | %(levelname)s | %(message)s",
        datefmt="%Y-%m-%d %H:%M:%S",
    )
    logger = logging.getLogger()
    
    # Define the dashboard border
    border = "=" * 60
    section_divider = "-" * 60
    
    # Check if GPU is available and set the device
    device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
    
    # Print device type (GPU/CPU)
    logger.info(border)
    logger.info(f"⚙️  Using Device: {device.type.upper()}")
    logger.info(border)
    
    # Additional info when using CUDA (GPU)
    if device.type == "cuda":
        gpu_name = torch.cuda.get_device_name(0)
    
        total_memory = round(
            torch.cuda.get_device_properties(0).total_memory / 1024**3, 1
        )  # Total GPU memory
    
        logger.info(f"🖥️  GPU Name: {gpu_name}")
        logger.info(f"📊 Total GPU Memory: {total_memory} GB")
        logger.info(border)
    

    確認 PyTorch 安裝結束,我們就來測試看看是否能讀取到顯卡資訊。

    Python
    python <上述 .py 路徑>

    3. 後話


    當我們確認好正確安裝與配置後,就可以安心地進入模型開發與探索的階段了。

    無論是進行深度學習的訓練,還是處理其他複雜的計算任務,擁有良好的驅動環境將確保你的工作流程順暢無礙。未來就讓我們一起探索模型的潛力,開啟 AI 領域的全新旅程吧!

  • MC 煉金工藝 – 音效配置與音訊導入

    MC 煉金工藝 – 音效配置與音訊導入

    0. 前言


    在遊戲中加入音訊不只帶動遊戲感,如果加上劇情對話還能帶來劇情張力並引導遊玩速度。

    透過 /playsound,趕緊看看如何透過生成工具簡單達成以上的目的吧!

    1. 重點


    該指令是在地點觸發,不會隨著物體移動
    音量的 volume 參數在 > 1.0 的情況去 x16 則代表是傳聲的距離,最小傳聲距離是 16 格
    最小音量是指傳聲範圍之外的常態音量,而非範圍內的最小音量

    2. 內容


    2.1. 解說 – 指令的整體架構

    關於 /playsound 的架構也不複雜,但最基本的情況下建議還是使用以下方式,因為在正常情況下我們是從某個地點或物體去發出聲音,所以 Selector 的設定相對重要。而如果製作的地圖中有版權音樂或音效,要讓直播者避開風險,通常建議放在 music 或 record 兩個相對較少人開啟的音軌。

    Python
    /playsound <聲音特效> <音軌> <SELECTOR>

    而除此之外還有一系列的參數可以調整,首先 /playsound 該指令是在「位置」進行傳聲並非跟著物體移動,因此自由活動的情況下並不適合長篇的音檔。音高的部分在 Java 版能從 0.5 ~ 2.0,上下 1 則代表是八度音的距離,而提高同時會讓聲音變得急促,反之拉低會讓音訊延長。

    而 volume 的設定從 0.0 ~ 1.0 是調整音量,但超出 1.0 後則會 x16 代表傳聲的距離,而傳聲的最小距離就是 16 格,而在傳聲範圍內離發聲地點越遠漸弱。末端的 minVolume 從 0.0 ~ 1.0 的數值實際上是在撥放範圍之外,玩家所能聽到的音量。所以假設 minVolume = 1.0 的時候,在超出撥放範圍外的音量反而比在圈內外圍還大聲。 這時候最好的限縮方式就是透過 Selector 搭配 distance 標籤進行塞選。

    Python
    /playsound <聲音特效> <音軌> <SELECTOR> <x> <y> <z> <音量/距離> <音高> <圈外音量>

    2.2. 實作 – 為材質包導入自訂義的音檔

    在影片中我們有稍微帶過以下這些可用的介面化工具

    【音效】Stable Audio, Meta Audiobox

    【語音】TTSMaker

    那這邊額外補充幾個工具給具有 Python 經驗 + GPU 的朋友

    【音效】AudioLDM2, Stable Audio Open

    【語音】speecht5_tts

    這次需要用到在 versions 檔案看不到的材質包屬性,首先將 .ogg 音檔放入到 sounds 資料夾目錄之中。

    另外建立一份 sounds.json 並進行編輯,這份檔案才是實質標註音訊的設定。各位可以參考以下的格式達成最基礎的設定,最主要會要設定 Sound Event ( 識別字串 ) 以及 name ( 檔案路徑 ) 。關於 stream 的串流設定建議設為 true 避免讀取完整大檔導致的 lag 。

    Python
    {
        "識別字串": {
            "sounds": [
                {
                    "name": "檔案路徑",
                    "stream": true
                }
            ]
        },
        "speeches.opening": {
            "sounds": [
                {
                    "name": "rpg:speeches/opening",
                    "stream": true
                }
            ]
        }
    }

    完成之後來到我們的遊戲之中,裝上材質包,最好再按下 F3 + T 重整一下。此時我們輸入指令應該要能看到我們自訂義的音檔,並可以正常進行撥放。

    2.3. 實作 – 將 MIDI 轉為音階盒樂曲

    我們透過 Open Note Block Studio 去讀取 MIDI 並轉換成音階盒格式,導入的時候麻煩維持 1x 並記得勾選 Read Note Velocity 進行音量調整。

    這邊提供範例使用的千本櫻 MIDI 音檔

    完成讀取後,由於通常公開的 MIDI 都已經調整好設定了,我們就透過 File >> Export as datapack ,等待一段時間直到有個視窗彈出才算完成。

    接著我們就能將 musicbox 這個資料夾移到我們自己的 Datapack 之中,此時記得將 load 與 tick 添加到 minecraft / tags 的兩份設定之中,最後記得若為 1.21 記得將 Namespace 底下的 functions 改為 function 該新的名稱。

    完成後就能到遊戲 /reload 開始測試,我們主要操作就是 play (撥放), pause (暫停), stop (停止) 上述三種,各位能注意影片中的記分板數值。

    3. 後話


    快速複習下本篇內容,指令的架構與基礎,再來添加自己的音檔,最後轉換 MIDI 並轉為音階盒樂曲。

    那下次我們終於要進入到 Ground Crafting,透過 execute 製作視覺化的合成效果。

    4. 參考


    [1] sounds.json 格式 — Minecraft Wiki
    https://minecraft.wiki/w/Sounds.json

    [2] playsound — Minecraft Wiki
    https://minecraft.wiki/w/Commands/playsound

  • MC 煉金工藝 – 粒子效果與旋轉法陣

    MC 煉金工藝 – 粒子效果與旋轉法陣

    0. 前言


    無論是在冒險地圖中製作生動的場景,或是為技能設計絢麗的動畫,/particle 指令都能派上用場。透過粒子效果可以大大提升遊戲的沉浸感,讓你的創意在遊戲中得以充分展現。

    那我們這篇我們會進行 particle 的基礎知識到進階設定,順帶簡單實作,馬上就來看看吧!

    1. 重點


    delta 用於指定粒子效果的範圍,並受 count 影響進行排列
    delta 在 count = 0 時通常用來指定 Motion
    force 不僅是增加視野距離,還可強迫在 Minimal 設定之下顯現粒子

    2. 內容


    2.1. 完整解析

    2.1.1. 粒子效果的特性

    在遊戲中粒子效果是以 2D Sprites 形式呈現,因此無論玩家如何移動它們總是面向玩家。而在短暫的動畫過程中可能會變換大小和旋轉,並去循環 Sprite 動畫。

    多數粒子是可以穿過牆面的,而部分粒子(ex: 煙霧)則與實心方塊碰撞,並在蜘蛛網中會被減速,但它們並不受其他實體的影響。

    另對於遊戲機制有影響的粒子效果基本還會顯現在 Minimal 設定之下。

    Sprite

    Sprite 是電腦圖形和遊戲的術語,指整合到場景或環境中的 2D 圖像或動畫。通常由多張不同動作的圖片組成循環動畫,避免遊戲角色在螢幕平移的滑稽情況,且可透過越多的禎數提供流暢的動態感。至今仍大量運用在 Platform, 2D RPG 等平面遊戲,到了 3D 則多都改由骨架進行控制。

    圖片來源: Sunny Land on itch.io
    2.1.2. 粒子效果的生成

    簡單認識粒子的特性後,我們就能夠進一步開始透過指令進行更好的調整囉。

    那由於涉及視覺設定上的觀感設定,我自己基本不會使用最基本的語法,能調整的太少了。

    Python
    /particle <particle_name> ~ ~ ~

    那另外一種較詳細的寫法中,我們能夠進一步調整粒子的數量, 呈現範圍, 速度, 視野距離, 強制顯示, 可看見者,相對有非常多的調整。

    Python
    /particle <particle_name> ~ ~ ~ <delta> <speed> <count> [force|normal] [viewers]

    在座標後方各位千萬別依照 Hint 乖乖地輸入座標。

    這個 delta 區塊主要用來表示要呈現粒子效果的區域,而其中心區域就是我們前面指定的座標。而這邊的數值被放大了 8 倍,所以想要呈現在一格之中我們則要設置為 .125 .125 .125,而後方的 count 除了影響數覺效果外還能用來辨別例外。

    接著先跳過來看 count 也就是粒子的總數,最高可到 32 bit 但前提是你的電腦承受的住。正如我們在 RPG 地圖 Boss Fight 難免遇到粒子效果造成的當機攻勢,生成越多粒子往往對玩家是種負擔。

    而粒子會在 delta 的範圍內隨機擺放,以下為從左到右的指令範例。可以發現即使再多的粒子在同個地點也沒有多少用處,而在 delta 的直徑範圍內除了縮放外還能針對樣式做調整。

    Python
    /particle flame ~ ~3 ~ 0 0 0 0 100 normal
    Python
    /particle flame ~ ~3 ~ .125 .125 .125 0 100 normal
    Python
    /particle flame ~ ~3 ~ .125 .5 .125 0 100 normal

    但在 count = 0 的時候不是沒有粒子,在此時的 delta 則等同於 Motion 設定,配合 speed 從隨機擴散變為直線射出粒子。

    針對音階符與 entity_effect 則用來決定粒子的顏色,色彩數值由 delta x speed 進行計算。

    那 speed 概念正如其名代表粒子的移動速度,但其活性視粒子效果反而不同。在下方的範例中分別是速度 0 與 0.05 來呈現火焰,可以看到在 0.05 的狀況下火焰就已經明顯向外擴散。

    但也不是說速度越高一定越糟,有些比較遲鈍或會下墜的粒子效果反而要到 1 才會變平常所見的樣貌。

    另外當然也有完全不受影響的案例。

    後方兩項都是選填的針對玩家的顯示設定,本身的預設值分別為 normal 與 @a ,但我自己習慣上還是加上 normal 提醒自己這邊還有參數可以設定。

    在 Minecraft Wiki 之中雖然只寫到 normal 與 force 用於顯示於 32 或 512 格之距離。

    但 force 還可強制在 minimal 設定下也看到效果,適合針對地圖製作中必要的元素避免影響遊戲。

    最後尾端的設定則常用於遊戲分組的時候,比如殺手或間諜能夠獨立看到特殊的機關進一步幹些壞事。以下範例以 tag = viewer 進行呈現。

    Python
    /particle flame ~ ~3 ~ .125 .5 .125 0 1 normal @a[tag=viewer]

    2.2. 實作體驗 – 旋轉法陣

    2.2.1. 活用工具

    首先到 GitHub 下載【該工具】,麻煩注意系統需求的部分,各位可能還要額外安裝 .NETCore 3.1 才能執行。

    接著我們能夠到【該網站】下載圖檔,習慣性按下 Preview,接著依照以下設定。

    簡單講解下齁,我們首先設為相對座標,這樣法陣才能夠進行旋轉。而為了放在地面則設為 Z-X 。接著將法陣對齊中心,並取消 Autosize 直接設置直徑為 4 。

    接著開啟 More Settings 調整粒子效果,那範例這我使用的是附魔文字的 enchant,並且將顯示設定改為 normal,就可以輸出 mcfunction 。

    接著到專案目錄進入 functions 目錄之中,複製與檔名相同的檔案。

    2.2.2. 指令測試

    接著貼到我們的 Datapack 之中做成 function 在遊戲中進行使用。那方便起見我們就偷懶用下指令方塊進行測試。

    我們首先準備一個 Repeat 指令方塊,讓盔甲座持續的旋轉。

    Python
    execute as @e[type=minecraft:armor_stand] at @s run tp @s ~ ~ ~ ~6 ~

    接著在後方接個 Chain 指令方塊,在盔甲座底下秀出魔法陣。

    Python
    execute as @e[type=minecraft:armor_stand] at @s run function |YOUR_FUNCTION|

    大功告成!會旋轉的法陣就是如此簡單,對於地圖擺設或技能特效都十分實用。

    3. 後話


    靈活運用這些粒子效果,你可以創造出極具視覺衝擊力的場景,並將你的想法具象化為動態效果,讓你的 Minecraft 創作更上一層樓。

    那由於篇幅關係,我們將 /playsound 拆出額外進行解說,另外也有準備額外實作進行音樂的添加,各位可以期待一下。

    4. 參考


    [1] Commands / particle — Minecraft Wiki
    https://minecraft.fandom.com/wiki/Commands/particle

    [2] Image Particle Generator – by Legitmoose
    https://www.youtube.com/watch?v=1DjAt-WuJFA

    5. 額外


    [1] Animated Particle Plotter – by Cloud Wolf
    https://www.youtube.com/watch?v=YFDo5Inn7x8

  • AWS – Billing and Cost – 計費與預算警報

    0. 前言


    隨著企業越發依賴雲端服務,管理和優化雲端支出的重要性也日益增加。

    而 AWS Billings 為用戶提供了一個全面而透明的計費管理服務,使用戶能夠清楚地了解其 AWS 資源使用情況,並作出明智的財務與優化決策。

    1. 重點


    AWS 在每日進行計費
    預算警報可設置在超出特定數值與 % 之時通知
    AWS 在每月三號收費

    2. 內容


    2.1. 開銷報告

    我們租賃 Amazon 機器總該付錢的,那我們又該到哪邊檢查呢?我們又如何知道哪個服務最燒錢呢?

    2.1.1. 開銷總攬與基礎設定

    我們從用戶的設定選單中我們找到 Billings 並進入介面。

    此時系統會將我們導引到成本管理的介面,這邊我們能快速看到這個月目前與後續預測金額,以及與上個月的比較。若我們想看到過往紀錄與細項服務的使用情況則必須到 Cost Explorer 進行。

    接著在左側選單找下 Cost Explorer,此時作為新帳戶的各位可能還沒有任何資料,會顯示藍色的提示框請 24 hr 後再嘗試。

    這邊我們可以調整統計時常以及統計時間,那預設情況只能顯示 1 年內的資料。而現版本的預設狀態好像是半年以月統計(我剛接觸的時候是單月每日)。此時滑鼠移到圖表上會顯示該間距各服務的花費。這邊要注意 Hourly 的資料採集是「付費功能」,沒有即時需求就不用開通!

    這邊我也順便訴苦下,可以看到維持我這 Blog 的 Lightsail 服務在 2024 五月後由於加收 IPv4 費用漲價了,各位不給獨自營運的我個好評嗎?

    要顯示到最久 38 個月的話我們需要開啟額外設定,必且 1 年以前的資料是指能開啟 Monthly Basis 的。那反正該功能是免費的我是習慣性開啟拉,畢竟比起到信箱調閱每月的帳單來的快速。

    完成設定後記得到頁面下方壓下 Save preferences 才會儲存設定喔,那這邊在處理期間是沒法做修改的。

    2.1.2. 給予子帳戶權限

    但在預設情況下所有子帳戶都是沒有權限瀏覽的。

    此時能夠在 root 帳號調整設定,變更為擁有 IAM 權限的母子用戶都能夠操作。

    進到資訊介面後我們往下滑,找到 IAM user … to Billing information 並將其開啟。接著重新

    等它生效要一段時間,可以先去樓下裝杯咖啡再回來啊 ~ 接著就是瘋狂地刷新。

    2.2. Free Tier 用量

    這邊我順道為新 AWS 用戶介紹下,同樣在 Billings 中的左側選單找到 Free Tier 進入介面。這邊會顯示你目前使用那些能折抵的服務,以及目前的使用量。

    詳細的資訊可以到【官方介面】進行了解,另外要注意有些是全年或每月統計。

    2.3. 預算警報

    阿我有 Free Tier 折抵我的費用,真的有需要擔心破費嗎?關於錢的事自然不能馬虎,但不乏疏漏的時刻。這邊案例是我在自學過程中就曾發生過操作失當多噴了近 15 USD 。

    假設當時我沒有設定警報,還是在月初的情況,我那個僅 30 日的試用不但浪費掉,此時用 26 日的 9 USD 隨意算一下,還要多付高於 270 USD,你說重不重要?

    預算警報主要有兩種作用,一種是當費用破表時寄送信件通知用戶,而另一種則是在超過 N% 的時候。

    2.3.1. 設置警報

    進到 AWS 介面之後我們就點擊用戶名稱開啟設定選單,這次選擇 Billing and Cost Management 進到關於花費的設定介面。

    在左側的選單我們下拉在 Budgets and Planning 找到 Budgets,接著進到該介面之中。

    首次進到頁面之中大概是這種版面,我們看向右側並壓下 Create a budget 按鈕。

    這邊我們選用 Advanced 進行建置不然少了許多功能。接者選擇針對開銷的 Cost budget 並進下步驟。

    我們就先不管右側的 Budget Preview 並關閉,這個視窗主要的用途只是讓我們去評估後續的預測。關於名稱的設定就自己能懂就好,這便範例就使用 10 美金作為界線。

    下面我們維持預設按月統計。而其底下的 renewal type 則是說該預算警報的形式,是無限期的重複啟用,還是有時效性的(專案)預算。

    從何時啟用我們也先不動,預設就是從本月開始計算。至於金額規則我們使用 Fixed 並固定為 10 美金。

    我們這邊同樣保留預設去統計所有 AWS 服務之支出金額。

    進到下個步驟我們新增門檻。

    範例這邊我們設為 Actual 的 80% 時會寄信到指定信箱,而 eMail 通知最多支援十人,否則就要倚靠另外兩個方式進行建立。

    而除了 Actual 還有 Forecasted 的觸發方式,相對提早預估異常的發生,但在月底的時候也很容易誤觸。

    再來就是過往沒有的功能,我們實際上還可以設定當觸發警報時會去執行甚麼動作。透過 IAM Role 給與權限去調整 IAM Policy 或者關閉 EC2 與 RDS 的 VM 資源。

    我們就先不操作這塊進入下步驟。

    再度確認一切設定,完成後就可以進行建立,如此當隔日計費時超過 8 與 10 USD 時都會寄送警告信。

    3. 後話


    初步觀察 Cost Explorer 後更能知曉與預測後續的花費,並結合 Budget 提醒用戶發生評估之外的異常狀態。但在參加取多官方活動時拿到了不少的折抵券,我們又如何進行兌換呢?

    下回快速的來看看吧!

    4. 參考


    [1] Grant access to the billing console – AWS Doc
    https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-set-up.html