I was involved in a long conversation about how to best migrate in place from Sensu Classic to Sensu Go, as part of a migration strategy. Here’s the key take aways from the discussion.
Known In-place Migration Difficulties
It’s possible to install the latest version of Sensu Classic (1.8 as of this post) side by side with Sensu Go (5.11 as of this post) without packaging conflicts. Previous versions of Sensu Classic may have packaging conflicts.
sensu-plugins-ruby package conflicts with Sensu Classic (both provide sensu-install) . It’s safe to force the install, just make sure you know which sensu-install is on the system to avoid confusion as to which ruby environment it installs into.
sensu-agent will fail to start while sensu-client is running if configured to offer sensu-client port (3030).
In-place Migration Strategy for Sensu Classic users
Note 1: Only attempt with Sensu Classic 1.8 or newer (if you are using Sensu Enterprise check with Sensu Enterprise support team for migration assitance)
Note 2: These steps have been tested on a CentOS 7 system, instruction details may need to be adapted for other target, but should work.
install sensu-go packages on target systems
sensu-go-backend and sensu-go-cli on the host running sensu-server
sensu-go-agent on the host running sensu-client
Adjust the sensu-agent configuration to disable the 3030 client socket
you’ll want to edit the /etc/sensu/agent.yml file
Leave this disabled until the migration is completed and the old sensu client is stopped.
Adjust the sensu-agent service to include the Sensu Classic ruby path and the new sensu-plugin-ruby path. Add file /etc/default/sensu-agent:
The situation really wouldn’t be much different except you’d want to copy the existing Sensu configs out of the production volume mount being used by the docker container, and into a workstation environment where you can run the translator gem as an aid to start the migration process.
Transaction check error:
file /var/log/sensu from install of sensu-go-agent-5.14.2-7022.x86_64 conflicts with file from package sensu-1:0.26.5-2.x86_64
Ah that is an older release of Sensu classic 0.25.
We made some packaging adjustments in the Sensu classic packages (1.8) that would prevent this conflict from happening.
It’s a pretty minor conflict as to what package owns a particular directory structure.
it should be save to force the install of the sensu-go-agent package via rpm.
Once you download the rpm locally onto that system you should be able to run rpm -ivh --force sensu-go-agent and get it installed.
I have a Host where i installed sensu core 1.8x and Sensu Go on docker containers (migration process).
but i’m not able to find backend.yml on /etc/sensu (either on host or on container)
When i run this command : sensu-backend start inside the container i get this error.
{“component”:“sensu-enterprise”,“error”:“error starting etcd: listen tcp 127.0.0.1:2380: bind: address already in use”,“level”:“fatal”,“msg”:“error executing sensu-backend”,“time”:“2019-11-11T11:22:48Z”}
I was able to translate the config files using the sensu-translator
sensu-translator -d /etc/sensu/conf.d -o /sensu_config_translated (inside sensu core container)
After sensuctl create --file /path/to/config.json (inside sensu Go container)
I get this following error:
resource 2: json: unknown field “severities”
resource 3: json: unknown field “username”
resource 5: json: unknown field “severities”
Error: in /etc/sensu/sensu_config_translated_singlefile.json: some resources couldn’t be parsed
As of now i’m only able to view Keepalive Alerts on sensu-backend web UI , No cpu , disk or Memory checks . Just keepalive
Anyone can help me on this? And also During migration has anyone worked on Translating metric checks ? https://docs.sensu.io/sensu-core/1.8/migration/#translating-metric-checks
(The Sensu 1.x type: metric attribute is no longer part of the Sensu Go check spec, so we’ll need to adjust it by hand) what exactly we need to adjust here ?
there is no default backend.yml installed as part of the sensu-go container or as part of sensu-go backend packaging.
If you are using Docker, you may want to look at the docker compose configuration for help with a workable pattern to follow.
You have another services already bound to power 2380 inside the docker network you are using inside your sensu-go container most likely. Sensu-go backend spins up an embedded etcd instance by default, using default etcd listen ports for clients and peers (tcp 2379 and 2380) You can adjust that with either runtime commandline options to sensu-backend or using the config file.
The translator is an aid, but it can not automatically translate everything due to the change in data format. Previously Sensu configurations were arbitrary json. In Sensu Go, the configuration resource files are much more structured, corresponding to the versioned resource types allowed by the backend api.
So as a result, the translator doesn’t know how to translate the json elements that do not map to a Sensu Go resource attribute definition.
You’ll need to inspect the “annotations” in the translated output, for the portions of the json config that were not translated, so that you can manually adjust as needed.
It doesn’t sound like you have successfully migrated an existing check yet. Remember it’s not enough to translate the check configuration as a file on-disk. Sensu Go does not read the files on-disk, but instead uses the etcd data store. So you need to use sensuctl create -f <resource_file> to ensure correct operation. Or use the web-ui check creation features (requires enterprise license currently - until 5.15 release)
I think we have a quick Sandbox lesson plan that tries to cover a simple migration example involving a metric check.