Sentry 的替代品:GlitchTip

GlitchTipSentry 的替代品,你仍然可以用 Sentry SDK 發送錯誤訊息,但接收端則是換成 GlitchTip。

Sentry 本身已經是 open source software 了 (可以在 getsentry/self-hosted 這邊裝) (參考「Sentry 的 License 不是 Open Source License...」),但最近的版本愈來愈肥,8GB RAM + 512MB Swap 的機器,光跑起來就蠻吃緊的。

對於在 AWS 的人來說,這等於被迫要用 16GB RAM 的機器跑 Sentry,像是 r6a.large (在 us-east-1 為 $0.1134/hr,約 $81.6/mo),如果是一年 RI 的話可以六折,三年 RI 可以四折,是有點費用,但這個費用對於公司用戶來說通常沒有太大問題。

GCP 的話也類似,但可以開 10GB RAM 來用,真的有用到的時候再逐步拉高記憶體空間,不過成本結構跟 AWS 是差不多的,所以對於公司也不是太大問題。

但對個人來說,光一個 Sentry 一個月就得花個 $80/mo 實在是太貴,而且考慮到這兩年的 Sentry 愈來愈沒有在管記憶體用量了:從之前 4GB RAM 能跑,到現在 8GB RAM 光開機就沒有 free memory,可以想像之後應該會愈來愈肥,所以試著找了替代方案。

目前看到的替代方案是 GlitchTip,在 server 端吃同樣的 input,所以 client 端可以維持原來的 sentry sdk,可以用雲端服務,也可以自己架設:「GlitchTip Installation Guide」。

跑起來後大約吃 500MB RAM,基本的功能都有,包括基本的 event group & call stack information,以及常用的 integration (像是 E-mail 通知與 Slack 通知),但畫面上沒有 Sentry 那麼好看,不過還算是乾淨。

有些功能要找文件 trial and error,跟 Sentry 文件相比起來完整度差一點,但還行...。

目前看起來自己用可以用這個,Sentry 真的太胖了...

關於 Hacker News 上在討論 Microsoft Teams 的一些有趣的發現

Hacker News 上看到「Ask HN: Why is MS Teams so slow, do devs test Teams on less powerful machines?」這串討論,發起的作者提到了超級吃資源的問題:

I have a laptop with an i5 processor and 8G of RAM. Hard drive is an SSD. It sometimes takes me a full minute and a half to get Teams open and ready to join a meeting. It is driving me crazy.

可以預期下面本來就會有一堆人在抱怨,不過意外看到有趣的回應:

Ex office dev here. Actual dev work is done on i9 workstations running 64 gb of ram, and usually located very near an Azure data center, regardless of where the dev works. The result is that it's fast for us.

Everyone knows that it runs like poop, but there are other priorities, and no performance regression tests.

所以你應該只要電腦夠暴力 + 離機房夠近就會快了 XDDD

的確像是最上面的 comment 提到的,開發者因為都用 MBP,至少還能動 (因為機器夠快),但其他團隊則是一直幹勦:

At my company, the developers are all on fairly powerful MacBook Pros, and everyone else in the company has Windows laptops (I think generally Surface devices)

For the developers, Teams works... as good as Teams can. So not great, but it works most of the time (for me, anyway). For everyone else though, I hear nothing but issues. Constantly having to restart to make Teams work. And again, this is on Surface devices, so Microsoft is making the app, the OS, and the hardware!

Ribbon filter

RocksDB 的 blog 上看到「Ribbon Filter」這個,主要是 RocksDB 從 6.15 開始支援 Ribbon filter,取代本來的 Bloom filter 機制。

RocksDB 的 wiki 上面是說用 CPU 資源換 memory 的使用量:

A new Bloom filter alternative is available as a drop-in replacement (since version 6.15.0), saving about 30% of Bloom filter space (most importantly, memory) but using about 3-4x as much CPU on filters. Most of the additional CPU time is in the background jobs constructing the filters, and this is usually a good trade because it is common for SST filters to use ~10% of system RAM and well under 1% of CPU.

論文則是在「Ribbon filter: practically smaller than Bloom and Xor」這邊可以看到,Facebook 之前也有提到 Ribbon filter:「Ribbon filter: Practically smaller than Bloom and Xor」,在 Hacker News 上有對應的討論可以翻:「Ribbon filter: Practically smaller than Bloom and Xor (fb.com)」。

在 Ribbon filter 的資料裡面都提到了 Xor filter 當作比較,先前在「比 Bloom filter 與 Cuckoo filter 再更進一步的 Xor filter」這邊有提到 Xor filter。

用 CPU 去換記憶體,算是特化的版本...

GET 與 POST 的差異

看到這篇在講 HTTP (& HTTPS) 裡面 GET 與 POST 的差異,剛好把一些標準的定義拿出來翻一翻,算是複習基本概念:「Get safe」。

第一個基本概念主要是 idempotence (& idempotent),重複被呼叫不會造成狀態的再次改變:

Idempotence ([...]) is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application.

數學定義是這樣跑:

An element x of a magma (M, •) is said to be idempotent if:

x • x = x.

If all elements are idempotent with respect to •, then • is called idempotent. The formula ∀x, x • x = x is called the idempotency law for •.

這點在 HTTP 標準 (RFC 7231) 裡面的定義也類似:

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

第二個基本概念是 Safe method (也是在同樣的 RFC 裡被提到),主要的思想是 read-only,這也是文章作者的標題要講的事情:

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

然後標準的 HTTP method 是有定義的:

   +---------+------+------------+---------------+
   | Method  | Safe | Idempotent | Reference     |
   +---------+------+------------+---------------+
   | CONNECT | no   | no         | Section 4.3.6 |
   | DELETE  | no   | yes        | Section 4.3.5 |
   | GET     | yes  | yes        | Section 4.3.1 |
   | HEAD    | yes  | yes        | Section 4.3.2 |
   | OPTIONS | yes  | yes        | Section 4.3.7 |
   | POST    | no   | no         | Section 4.3.3 |
   | PUT     | no   | yes        | Section 4.3.4 |
   | TRACE   | yes  | yes        | Section 4.3.8 |
   +---------+------+------------+---------------+

不過文章裡面提到的第一個例子並沒有很好,POST 不保證 safe 沒錯,但不代表 safe operation 就不能用 POST。

這邊用 URI resource 的概念 (以及 SEO?) 或是用 Post/Redirect/Get 的概念來說明會比較好:

<form method="get" action="/search">
<input type="search" name="term">

不過文章後續提到的問題的確就是我自己都會犯錯的問題:

“Log out” links that should be forms with a “log out” button—you can always style it to look like a link if you want.

“Unsubscribe” links in emails that immediately trigger the action of unsubscribing instead of going to a form where the POST method does the unsubscribing. I realise that this turns unsubscribing into a two-step process, which is a bit annoying from a usability point of view, but a destructive action should never be baked into a GET request.

這兩個動作都會造成 server 端的狀態改變,不應該用 GET,而我自己常常忘記第一個... 這邊其實可以用 form 產生 POST 需求,並且用 css 效果包起來,達到看起來跟一般的連結一樣。

寫起來讓自己多一點印象,之後避免再犯一樣的錯誤...

用 GitHub Actions 記錄 API 資料的變化

Hacker News Daily 上看到的方式,Simon Willison 利用了 GitHub Actions 定時去抓資料更新 git repository:「Git scraping: track changes over time by scraping to a Git repository」。

文章裡面測試了 JSON 檔案的變化:

這個方式利用了 GitHub 自家的架構做完所有的事情,因為他的範例是拉加州政府的資料,感覺 g0v 裡應該有些專案也用這個方式搞,翻了一下 Telegram 上的記錄,果然翻到記錄了:「零營運費用開源開發」。

另外我猜用 free-for.dev 這邊的資源應該也有機會堆出類似的東西...

EC2 的 Auto Scaling 增加了兩個功能

Amazon EC2Auto Scaling 增加了兩個功能,一個是 instance 可以有權重了:「Amazon EC2 Auto Scaling Now Supports Instance Weighting」,另外一個是可以設定 instance 活多久就要換一台:「Amazon EC2 Auto Scaling Now Supports Maximum Instance Lifetime」。

前面的 instance weighting 這個功能對於會混多種不同 family type 的情境會好用不少 (像是同時混用 {c3,c4,c5}.xlarge),可以讓設定上細緻一些,不然就只能以效能最低的那個類型規劃...

後面的 maximum instance lifetime 這個功能看起來可以拿來解各種 resource leak 的情境,而且現在 EC2 instance 是以秒計費,所以不用太擔心成本浪費太多的問題... 這樣不管是 memory leak 還是 /tmp 下暫存檔懶的清的問題,都可以很順利的逃避現實 XDDD

Chrome 將不會在 HTTPS 頁面上載入 HTTP 資源...

現在 Google Chrome 的穩定版是 77,到了十二月會推出的 79 的時候,就會有一連串的避免 HTTPS 頁面使用 HTTP 資源的措施:「No More Mixed Messages About HTTPS」。

首先是 79 的時候會有新的界面,讓使用者可以修改阻擋類的設定。

到了 80 的時候會試著將 HTTP 的影音 <audio><video> 升級到 HTTPS 連線,如果 HTTPS 讀不到的話就當作讀取失敗。但圖片 <img> 的部份則是會讀進來,只是安全性上會顯示 Not Secure。

到了 81 就是這系列的最終階段,包括 <img> 也會一使用 80 時影音的邏輯,沒辦法在 HTTPS 上讀到就當作讀取失敗。

EC2 要從 Instance 數量限制改成 vCPU 數量限制

這算是 AWS 的保護機制,在 Amazon EC2 上能開的機器數量都是有限制的。

打算要用新的 vCPU 數量限制取代舊的 Instance 數量限制:「Using new vCPU-based On-Demand Instance limits with Amazon EC2」,然後現在可以先加入:「vCPU-based On-Demand Instance Limits are Now Available in Amazon EC2」。

這次改善的問題是,以往 m5.largem5.xlarge 是兩個不同的限制,所以用起來會比較卡,現在則改成用 vCPU 來管理。

這次的架構是改成,一般性的機器會有一個 vCPU 數量限制,其他不同特性的各自有自己的 vCPU 數量限制:

In addition to now measuring usage in number of vCPUs, there will only be five different On-Demand Instance limits—one limit that governs the usage of standard instance families such as A, C, D, H, I, M, R, T, and Z, and one limit per accelerated instance family for FPGA (F), graphic-intensive (G), general purpose GPU (P), and special memory optimized (X) instances.

9/24 可以先手動加入,會拿你現在的量會換算過去,然後 10/24 會全部都轉過去:

During a transition period from September 24, 2019, through October 24, 2019, you can opt in to receive vCPU-based instance limits. When you opt in, EC2 automatically computes your new limits, giving you access to launch at least the same number of instances (if not more) than you do currently. Beginning October 24, 2019, all accounts will switch to vCPU-based instance limits, and the current count-based instance limits will no longer be supported. Although the switchover will not impact your ability to launch EC2 instances, you should familiarize yourself with the new On-Demand Instance limits experience and opt into vCPU limits at a time of your choosing.

應該是會方便一些...

Facebook 的招募狀況

Facebook 的各種醜聞知道招募變難 (而且醜聞沒停過),但變得多困難則是第一次看到報導:「Facebook has struggled to hire talent since the Cambridge Analytica scandal, according to recruiters who worked there」。

新鮮人的接受從 85% 掉到 35%~55%,依據不同的學校而有差異:

Among top schools, Facebook’s acceptance rate for full-time positions offered to new graduates has fallen from an average of 85% for the 2017-2018 school year to between 35% and 55% as of December.

Among top schools, such as Stanford, Carnegie Mellon and Ivy League universities, Facebook’s acceptance rate for full-time positions offered to new graduates has fallen from an average of 85% for the 2017-2018 school year to between 35% and 55% as of December, according to former Facebook recruiters. The biggest decline came from Carnegie Mellon University, where the acceptance rate for new recruits dropped to 35%.

工程師則是從 90% 掉到 50%:

The company has seen a decline in its job offer acceptance rates to software engineer candidates from nearly 90% in late 2016 to almost 50% in early 2019.

Facebook 發言人 Anthony Harrison 否認,不過沒有給出說明:

After the publication of this story, Harrison contacted CNBC to say "these numbers are totally wrong."

Facebook disputed the accuracy of the recruiters' accounts, but declined to point out any specific points that were wrong.

Hacker News 上的討論也蠻有趣的:「https://news.ycombinator.com/item?id=19931977」,有不少其他的觀察。

Amazon Lightsail 試用兩天的心得...

前幾天在「Amazon Lightsail 降價...」這篇文章提到了 Lightsail 這波降價還蠻有競爭力的,但之前看過「Is the fact that Lightsail instances are just renamed T2 instances that run on CPU credits actually documented anywhere?」這篇,大概知道 Lightsail 後面其實就是 t2 系列的機器,只是在這次 t3 出來後的改版不知道有沒有順便一起改...

前幾天直接把 blog + wiki 整個搬過去看看。本來在 Vultr 的主機是 1GB RAM,就挑了對應的方案搬過去... 如果還是 t2 的話,應該就會是 t2.micro 的機器。

由於搬家前面一天都在弄各種環境,所以應該累積了不少 CPU credit,實際的情況還是要等 DNS 指過來超過一天後才會知道。在剛剛跑了一整天,把 CPU credit 吃差不多後確認了,應該還是 t2.micro,baseline 在 10% (被降速了):

這樣的話就維持在 Vultr 好了... CPU 資源看起來還是用超過了。