Tag: influxdb

自己從頭搞整套 Pi-hole 方案 (DNS 阻擋廣告的方案)

如果不用 Pi-hole 這種套件的話，從頭自己搞差不多就是這樣：「Ads blocking with OpenBSD unbound(8)」。

作者除了阻擋的必要功能部份以外，還把 log 導出來丟進 InfluxDB，透過 Grafana 可以看狀態，這類似於 Pi-hole 提供的方案：

Grafana to render the statistics ;
InfluxDB to store the information ;
syslogd(8) and awk(1) to turn DNS queries into statistics ;
collectd(1) and shell script to store unbound statistics and logs ;
unbound(8) and shell script to get and block DNS queries.

對應的 diagram 長這樣 (但為什麼作者要用 comic sans 呢...)：

瀏覽器可以用 uBlock Origin 這類方案來做，可以擋的更細緻，而手機 app 一般就只能靠這種方法過濾掉部份的廣告。

如果想要擋更多的話 (像是只擋某個 url，而不是整個 domain)，得用自建的 root CA 加上 MITM 的方式攔 HTTPS 連線，這通常都是在手機上面跑 virtual VPN，像是 iOS 上的 Surge 5 或是 Quantumult X。

DNSFilter 使用 InfluxDB 與 TimescaleDB 的過程

DNSFilter 這篇講 InfluxDB 與 TimescaleDB 的文章頗有趣的：「Towards 3B time-series data points per day: Why DNSFilter replaced InfluxDB with TimescaleDB」。

在沒有實際用過之前，其實都只能算是一方之詞... 另外這種轉換其實也跟每個公司內的組織組成有關，像是熟悉 PostgreSQL 的單位就比較有機會用 TimescaleDB 解決 time series data 的問題。

不過有個地方倒是讓我想記錄起來：

Comparing TimescaleDB to InfluxDB at the same time — we realized we were losing data. InfluxDB relied on precisely timed execution of rollup commands to process the last X minutes of data into rollups. Combined with our series of rollups, we realized that some slow queries were causing us to lose data. The TimescaleDB data had 1–5% more entries! Also we no longer had to deal with cardinality issues, and could show our customers every last DNS request, even at a monthly rollup.

會掉資料等於是跟 InfluxDB 的使用者發出警訊，要大家確認自己手上的資料是否正確... 這對於正確性要求 100% 的應用就不是開玩笑了 @_@