很多使用者來問，這個名額是什麼意思，那個名額是什麼意思，解釋半天也解釋不明白，核心原因是，使用者對他要監控的目标本身就缺乏知識。比如Nightingale裡的一個net.in.dropped名額，表示入方向的網卡每秒丢包量，如果你從來沒有執行過ifconfig指令，對網絡丢包不知道是咋回事，真的就很難了解這個名額的意思了。
下面會分别講解一些常見名額的擷取方式，讓大家有個感性的認識，會帶出部分Linux基礎知識。坐好扶穩~
Linux相關名額舉例
Linux下很多名額都是來自/proc目錄下的一些資訊，這個目錄很特殊，從網上摘抄一段話給大家：
Linux系統上的/proc目錄是一種檔案系統，即proc檔案系統。與其它常見的檔案系統不同的是，/proc是一種僞檔案系統（也即虛拟檔案系統），存儲的是目前核心運作狀态的一系列特殊檔案，使用者可以通過這些檔案檢視有關系統硬體及目前正在運作程序的資訊，甚至可以通過更改其中某些檔案來改變核心的運作狀态。
基于/proc檔案系統如上所述的特殊性，其内的檔案也常被稱作虛拟檔案，并具有一些獨特的特點。例如，其中有些檔案雖然使用檢視指令檢視時會傳回大量資訊，但檔案本身的大小卻會顯示為0位元組。此外，這些特殊檔案中大多數檔案的時間及日期屬性通常為目前系統時間和日期，這跟它們随時會被重新整理（存儲于RAM中）有關。
為了檢視及使用上的友善，這些檔案通常會按照相關性進行分類存儲于不同的目錄甚至子目錄中，如/proc/scsi目錄中存儲的就是目前系統上所有SCSI裝置的相關資訊，/proc/N中存儲的則是系統目前正在運作的程序的相關資訊，其中N為正在運作的程序（可以想象得到，在某程序結束後其相關目錄則會消失）。
大多數虛拟檔案可以使用檔案檢視指令如cat、more或者less進行檢視，有些檔案資訊表述的内容可以一目了然，但也有檔案的資訊卻不怎麼具有可讀性。不過，這些可讀性較差的檔案在使用一些指令如apm、free、lspci或top檢視時卻可以有着不錯的表現。
我們挑一類簡單的名額：最近1min、5min、15min的負載資料，這3個名額我們平時用的比較多，執行uptime指令就能看到，比如：
[root@10-255-0-103 ~]# uptime
10:49:34 up 10 days, 16:54, 1 user, load average: 0.09, 0.14, 0.18 監控系統去采集的時候，并非是執行uptime指令，那就太low了，效率也差，實際上我們是從/proc/loadavg檔案讀取的，因為/proc的讀取不涉及真實的硬碟IO是以效率是非常高的。看一眼這個檔案的内容哈：
[root@10-255-0-103 ~]# cat /proc/loadavg
0.09 0.14 0.18 3/271 9043 看完了負載的名額，再看個記憶體使用率，我們經常用free -h來看記憶體使用情況，實際記憶體資料是在/proc/meminfo檔案，我們來看一眼：
[root@10-255-0-103 ~]# cat /proc/meminfo
MemTotal: 8008856 kB
MemFree: 208368 kB
MemAvailable: 3421636 kB
Buffers: 0 kB
Cached: 1499772 kB
SwapCached: 0 kB
Active: 4085356 kB
Inactive: 622092 kB
Active(anon): 3322972 kB
Inactive(anon): 73668 kB
Active(file): 762384 kB
Inactive(file): 548424 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 3312 kB
Writeback: 0 kB
AnonPages: 3207724 kB
Mapped: 155608 kB
Shmem: 188964 kB
Slab: 2948432 kB
SReclaimable: 2208352 kB MemTotal、MemFree、MemAvailable都有。
最後再看一下磁盤使用情況，這個要比上面兩個都更難擷取，不僅僅是讀取/proc的内容了。Linux上面的指令就是df -h，可以看到各個挂載點的使用情況。監控系統實際在采集這個資料的時候，是分成兩步。
第一步是讀取/proc/mounts擷取所有的挂載點，過濾掉一些虛拟挂載點，然後執行Statfs的一個系統調用才能得到這個分區的使用情況。
Redis相關名額舉例
我這有一個redis執行個體，連上去執行一下info指令給大家看看輸出：
[root@10-255-0-103 ~]# redis-cli
127.0.0.1:6379> info
# Server
redis_version:3.2.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:7897e7d0e13773f
redis_mode:standalone
os:Linux 3.10.0-957.27.2.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.8.5
process_id:5453
run_id:9c7374106c06eaf9762b9b9c4cc5e2862507b9f7
tcp_port:6379
uptime_in_seconds:925547
uptime_in_days:10
hz:10
lru_clock:8534430
executable:/usr/bin/redis-server
config_file:/etc/redis.conf
# Clients
connected_clients:7
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:1
# Memory
used_memory:946912
used_memory_human:924.72K
used_memory_rss:7606272
used_memory_rss_human:7.25M
used_memory_peak:1167288
used_memory_peak_human:1.11M
total_system_memory:8201068544
total_system_memory_human:7.64G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:8.03
mem_allocator:jemalloc-3.6.0
# Persistence
loading:0
rdb_changes_since_last_save:34
rdb_bgsave_in_progress:0
rdb_last_save_time:1619147033
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
# Stats
total_connections_received:243702
total_commands_processed:41498406
instantaneous_ops_per_sec:43
total_net_input_bytes:1086332717
total_net_output_bytes:270616329
instantaneous_input_kbps:1.08
instantaneous_output_kbps:0.26
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:6300
keyspace_misses:86977
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:241
migrate_cached_sockets:0
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
# CPU
used_cpu_sys:1479.91
used_cpu_user:812.97
used_cpu_sys_children:5.35
used_cpu_user_children:0.87
# Cluster
cluster_enabled:0
# Keyspace
db0:keys=3,expires=2,avg_ttl=2283306048 看到了吧，各種名額都有，當我們談到redis監控的時候，主要就是監控這些名額。
做得易用的監控，會允許你直接配置redis的連接配接位址，監控系統會自動連上去執行指令。如果沒有提供頁面配置方式，一般至少也會提供插件擴充方式，容許使用者寫腳本，用腳本去采集監控名額，然後将監控資料推給監控服務端。
應用業務層面名額監控
應用層面的監控主要是接口成功率、響應時長、QPS等，這些監控資料的采集，最好是能在統一的HTTP架構或RPC架構裡搞定，或者在統一的七層接入裡搞定，減少各業務接入成本。
如果要做trace監控或者業務層面的名額監控，那基本就隻能埋點了，比如監控系統的資料接口子產品，我想統計一下每秒接收多少個資料點，那就需要資料接收子產品在代碼裡寫相關的采集邏輯了。
通過日志提取名額，也是個典型手段，通常就是用ELK這種方案，把日志收集到中心，寫查詢語句去查詢分析。但這種方式比較重，我們在Nightingale中引入了一種更輕量的方案供大家參考。核心邏輯是在服務端配置正規表達式，下發到agent側，agent流式讀取日志檔案，每讀到一行，就用正則比對一下，看是否命中，如果命中，就可以從中提取出一些名額資訊。