Tag: error

PChome 修正了問題，以及 RFC 4074 的說明

早些時候測試發現 PChome 已經修正了之前提到的問題：「PChome 24h 連線會慢的原因...」、「PChome 24h 連線會慢的原因... (續篇)」，這邊除了整理一下以外，也要修正之前文章裡的錯誤。

在 RFC 4074 (Common Misbehavior Against DNS Queries for IPv6 Addresses) 裡面提到了當你只有 IPv4 address 時，DNS server 要怎麼回應的問題。

在「3. Expected Behavior」說明了正確的作法，當只有 A RR 沒有 AAAA RR 的時候，應該要傳回 NOERROR，而 answer section 裡面不要放東西：

Suppose that an authoritative server has an A RR but has no AAAA RR for a host name. Then, the server should return a response to a query for an AAAA RR of the name with the response code (RCODE) being 0 (indicating no error) and with an empty answer section (see Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that there is at least one RR of a different type than AAAA for the queried name, and the stub resolver can then look for A RRs.

在「4.2. Return "Name Error"」裡提到，如果傳回 NXDOMAIN (3)，表示查詢的這個名稱完全沒有 RR，而不僅僅限於 AAAA record，這就是我犯的錯誤 (在前面的文章建議傳回 NXDOMAIN)：

This type of server returns a response with RCODE 3 ("Name Error") to a query for an AAAA RR, indicating that it does not have any RRs of any type for the queried name.

With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with a query for an A RR, the negative response for the name has been cached in the caching server, and the caching server will simply return the negative response. As a result, the stub resolver considers this to be a fatal error in name resolution.

Several examples of this behavior are known to the authors. As of this writing, all have been fixed.

PChome 這次的修正回應了正確的值 (而不是我提到的 NXDOMAIN)：

$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<<<- opcode: QUERY, status: NOERROR, id: 40767
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;shopping.gs1.pchome.com.tw.    IN      AAAA

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      5       IN      SOA     ns1.gs1.pchome.com.tw. root.dns.pchome.com.tw. 20171123 3600 3 3600 5

;; Query time: 16 msec
;; SERVER: 210.242.216.91#53(210.242.216.91)
;; WHEN: Fri Nov 24 01:44:52 CST 2017
;; MSG SIZE  rcvd: 134

另外 RFC 也有一些其他的文件可以參考，像是 RFC 2308 (Negative Caching of DNS Queries (DNS NCACHE))、RFC 4697 (Observed DNS Resolution Misbehavior) 以及 RFC 8020 (NXDOMAIN: There Really Is Nothing Underneath)，這些文件描述了蠻多常見的問題以及正確的處理方法，讀完對於現在愈來愈複雜的 DNS 架構有不少幫助。

Reddit 在處理 Page View 的方式

Reddit 說明了他們如何處理 pageview：「View Counting at Reddit」。

以 Reddit 的規模有提到兩個重點，第一個在善用 Redis 的 HyperLogLog 這個資料結構，當量大的時候其實可以允許有微小的誤差：

The amount of memory varies per implementation, but in the case of this implementation, we could count over 1 million IDs using just 12 kilobytes of space, which would be 0.15% of the original space usage!

維基百科上有說明當資料量在 109 這個等級時，用 1.5KB 的記憶體只有 2% 的誤差值：

The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical error rate of 2%, using 1.5 kB of memory.

第二個則是寫入允許短時間的誤差 (pageview 不會即時反應)，透過批次處理降低對 Cassandra cluster 的負荷：

Writes to Cassandra are batched in 10-second groups per post in order to avoid overloading the cluster.

可以注意到把 Redis 當作 cache 層而非 storage 層。

主要原因應該跟 Redis 定位是 data structure server 而非 data structure storage 有關 (可以從對 Durability 的作法看出來)，而使用 Cassandra 存 key-value 非常容易 scale，但讀取很慢。剛好兩個相輔相成。

RightScale 介紹的 TrackJS

RightScale 介紹了 TrackJS 這個服務：「Why do we use TrackJS」。

可以看發生錯誤的 stack：

有錯誤的綜合分析：

然後可以將 minified 的 JS 試著展開，讀起來會比較容易，不過沒看到對 source map 的支援？

價位上比 Rollbar 低不少 ($249 在 TrackJS 可以記 10M，但在 Rollbar 只能記 1.5M)，不過 Rollbar 支援的平台比較多 (台灣也有代理商可以開發票處理帳務)，也許找機會用看看 TrackJS 再決定吧。

讓 nginx 看到 5xx 回應時，去另外一台有開 debug-mode 的 server 上再跑一次

Debug 模式會比一般的模式來的慢，但可以看到更多資訊。以往的問題是 5xx 難以重製，而 NGINX 的「Capturing 5xx Errors with a Debug Server」這篇文章介紹了如何用 nginx 實作標題的功能。

如果是隨機造成的問題就沒辦法重製，但如果是 client 的狀態造成的問題，就很有可能可以抓出來... 不是解決所有問題，但可以幫助解掉以前不太好解的狀況。

跳過 MySQL replication 失敗的方法...

在 MySQL replication 發生錯誤後，需要一邊 skip replication error，一邊跑 pt-table-sync 強制資料庫同步：

while true; do ( echo 'SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;' | mysql -h $1 ) || sleep 1; done

那個 sleep 1 的設計是用在「如果 replication 正常，停一下再跑一次」的前提下而設計的；如果不需要的話拿掉也是 okay 的。

要注意，能這樣跑的前提是 max_connect_errors 要開超大，我是設成 max_connect_errors = 4294967295。

NASA 用雷射光傳送「蒙娜麗莎」圖片到月球上...

NASA 用雷射光將灰階「蒙娜麗莎」傳送到月球軌道上的 LOLA (Lunar Orbiter Laser Altimeter，看起來是台描繪地表用的儀器？)：「NASA Beams Mona Lisa to Lunar Reconnaissance Orbiter at the Moon」。

Lunar Orbiter Laser Altimeter

傳輸速度是 300bits/sec (這數字讓人真感動 XD)，傳送 152x200 的 4096 灰階圖片。這次測試其中一個目的是了解地球大氣層對光訊號的影響，可以看到左邊的 raw data 與右邊靠 2/3 RS code 修正的結果：

To clean up transmission errors introduced by Earth's atmosphere (left), Goddard scientists applied Reed-Solomon error correction (right), which is commonly used in CDs and DVDs. Typical errors include missing pixels (white) and false signals (black). The white stripe indicates a brief period when transmission was paused.

不過好像沒提到用多大台的雷射打到月球上... (雷射砲？)

用 Google Analytics 紀錄 JavaScript 錯誤...

「Client-Side Error Logging With Google Analytics」這篇提到可以用 Google Analytics 紀錄 JavaScript 錯誤...

不過這不是即時的紀錄，倒是作者有提到可以交叉比對，當發生 JavaScript 錯誤對於其他參數的影響：

Track the impact of client-side errors on other business metrics. With the reporting in Google Analytics you can see how these errors are affecting bounce rate, conversion and sales.