## 常見問題
### 一般問題
#### 1. Prometheus是什么?
> Prometheus是一款高活躍生態系統的開源系統監控和警告工具包。詳見[概覽](https://prometheus.io/docs/introduction/overview/)
#### 2. Prometheus與其他的監控系統比較
> 詳見[比較](https://prometheus.io/docs/introduction/comparison/)
#### 3. Prometheus有什么依賴?
> Prometheus服務獨立運行,沒有其他依賴
#### 4. Prometheus有高可用的保證嗎?
> 是的,在多臺服務器上運行相同的Prometheus服務,相同的報警會由警告管理器刪除
> 警告管理器當前不能保證高可用,但高可用是目標
#### 5. 我被告知Prometheus"不能水平擴展"
> 事實上,有許多方式可以擴展Prometheus。 閱讀Robust Percetion的博客關于Prometheus的[擴展](https://www.robustperception.io/scaling-and-federating-prometheus/)
#### 5. Prometheus是什么語言寫的?
> 大多數Prometheus組件是由Go語言寫的。還有一些是由Java,Python和Ruby寫的
#### 6. Prometheus的特性、存儲格式和APIs有多穩定?
> Prometheus從v1.0.0版本開始就非常穩定了,我們現在有一些版本功能規劃,詳見[路線圖](https://prometheus.io/docs/introduction/roadmap/)
#### 7. 為什么是使用的是pull而不是push?
基于Http方式的拉模型提供了一下優點:
- 當開發變化時,你可以在筆記本上運行你的監控
- 如果目標實例掛掉,你可以很容易地知道
- 你可以手動指定一個目標,并通過瀏覽器檢查該目標實例的監控狀況
總體來說,我們相信拉模式比推模式要好一地啊你,但是當考慮一個監控系統時,它不是主要的考慮點
[Push vs. Pull](http://www.boxever.com/push-vs-pull-for-monitoring)監控在Brian Brazil的博客中被詳細的描述
如果你必須要用Push模式,我們提供[Pushgateway](https://prometheus.io/docs/instrumenting/pushing/)
#### 8. 怎么樣把日志推送到Prometheus系統中?
> 簡單地回答:千萬別這樣做,你可以使用ELK棧去實現
> 比較詳細的回答:Prometheus是一款收集和處理度量指標的系統,并非事件日志系統。Raintank的博客有關[日志、度量指標和圖表](https://blog.raintank.io/logs-and-metrics-and-graphs-oh-my/)在日志和度量指標之間,進行了詳盡地闡述。
如果你想要從應用日志中提取Prometheus度量指標中。 谷歌的[mtail](https://github.com/google/mtail)可能會更有幫助
#### 9. 誰寫的Prometheus?
> Prometheus項目發起人是Matt T. Proud和Julius Volz。 一開始大部分的開發是由SoundCloud贊助的
> 現在它由許多公司和個人維護和擴展
#### 10. 當前Prometheus的許可證是用的哪個?
> Apache 2.0
#### 11. Prometheus單詞的復數是什么?
> Prometheis
#### 12. 我能夠動態地加載Prometheus的配置嗎?
> 是的,通過發送SIGHUP信號量給Prometheus進行,將會重載配置文件。不同的組件會優雅地處理失敗的更改
#### 13. 我能發送告警嗎?
> 是的,通過警告管理器
當前,下面列表的外部系統都是被支持的
- Email
- General Webhooks
- PagerDuty(http://www.pagerduty.com/)
- HipChat(https://www.hipchat.com/)
- Slack(https://slack.com/)
- Pushover(https://pushover.net/)
- Flowdock(https://www.flowdock.com/)
#### 14. 我能創建Dashboard嗎?
> 是的,但是在生產使用中,我們推薦用[Grafana](https://prometheus.io/docs/visualization/grafana/)。[PromDash](https://prometheus.io/docs/visualization/promdash/)和[Console templates](https://prometheus.io/docs/visualization/consoles/)也可以
#### 15. 我能改變timezone和UTC嗎?
> 不行。為了避免任何時區的困惑和混亂,我們用了UTC這個通用單位
### 工具庫
#### 1. 哪些語言有工具庫?
> 這里有很多客戶端庫,用Prometheus的度量指標度量你的服務。詳見[客戶庫](https://prometheus.io/docs/instrumenting/clientlibs/)
> 如果你對功能工具庫非常感興趣,詳見[exposition formats](https://prometheus.io/docs/instrumenting/exposition_formats/)
#### 2. 我能監控機器嗎?
> 是的。[Node Exporter](https://github.com/prometheus/node_exporter)暴露了很多機器度量指標,包括CPU使用率、內存使用率和磁盤利用率、文件系統的余量和網絡帶寬等數據
#### 3. 我能監控網絡數據嗎?
> 是的。[SNMP Exporter](https://github.com/prometheus/snmp_exporter)允許監控網絡設備
#### 4. 我能監控批量任務嗎?
> 是的,通過[Pushgateway](https://prometheus.io/docs/instrumenting/pushing/). 詳見[最佳實踐](https://prometheus.io/docs/practices/instrumentation/#batch-jobs)
#### 5. Prometheus的第三方工具有哪些?
> 詳見[exporters for third-party systems](https://prometheus.io/docs/instrumenting/exporters/)
#### 6. 我能通過JMX監控JVM應用程序嗎?
> 是的。不能直接使用Java客戶端進行測試的應用程序,你可以將[JMX Exporter](https://github.com/prometheus/jmx_exporter)單獨使用或者Java代理使用
#### 7. 工具對性能的影響是什么?
> 客戶端和語言的性能可能不同。對于Java,基準表明使用Java客戶端遞增計數器需要12~17ns,具體依賴于競爭。最關鍵的延遲關鍵代碼之外的所有代碼都是可以忽略的。
### 故障排除
#### 1. 當服務崩潰恢復后,我的服務需要很多時間啟動和清理垃圾日志。
> 你的服務可能遭到了不干凈的關閉。Prometheus必須在SIGTERM后徹底關閉,特別地對于一些重量級服務可能需要比較長的時間去。如果服務器崩潰或者司機(如:在等待Prometheus關閉時,內核的OOM殺死你的Prometheus服務),必須執行崩潰恢復,這在正常情況下需要不到一分鐘。詳見[崩潰恢復](https://prometheus.io/docs/operating/storage/#crash-recovery)
#### 2. 我在Linux上使用ZFS,單元測試TestPersistLoadDropChunks失敗。盡管測試失敗,我運行Prometheus服務,奇怪的事情會發生。
你在Linux上有bug的ZFS文件系統運行Prometheus服務。詳見[Issue #484](https://github.com/prometheus/prometheus/issues/484), 在linux v.0.6.4上升級ZFS應該可以解決該問題。
### 實現
#### 1. 為什么所有樣品值都是float64數據類型?我想要integer數據類型。
> 我們限制了float64以簡化設計,IEEE 754雙精度二進制浮點格式支持高達253的值的整數精度。如果您需要高于253但低于263的整數精度,支持本地64位整數將有幫助。原則上,支持不同的樣本值類型 (包括某種大整數,支持甚至超過64位)可以實現,但它現在不是一個優先級。 注意,一個計數器,即使每秒增加100萬次,只有在超過285年后才會出現精度問題。
#### 2. 為什么Prometheus使用自定義的存儲后端,而不是使用其他的存儲方法?是不是“一個時間序列一個文件”會大大地傷害性能?
> 一開始,Prometheus是在LevelDB上存儲事件序列數據,但不能達到比較好的性能,我們必須改變大量時間序列的存儲方式。我們評估了當時可用的許多存儲系統,但是沒有得到滿意的結果。所以我們實現了我們需要的部分。同時保持LevelDB的索引和大量使用文件系統功能。我們最重要的要求是對于常見查詢的可接受查詢速度,以及每秒數千個樣本的可持續速率。后者取決于樣本數據的可壓縮性和樣本所屬的時間序列數,但是給你一個想法,這里有一些基準的結果:
- 在具有Intel Core i7 CPU,8GiB RAM和兩個旋轉磁盤(三星HD753LJ)的老式8核機器上,Prometheus在每個RAID-1設置中的吞吐速率為34k樣本,屬于170k時間序列, 600個目標。
- 在具有64GiB RAM,32個CPU內核和SSD的現代服務器上,Prometheus的每秒吞吐率為525k樣本,屬于1.4M時間序列,從1650個目標中剔除。
在這兩種情況下,沒有明顯的瓶頸。在相同的流入速度下,各個階段的處理管道或多或少都會達到他們的限度。
在通常的設置中,不可能使用inode。 有一個可能的缺點:如果你想刪除Prometheus的存儲目錄,你會注意到,一些文件系統在刪除文件時非常慢。
#### 3. 為什么Prometheus服務器組件不支持TLS或身份驗證? 我可以添加這些嗎?
> 雖然TLS和身份驗證是經常請求的功能,但我們有意不在Prometheus的任何服務器端組件中實現它們。 有這么多不同的選項和參數(僅限TLS的10多個選項),我們決定專注于建立最佳的監控系統,而不是在每個服務器組件中支持完全通用的TLS和身份驗證解決方案。
如果您需要TLS或身份驗證,我們建議將反向代理放在Prometheus前面。 參見例如使用Nginx添加對Prometheus的基本認證。
請注意,這僅適用于入站連接。 Prometheus確實支持刪除TLS-和auth啟用的目標,以及其他創建出站連接的Prometheus組件具有類似的支持。