ServicePilot Agents

What is a ServicePilot Agent?

ServicePilot Agents are designed to collect monitoring data from various sources and send this data to ServicePilot. ServicePilot Agents require minimal configuration. Once installed, all they need is a web access to ServicePilot and an API key to secure the communication. All further configuration is done through the ServicePilot web interface.

They have been designed to ensure the effectiveness in their data collection and transmission tasks with several mechanisms:

• Local processing: Some of the analysis can be performed locally. Filtering and aggregating raw data to transmit only essential KPIs to ServicePilot limits upstream flows.
• Secure protocol: It uses HTTP2 combined with the HTTPS protocol to help with compression, optimize exchanges and enable secure data communication.

There is always a requirement for at least one ServicePilot Agent, as virtually all data collection is performed by agents. The number of agents required depends on the type of monitoring the agents are asked to perform and if the agents can access the data required.

Local and remote data collection

Different ServicePilot Agents have different collection capabilities. To see if a ServicePilot Agent needs to be installed on the same server from which it will collect data, see the Local collect column in the Licenses - Agent details table in the ServicePilot web interface.

Local data collection	Remote data collection
Agents can collect data from the server on which they are installed. Some data collection can only be performed on the same host as a ServicePilot Agent.	Agents can also obtain data from other devices and listen for events that are pushed to them, provided that network access to other devices is not blocked.

ServicePilot Agent types

The table below lists the different types of ServicePilot agents, their platforms, their primary uses, and their technical specifications.

ServicePilot Agent installation

Download ServicePilot Agents

Obtain a ServicePilot API key

ServicePilot Agents communicate with ServicePilot using an API key. Multiple API keys may be created and used but each Agent needs to be configured with a valid write capable API key. To view the API keys that can be used, go to the API keys web page:

Install ServicePilot Agent

# chmod +x servicepilotlinuxagent.run
# ./servicepilotlinuxagent.run

Creating directory _agent_files
Verifying archive integrity...  100%   All good.
Uncompressing ServicePilot Linux Agent Package  100%
spagent install script running
No configuration found, awaiting input
Enter API KEY

10000000-0000-0000-0000-000000000000

Use web proxy? [default: n]

n

Use ServicePilot proxy? [default: n]

n

Run in debug mode? [default: n]

n

Enter ServicePilot Agent Log Path [default: '/var/log/servicepilot/']

/var/log/servicepilot/

This is debian based distro
Removing spagent files
Removing dotnetcoreagent files
Reset spagent
Created symlink /etc/systemd/system/multi-user.target.wants/spagent.service → /etc/systemd/system/spagent.service.
spagent started

#

./servicepilotlinuxagent.run -- --help

# Create a namespace for ServicePilot components
apiVersion: v1
kind: Namespace
metadata:
  name: monitoring
  labels:
    app: servicepilot-agent
---
# To have ServicePilot retrieve metrics from Kubelets with authentication and
# authorization enabled (which is highly recommended and included in security
# benchmarks) the following flags must be set on the kubelet(s):
#
# --authentication-token-webhook
# --authorization-mode=Webhook
#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: servicepilot-stats-viewer
  labels:
    rbac.authorization.k8s.io/servicepilot-stats-viewer: "true"
rules:
  - apiGroups: [""]
    resources:
      - nodes
      - nodes/proxy
      - nodes/metrics
      - nodes/stats
      - services
      - endpoints
      - pods
      - ingresses
      - configmaps
      - persistentvolumes
    verbs: ["get", "list", "watch"]
  - apiGroups: ["extensions", "networking.k8s.io"]
    resources:
      - ingresses/status
      - ingresses
    verbs: ["get", "list", "watch"]
  - apiGroups: ["metrics.k8s.io"]
    resources: 
      - pods
    verbs: ["get", "list", "watch"]
  - nonResourceURLs:
      - "/metrics"
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: servicepilot
  labels:
    app: servicepilot-agent
aggregationRule:
  clusterRoleSelectors:
    - matchLabels:
        rbac.authorization.k8s.io/servicepilot-stats-viewer: "true"
    - matchLabels:
        rbac.authorization.k8s.io/aggregate-to-view: "true"
rules: [] # Rules are automatically filled in by the controller manager.
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: servicepilot
  labels:
    app: servicepilot-agent
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: servicepilot
  labels:
    app: servicepilot-agent
subjects:
  - kind: ServiceAccount
    name: servicepilot
    namespace: monitoring
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: servicepilot
---
# ServicePilot Agent deployment
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: servicepilot-agent
  namespace: monitoring
  labels:
    app: servicepilot-agent
spec:
  selector:
    matchLabels:
      app: servicepilot-agent
  template:
    metadata:
      labels:
        app: servicepilot-agent
    spec:
      tolerations:
      # this toleration is to have the daemonset runnable on master nodes
      # remove it if your masters can't run pods
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      serviceAccountName: servicepilot
      containers:
        - name: servicepilot
          image: servicepilot/agent
          env:
          - name: SERVICEPILOT_API_KEY
            value: "10000000-0000-0000-0000-000000000000"
          - name: SERVICEPILOT_IP
            value: "data.servicepilot.com"
          - name: SERVICEPILOT_PORT
            value: "443"
          - name: HTTPS
            value: "1"
          - name: NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: NODE_IP
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP
          - name: HOSTNAME
            value: $(NODE_NAME)-pod
          - name: SP_K8_RESOURCE
            value: "K8 Cluster 1"
          - name: SP_K8_NAMESPACE_FILTER
            value: "*"
          - name: SP_K8_POD_FILTER
            value: "*"

Check that a ServicePilot Agent is working

To make sure that the ServicePilot Agents are communicating correctly with ServicePilot, open the Agents web page:

Set the Default agent

When provisioning resources, at least one ServicePilot Agent can be set to indicate to perform that resource monitoring on the same machine as the resource or from remote Agents.

If the Agent fields are left blank then the Default agent will be used to monitor the resource.

To change the ServicePilot Default agent:

Set a Backup agent

Optionally, a Backup agent can be set that will take over the monitoring responsibilities of the Default agent after a new minutes if the Default agent looses connectivity with the ServicePilot Manager. The Backup agent needs to be in a position to access all of the same resources as the Default agent and be installed on the same OS type as the Default agent.

To change the ServicePilot Backup agent:

The Backup agent cannot be the same value as the Default Agent.

ServicePilot Agent SPProxy

The SPProxy is a ServicePilot Agent proxy role that can act as a gateway and concentrator between several ServicePilot Agents and the ServicePilot Manager. In distributed environments and low-bandwidth remote sites, it greatly simplifies deployment because agents connect locally to the proxy. It helps with:

• Pooling and optimizing traffic: SPProxy aggregates and compresses communications from agents at the same site before transmitting them. With fewer simultaneous connections to the central server, it lowers bandwidth consumption and provides faster exchanges.
• Security and flow simplification: By consolidating outgoing communications, remote agents no longer need to open external sessions individually thus reducing exposure by limiting direct connections between the site and the ServicePilot platform. It provides end-to-end, systematic encryption of exchanges for all connected agents.

ServicePilot Agent logs

ServicePilot Agent logs may indicate connectivity errors between the ServicePilot Agent and ServicePilot or they may indicate issues obtaining data from devices. These Agent logs are particularly interesting if monitoring does not appear to work between the Agent and remote devices due to bad access credentials.

Open the Agent logs with a text editor:

C:\Program Files\ServicePilot\ServicePilot ISM Enterprise\logs\ServicePilotAgent.log

/var/log/servicepilot/servicepilotagent.log
/var/log/servicepilot/spgoagent.log

Uninstalling a ServicePilot Agent

If a ServicePilot Agent is no longer required, it can be uninstalled.

Check if an Agent is being used

ServicePilot Agent uninstallation

./servicepilotlinuxagent.run -- --uninstall

Remove uninstalled Agents from the Agent list

When an Agent is uninstalled from a system, the associated provisioned resources (monitored items, automatically created objects, dependent configurations, etc.) remain in ServicePilot as long as the Agent is still listed in the Agents list. Removing the Agent from this list therefore allows you to cleanly delete all related resources.

As long as an Agent is still installed and active, removing it from the list will have no lasting effect: it will continue to communicate with ServicePilot and will automatically re-register.

Here are the steps to remove an uninstalled Agent: