Sumologic

Agent setup

Fetch the installation script
curl -o archagentctl https://bin.archsaber.com/install/archagentctl && chmod 755 archagentctl
Execute the script with your license key
sudo ./archagentctl -i <your license key>

You can get your license key from your profile page

The agent archagent will be installed as a service and automatically started.


Usage

You can use the archagentctl utility downloaded above to control the archagent as well.

sudo archagentctl -c <start|stop|restart|status>

We recommend you add this utility to your $PATH. However, in case you don't want to use this utility, the commands to control the agent will depend on your OS, as detailed below.

For systemd users:
sudo systemctl <start|stop|restart|status> archagent

systemd is the default service manager for Debian >= 8, Ubuntu >=15.04, CentOS >= 7.14.4, Red Hat Enterprise Linux >=7.0, openSUSE >= 12.2, CoreOS > v94.0, Arch Linux

For systemv users:
sudo service archagent <start|stop|restart|status>

NOTE : To start the service upon forceful kill (kill -9) or after a system halt, instead of start run the restart task to enable the agent.

sudo archagentctl -c restart or sudo systemctl restart archagent or sudo service restart archagent


Uninstall

sudo ./archagentctl -u

This removes the agent's binary, config and log files.


Docker (ArchSaber's standard image)

You can run archsaber agents in a separate docker container to ensure isolation from your core services. This can be done by either using the standard container image that we provide, or, defining your own container image which can reside in your docker registry. This section covers the former.

ArchSaber provides an image which effectively runs supervisord to exec the agents inside a docker container. Before starting the docker container, the relevant configs need to be present. Take the following steps in order to run the agents inside a docker container:

  1. Downloading agent binaries and configs:

    curl -o archagentctl https://bin.archsaber.com/install/archagentctl && chmod 755 archagentctl && sudo ./archagentctl -d <your license key>
    
  2. Now that the binaries and configs are available, start the container with the directories of the agents and configs mounted:

    docker run -d --name <choose a name> --network <network name> -v /proc/:/host/proc/:ro -v /etc/:/host/etc/:ro -v /sys/:/host/sys/:ro -v /etc/opt/archsaber/:/etc/opt/archsaber/:rw -v /opt/archsaber/bin/:/opt/archsaber/bin/:rw archsaber/agents
    

Note that it is recommended that you provide a custom name to the container (through the --name flag). To enable the agents to communicate with other services running in different containers on the same underlying host, it is necessary to specify the same network for the archsaber container (through the --network flag). It is recommended that this common underlying network should not be the default network, or else container names specified as endpoints would not be resolved. The -v flag is needed to ensure bind mounts of the directories specified above, which are needed for metric collection. These directories are mounted in read-only mode (ro flag as specified above).

Modifying and Updating the Configs

The configs are located in /etc/opt/archsaber/ on the underlying host on which the docker container is running. In order to monitor services running inside other containers, you can specify either the container name or its IP address as the endpoint and other credentials in the config data.json.

To stop your docker container, we recommend using a graceful timeout of more than the default, 10 secs

docker stop -t 20 <container-id>

Docker (Create your image)

You can run archsaber agents in a separate docker container to ensure isolation from your core services. This can be done by either defining your own container image which can reside in your docker registry, or, using the standard container image that we provide. This section covers the latter.

Since you need to run archagent and archsaber-trace-agent, we recommend using a supervisor process, such as supervisord, which can be invoked via a script that downloads the required binaries and configs first. It requires the license key in an environment variable which will be passed at the time of docker run. Let's call this script downloader.sh and it will look something like this

#! /bin/bash
# check for license key
if [ "$LICENSE_KEY" == "" ]
then
    echo "No License Key: "$LICENSE_KEY" arg:"$arg > /tmp/service.log
    exit
fi
curl -o archagentctl https://bin.archsaber.com/install/archagentctl
chmod 755 archagentctl
./archagentctl -d $LICENSE_KEY
exec /usr/bin/supervisord -c /etc/supervisor/conf.d/supervisord.conf

Your supervisord.conf will look something like the following

[supervisord]
nodaemon=true

[program:archagent]
command=./archagentctl -e archagent
startsecs=0
startretries=0
autorestart=false
stopsignal=INT
user=root

[program:archsaber-trace-agent]
command=./archagentctl -e archsaber-trace-agent
startsecs=0
startretries=0
autorestart=false
stopsignal=INT
user=root

Here we have configured supervisord to send the INT signal to the agent processes upon docker shutdown.

Finally, your Dockerfile should look something like the following (assuming you have a supervisord.conf and downloader.sh present alongside your Dockerfile)

FROM debian:8

RUN apt-get update && apt-get install -y curl sudo supervisor vim

ARG LICENSE_KEY
ENV HOST_ETC=/host/etc
ENV HOST_PROC=/host/proc
ENV HOST_SYS=/host/sys

# supervisord
ADD supervisord.conf /etc/supervisor/conf.d/supervisord.conf
ADD downloader.sh .
RUN chmod 755 downloader.sh
CMD ["sudo", "-E", "/bin/bash", "-c", "./downloader.sh"]

The steps in the dockerfile above invoke the downloader.sh script, which downloads the agents and configs, and further invokes supervisord. The supervisord, in turn, has been configured to exec the agents. One benefit of downloading agent binaries and configs through the script and not directly in the Dockerfile is that when the binaries and configs are updated at our end, there is no need to rebuild your docker image.

Once you have created the Dockerfile, you can build an image, push to your docker registry and use the following command to pull and run the image elsewhere.

docker build -t <image name> <directory of dockerfile>
docker run -d --name <choose a name> --network <network name> --env LICENSE_KEY='<your license key goes here>' -v /proc/:/host/proc/:ro -v /etc/:/host/etc/:ro -v /sys/:/host/sys/:ro <image name>

Do not forget to put your license key in the above command (it can be obtained from your profile page). Note that it is recommended that you provide a custom name to the container (through the --name flag). To enable the agents to communicate with other services running in different containers on the same underlying host, it is necessary to specify the same network for the archsaber container (through the --network flag). It is recommended that this common underlying network should not be the default network, or else container names specified as endpoints would not be resolved. The -v flag is needed to ensure bind mounts of the directories specified above, which are needed for metric collection. These directories are mounted in read-only mode (ro flag as specified above).

Modifying and Updating the Configs

The configs are located in /etc/opt/archsaber/ in the docker container. In order to monitor services running inside other containers, you can specify either the container name or its IP address as the endpoint and other credentials in the config /etc/opt/archsaber/data.json. To edit the config, you would to have to exec into the container

docker exec -it <container name> /bin/bash

And edit the config using an editor like nano or vi.

To stop your docker container, we recommend using a graceful timeout of more than the default, 10 secs

docker stop -t 20 <container-id>

Kubernetes

If you are using Kubernetes as your Docker container orchestration tool, you can deploy ArchSaber agent on each node using a Kubernetes daemonset. You need to enter your license key for the LICENSE_KEY env variable in following yml file (archsaber-agent.yml).

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: archsaber-agent
spec:
  template:
    metadata:
      labels:
        name: archsaber-agent
    spec:
      hostNetwork: true
      nodeSelector:
        beta.kubernetes.io/os: linux
      volumes:
      - name: host-root
        hostPath:
          path: /
      - name: host-etc
        hostPath:
          path: /etc
      - name: host-proc
        hostPath:
          path: /proc
      - name: host-sys
        hostPath:
          path: /sys
      containers:
      - name: archsaber-agent
        image: archsaber/archagent
        imagePullPolicy: Always
        volumeMounts:
        - name: host-root
          mountPath: /mnt/root
        - name: host-etc
          mountPath: /host/etc
        - name: host-proc
          mountPath: /host/proc
        - name: host-sys
          mountPath: /host/sys
        env:
        - name: HOST_ETC
          value: /host/etc
        - name: HOST_PROC
          value: /host/proc
        - name: HOST_SYS
          value: /host/sys
        - name: LICENSE_KEY
          value: <your license key>

By default, it picks the image archsaber/archagent, which was created in the same manner as mentioned in the previous section on creating your own image ("Docker (Create your image)"). You may create your own image and use that instead.

Once the archsaber-agent.yml file is created, create and deploy the daemonset using:

kubectl create -f archsaber-agent.yml --namespace=kube-system

You can verify that the archsaber-agent daemonset has been created successfully by:

kubectl get pods --namespace=kube-system
NAME                       READY     STATUS              RESTARTS   AGE
archsaber-agent-kvs5j      1/1       Running             0          1m
archsaber-agent-t5sg2      1/1       Running             0          1m

You can further access the logs of the corresponding pod:

kubectl logs -f archsaber-agent-kvs5j --namespace=kube-system

Updates

When there is a new rollout of archsaber agents, you can re-deploy by just deleting the daemonset and re-running it.

kubectl delete ds archsaber-agent --namespace=kube-system
kubectl create -f <path of yml file> --namespace=kube-system

results matching ""

    No results matching ""