整合營銷服務商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
誒嘿，如何使用西部數(shù)碼官方的api給機子的域名做解析呢？
看看下邊的代碼吧
import sys
import requests
import hashlib
import json
import warnings
warnings.filterwarnings("ignore")
class DomainApiUtils:
def __init__(self, api_url: str, user_name: str = None, api_password: str = None):
""" 初始化類，用戶認證和域名apidomainkey必選其一
:param api_url : 接口地址
:param user_name: 在西部數(shù)碼的賬號
:param api_password: SSL的專用api 密碼
"""
self.api_url = api_url
self.user_name = user_name
self.api_password = api_password
def get_public_parm(self, apidomainkey: str = None) -> dict:
""" 獲取公共參數(shù) """
if apidomainkey:
return {"apidomainkey": apidomainkey}
if not self.user_name or not self.api_password:
print("API 認證參數(shù)錯誤, 請選擇用戶認證或apidomainkey認證。程序退出")
sys.exit(0)
__apikey = self.get_convert_md5(self.api_password)
return {"username": self.user_name, "apikey": __apikey}
def get_convert_md5(self, __string: str, upper: bool = False) -> str:
""" 計算字符串md5值 """
__my_hash = hashlib.md5()
__my_hash.update(__string.encode('GBK'))
__hash = __my_hash.hexdigest()
return __hash.upper() if upper else __hash
def encode_parm(self, __rep_parm: dict, charset: str = 'GBK') -> dict:
""" 統(tǒng)一轉(zhuǎn)換參數(shù)編碼 """
__encoded_data = {}
for k, v in __rep_parm.items():
if isinstance(v, str):
__encoded_data[k] = v.encode(charset).decode(charset)
else:
__encoded_data[k] = v
return __encoded_data
def do_api(self, __act_url: str, rep_parm: dict = {}, apidomainkey: str = None, isget: bool = True):
''' 調(diào)用接口 '''
__api_url = self.api_url + __act_url if __act_url else self.api_url
__rep_status, __respon = self.request_act(__api_url, rep_parm, apidomainkey, isget)
return __rep_status, __respon
def request_act(self, __url: str, __rep_parm: dict, apidomainkey: str = None, isget: bool = True, timeout: int = 10, charset: str = 'GBK'):
''' 發(fā)起請求 '''
try:
session = requests.Session()
session.keep_alive = False
if isget:
__rep_parm.update(self.get_public_parm(apidomainkey))
__respon = session.get(__url, params=self.encode_parm(__rep_parm), timeout=timeout)
else:
__rep_parm = self.encode_parm(__rep_parm)
__respon = session.post(__url, data=__rep_parm, params=self.get_public_parm(apidomainkey), timeout=timeout)
return True, __respon
except requests.exceptions.RequestException as e:
return False, str(e)
def domain_dnsrec_add(self, __domain: str, __record_type: str, __hostname: str, __record_value: str, record_line: str = None, record_ttl: int = 900, record_level: int = None, apidomainkey: str = None):
""" 域名添加解析 """
print("############### 添加域名解析 #####################")
__rep_parm = {
"act": "dnsrec.add",
"domain": __domain,
"record_type": __record_type,
"hostname": __hostname,
"record_value": __record_value,
"record_line": record_line,
"record_ttl": record_ttl,
"record_level": record_level,
}
__rep_status, __respon = self.do_api(None, __rep_parm, apidomainkey=apidomainkey, isget=False)
if __rep_status:
__json_data = __respon.json()
print(json.dumps(__json_data, indent=4, sort_keys=True))
if __json_data.get('code') == 200:
return True, __json_data.get('body').get('record_id')
else:
return False, __json_data.get('msg')
else:
return False, "請求失敗"
if __name__ == '__main__':
api_url = 'https://api.west.cn/API/v2/domain/dns/' # 接口地址
user_name = 'your_username' # 賬號
api_password = 'your_api_password' # api 密碼或使用apidomainkey
__util = DomainApiUtils(api_url, user_name, api_password)
############### 添加域名解析 #####################
__status, __body = __util.domain_dnsrec_add("example.com", "A", "www", "192.168.1.1")
print(__status, __body)
只要填寫這兩個部分就好了
= '' # 賬號
= '' # api 密碼或使用
而最后個就是添加解析記錄了，第一個是你要負責解析的域名，也就是，第二個是解析類型，第三個是主機名，第四個是對應值，只需要修改這括號里的就好了
, __body = __util.("", "A", "www", "192.168.1.1")
Linux 服務器性能參數(shù)指標中的蛛絲馬跡
【摘要】一個基于 Linux 操作系統(tǒng)的服務器運行的同時，會表征出各種各樣參數(shù)信息，這些蛛絲馬跡往往會幫助快速定位跟蹤問題。
這里只是一些簡單的工具查看系統(tǒng)的相關(guān)參數(shù)，當然很多工具也是通過分析加工 /proc、/sys 下的數(shù)據(jù)來工作的，而那些更加細致、專業(yè)的性能監(jiān)測和調(diào)優(yōu)，可能還需要更加專業(yè)的工具(perf、 等)和技術(shù)才能完成哦。畢竟來說，系統(tǒng)性能監(jiān)控本身就是個大學問。
一、CPU和內(nèi)存類1.1 top
? ~ top
第一行后面的三個值是系統(tǒng)在之前 1、5、15 的平均負載，也可以看出系統(tǒng)負載是上升、平穩(wěn)、下降的趨勢，當這個值超過 CPU 可執(zhí)行單元的數(shù)目，則表示 CPU 的性能已經(jīng)飽和成為瓶頸了。
第二行統(tǒng)計了系統(tǒng)的任務狀態(tài)信息。running 很自然不必多說，包括正在 CPU 上運行的和將要被調(diào)度運行的； 通常是等待事件(比如 IO 操作)完成的任務，細分可以包括 和 的類型；stopped 是一些被暫停的任務，通常發(fā)送 SIGSTOP 或者對一個前臺任務操作 Ctrl-Z 可以將其暫停；zombie 僵尸任務，雖然進程終止資源會被自動回收，但是含有退出任務的 task 需要父進程訪問后才能釋放，這種進程顯示為 defunct 狀態(tài)，無論是因為父進程提前退出還是未 wait 調(diào)用，出現(xiàn)這種進程都應該格外注意程序是否設(shè)計有誤。
第三行 CPU 占用率根據(jù)類型有以下幾種情況：
√ (us) user：CPU 在低 nice 值(高優(yōu)先級)用戶態(tài)所占用的時間(nice0)。默認新啟動的進程 nice=0，是不會計入這里的，除非手動通過 renice 或者 () 的方式修改程序的nice值
√ (id) idle：CPU 在空閑狀態(tài)(執(zhí)行 kernel idle handler )所占用的時間
√ (wa) iowait：等待 IO 完成做占用的時間
√ (hi) irq：系統(tǒng)處理硬件中斷所消耗的時間
√ (si) softirq：系統(tǒng)處理軟中斷所消耗的時間，記住軟中斷分為 、 (其實是前者的特例)、work queues，不知道這里是統(tǒng)計的是哪些的時間，畢竟 work queues 的執(zhí)行已經(jīng)不是中斷上下文了
√ (st) steal：在虛擬機情況下才有意義，因為虛擬機下 CPU 也是共享物理 CPU 的，所以這段時間表明虛擬機等待 調(diào)度 CPU 的時間，也意味著這段時間 將 CPU 調(diào)度給別的 CPU 執(zhí)行，這個時段的 CPU 資源被“stolen”了。這個值在我 KVM 的 VPS 機器上是不為 0 的，但也只有 0.1 這個數(shù)量級，是不是可以用來判斷 VPS 超售的情況？
CPU 占用率高很多情況下意味著一些東西，這也給服務器 CPU 使用率過高情況下指明了相應地排查思路：
√ 當 user 占用率過高的時候，通常是某些個別的進程占用了大量的 CPU，這時候很容易通過 top 找到該程序；此時如果懷疑程序異常，可以通過 perf 等思路找出熱點調(diào)用函數(shù)來進一步排查；
√ 當 system 占用率過高的時候，如果 IO 操作(包括終端 IO)比較多，可能會造成這部分的 CPU 占用率高，比如在 file server、 server 等類型的服務器上，否則(比如>20%)很可能有些部分的內(nèi)核、驅(qū)動模塊有問題；
√ 當 nice 占用率過高的時候，通常是有意行為，當進程的發(fā)起者知道某些進程占用較高的 CPU，會設(shè)置其 nice 值確保不會淹沒其他進程對 CPU 的使用請求；
√ 當 iowait 占用率過高的時候，通常意味著某些程序的 IO 操作效率很低，或者 IO 對應設(shè)備的性能很低以至于讀寫操作需要很長的時間來完成；
√ 當 irq/softirq 占用率過高的時候，很可能某些外設(shè)出現(xiàn)問題，導致產(chǎn)生大量的irq請求，這時候通過檢查 /proc/ 文件來深究問題所在；
√ 當 steal 占用率過高的時候，黑心廠商虛擬機超售了吧！
第四行和第五行是物理內(nèi)存和虛擬內(nèi)存(交換分區(qū))的信息：
total = free + used + buff/cache，現(xiàn)在buffers和cached Mem信息總和到一起了，但是buffers和cached Mem 的關(guān)系很多地方都沒說清楚。其實通過對比數(shù)據(jù)，這兩個值就是 /proc/meminfo 中的 Buffers 和 Cached 字段：Buffers 是針對 raw disk 的塊緩存，主要是以 raw block 的方式緩存文件系統(tǒng)的元數(shù)據(jù)(比如超級塊信息等)，這個值一般比較小(20M左右)；而 Cached 是針對于某些具體的文件進行讀緩存，以增加文件的訪問效率而使用的，可以說是用于文件系統(tǒng)中文件緩存使用。
而 avail Mem 是一個新的參數(shù)值，用于指示在不進行交換的情況下，可以給新開啟的程序多少內(nèi)存空間，大致和 free + buff/cached 相當，而這也印證了上面的說法，free + buffers + cached Mem才是真正可用的物理內(nèi)存。并且，使用交換分區(qū)不見得是壞事情，所以交換分區(qū)使用率不是什么嚴重的參數(shù)，但是頻繁的 swap in/out 就不是好事情了，這種情況需要注意，通常表示物理內(nèi)存緊缺的情況。
最后是每個程序的資源占用列表，其中 CPU 的使用率是所有 CPU core 占用率的總和。通常執(zhí)行 top 的時候，本身該程序會大量的讀取 /proc 操作，所以基本該 top 程序本身也會是名列前茅的。
top 雖然非常強大，但是通常用于控制臺實時監(jiān)測系統(tǒng)信息，不適合長時間(幾天、幾個月)監(jiān)測系統(tǒng)的負載信息，同時對于短命的進程也會遺漏無法給出統(tǒng)計信息。
1.2 vmstat
vmstat 是除 top 之外另一個常用的系統(tǒng)檢測工具，下面截圖是我用-j4編譯boost的系統(tǒng)負載。
r 表示可運行進程數(shù)目，數(shù)據(jù)大致相符；而b表示的是 睡眠的進程數(shù)目；swpd 表示使用到的虛擬內(nèi)存數(shù)量，跟 top-Swap-used 的數(shù)值是一個含義，而如手冊所說，通常情況下 buffers 數(shù)目要比 cached Mem 小的多，buffers 一般20M這么個數(shù)量級；io 域的 bi、bo 表明每秒鐘向磁盤接收和發(fā)送的塊數(shù)目(blocks/s)；system 域的 in 表明每秒鐘的系統(tǒng)中斷數(shù)(包括時鐘中斷)，cs表明因為進程切換導致上下文切換的數(shù)目。
說到這里，想到以前很多人糾結(jié)編譯 linux kernel 的時候 -j 參數(shù)究竟是 CPU Core 還是 CPU Core+1？通過上面修改 -j 參數(shù)值編譯 boost 和 linux kernel 的同時開啟 vmstat 監(jiān)控，發(fā)現(xiàn)兩種情況下 context switch 基本沒有變化，且也只有顯著增加 -j 值后 context switch 才會有顯著的增加，看來不必過于糾結(jié)這個參數(shù)了，雖然具體編譯時間長度我還沒有測試。資料說如果不是在系統(tǒng)啟動或者 的狀態(tài)，參數(shù) context switch>100000 程序肯定有問題。
1.3 pidstat
如果想對某個進程進行全面具體的追蹤，沒有什么比 pidstat 更合適的了——棧空間、缺頁情況、主被動切換等信息盡收眼底。這個命令最有用的參數(shù)是-t，可以將進程中各個線程的詳細信息羅列出來。
-r：顯示缺頁錯誤和內(nèi)存使用狀況，缺頁錯誤是程序需要訪問映射在虛擬內(nèi)存空間中但是還尚未被加載到物理內(nèi)存中的一個分頁，缺頁錯誤兩個主要類型是
√ minflt/s 指的 minor faults，當需要訪問的物理頁面因為某些原因(比如共享頁面、緩存機制等)已經(jīng)存在于物理內(nèi)存中了，只是在當前進程的頁表中沒有引用，MMU 只需要設(shè)置對應的 entry 就可以了，這個代價是相當小的
√ majflt/s 指的 major faults，MMU 需要在當前可用物理內(nèi)存中申請一塊空閑的物理頁面(如果沒有可用的空閑頁面，則需要將別的物理頁面切換到交換空間去以釋放得到空閑物理頁面)，然后從外部加載數(shù)據(jù)到該物理頁面中，并設(shè)置好對應的 entry，這個代價是相當高的，和前者有幾個數(shù)據(jù)級的差異
-s：棧使用狀況，包括 StkSize 為線程保留的棧空間，以及 StkRef 實際使用的棧空間。使用ulimit -s發(fā)現(xiàn)CentOS 6.x上面默認棧空間是10240K，而 CentOS 7.x、Ubuntu系列默認棧空間大小為8196K
-u：CPU使用率情況，參數(shù)同前面類似
-w：線程上下文切換的數(shù)目，還細分為cswch/s因為等待資源等因素導致的主動切換，以及nvcswch/s線程CPU時間導致的被動切換的統(tǒng)計
如果每次都先ps得到程序的pid后再操作pidstat會顯得很麻煩，所以這個殺手锏的-C可以指定某個字符串，然后Command中如果包含這個字符串，那么該程序的信息就會被打印統(tǒng)計出來，-l可以顯示完整的程序名和參數(shù)
? ~ pidstat -w -t -C “ailaw” -l
這么看來，如果查看單個尤其是多線程的任務時候，pidstat比常用的ps更好使！
1.4 其他
當需要單獨監(jiān)測單個 CPU 情況的時候，除了 htop 還可以使用 mpstat，查看在 SMP 處理器上各個 Core 的工作量是否負載均衡，是否有某些熱點線程占用 Core。
? ~ mpstat -P ALL 1
如果想直接監(jiān)測某個進程占用的資源，既可以使用top -u taozj的方式過濾掉其他用戶無關(guān)進程，也可以采用下面的方式進行選擇，ps命令可以自定義需要打印的條目信息：
while :; do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd'; sleep 1; done
如想理清繼承關(guān)系，下面一個常用的參數(shù)可以用于顯示進程樹結(jié)構(gòu)，顯示效果比pstree詳細美觀的多
? ~ ps axjf
二、磁盤IO類
iotop 可以直觀的顯示各個進程、線程的磁盤讀取實時速率；lsof 不僅可以顯示普通文件的打開信息(使用者)，還可以操作 /dev/sda1 這類設(shè)備文件的打開信息，那么比如當分區(qū)無法 umount 的時候，就可以通過 lsof 找出磁盤該分區(qū)的使用狀態(tài)了，而且添加 +fg 參數(shù)還可以額外顯示文件打開 flag 標記。
2.1 iostat
? ~ iostat -xz 1
其實無論使用 iostat -xz 1 還是使用 sar -d 1，對于磁盤重要的參數(shù)是：
√ avgqu-s：發(fā)送給設(shè)備 I/O 請求的等待隊列平均長度，對于單個磁盤如果值>1表明設(shè)備飽和，對于多個磁盤陣列的邏輯磁盤情況除外
√ await(r_await、w_await)：平均每次設(shè)備 I/O 請求操作的等待時間(ms)，包含請求排列在隊列中和被服務的時間之和；
√ svctm：發(fā)送給設(shè)備 I/O 請求的平均服務時間(ms)，如果 svctm 與 await 很接近，表示幾乎沒有 I/O 等待，磁盤性能很好，否則磁盤隊列等待時間較長，磁盤響應較差；
√ %util：設(shè)備的使用率，表明每秒中用于 I/O 工作時間的占比，單個磁盤當 %util>60% 的時候性能就會下降(體現(xiàn)在 await 也會增加)，當接近100%時候就設(shè)備飽和了，但對于有多個磁盤陣列的邏輯磁盤情況除外；
還有，雖然監(jiān)測到的磁盤性能比較差，但是不一定會對應用程序的響應造成影響，內(nèi)核通常使用 I/O 技術(shù)，使用讀寫緩存技術(shù)來改善性能，不過這又跟上面的物理內(nèi)存的限制相制約了。
上面的這些參數(shù)，對網(wǎng)絡文件系統(tǒng)也是受用的。
三、網(wǎng)絡類
網(wǎng)絡性能對于服務器的重要性不言而喻，工具 iptraf 可以直觀的現(xiàn)實網(wǎng)卡的收發(fā)速度信息，比較的簡潔方便通過 sar -n DEV 1 也可以得到類似的吞吐量信息，而網(wǎng)卡都標配了最大速率信息，比如百兆網(wǎng)卡千兆網(wǎng)卡，很容易查看設(shè)備的利用率。
通常，網(wǎng)卡的傳輸速率并不是網(wǎng)絡開發(fā)中最為關(guān)切的，而是針對特定的 UDP、TCP 連接的丟包率、重傳率，以及網(wǎng)絡延時等信息。
3.1 netstat
? ~ netstat -s
顯示自從系統(tǒng)啟動以來，各個協(xié)議的總體數(shù)據(jù)信息。雖然參數(shù)信息比較豐富有用，但是累計值，除非兩次運行做差才能得出當前系統(tǒng)的網(wǎng)絡狀態(tài)信息，亦或者使用 watch 眼睛直觀其數(shù)值變化趨勢。所以netstat通常用來檢測端口和連接信息的：
netstat –all(a) –numeric(n) –tcp(t) –udp(u) –timers(o) –(l) –program(p)
–timers可以取消域名反向查詢，加快顯示速度；比較常用的有
? ~ netstat -antp #列出所有TCP的連接
? ~ netstat -nltp #列出本地所有TCP偵聽套接字，不要加-a參數(shù)
3.2 sar
sar 這個工具太強大了，什么 CPU、磁盤、頁面交換啥都管，這里使用 -n 主要用來分析網(wǎng)絡活動，雖然網(wǎng)絡中它還給細分了 NFS、IP、ICMP、SOCK 等各種層次各種協(xié)議的數(shù)據(jù)信息，我們只關(guān)心 TCP 和 UDP。下面的命令除了顯示常規(guī)情況下段、數(shù)據(jù)報的收發(fā)情況，還包括
TCP
? ~ sudo sar -n TCP,ETCP 1
√ active/s：本地發(fā)起的 TCP 連接，比如通過 connect()，TCP 的狀態(tài)從CLOSED -> SYN-SENT
√ passive/s：由遠程發(fā)起的 TCP 連接，比如通過 accept()，TCP 的狀態(tài)從LISTEN -> SYN-RCVD
√ retrans/s()：每秒鐘 TCP 重傳數(shù)目，通常在網(wǎng)絡質(zhì)量差，或者服務器過載后丟包的情況下，根據(jù) TCP 的確認重傳機制會發(fā)生重傳操作
√ isegerr/s()：每秒鐘接收到出錯的數(shù)據(jù)包(比如 失敗)
UDP
? ~ sudo sar -n UDP 1
√ noport/s()：每秒鐘接收到的但是卻沒有應用程序在指定目的端口的數(shù)據(jù)報個數(shù)
√ idgmerr/s()：除了上面原因之外的本機接收到但卻無法派發(fā)的數(shù)據(jù)報個數(shù)
當然，這些數(shù)據(jù)一定程度上可以說明網(wǎng)絡可靠性，但也只有同具體的業(yè)務需求場景結(jié)合起來才具有意義。
3.3 tcpdump
tcpdump 不得不說是個好東西。大家都知道本地調(diào)試的時候喜歡使用 ，但是線上服務端出現(xiàn)問題怎么弄呢？
附錄的參考文獻給出了思路：復原環(huán)境，使用 tcpdump 進行抓包，當問題復現(xiàn)(比如日志顯示或者某個狀態(tài)顯現(xiàn))的時候，就可以結(jié)束抓包了，而且 tcpdump 本身帶有 -C/-W 參數(shù)，可以限制抓取包存儲文件的大小，當達到這個這個限制的時候保存的包數(shù)據(jù)自動 rotate，所以抓包數(shù)量總體還是可控的。此后將數(shù)據(jù)包拿下線來，用 想怎么看就怎么看，豈不樂哉！tcpdump 雖然沒有 GUI 界面，但是抓包的功能絲毫不弱，可以指定網(wǎng)卡、主機、端口、協(xié)議等各項過濾參數(shù)，抓下來的包完整又帶有時間戳，所以線上程序的數(shù)據(jù)包分析也可以這么簡單。
下面就是一個小的測試，可見 Chrome 啟動時候自動向 發(fā)起建立了三條連接，由于這里限制了 dst port 參數(shù)，所以服務端的應答包被過濾掉了，拿下來用 打開，SYNC、ACK 建立連接的過程還是很明顯的！在使用 tcpdump 的時候，需要盡可能的配置抓取的過濾條件，一方面便于接下來的分析，二則 tcpdump 開啟后對網(wǎng)卡和系統(tǒng)的性能會有影響，進而會影響到在線業(yè)務的性能。
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
