Introduction
Elastifile has a built-in call home function that monitors the system status and sends hourly reports.
In addition, in the case of an event in your system, a notification is sent to our support team, allowing them to proactively offer assistance and help you ensure the system is up and running.
These notifications and reports contain only anonymized information about your system and do not include any stored data from your system.
Any Elastifile version which is below 3.2.1.30 uses the old 3rd party solution called Sendgrid, unless it was patched by the support team.
In version 3.2.1.30 and above, Elastifile introduced a new approach based on GCP native solution that give Elastifile better control over the data in transit and at rest.
Important note:
The cutoff date for the 3rd party solution removal is September 30th, 2020. After that day systems that are not set with the GCP native solution will not report back to the call home system and will not enjoy proactive support.
Forcing a Manual CallHome Request
1. Using elfs-cli command (recommended):
[root@callhome ~(elfs_admin)]# elfs-cli system callhome --id 1
2. If the command is not available in the version you run, you can use the following:
root@emanage2 /elastifile/emanage# ./console.sh
Loading production environment (Rails 4.2.3)
irb(main):001:0> CallHome.call("test")
Sent call home report
=> true
Process Verification
GCP Native Solution
The following entries should be found after a success attempt in /elastifile/log/emange/production.log file:
* Note- The file name would changed per new attempt.
Running command 'gsutil cp /elastifile/emanage/tmp/528ec826ead0c9155ff135ca7bd0a6f714aadae8 gs://callhome' on 'localhost (ip: 127.0.0.1)'
localhost> Copying file:///elastifile/emanage/tmp/528ec826ead0c9155ff135ca7bd0a6f714aadae8 [Content-Type=application/octet-stream]...
localhost> Operation completed over 1 objects/27.4 KiB.
Running command '/bin/rm -f /elastifile/emanage/tmp/528ec826ead0c9155ff135ca7bd0a6f714aadae8' on 'localhost (ip: 127.0.0.1)'
Sendgrid
In the production.log file, you can find the following entries for a successful or failed indications:
Good Messages-
root@emanage ~# grep "Sent call home report" /elastifile/log/emanage/production.log
I, [2017-07-08T23:00:00.694249 #909] INFO -- : Sent call home report
I, [2017-07-09T23:00:00.844501 #909] INFO -- : Sent call home report
Bad Messages-
root@emanage ~# grep "Sent call home report" /elastifile/log/emanage/production.log
E, [2017-07-08T23:00:00.694249 #909] ERROR -- : Error sending call home report
E, [2017-07-09T23:00:00.844501 #909] ERROR -- : Error sending call home report
SendGrid Version
Sendgrid Requirements
The 3rd party approach by Sendgrid, requires access to the Sendgrid API from the network perspective.
In order to do that, follow the above steps:
1. Open port 443 outbound from EMS server to api.sendgrid.com
2. Verify by running telnet on the EMS:
root@emanage ~# telnet api.sendgrid.com 443
Trying 159.122.224.200...
Connected to api.sendgrid.com.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
Apply Sendgrid Patch
For version 3.2.1.30 and below, Sendgrid requires a patch for the cluster to send information to NOC in order for support team to be able to provide proactive support and monitoring.
Important note:
The cutoff date for the 3rd party solution removal is September 30th, 2020. After that day systems that are not set with the GCP native solution will not report back to the call home system and will not enjoy proactive support.
To download the sendgrid patch:
1. SSH to EMS for that system and change to root
$ sudo su -
2. Download patch from bucket
$ gsutil -m cp gs://elastifile-software-repo/Sendgrid_replacement_patch/0001-emanage-EL-17016-replace-sendgrid-with-gs-bucket.patch /root/
3. Change to elastifile dir
$ cd /elastifile/
4. Apply patch
$ patch -p1 < /root/0001-emanage-EL-17016-replace-sendgrid-with-gs-bucket.patch
5. Re-start the EMS services
$ systemctl restart emanage
$ systemctl status emanage