{"id":2958,"date":"2018-09-18T06:00:04","date_gmt":"2018-09-18T06:00:04","guid":{"rendered":"https:\/\/blog.ssdnodes.com\/blog\/?p=2710"},"modified":"2025-05-18T19:01:12","modified_gmt":"2025-05-18T19:01:12","slug":"vps-monitoring-self-hosting","status":"publish","type":"post","link":"https:\/\/www.ssdnodes.com\/blog\/vps-monitoring-self-hosting\/","title":{"rendered":"Smart VPS monitoring with NetData and Docker"},"content":{"rendered":"<p>Welcome to the sixth page of our handbook on self-hosting. Begin <a href=\"https:\/\/www.ssdnodes.com\/blog\/self-hosting-handbook\/\">here<\/a>. Read the previous page <a href=\"https:\/\/www.ssdnodes.com\/blog\/self-hosting-nextcloud\/\">here<\/a>. On this page, we\u2019ll cover self-hosting <a href=\"https:\/\/my-netdata.io\/\" target=\"_blank\" rel=\"noopener\">NetData<\/a> with Docker (<code>docker-compose<\/code>, more specifically) on top of the stack we\u2019ve built on previous pages.<\/p>\n<hr \/>\n<h2><a id=\"Topics_covered_on_this_page_6\"><\/a>Topics covered on this page<\/h2>\n<ol>\n<li>Why is monitoring a VPS important?<\/li>\n<li>The benefits of using NetData on your VPS<\/li>\n<li>What to add to your docker-compose.yml file<\/li>\n<li>Showing Docker container names in NetData<\/li>\n<\/ol>\n<h2><a id=\"Why_monitor_a_VPS_14\"><\/a>Why monitor a VPS?<\/h2>\n<p>This is a difficult question to answer in a relatively short period of time\u2014I want to get you straight into the process of installing it on your VPS. I\u2019m going to dedicate an entire post to the importance of VPS monitoring soon, so stay tuned for that.<\/p>\n<p>In short, monitoring a VPS empowers you in a few key ways:<\/p>\n<ol>\n<li>Discover which, if any, processes are consuming too many resources, thereby affecting the rest of your experience<\/li>\n<li>Ensure all your services are running as expected\u2026<\/li>\n<li>\u2026 and know ASAP when they\u2019re not via alerts<\/li>\n<\/ol>\n<p>Your VPS use case helps dictates just how vital a robust monitoring solution is, but so does personal preference. If you\u2019re the only one using your self-hosted services, it might be less of a priority than if you\u2019re self-hosting your business\u2019 website or app, or have other developers collaborating on code via a private <a href=\"https:\/\/www.ssdnodes.com\/blog\/using-docker-compose-self-hosting\/#example-adding-gitea-to-your-self-hosting-stack\">Gitea installation<\/a>, for example.<\/p>\n<p>My self-hosted stack is for personal use only, and nothing is <em>too<\/em> critical to my day-to-day computing life, but I <em>do<\/em> choose to implement some monitoring to make troubleshooting easier.<\/p>\n<div class=\"cta-inline\"><\/div>\n<h2><a id=\"The_benefits_of_using_NetData_on_your_VPS_29\"><\/a>The benefits of using NetData on your VPS<\/h2>\n<p>Long ago, as I was searching for <a href=\"https:\/\/www.ssdnodes.com\/blog\/7-free-new-relic-alternatives-for-vps-monitoring\/\">alternatives to NewRelic for monitoring<\/a>, I came across <a href=\"https:\/\/my-netdata.io\/\" target=\"_blank\" rel=\"noopener\">NetData<\/a> and was impressed by not only its looks, but also the extensiveness of its analysis.<\/p>\n<p>Let\u2019s give NetData\u2019s developers a moment to explain themselves:<\/p>\n<blockquote><p>Unparalleled insights, in real-time, of everything happening on your systems and applications, with stunning, interactive web dashboards and powerful performance and health alarms. Analyze thousands of metrics per server. Everything about the system (CPU, RAM, disks, network, firewall, QoS, NFS, ZFS, etc). Detailed performance metrics for dozens of applications (such as web servers, databases servers, email servers, DNS servers, etc). Visualize metrics collected from SNMP devices, and APM metrics via the embedded statsd server.<\/p><\/blockquote>\n<p>Sounds pretty good, right?<\/p>\n<p>It\u2019s important to note that NetData only shows real-time data, not historical data. NetData is excellent for alerts and seeing the health of your VPS <em>right now<\/em>, but not built to figure out why a specific process crashed last week.<\/p>\n<h2><a id=\"What_to_add_to_your_dockercomposeyml_file_42\"><\/a>What to add to your docker-compose.yml file<\/h2>\n<p>Deploying NetData with <code>docker-compose<\/code> is simple and requires almost no customization.<\/p>\n<p>As always, replace the <code>EMAIL<\/code>, <code>DOMAIN<\/code>, and <code>TLD<\/code> variables in the following code with your values.<\/p>\n<pre><code>  netdata:\n    image: firehol\/netdata\n    container_name: netdata\n    hostname: monitor.DOMAIN.TLD\n    ports:\n      - 19999:19999\n    cap_add:\n      - SYS_PTRACE\n    security_opt:\n      - apparmor:unconfined\n    volumes:\n      - \/proc:\/host\/proc:ro\n      - \/sys:\/host\/sys:ro\n      - \/var\/run\/docker.sock:\/var\/run\/docker.sock:ro\n    environment:\n      - VIRTUAL_HOST=monitor.DOMAIN.TLD\n      - LETSENCRYPT_HOST=monitor.DOMAIN.TLD\n      - LETSENCRYPT_EMAIL=EMAIL@DOMAIN.TLD\n<\/code><\/pre>\n<p>You can now run <code>docker-compose up -d<\/code> and wait a moment as the NetData image is downloaded and launched as a container. Visit <code>monitor.DOMAIN.TLD<\/code> in your browser and see your data start to flow!<\/p>\n<h2><a id=\"Showing_Docker_container_names_in_NetData_72\"><\/a>Showing Docker container names in NetData<\/h2>\n<p>When I first launched NetData, I noticed that while I could view the resource usage and status of every Docker container in my self-hosted stack, they were referred to only as their IDs, not their names. Maybe you\u2019ve memorized that <code>ed2fd5fe702f<\/code> equals your <a href=\"https:\/\/www.ssdnodes.com\/blog\/self-hosting-nextcloud\/\">NextCloud installation<\/a>, but I need a little more help.<\/p>\n<p>NetData\u2019s <a href=\"https:\/\/github.com\/firehol\/netdata\/wiki\/Install-netdata-with-Docker\" target=\"_blank\" rel=\"noopener\">installation instructions<\/a> have a solution. When you <a href=\"https:\/\/dillinger.io\/\" target=\"_blank\" rel=\"noopener\">first installed Docker<\/a>, you likely created a group for Docker users and added your user to it. That group has a <code>PGID<\/code>, and if you let NetData know which <code>PGID<\/code> to look at, it can convert those IDs into the names you specified.<\/p>\n<p>Just run the following command to find your <code>PGID<\/code>:<\/p>\n<p><code>grep docker \/etc\/group | cut -d ':' -f 3<\/code><\/p>\n<p>My Docker <code>PGID<\/code> is <code>999<\/code>, so I added the following as another environment variable: <code>- PGID=999<\/code>. I then ran <code>docker-compose up -d<\/code> again to recreate the NetData container with this <code>PGID<\/code> environment variable enabled, which allows NetData to display the container names for easy monitoring of individual containers.<\/p>\n<h2><a id=\"Taking_NetData_a_step_further_with_Pushbullet_notifications_85\"><\/a>Taking NetData a step further with Pushbullet notifications<\/h2>\n<p>Head on over to <a href=\"https:\/\/www.pushbullet.com\" target=\"_blank\" rel=\"noopener\">Pushbullet<\/a> and create an account if you don\u2019t have one. Once created, head to <code>Settings -&gt; Account<\/code> and create a new Access Token. Keep this code safe.<\/p>\n<p>Log into your VPS if you\u2019re not already, and navigate to whichever folder you keep your <code>docker-compose.yml<\/code> file in.<\/p>\n<p>Now, there are lots of ways to edit a file within a running container, but I like what I call the copy-out-copy-in method. First, copy the <code>\/etc\/netdata\/health_alarm_notify.conf<\/code> from within the NetData container into your current folder.<\/p>\n<pre><code>$ docker cp netdata:\/etc\/netdata\/health_alarm_notify.conf .\n<\/code><\/pre>\n<p>You can then edit the <code>health_alarm_notify.conf<\/code> file with your editor of choice. Navigate down to the section, which looks like the following:<\/p>\n<pre><code>#------------------------------------------------------------------------------\n# pushbullet (pushbullet.com) push notification options\n\n# multiple recipients can be given like this:\n#                  \"user1@email.com user2@mail.com\"\n\n# enable\/disable sending pushbullet notifications\nSEND_PUSHBULLET=\"YES\"\n\n# Signup and Login to pushbullet.com\n# To get your Access Token, go to https:\/\/www.pushbullet.com\/#settings\/account\n# Create a new access token and paste it below.\n# Then just set the recipients' emails.\n# Please note that the if the email in the DEFAULT_RECIPIENT_PUSHBULLET does\n# not have a pushbullet account, the pushbullet service will send an email\n# to that address instead.\n\n# Without an access token, netdata cannot send pushbullet notifications.\nPUSHBULLET_ACCESS_TOKEN=\"\"\nDEFAULT_RECIPIENT_PUSHBULLET=\"\"\n\n# Device iden of the sending device. Optional.\nPUSHBULLET_SOURCE_DEVICE=\"\"\n<\/code><\/pre>\n<p>In the <code>PUSHBULLET_ACCESS_TOKEN<\/code> area, copy the access token you just created on the Pushbullet dashboard.<\/p>\n<p>For the <code>DEFAULT_RECIPIENT_PUSHBULLET<\/code> field, add any accounts where you would like to receive an email notification for your alarms. If you add the email you used to create your Pushbullet account you <em>should<\/em> get a push notification, whereas other email accounts will get an email notification.<\/p>\n<p>Time to copy the <code>.conf<\/code> file back into the container and restart the NetData container to reload the configuration changes.<\/p>\n<pre><code>$ docker cp health_alarm_notify.conf netdata:\/etc\/netdata\/health_alarm_notify.conf\n$ docker restart netdata\n<\/code><\/pre>\n<p>You should get a push notification and\/or an email if a NetData alarm is triggered! NetData can send notifications to far more services in complex configurations, so you should check out <a href=\"https:\/\/github.com\/firehol\/netdata\/wiki\/health-monitoring\" target=\"_blank\" rel=\"noopener\">the health monitoring documentation<\/a> for more. You may also want to read up on creating your own alarms depending on your particular configurations.<\/p>\n<p>Monitoring your self-hosted stack is important, and NetData is just the first piece of a complex puzzle. More self-hosting to come soon!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>VPS monitoring a self-hosted stack might seem like overkill, but we want to know if and when something crashes. NetData to the rescue.<\/p>\n","protected":false},"author":20,"featured_media":2979,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[18],"tags":[182,258],"class_list":["post-2958","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","tag-docker","tag-netdata"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts\/2958","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/comments?post=2958"}],"version-history":[{"count":3,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts\/2958\/revisions"}],"predecessor-version":[{"id":13040,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts\/2958\/revisions\/13040"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/media\/2979"}],"wp:attachment":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/media?parent=2958"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/categories?post=2958"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/tags?post=2958"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}