Currently the do-agent runs as the nobody user on debian, a user which is supposed to have no privileges. However, with a firewall that defaults to blocking outbound requests the nobody user does by default not have network privileges, and I want to be able to let the do-agent through the firewall without doing so for nobody, since that's not exclusive to do-agent. It's also better for logging and audit purposes when services run under their own users. Could the deb create a do-agent user and run under that instead?

I would have submitted a PR, but the packaging files aren't in the repo yet (#44, #12).

I installed the agent using curl -sSL https://agent.digitalocean.com/install.sh | sh on a Ubuntu 16 machine. Two days later and I still don't see the new graphs like disk usage and memory in the DO dashboard. Is there any way to debug it/logs?

Hello guys. Thanks for nice script. However after few hours of monitoring I found some inconsistencies between real droplet data and what agent show.

I have constant traffic for my droplet for ~1.0 Mbps in and out.

Agent shows 0.07 Mbps in and 0.08 Mbps out. This is impossible. I also checked with iftop. Constant 1.0 Mbps with peaks to 6 Mbps but nothing of this is present on agent graphs.

Prev. graph was showing correct values.

Stuck in "Check back soon, we're loading new metrics" state running on kubernetes
Image created on last master

make docker
docker tag do-agent:0.5.1 trurlmcbyte/do-agent:0.5.1
docker push trurlmcbyte/do-agent:0.5.1

logs after 25 minutes running:

2018/08/08 10:27:50 Do-Agent version 0.5.1.b665561-docker
2018/08/08 10:27:50 Do-Agent build master.b665561
2018/08/08 10:27:50 Architecture: amd64
2018/08/08 10:27:50 Operating System: linux
2018/08/08 10:27:50 Local Repository Path Override: /agent/updates
2018/08/08 10:27:50 Using alternative location for procFS: /agent/proc
2018/08/08 10:27:51 Checking for newer version of do-agent
2018/08/08 10:27:51 No repository update available 

DaemonSet:

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: do-agent
  namespace: monitoring
spec:
  selector:
    matchLabels:
      name: do-agent
      phase: prod
  template:
    metadata:
      labels:
        name: do-agent
        phase: prod
    spec:
      volumes:
      - name: proc
        hostPath:
          path: /proc
      containers:
      - name: do-agent
        image: trurlmcbyte/do-agent:0.5.1
        ports:
        - containerPort: 10253
          hostPort: 10253
          protocol: TCP
          name: metrics
        volumeMounts:
        - name: proc
          readOnly: true
          mountPath: /host/proc
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      hostNetwork: true
      hostPID: true
      schedulerName: default-scheduler
      tolerations:
      - operator: Exists
        effect: NoSchedule
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  templateGeneration: 1
  revisionHistoryLimit: 10

Any solutions how to find where is problem?

When I try to build on Arch, the govendor sync step fails with:
Error: Package "/home/imntreal/do-agent/src/do-agent-0.4.5" not a go package or not in GOPATH.

Setting $GOPATH to "/home/imntreal/do-agent/src" doesn't help.

It would be great to use the do-agent on Alpine 3.7/3.8 via APK👌

May you add also Prometheus metrics support for internal monitoring?
On agent itself or as part of DO API.

I got the following error when trying to run the do-agent docker container on rancheros:

x509: failed to load system roots and no roots provided

The fix was to update dockerfile to install ca-certificates:

RUN  apk update && \
     apk add libc6-compat && \
     apk add ca-certificates

This might help someone out -
For whatever reason, my Debian8/jessie install was lacking the needed package "apt-transport-https".
run

apt-get install apt-transport-https

before

echo "deb https://repos.sonar.digitalocean.com/apt main main" > /etc/apt/sources.list.d/sonar.list

Describe the problem

This script does not support the OS/Distribution on this machine

Steps to reproduce

I remove old metrics, using:
sudo yum remove do-agent

System Information

16 GB Memory / 320 GB Disk / NYC3 - CentOS 7.5 x64
WHM - cPanel

do-agent information:

curl -sSL https://insights.nyc3.cdn.digitaloceanspaces.com/install.sh | sudo bash
Cleaning up old sources...OK
Verifying machine compatability...OK
Verifying compatability with script...
This script does not support the OS/Distribution on this machine.
If you feel that this is an error contact [email protected]
or create an issue at https://github.com/digitalocean/do-agent/issues/new.

Describe the problem

Some times, when do-agent updates itself via daily cron, I get an email with an error log telling TERM env variable is not set. That's because it's a cron job. It should indicate debian that it's a non interactive task and therefore should update silently.

To fix it should be enought by adding export DEBIAN_FRONTEND="noninteractive" to the update script. I don't do it myself because I'm afraid of futures updates overwriting it.

Steps to reproduce

You must have configured an email server on your VPS (as I have). Then, just wait for a random day and will get the following email:

Subject: Cron <root@my-vps-hostname> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
Body:
/etc/cron.daily/do-agent:
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin: 
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 61910 files and directories currently installed.)
Preparing to unpack .../do-agent_2.2.3_amd64.deb ...
Creating do-agent user...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Stopping systemctl service...
Unpacking do-agent (2.2.3) over (2.2.1) ...
Configure systemd...
cron removed
userdel: do-agent mail spool (/var/mail/do-agent) not found
userdel: do-agent home directory (/home/do-agent) not found
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Setting up do-agent (2.2.3) ...
Detecting SELinux
SELinux not enforced
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Creating /etc/systemd/system/do-agent.service...
Created symlink /etc/systemd/system/multi-user.target.wants/do-agent.service → /etc/systemd/system/do-agent.service.

Expected behavior

Update script should indicate debian that it's a non interactive task and therefore should update silently. No more emails because TERM env variable is not set.

To fix it should be enought by adding export DEBIAN_FRONTEND="noninteractive" to the update script. I don't do it myself because I'm afraid of futures updates overwriting it.

System Information

Distribution and version:

do-agent information:

/opt/digitalocean/bin/do-agent --version:

do-agent (DigitalOcean Agent)

Version:     2.2.3
Revision:    b1a08da
Build Date:  Sat May 18 04:02:16 UTC 2019
Go Version:  go1.12.1
Website:     https://github.com/digitalocean/do-agent

Copyright (c) 2019 DigitalOcean, Inc. All rights reserved.

This work is licensed under the terms of the Apache 2.0 license.
For a copy, see <https://www.apache.org/licenses/LICENSE-2.0.html>.

apt-cache policy do-agent:

do-agent:
  Instalados: 2.2.3
  Candidato:  2.2.3
  Tabla de versión:
 *** 2.2.3 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
        100 /var/lib/dpkg/status
     2.2.1 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     2.2.0 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     2.1.3 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     2.0.2 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     2.0.1 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     2.0.0 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     1.1.3 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages

The install instructions for do-agent tell me to run the command curl -sSL https://agent.digitalocean.com/install.sh | sh, but doing that fails on my Fedora 26 droplet. The script install.sh adds a repo called digitalocean-agent by writing a file /etc/yum.repos.d/digitalocean-agent.repo like this

$ cat /etc/yum.repos.d/digitalocean-agent.repo 
[digitalocean-agent]
name=DigitalOcean agent
baseurl=https://repos.sonar.digitalocean.com/yum/\$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=https://repos.sonar.digitalocean.com/sonar-agent.asc

The reason this repo doesn't work is that \$basearch leads to an invalid baseurl. The correct is $basearch, and when I delete the backslash do-agent installs successfully.

Can you please correct the install.sh script? The issue is the heredoc block from line 48 to line 58. Line 48 reads cat > /etc/yum.repos.d/digitalocean-agent.repo <<"EOM", but the quotes around EOM mean that the \$ on line 51 is not treated as an escape sequence, but repeated verbatim, hence we get the repo file as listed above. If you remove the quotes around EOM the $ is escaped correcltly and we get the correct baseurl in the repo file. Alternatively you can keep the quotes around EOM on line 48, but then you don't need to escape $.

Thank you in advance

Is https://repos.sonar.digitalocean.com/apt main main avalaible? Because I get

W: Failed to fetch https://repos.sonar.digitalocean.com/apt/dists/main/main/binary-amd64/Packages Hash Sum mismatch

Describe the problem

we got errors

If restart droplet it works some time, and then starts again to show an error

in syslog

DigitalOceanAgent[1419]: ERROR: 2019/03/22 23:15:12 /gopath/src/github.com/digitalocean/do-agent/cmd/do-agent/run.go:47: failed to send metrics: circuit breaker is open; deliberately failing due to exponential backoff

Steps to reproduce

dont know

Expected behavior

no error shown

System Information

Distribution and version: Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-143-generic x86_64)

do-agent information:

Paste the entire output

/opt/digitalocean/bin/do-agent --version:

$ /opt/digitalocean/bin/do-agent --version

do-agent (DigitalOcean Agent)

Version:     2.0.2
Revision:    08dc07b
Build Date:  Thu Mar  7 19:07:30 UTC 2019
Go Version:  go1.11.5
Website:     https://github.com/digitalocean/do-agent

Copyright (c) 2019 DigitalOcean, Inc. All rights reserved.

This work is licensed under the terms of the Apache 2.0 license.
For a copy, see <https://www.apache.org/licenses/LICENSE-2.0.html>.

Ubuntu, Debian

apt-cache policy do-agent:

$ apt-cache policy do-agent
do-agent:
  Installed: 2.0.2
  Candidate: 2.0.2
  Version table:
 *** 2.0.2 100
        100 /var/lib/dpkg/status
     0.5.1 500
        500 https://repos.sonar.digitalocean.com/apt main/main amd64 Packages

Before opening an issue, make sure there is not a similar issue already open

• Doesn't seem to be an existing issue

Describe the problem

When I manually ran sudo apt-get update to update the list of repos, I saw the following items.

...
N: Repository 'https://repos.sonar.digitalocean.com/apt main InRelease' changed its 'Version' value from '' to '1.0'
E: Repository 'https://repos.sonar.digitalocean.com/apt main InRelease' changed its 'Codename' value from 'main' to 'beta'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

As main insinuates it's for general releases IMO, it sounds like the general release channel got repurposed to a beta release channel. However, despite the obvious repercussions of this bad practice, I have no idea where I can point our production servers so we once again have a stable channel.

Steps to reproduce

In Ubuntu (or presumably any Debian-based system), follow the README.md file's infructions in this repo. Below is what it says at the time of writing.

echo "deb https://repos.sonar.digitalocean.com/apt main main" > /etc/apt/sources.list.d/sonar.list
curl https://repos.sonar.digitalocean.com/sonar-agent.asc | sudo apt-key add -
sudo apt-get update

As this says it was changed, then things will most likely go smoothly and not show any issues. However, if you examine the metadata for the repository, you'll see that the file contains the following information at the top. (FYI: main main apparently points to main InRelease which causes this issue.)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Architectures: amd64 i386
Codename: beta
Components: main contrib non-free
Date: Mon, 14 Jan 2019 22:38:32 +0000
Label: . main
Origin: . main
Suite: main
Version: 1.0
...

Expected behavior

Have main main be the stable repository, and exclusively use beta main for the beta channel.

System Information

Distribution:

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.1 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.1 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

Version:
N/A

Metrics-Agent Version:
N/A

(paste the output of do-agent --version)
N/A

Describe the problem

Hello,
please consider to add Oracle Linux 7 support for do-agent install script - https://insights.nyc3.cdn.digitaloceanspaces.com/install.sh.
Logic should be as for RHEL.

My workaround was to add "ol" in ${dist} options list, this works.

System Information

Oracle Linux Server 7.6

Go lets you have multiple paths in your GOPATH environment variable. It will use the first path provided for things like go get, but it will look for packages in all specified paths. This is useful for keeping your own packages separate from packages installed as dependencies (or tools, since vendoring is the typical way to install dependencies). For example, I usually have my GOPATH=/home/pib/go:/home/pib/work/go.

If I try to use the Makefile provided, it gives a mysterious error Makefile:55: *** target pattern contains no '%'. Stop. which I figured out means that there's an extra : on the target line, which makes sense since the dependencies: $GOVENDOR line is being expanded to dependencies: /home/pib/go:/home/pib/work/go/bin/govendor.

I can work around it by temporarily changing my GOPATH, but it would be nice if I didn't have to do that.

Describe the problem

The daily cron job appears to not have silenced the output from yum and thus produce useless mail daily. The mail has content:

/etc/cron.daily/do-agent:

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Metadata Cache Created

Steps to reproduce

1. Install the new do-agent
2. Wait a day

Expected behavior

No useless cron mail should be sent.

System Information

Distribution and version: CentOS 7

do-agent information:

# /opt/digitalocean/bin/do-agent --version

do-agent (DigitalOcean Agent)

Version:     2.1.3
Revision:    6712f22
Build Date:  Mon Apr  8 13:56:04 UTC 2019
Go Version:  go1.11.5
Website:     https://github.com/digitalocean/do-agent

Copyright (c) 2019 DigitalOcean, Inc. All rights reserved.

This work is licensed under the terms of the Apache 2.0 license.
For a copy, see <https://www.apache.org/licenses/LICENSE-2.0.html>.
# yum --cacheonly list do-agent
Loaded plugins: fastestmirror
Installed Packages
do-agent.x86_64                                       2.1.3-1                                        @digitalocean-agent

please help me sir :( how to solve server may be slow or overloaded in digitalocean ?

my spec droplet =
16 GB Memory / 80 GB Disk / SGP1 - Ubuntu WordPress 4.9.1 on 16.04

my website in myserver :
https://modelunitednation.org
https://youtex.org/
https://sasambo.org/

mywebsite always Up & down after opened web

Hello,

I'm looking to contribute to do-agent if there is anything to do.
About a month ago, I asked in #14 what can be done, but I got no answer from then.
There are no PRs or issues (beside #21 which I'll look into it).
Beside upcoming features, are there any things that need to be done? Some tweaking, bug fixing, is there anything that could improve agent?

I know about plugins, and about them, are there any specific that you/DO would love to see or that's on our creativity?

I'm very interested in do-agent/contributing so I'm looking to learn more about it and is there anything needed. =)

cc @cagedmantis

Please only create a Github issue for bugs related to the code itself. If you are
experiencing an issue with sending metrics, display graphs, errors from the agent,
etc, please contact https://cloudsupport.digitalocean.com/s/ so we can provide support

Before opening an issue, make sure there is not a similar issue already open

Describe the problem

Installation silently fails when there are defunct entries in sources.list

Steps to reproduce

Uninstall do-agent. Add a defunct repo to sources.list and try to install. I ran into this with a packagecloud.io repo that no longer existed.

Expected behavior

Should still install or at least produce an error message to remove old entries from sources.

System Information

Distribution and version:
Ubuntu 14.04

do-agent information:

None because it didn't install.

I was able to resolve by manually removing the old entries from /etc/apt/sources.list and /etc/apt/sources.d/[offending repo].list

Hi I'm experiencing issues when i try to start do-agent:
2017/09/08 15:41:28 Unable to read credentials: DigitalOcean sonar service returned unexpected status: 401

tufLocalStore file is not being created, tried to update/re-install...

Describe the problem

After installing the new DO Metrics Agent I noticed the service account was created with its home directory in /home

Steps to reproduce

For me this was an upgrade from the old Metrics Agent so I followed the upgrade steps at https://www.digitalocean.com/docs/monitoring/how-to/switch-agents/. However when I noticed this issue I removed the new Metrics Agent and performed a clean installation:

• sudo apt purge do-agent
• sudo deluser do-agent
• sudo rm /etc/apt/sources.list.d/digitalocean-agent.list
• curl -sSL https://insights.nyc3.cdn.digitaloceanspaces.com/install.sh | sudo bash

After this:

• getent passwd do-agent

do-agent:x:119:65534::/home/do-agent:/usr/sbin/nologin

Expected behavior

Directories that save state data for a service do not belong in /home. Their preferred location is /var/lib/ according to the Filesystem Hierarchy Standard. Alternatively, if a service does not need to save any state information, setting it's home directory to /nonexistent is common practice at least on Debian derived distributions like Ubuntu.

System Information

Distribution and version:
Ubuntu 18.04.2 LTS

do-agent information:

• /opt/digitalocean/bin/do-agent --version:

do-agent (DigitalOcean Agent)

Version:     2.0.2
Revision:    08dc07b
Build Date:  Thu Mar  7 19:07:30 UTC 2019
Go Version:  go1.11.5
Website:     https://github.com/digitalocean/do-agent

Copyright (c) 2019 DigitalOcean, Inc. All rights reserved.

This work is licensed under the terms of the Apache 2.0 license.
For a copy, see <https://www.apache.org/licenses/LICENSE-2.0.html>.

• apt-cache policy do-agent:

do-agent:
  Installed: 2.0.2
  Candidate: 2.0.2
  Version table:
 *** 2.0.2 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
        100 /var/lib/dpkg/status
     2.0.1 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     2.0.0 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     1.1.3 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages

The announcement noticeably omitted CoreOS. Is there a technical reason for this? I'm not savvy in all the reasons why this might be. Perhaps the most popular were targeted first?

Hello!

I've been using the new do-agent for a few production DO instances and am generally happy with how it's working.

I'm curious, is there a project roadmap for do-agent? Is there a list of proposed or intended upcoming features?

Cloudlinux is pretty much a rebranded copy of CentOS with some extra security features and agent should work just fine on it. Any plans to add support for Cloudlinux? Is there a way to force the install to see if it will work?

Running make build fails on FreeBSD nodes. Here are the errors shown on my node which is running FreeBSD 10.3.

root@bsd1:/usr/src/do-agent # make build
make: "/usr/src/do-agent/Makefile" line 8: Missing dependency operator
make: "/usr/src/do-agent/Makefile" line 10: Need an operator
make: "/usr/src/do-agent/Makefile" line 12: Need an operator
make: "/usr/src/do-agent/Makefile" line 82: Missing dependency operator
make: "/usr/src/do-agent/Makefile" line 83: warning: duplicate script for target "ifeq" ignored
make: "/usr/src/do-agent/Makefile" line 9: warning: using previous script for "ifeq" defined here
make: "/usr/src/do-agent/Makefile" line 83: warning: duplicate script for target "("",)" ignored
make: "/usr/src/do-agent/Makefile" line 9: warning: using previous script for "("",)" defined here
make: "/usr/src/do-agent/Makefile" line 84: Need an operator
make: "/usr/src/do-agent/Makefile" line 86: Need an operator
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/src/do-agent

In our syslog on Debian 9 machines, I get a lot of lines like:

Nov 27 14:54:27 db0a do-agent[725]: 2018/11/27 14:54:27 Sending metrics to DigitalOcean: Post https://ams3.sonar.digitalocean.com/v1/metrics/droplet_id/********: read  tcp *.*.*.*:39608->5.101.110.176:443: read: connection reset by peer
Nov 27 15:04:30 db0a do-agent[725]: 2018/11/27 15:04:30 Sending metrics to DigitalOcean: Post https://ams3.sonar.digitalocean.com/v1/metrics/droplet_id/********: read  tcp *.*.*.*:39628->5.101.110.176:443: read: connection reset by peer
Nov 27 15:08:32 db0a do-agent[725]: 2018/11/27 15:08:32 Sending metrics to DigitalOcean: Post https://ams3.sonar.digitalocean.com/v1/metrics/droplet_id/********: write tcp *.*.*.*:39636->5.101.110.176:443: write: connection reset by peer
Nov 27 15:10:32 db0a do-agent[725]: 2018/11/27 15:10:32 Sending metrics to DigitalOcean: Post https://ams3.sonar.digitalocean.com/v1/metrics/droplet_id/********: write tcp *.*.*.*:39640->5.101.110.176:443: write: connection reset by peer
Nov 27 15:14:29 db0a do-agent[725]: 2018/11/27 15:14:29 Sending metrics to DigitalOcean: Post https://ams3.sonar.digitalocean.com/v1/metrics/droplet_id/********: write tcp *.*.*.*:39648->5.101.110.176:443: write: connection reset by peer
Nov 27 15:26:26 db0a do-agent[725]: 2018/11/27 15:26:26 Sending metrics to DigitalOcean: Post https://ams3.sonar.digitalocean.com/v1/metrics/droplet_id/********: write tcp *.*.*.*:39672->5.101.110.176:443: write: connection reset by peer
Nov 27 15:31:29 db0a do-agent[725]: 2018/11/27 15:31:29 Sending metrics to DigitalOcean: Post https://ams3.sonar.digitalocean.com/v1/metrics/droplet_id/********: write tcp *.*.*.*:39692->5.101.110.176:443: write: connection reset by peer
Nov 27 15:35:26 db0a do-agent[725]: 2018/11/27 15:35:26 Sending metrics to DigitalOcean: Post https://ams3.sonar.digitalocean.com/v1/metrics/droplet_id/********: write tcp *.*.*.*:39700->5.101.110.176:443: write: connection reset by peer

Is this expected? If not, what is the issue? To me it looks like the ams3.sonar.DO.com endpoint is overloaded sometimes?

Graphs seem to have proper performance data.

Hello,

If I install and then uninstall do-agent, and then reboot, the do-agent is automatically reinstalled.

To replicate, use the following process (on Centos7):

# curl -sSL https://agent.digitalocean.com/install.sh | sh

# yum -y install do-agent

# yum -y remove do-agent

# reboot

Expected result: do-agent not installed nor running

Actual result: do-agent installed and running

there appears to be an error in this section

# /opt/digitalocean/bin/do-agent 
2017/02/01 09:04:29 Do-Agent version 0.4.6
2017/02/01 09:04:29 Do-Agent build HEAD.704e794
2017/02/01 09:04:29 Architecture: amd64
2017/02/01 09:04:29 Operating System: linux
2017/02/01 09:04:30 Checking for newer version of do-agent
2017/02/01 09:04:31 Unable to update do-agent: Update: Unable to create repository file: /var/opt/digitalocean/do-agent/tufLocalStore

# ls -l /var/opt/digitalocean/do-agent/tufLocalStore
-rw------- 1 nobody nogroup 32768 Feb 1 08:49 /var/opt/digitalocean/do-agent/tufLocalStore

...
func (u *update) createTufClient() (*client.Client, error) {
	if u.client != nil {
		return u.client, nil
	}

	localStoreFile := fmt.Sprintf("%s%s", u.localStorePath, "/tufLocalStore")
	ls, err := client.FileLocalStore(localStoreFile)
	if err != nil {
		return nil, ErrUnableToCreateLocalStore{Path: localStoreFile}
	}
...

func (e ErrUnableToCreateLocalStore) Error() string {
55		return fmt.Sprintf("Update: Unable to create repository file: %s", e.Path)
…	
64		return fmt.Sprintf("Update: Unable to query repository file: %s", e.StoreURL)
65	}

Latest 0.4.11, apt install fails with:

Preparing to unpack .../do-agent_0.4.11_amd64.deb ...
do-agent: unrecognized service
Unpacking do-agent (0.4.11) ...
Setting up do-agent (0.4.11) ...
do-agent: unrecognized service
dpkg: error processing package do-agent (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 do-agent
E: Sub-process /usr/bin/dpkg returned an error code (1)

this is on Debain with systemd removed and running under SysV

Describe the problem

Do-agent failed to install

Steps to reproduce

$ curl -sSL https://insights.nyc3.cdn.digitaloceanspaces.com/install.sh | sudo bash
[sudo] password for ***:
Cleaning up old sources...OK
Verifying machine compatability...OK
Verifying compatability with script...OK
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package do-agent
Installing apt repository...
W: http://get.docker.io/ubuntu/dists/docker/Release.gpg: Signature by key 36A1D7869245C8950F966E92D8576A8BA88D21E9 uses weak digest algorithm (SHA1)
Installing gpg key...OK
W: http://get.docker.io/ubuntu/dists/docker/Release.gpg: Signature by key 36A1D7869245C8950F966E92D8576A8BA88D21E9 uses weak digest algorithm (SHA1)
Selecting previously unselected package do-agent.
(Reading database ... 100768 files and directories currently installed.)
Preparing to unpack .../do-agent_2.2.1_amd64.deb ...
Creating do-agent user...
Stopping systemctl service...
Unpacking do-agent (2.2.1) ...
Setting up do-agent (2.2.1) ...
Detecting SELinux
SELinux not enforced
Creating /etc/systemd/system/do-agent.service...
Created symlink /etc/systemd/system/multi-user.target.wants/do-agent.service, pointing to /etc/systemd/system/do-agent.service.
Failed to start do-agent.service: Unknown unit: do-agent.service
See system logs and 'systemctl status do-agent.service' for details.
dpkg: error processing package do-agent (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
do-agentE: Sub-process /usr/bin/dpkg returned an error code (1)

Expected behavior

do-agent installed and running

System Information

uname -a

Linux hhh 4.4.0-141-generic #167-Ubuntu SMP Wed Dec 5 10:40:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.5 LTS
Release: 16.04
Codename: xenial

do-agent information:

./do-agent --version

do-agent (DigitalOcean Agent)

Version: 2.2.1
Revision: c79bf68
Build Date: Tue May 14 16:20:41 UTC 2019
Go Version: go1.12.1
Website: https://github.com/digitalocean/do-agent

Copyright (c) 2019 DigitalOcean, Inc. All rights reserved.

This work is licensed under the terms of the Apache 2.0 license.
For a copy, see https://www.apache.org/licenses/LICENSE-2.0.html.

n# apt-cache policy do-agent
do-agent:
Installed: 2.2.1
Candidate: 2.2.1
Version table:
*** 2.2.1 500
500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
100 /var/lib/dpkg/status
2.2.0 500
500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
2.1.3 500
500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
2.0.2 500
500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
2.0.1 500
500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
2.0.0 500
500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
1.1.3 500
500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages

systemctl list-unit-files | grep do-agent

do-agent.service enabled

It would be great to use the do-agent on RancherOS 👌

I've tried using plugins for do-agent.

I can use the plugin https://github.com/digitalocean/do-agent/blob/master/plugins/test.sh with do-agent.

The plugin sends that data from that plugin to DigitalOcean. This is great 👍

How do I use the data sent with that plugin?
How do I access that data?
How to I graph it, or alert on it?

(n.b: I've already asked DO support who recommended opening an issue here)

Include metadata url override information in the readme.

Before opening an issue, make sure there is not a similar issue already open

• Appears related to #43

Describe the problem

Error in logs Unable to update do-agent: Update: Error initializing repository: tuf: missing remote metadata root.json

Steps to reproduce

Though this message appears nearly-hourly, it is also generated when running:

root@system:/opt/digitalocean/bin# ./do-agent 
2019/01/17 01:41:37 Do-Agent version 0.5.1
2019/01/17 01:41:37 Do-Agent build HEAD.c799b1e
2019/01/17 01:41:37 Architecture: amd64
2019/01/17 01:41:37 Operating System: linux
2019/01/17 01:41:37 Checking for newer version of do-agent
2019/01/17 01:41:37 Unable to update do-agent: Update: Error initializing repository: tuf: missing remote metadata root.json
root@system:/opt/digitalocean/bin# ./do-agent -force_update
2019/01/17 01:46:35 Do-Agent version 0.5.1
2019/01/17 01:46:35 Do-Agent build HEAD.c799b1e
2019/01/17 01:46:35 Architecture: amd64
2019/01/17 01:46:35 Operating System: linux
2019/01/17 01:46:35 Checking for newer version of do-agent
2019/01/17 01:46:35 Unable to update do-agent: Update: Error initializing repository: tuf: missing remote metadata root.json

Expected behavior

Updating? Unsure, I haven't done anything manual to date.

System Information

Distribution: Ubuntu 16.04

Version: 0.51

Metrics-Agent Version: (unsure how to confirm)

(paste the output of do-agent --version)

root@system:/opt/digitalocean/bin# ./do-agent --version
flag provided but not defined: -version
Usage of ./do-agent:
  -force_update
    	Update the version of do-agent.
  -log_level string
    	Log level to log: ERROR, INFO, DEBUG (default "INFO")
  -log_syslog
    	Log to syslog.

Please only create a Github issue for bugs related to the code itself. If you are
experiencing an issue with sending metrics, display graphs, errors from the agent,
etc, please contact https://cloudsupport.digitalocean.com/s/ so we can provide support

Before opening an issue, make sure there is not a similar issue already open

Describe the problem

Debian packages depends on cron when it should be cron-daemon

Steps to reproduce

Install systemd-cron to replace cron

Expected behavior

System Information

Distribution and version:
Debian 9.8

do-agent information:

Paste the entire output

/opt/digitalocean/bin/do-agent --version:
Not Found

Ubuntu, Debian

apt-cache policy do-agent:

root@gitlab:~# apt-cache policy do-agent
do-agent:
  Installed: (none)
  Candidate: 2.1.3
  Version table:
     2.1.3 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     2.0.2 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     2.0.1 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     2.0.0 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages
     1.1.3 500
        500 https://repos.insights.digitalocean.com/apt/do-agent main/main amd64 Packages

Before opening an issue, make sure there is not a similar issue already open

Describe the problem

Apt repositories (at least for ubuntu bionic) contain only latest version in 0.x branch, which is over 2 years old.

Steps to reproduce

Run recommended install method ubuntu Bionic:
curl -L https://agent.digitalocean.com/install.sh | sudo bash

Expected behavior

Latests packages should be available

System Information

Distribution and version:
Ubuntu Bionic 18.04.2 LTS

I wasn't really sure where to post this issue, as it relates to the script hosted on the following:
curl -sSL https://agent.digitalocean.com/install.sh | sh

Hopefully you guys can find the proper home for it.

The following line in the install.sh script fails on my platform, as the output for the following yields two results:
rpm -q --whatprovides redhat-release --queryformat "%{VERSION}\n" | sed 's/\/.*//' | sed 's/\..*//' | sed 's/Server*//'

The reason for the two results is the following:

[root@sb1 ~]# rpm -q --whatprovides redhat-release
centos-release-6-7.el6.centos.12.3.x86_64
centos-release-6-8.el6.centos.12.3.x86_64

Making the following change I was able to get the script to work properly:
rpm -q --whatprovides redhat-release --queryformat "%{VERSION}\n" | tail -n 1 | sed 's/\/.*//' | sed 's/\..*//' | sed 's/Server*//'

Good sunday morning :)
Just tried pulling the image on a new CoreOS doplet but it doesn't seem to exist anymore the hub page shows 404 and docker pull isn't able to access either

What a pity :/
Anything I missed?

For the last few days I've been seeing this error go by in my logs:

Unable to update do-agent: Update: Error initializing repository: tuf: failed to decode root.json: expired at 2017-07-22 15:27:54 +0000 UTC

The do-agent binary was last updated on July 19 and that's about when the issue started. It sounds like tuf is trying to reference a file/resource that is somehow considered expired.

Looks like others are seeing the same: https://www.digitalocean.com/community/questions/do-agent-unable-to-update

Any advice?

I encounter the following error after running do-agent manually. No new graphs are visible in the web interface as well. I tried force update but it didn't help. How can help with debugging/get it running?

$ ./do-agent
2016/12/15 23:13:09 Do-Agent version 0.4.5
2016/12/15 23:13:09 Do-Agent build HEAD.e02833e
2016/12/15 23:13:09 Architecture: amd64
2016/12/15 23:13:09 Operating System: linux
2016/12/15 23:13:09 Unable to read credentials: unexpected response from metadata API, status 500: internal server error
2016/12/15 23:13:09 do-agent requires a DigitalOcean host

$ uname -a
Linux hex64.com 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux

Hi, I just created CentOS 7 droplets and check new monitoring dashboard.
But doesn't show new metrics.
I checked install script and found logs below.

Command failed, retrying in 512 seconds
--2016-12-03 11:11:14--  https://repos.sonar.digitalocean.com/yum/x86_64/do-agent-0.4.5-1.x86_64.rpm
Resolving repos.sonar.digitalocean.com (repos.sonar.digitalocean.com)... 151.101.9.7
Connecting to repos.sonar.digitalocean.com (repos.sonar.digitalocean.com)|151.101.9.7|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2016-12-03 11:11:15 ERROR 403: Forbidden.

Command failed, retrying in 900 seconds
--2016-12-03 11:26:15--  https://repos.sonar.digitalocean.com/yum/x86_64/do-agent-0.4.5-1.x86_64.rpm
Resolving repos.sonar.digitalocean.com (repos.sonar.digitalocean.com)... 151.101.9.7
Connecting to repos.sonar.digitalocean.com (repos.sonar.digitalocean.com)|151.101.9.7|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2016-12-03 11:26:16 ERROR 403: Forbidden.

Command failed, retrying in 900 seconds

Install script find latest version from debian package list. It is 0.4.5 now.
But rpm package doesn't exist yet. preparing now?

Please only create a Github issue for bugs related to the code itself. If you are
experiencing an issue with sending metrics, display graphs, errors from the agent,
etc, please contact https://cloudsupport.digitalocean.com/s/ so we can provide support

Before opening an issue, make sure there is not a similar issue already open

Describe the problem

When I uninstalled do-agent and tried to upgrade to the latest version of do-agent, it gives "method https has died unexpectedly!"

Steps to reproduce

just install it manually.
Cleaning up old sources...OK
Verifying machine compatability...OK
Verifying compatability with script...OK
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'do-agent' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 275 not upgraded.
Installing apt repository...
E: Method https has died unexpectedly!
E: Sub-process https received signal 9.
Installing gpg key...OK
E: Method https has died unexpectedly!
E: Sub-process https received signal 9.

Expected behavior

System Information

Distribution and version:
Ubuntu 14.04

do-agent information:

Paste the entire output

/opt/digitalocean/bin/do-agent --version:

Ubuntu, Debian

apt-cache policy do-agent:

Fedora, CentOS

yum --cacheonly list do-agent:

Installing do-agent v0.5.0 on a CentOS 7 machine, there's a error from a shell conditional, I assume in one of the install-time scripts:

# yum upgrade
...
Downloading packages:
do-agent-0.5.0-1.x86_64.rpm                                                                                                                            | 2.5 MB  00:00:02
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
/var/tmp/rpm-tmp.lESxHL: line 9: [: -nt: unary operator expected
  Updating   : 1501084918:do-agent-0.5.0-1.x86_64                                                                                                                         1/2
/var/tmp/rpm-tmp.BUIJGI: line 9: [: -nt: unary operator expected
  Cleanup    : 1500494602:do-agent-0.5.0-1.x86_64                                                                                                                         2/2
  Verifying  : 1501084918:do-agent-0.5.0-1.x86_64                                                                                                                         1/2
  Verifying  : 1500494602:do-agent-0.5.0-1.x86_64                                                                                                                         2/2

Updated:
  do-agent.x86_64 1501084918:0.5.0-1

I was hoping to see how do-agent was packaged and hence see about fixing and opening a PR for the issue above, however there doesn't appear to be any packaging related code and it also appears that the package repo is hosted on S3 and so it's not straightforward to see if you're publishing SRPMs I could take apart.

Include packaging code, or update the README to point to the tooling you're using, please.

The provided rpm and deb packages include init scripts for the associated platform. Could these be included here?

I think it will make it easier for other distributions to package do-agent, and make it clear if these files are covered by the same license as the source.

Describe the problem

Because the Prometheus Node Exporter don't work with the digital ocean managed Kubernetes (See here and here), I tried to deploy the do-node-agent on Kubernetes. For this I used the deployment file under deploy/do-agent.yaml with slightly changes (Add port to container specification and add service definition).

Steps to reproduce

• kubectl create -f do-agent.yaml
  But after the Pod start, I get following log output:

ERROR: 2019/03/14 09:58:10 /gopath/src/github.com/digitalocean/do-agent/cmd/do-agent/config.go:220: Failed to get cluster UUID when initializing DO Kubernetes metrics: kubernetes cluster UUID not found
main.init
	/gopath/src/github.com/digitalocean/do-agent/cmd/do-agent/config.go:51
runtime.main
	/usr/local/go/src/runtime/proc.go:189
runtime.goexit
	/usr/local/go/src/runtime/asm_amd64.s:1333

Any ideas? Do I miss something?

Here is my complete yaml

kind: Namespace
apiVersion: v1
metadata:
  name: prometheus
  labels:
    name: monitoring
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: do-agent
  namespace: prometheus
---
#do-node-agent service
kind: Service
apiVersion: v1
metadata:
  name:  do-node-agent
  namespace: prometheus
spec:
  selector:
    app:  do-node-agent
  type:  ClusterIP
  ports:
  - name:  metrics
    port:  10253
    targetPort:  10253
---
# DaemonSet to create a do-agent on each node that scrapes node metrics
apiVersion: apps/v1beta2
kind: DaemonSet
metadata:
  labels:
    app: do-node-agent
  name: do-node-agent
  namespace: prometheus
spec:
  selector:
    matchLabels:
      app: do-node-agent
  template:
    metadata:
      labels:
        app: do-node-agent
    spec:
      containers:
      - name: do-node-agent
        image: docker.io/digitalocean/do-agent:2.0
        ports:
          - hostPort: 10253
            containerPort: 10253
            protocol: TCP
            name: metrics
        resources:
          limits:
            cpu: 102m
            memory: 100Mi
          requests:
            cpu: 102m
            memory: 80Mi
        volumeMounts:
        - mountPath: /host/proc
          name: proc
          readOnly: true
        - mountPath: /host/sys
          name: sys
          readOnly: true
        - mountPath: /host/root
          mountPropagation: HostToContainer
          name: root
          readOnly: true
        command:
          - "/bin/do-agent"
          - "--path.procfs=/host/proc"
          - "--path.sysfs=/host/sys"
          - "--k8s-metrics-path=http://kube-state-metrics.kube-system.svc.cluster.local:8080/metrics"
      nodeSelector:
        beta.kubernetes.io/os: linux
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
      serviceAccountName: do-agent
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
      volumes:
      - hostPath:
          path: /proc
        name: proc
      - hostPath:
          path: /sys
        name: sys
      - hostPath:
          path: /
        name: root

EDIT:
I guess the reason is the Droplet Metadata service.
When I curl the metadata url from inside I got following output:

k8saas_role: _<hidden>_
k8saas_master_domain_name: _<hidden>_
k8saas_bootstrap_token: _<hidden>_
k8saas_proxy_token: _<hidden>_
k8saas_ca_cert: _<hidden>_
k8saas_etcd_ca: _<hidden>_
k8saas_etcd_key: _<hidden>_
k8saas_overlay_subnet: _<hidden>_
k8saas_dns_service_ip: _<hidden>_

As you can see there is no entry named "k8saas_cluster_uuid:", and that is the reason why the App thorws panic. (See code here)

As discussed in #32 - which is closed by inactivity - an agent can be deployed using a container (see #32 (comment)).

Please, consider adding this as an option.

Is there a way to use the new do-agent with upstart? I'm not a fan of systemd.

Also the bash upgrade script is a bit sketchy to me, if anyone hacked your github account, they could compromise the production systems of anyone who ran the script that you are recommending. Good sysadmins will read the script, but 50% of sysadmins are not good and 25% of the good ones wouldn't catch it if someone was sneaky enough.

To make this slightly more useful, is it possible to document the protocol used beyond it being gRPC, and ideally the exception the client has of the server side? That would make it easier for both adding new metric collection and pointing it towards third party collection servers.