They may be confusing at first since two scales are used for multiple elements, with for example the left sacle (0 to 100) showing CPU usage in percent and SoC temperature, with the left scale (0 to 5) used for the other metrics such as CPU frequency in GHz, Active CPUs, etc… Each element can be easily disabled and enabled. That’s all good, but my favorite part is the Statistics tab with show really neat and useful charts. Once the installation is complete redirect your computer browser to the URL provided at the end of the script to access the web interface.Ĭlick on Start to make the system automatically collect data, and you’ll end up on the status page with version information, uptime, CPU usage, temperature, memory usage, SD card usage, and network traffic. It actually took around 8 minutes on my board, as it downloaded and installed required packages. So with a pretty simple and minimal OSS solution, I was able to setup monitoring for my home network! Over the last few days whenever my ISP had slightest of trouble, I can correlate it with my metrics! I mean I still can't do anything about it cause the other person on ISP's customer support is "Did you try rebooting your router" - the quintessential solution to all tech problems.Now you' re able to enjoy RPi - Monitor at http : //192.168.0.112:8888 This might be useful only to people self-hosting their DNS servers. We can similarly query the DNS response time by visualising the average response time for a DNS query. Since I scrape metrics at an interval of 1m(in order to not ping too frequently and disrupt my actual browsing experience), in this query I am averaging the data points for the metric ping_percent_packet_loss in a window.
The next graph is interesting, it lets me visualise the avg, min, max ping response time as well as the % packet loss plotted on the Y2 (right Y) axis.Īn interesting query to calculate uptime (just in the context whether the upstream is reachable) is: 100 - avg_over_time(ping_percent_packet_loss) Repeat this panel for the variable $url and you should be able to generate a nice row view like this.Īdditonally you can choose Thresholds and the Unit to be displayed in the panel with these options. % Total % Received % Xferd Average Speed Time Time Time CurrentĠ 0 0 0 0 0 0 0 -:-:-:-:-:-:- 0# HELP dns_query_query_time_ms Telegraf collected metricĭns_query_query_time_ms. I am using official Docker image to run the agent with the following config: docker run -name telegraf-agent -restart always -d -p 9283:9283 -v $ PWD /nf:/etc/telegraf/nf:ro telegrafĪfter running the above command, you should be able to see the metrics at localhost:9283/metrics $ curl localhost:9283/metrics | head With the above config in place, let's try running the agent and see what metrics we get. The output is in Prometheus format so it can be scraped and ingested by Prometheus' time-series DB. Getting back to the configuration part, ugin is a list of plugins that can be configured and I have configured the Ping and DNS plugin in my config. Urls = ĭomains = įirstly, so nice to see an Ops tool not using YAML. Here's what my nf looks like: # Input plugins This makes Telegraf extermely extensible, you could write a plugin (in Go) of your choice if you fancy that as well!
What this basically means is that you can configure multiple input plugins like DNS, ICMP, HTTP and export the data of these plugins in a format of your choice with Output plugins. Telegraf has the concept of Plugins for Input, Output, Aggregating and Processing.
MONITOR INTERNET UPTIME WITH RASPBERRY PI DOWNLOAD
To get started, we need to download Telegraf and configure the Ping plugin. I decided to run a Telegraf agent in my RPi connected to my home router over LAN and scrape metrics using Prometheus and visualise graphs in Grafana! For the non-patient readers, here's what my dashboard looks like!: Googling a bit more, I found Telegraf supports Prometheus format (amongst a huge list of others!) but this wasn't so clear in their docs. This is exactly what I've been looking for but for some reason, I had wrongly assumed Telegraf needs InfluxDB to store the data. So, I looked for other solutions and luckily happened to stumble upon oddtazz in one of the common Telegram groups where he shared his solution for the above: Telegraf ICMP plugin and Grafana. It's quite a great solution but for my current stack which involves Prometheus and Grafana, it meant I had to deploy a standalone tool separate from my monitoring stack - something which I wanted to avoid. SmokePing is written in Perl and is used to visualise network latencies. There are a couple of ways to go around this, a very popular and OSS solution is SmokePing.
That's what I do at work and when my home ISP started giving me random problems and I decided it would be nice to monitor my home network as well.
0 kommentar(er)
