在 GCP 價目表上找到一個很便宜的機型,RustDesk server 主要做 relay,share CPU 應該不太有影響。

跑了一陣子,記憶體僅用了 250 MB 左右,中間機器有掛了幾器,重新開機以後恢復正常。
latency 很低,放幾天看看,夠穩定的話,說不定可以再塞一些小服務。
軟體開發和生活瑣事
在 GCP 價目表上找到一個很便宜的機型,RustDesk server 主要做 relay,share CPU 應該不太有影響。

跑了一陣子,記憶體僅用了 250 MB 左右,中間機器有掛了幾器,重新開機以後恢復正常。
latency 很低,放幾天看看,夠穩定的話,說不定可以再塞一些小服務。
剛好有一些資料打算封存,所以嘗試各種雲端除存服務。
以儲存空間計費 (忽略資料傳輸費用) 的話,由貴到便宜分別是:
原本以為 BackBlaze 沒有亞洲資料中心,傳輸速度會很慢,但一直都有維持在 5 MB/s 以上,還算不錯。
Azure 還沒研究,等下一輪吧
Google Cloud Build error:
failed unmarshalling build config cloudbuild.yaml: json: cannot unmarshal array into Go value of type string
設定檔中並沒有 JSON config,查了半天才知道是 YAML 格式有誤 (I hate YAML)
正確的 cloudbuild.yaml 檔案格式,可以參考 Google Cloud Build configure file schema。
上一篇文章,是將 Cloud Logging 下載回 local,不過在扒 log 時發現 json log 其實閱讀難度不低。
從 Cloud Logging 上檢視記錄時,可以發現 MySQL slow query log 會有多行的資料,而 Cloud Logging 則是將將一行記錄轉成一個 json item:

這類資料還是不要轉為 JSON 比較容易閱讀 ….
個人覺得 GCP 後端管理頁面很難操作,顯示方法也不直覺,所以決定把 Cloud Logging 上的資料全部拉回 local 來分析。
首先在 Cloud Logging 上面建立 filter 來篩選出需要的資料,以下範例是篩出 Cloud SQL 的 logs:

接下來透過 gcloud console 來組出命令,主要以 gcloud logging read 開始,在加入上圖的 filter ,最後選擇 log format :
gcloud logging read \
'resource.type=cloudsql_database AND \
resource.labels.database_id="my-database" AND \
logName=("projects/my-project/logs/cloudsql.googleapis.com%2Fmysql.err" OR \
"projects/my-project/logs/cloudsql.googleapis.com%2Fmysql-general.log" OR \
"projects/my-project/logs/cloudsql.googleapis.com%2Fmysql-slow.log") AND \
timestamp>="2022-04-26T07:00:00Z" AND timestamp<="2022-04-26T20:00:00Z" ' \
--project=my-project \
--format=json > local-logs.json