snmp 與 VMware ESXi

我任職的公司開發的產品，是基於 open-falcon 的監控軟體。北京快網的人，最近對我提了一個需求，要我用 snmp 去監控 VMware 的 ESXi system。

最初也沒有想得很清楚，一直以為要監控的重點是 Guest machine。直到我跟北京快網的運維再次確認之後，才搞懂，原來要監控的重點是 Host machine 。因為 Guest machine 通常是使用 CentOS ，這種都是可以跑 open-falcon agent ，自然也就不需要使用 snmp 了。然而， Host machine 的作業系統是 ESXi system ，沒有辦法安裝 open-falcon agent，所以才會需要使用 snmp 。

我接到工作的時候，翻了翻文件，很快地就找到了一個 open-source 的套件，叫 swcollector ，是特製的 open-falcon agent，可以用來存取 snmp 。但是，仔細看了它的設置檔之後，發現 swcollector 適合去做監控 switch 的事，但是這次的需求是要監控 ESXi system，其實跟 switch 也差很多。

最關鍵的點是 OID 的部分，因為其實 ESXi system，就跟許許多多的 switch 一樣，它使用自己特別的 OID。我下了 snmpwalk 指令，把 ESXi system 所有的 OID 全部撈回之後，就發現 OID 還真的不是一般的多。這邊還有一個插曲，我本來不知道其實我需要去 VMware 的網站上，下載 VMware 的 mib 檔。所以我撈回來的 OID 裡，會有一部分，一定是用數字呈現。後來我注意到可以去 VMware 的網站上下載 VMware ESXi 專屬的 mib 檔，安裝到 /usr/share/snmp/mibs 之後，才把一些本來看不懂的 OID 變成可愛的英文。

不知不覺，這個工作也即將完成。 https://github.com/humorless/esxicollector 

過去用得很開心的 MRTG, Catci, 底下都是靠這個 snmp 在運作，終於搞懂了 snmp 是怎麼運作的了。

用 python 來測試 system call 的行為

在客戶的機器上，發現 curl 和 ping 的 DNS 解析行為不一樣。查了半天，才發現原來是底層呼叫的系統呼叫不同。 curl 使用 getaddrinfo() ，而 ping 使用 gethostbyname() 。於是，這時我發現了有一個問題，過去沒有仔細思考過，在 linux 的 shell 環境之下，要怎麼樣可以測試「系統呼叫」的行為呢？ 查了一下，發現還是用 python 最省事。

另外，也是因為處理了這個問題，我才發現原來 DNS 也是有緩存的。Nscd caches libc-issued requests to the Name Service. If retrieving NSS data is fairly expensive, nscd is able to speed up consecutive access to the same data dramatically and increase overall system performance.  也因此，如果修改了 resolv.conf 的話，記得要叫 nscd 做一下重新載入。

Use the index, Luke

use-the-index-luke 是 SQL performance 的教學網站。 內容滿深入淺出的。我一開始是為了要理解 clustered index 和 primary key 有什麼關系，而查到這個網站。想不到立刻就看到這個網站上的一篇文章，談論「 MySQL 的預設值將 primary key 設定為 clustered index 這是不盡理想的設計」，文章的大意是：

1. 要使用 primary key 的話，建議要使用 non-clustered primary key。不要用 MySQL 的預設設置的 clustered primary key 。否則會得到 clustered index penalty 。
2. 效能的重點在 index-only scan 

由於網站上的文章也相當多，我讀了兩三篇之後，改變心意，用速成的方式來學好了。於是我做了網站上的習題。結果，五題裡頭，我還真的只會兩題，就是有讀過網站上文章所以才會寫兩題。 題目很有啟發性，下方就是其中的一題，題目是不好的 SQL 語句，要能夠看出效能的瓶頸才算通過。

SQL schema 設定 primary key 的 constraint

最近做的工作，我在產品的資料庫，新增了一張 table 。在 code review 時，被同事建議「要設定 primary key」。於是，我就順便研究了設定 primary key 的重要性及理由。

主要的原因如下：有設定 primary key 的 column ，其值必定是唯一的。目前設計的這個 table，它的 business logic 裡，有一個 column 它的值也是唯一存在的，不會有重複的值。既然 business logic 就隱含了 unique value 的概念，加上 Primary key 的 constraint 自然可以「讓錯誤看得出來是錯誤」。

而好的 Primary Key 該如何設定呢？
Good primary keys are essential to good database design. They let you query and modify each table row individually without changing other rows in the same table. When you evaluate candidates for a table's primary key, follow these rules:

• The primary key should consist of one column whenever possible.
• The name should mean the same 5 years from now as it does today.
• The data value should be non-null and remain constant over time.
• The data type should be either an integer or a short, fixed-width character.
• If you're using a character data type, the primary key should exclude differential capitalization, spaces, and special characters, which might be difficult to remember.