/sensu-go/6.12/operations/monitor-sensu/ Recent content in Monitor Sensu on Sensu Docs Hugo -- gohugo.io en-us /sensu-go/6.12/operations/monitor-sensu/log-sensu-systemd/ Mon, 01 Jan 0001 00:00:00 +0000 /sensu-go/6.12/operations/monitor-sensu/log-sensu-systemd/ By default, systems where systemd is the service manager do not write logs to /var/log/sensu/ for the sensu-agent and the sensu-backend services. This guide explains how to add log forwarding from journald to syslog, have rsyslog write logging data to disk, and set up log rotation of the newly created log files. Requirements To follow this guide, install the Sensu backend and make sure at least one Sensu agent is running. /sensu-go/6.12/operations/monitor-sensu/monitor-sensu-with-sensu/ Mon, 01 Jan 0001 00:00:00 +0000 /sensu-go/6.12/operations/monitor-sensu/monitor-sensu-with-sensu/ This guide describes best practices and strategies for monitoring the Sensu backend with another Sensu backend or cluster. To completely monitor Sensu (a Sensu backend with internal etcd and an agent), you will need at least one independent Sensu instance in addition to the primary instance you want to monitor. The second Sensu instance will ensure that you are notified when the primary is down and vice versa. This guide requires Sensu plugins using dynamic runtime assets. /sensu-go/6.12/operations/monitor-sensu/health/ Mon, 01 Jan 0001 00:00:00 +0000 /sensu-go/6.12/operations/monitor-sensu/health/ Use Sensu’s /health API to make sure your backend is up and running and check the health of your etcd cluster members and PostgreSQL datastore resources. A request to the /health API endpoint retrieves a JSON map with health data for your Sensu instance. Here’s an example request to the health endpoint: curl -X GET \ http://127.0.0.1:8080/health Healthy cluster example In this example, all cluster members are healthy. { "Alarms": null, "ClusterHealth": [ { "MemberID": 9861478486968594000, "MemberIDHex": "88db026f7feb72b4", "Name": "backend01", "Err": "", "Healthy": true }, { "MemberID": 16828500076473182000, "MemberIDHex": "e98ad7a888d16bd6", "Name": "backend02", "Err": "", "Healthy": true }, { "MemberID": 848052855499371400, "MemberIDHex": "bc4e39432cbb36d", "Name": "backend03", "Err": "", "Healthy": true } ], "Header": { "cluster_id": 17701109828877156000, "member_id": 16828500076473182000, "raft_term": 42 } }, "PostgresHealth": [ { "Name": "my-first-postgres", "Active": true, "Healthy": true }, { "Name": "my-other-postgres", "Active": false, "Healthy": false } ] } Unhealthy cluster member example In this example, one cluster member is unhealthy: it cannot communicate with the other cluster members. /sensu-go/6.12/operations/monitor-sensu/ready/ Mon, 01 Jan 0001 00:00:00 +0000 /sensu-go/6.12/operations/monitor-sensu/ready/ Use Sensu’s /ready API endpoint to confirm whether a Sensu instance is ready to serve API requests and accept agent connections. A request to the /ready backend API endpoint retrieves a text response with information about whether your Sensu instance is ready to serve API requests. Here’s an example request to the /ready API endpoint: curl -X GET \ http://127.0.0.1:8080/ready A request to the /ready agent transport API endpoint via the backend WebSocket retrieves information about whether your Sensu instance is ready to accept agent connections. /sensu-go/6.12/operations/monitor-sensu/tessen/ Mon, 01 Jan 0001 00:00:00 +0000 /sensu-go/6.12/operations/monitor-sensu/tessen/ Tessen is the Sensu call-home service. It is enabled by default on Sensu backends. Tessen sends anonymized data about Sensu instances to Sensu Inc., including the version, cluster size, number of events processed, and number of resources created (like checks and handlers). We rely on Tessen data to understand how Sensu is being used and make informed decisions about product improvements. Read Announcing Tessen, the Sensu call-home service to learn more about Tessen.