|Note: This document is also available in other formats|
A PDF version of this document along with all current and older documentation in PDF format can be found at https://my.clavister.com.
It is also available in a framed HTML version.
The Scope of this GuideThis guide outlines the data collection procedures to be used with the on-premises Clavister InCenter product when entering a Support Ticket into the Clavister support system. The procedures it describes should be applied for each ticket submitted.
Following the recommendations in this document ensures that appropriate and sufficient information is provided to support personnel in order to achieve timely issue resolution.
Support TicketsA Support Ticket is the basis for all issue reporting to Clavister support personnel. It is created online after logging in to the MyClavister section of the Clavister website and then selecting the Help Desk option. After creation, each ticket goes through a defined process towards a satisfactory resolution. Creating tickets and the resolution process are described in Chapter 2, Creating Tickets.
A ticket single relates to a single issue for which resolution is sought. Once entered, both the customer and support personnel can provide and exchange information via the ticket system with email notifications going to the customer when the ticket's status changes.
Providing the Required Information is ImportantIf a ticket is incorrectly entered or the necessary information and/or attachments are missing, processing can be delayed or may even require resubmission. It is therefore vital to provide all the mandatory information and any relevant optional information.
|Important: This guide is subject to change|
This document is subject to change between InCenter releases and will be updated whenever features affecting troubleshooting and logging are changed.
This chapter looks in detail at how a Support Ticket is created when reporting an issue to Clavister support personnel.
Using the Support Ticket SystemTo create a new ticket in the Clavister support ticket system, use the following steps:
Open a web browser and log into the relevant account at https://my.clavister.com.
As explained at the end of this chapter, a new account may need to be created which will then need to be associated with an organization's administrator account.
The next step allows a short and longer textual description of the problem to be entered along with the estimated priority of the reported issue.
As an option, it is possible to enter the user's own internal reference number for the ticket.
The final step in ticket creation is to review the entered information and confirm it. Note that email notifications associated with the ticket are sent to the email address associated with the MyClavister account being used to create the ticket and this email address appears in this confirmation step.
As described at the end of Chapter 1, Introduction & Scope, an organization could create several MyClavister accounts in order to send different sets of ticket notifications to different email addresses.
Support Ticket ComponentsThe following submitted components make up a support ticket:
A. The Issue Description
These two components will now be described further.
A. The Issue DescriptionThis part allows the entry of free text to describe the issue. The text description is in two parts:
The longer text description should cover the following:
Categorize the end-user impact by selecting a severity description from the list provided. The descriptions translate to one of the following severities:
B. AttachmentsA support ticket usually also includes attachments which consist of files containing system output that help support personnel to understand the issue. These files should be compressed together into a single ZIP file. The ZIP file is then added after ticket creation by opening the ticket and then dragging and dropping the ZIP file into the attachment box on the webpage.
The attachment should be a single compressed ZIP file. Do not use tar + gzip.
Where the ZIP file exceeds 25 MBytes, it should not be attached to a ticket in the MyClavister system. Instead, support personnel should be contacted to get instructions for uploading to Clavister support's FTP server. A request for FTP upload of attachments could be made in the description text that is entered when the ticket is created.
Attachments are described in more detail in Chapter 3, Attachments.
Available Customer Options After Ticket CreationOnce a ticket is created, there are three ticket options available to the administrator:
The Ticket Life Cycle and Ticket StatesA support ticket has a large number of possible states which indicate its progress in the ticket system. However, only a small number of states will be encountered by a typical ticket and those are the ones that will be discussed here.
The typical ticket life cycle and the associated states are as follows:
When the ticket has been created and is being examined and discussed, the ticket state is Open.
When support personnel have requested more information about a ticket, the state becomes Awaiting Information. This state could occur more than once as additional information is sought.
Supplying all the mandatory and any relevant optional information at the time of ticket creation can help to avoid this state.
When support personnel believe the issue has been resolved, the state will become Fixed. This is not the same as Closed.
When the state becomes Fixed, the ticket will remain in this state for two weeks. During these two weeks, the customer has the option to Reopen the ticket if they feel the issue has not been resolved.
If, after two weeks, the customer has not reopened the ticket, support personnel will set the state to Closed. The customer can also set the state to Closed if they believe the issue has been resolved and requires no further action.
The state reached when a ticket has been resolved. As described above, either support personnel or the customer will set the state to Closed.
Email NotificationsAny change of support ticket state is reported to the customer automatically via an email. The email will not state what has changed in the ticket, only that there has been a change.
The addition of comments by support personnel will also cause a notification email to be sent even though there may be no state change.
Multiple Organization Users Can Track a Single TicketMultiple login accounts can be associated with a single organisation in the support system and it is possible for any of these to see a ticket and also get email notifications of status changes.
An Explanation of the MyClavister User Account HierarchyEach customer organization should have at least one initial top-level administrator MyClavister account. Each administrator account will have product licenses associated with it and also has a complete overview of tickets associated with those licenses. For smaller organizations this can be sufficient.
However, for larger organizations with many product installations, multiple new user accounts could be created later, with different login credentials and email addresses, and these can then be linked with the organization. Linking is done by an administrator account inviting in a new user so they become associated with the same organization as the administrator. The administrator can then assign access rights to the newly included user. A new user could be given administrator privileges too or, more typically, they might be given only restricted access to support tickets and/or licenses.
It is often beneficial for a larger organization to have one or a small number of administrator user accounts and then different user groups could create accounts which are invited in by an administrator to be part of an organization. This will mean that accounts can have a separate email address so that email traffic related to their support tickets will go only to the user who created the ticket. However, an administrator or any user with support ticket access privileges will still have the ability to see the ticket details for all the accounts associated with an organization.
This chapter reviews the attachments that may be included with a support ticket in a single ZIP file and describes how they are created and the folder structure in which they should be sent. Before beginning the process of gathering data, a number of points should be noted:
Create Attachments Directly After Issue Occurrence
Try to create all attachments as soon as possible after the issue occurs and, where possible, before a system reboot.
Check the System Date and Time
Before commencing the data collection necessary for support ticket attachments, make sure that the InCenter system date and time are set correctly.
This is important for the accuracy of the timestamps on submitted data.
CLI Console Access
Access to the InCenter CLI is done via the management IP address using SSH. SSH access will require using third-party console client software such as PuTTY. The CLI output can then be saved to a file for submission as an attachment. In the PuTTY client this is done by selecting Session > Logging > All Session Output.
Some of the CLI commands used for data collection might generate a large amount of output. For this reason, the output buffer size of the console client being used for CLI access should be checked and increased if necessary.
Mandatory and Optional AttachmentsAttachments are considered to be either mandatory or optional. When submitting a new ticket, it is advisable to provide the mandatory attachments (configuration and techsupport output) since they are considered the minimum amount of information usually needed for timely issue resolution.
The optional attachments should be provided where the ticket creator judges they are relevant to the reported issue. Both types of attachments will now be described further.
A. Mandatory Attachments
B. Optional Attachments
The Format and Folder Structure for Submitted DataAll attachments for a given support ticket should be submitted in a single compressed ZIP file. The structure of the compressed files submitted should follow the hierarchical folder structure shown below, with subfolders included as needed:
TIC-nnnn Eventn_ICEnn_YYYYMMDD_HHMM Techsupport Config CLI Logs VM
At a minimum, the Config and Techsupport subfolders should always be included. Other folders should be included when relevant.
The folder naming scheme used in the above structure is the following:
Including Multiple Incidents/servers in One TicketWhen reporting several issues within the same support ticket, place each issue into its own Eventnnn_ICEnn_YYYYMMDD_HHMM folder.
When the issue involves a redundant cluster of InCenter servers, there should be one Eventnnn_ICEnn_YYYYMMDD_HHMM folder for each server.
Each of the lower level subfolders is designed to hold those files related to a specific subject and the different subfolders and subjects are discussed next.
The Config FolderThis mandatory folder contains a backup file of the configuration. A backup is created by running the backup.sh script outside of InCenter and in the underlying Linux system. The script can be found in the Linux folder /home/administrator/scripts. A typical Linux command to run the script could be the following:
$ ./backup.sh my-config.tar.gzThe backup file created can then be downloaded to the local disk of the management computer using SCP. The SCP command must connect to the management IP of the InCenter server on port 2222 to do this. A typical SCP command might take the following form:
> scp -P 2222 administrator@<ip>/home/administrator/my-config.tar.gz /<folder>/Where <ip> is the InCenter management IP address and <folder> is the local directory the file will be saved into.
The Techsupport FolderThis mandatory folder holds the file(s) created by running the output of the techsupport CLI command. This output is the most important source of troubleshooting information and the output file from the command is often referred to by support personnel as the TSF (Technical Support File).
For troubleshooting InCenter problems, the techsupport command should be used without any parameters:
admin@InCenter:/>techsupport Collecting and storing Technical Support Information... Technical Support file created: InCenter-techsupport-2019-12-30T23_12_42.tar.gz
This will save a file which provides information about only the InCenter system itself and not any of the nodes under its control. The file will be saved in the InCenter system folder called techsupport. SCP can be used to download the file by connecting to the InCenter management IP on port 22. A typical SCP command line to download the system log file to the local management disk would be the following:
> scp admin@<mgmt-IP>:./techsupport/<techsupport-filename> .
Ideally, the techsupport tool should be run immediately after a problem occurs so that the state of InCenter after the event can be viewed. However, in some cases, running the command as late as possible prior to the event can provide additional information or may even be necessary if the tool cannot function after the critical event.
If, for some reason, the InCenter CLI is not available but access is still possible to the
CLI of the underlying Linux system, there is a script called techsupport.sh
which can be run instead of the command. The resulting output will be the same as the command and can
be downloaded in the same way from the same folder. The script is preinstalled in the folder
/home/administrator/scripts and can be run using the Linux command:
The CLI FolderThis optional folder holds any relevant InCenter console output which is additional to the output of the techsupport tool. An administrator CLI console should be opened to capture this output from InCenter.
The Logs FolderThis optional folder contains log event information. The recommendation is to provide logs that cover at least 30 minutes before the system issue occurred and, where possible, 30 minutes after the issue.
Using SCP on port 22 of the management IP address is used to download system log files from the InCenter system directory called logs. A typical SCP command line to download the system log file to the local management disk could take the following form:
> scp admin@<mgmt-IP>:./logs/system.log .
It is also possible to send InCenter system log messages to an external Syslog server and this provides an alternative method of collecting logs for the attachment. Setting up a Syslog server is described in the separate InCenter Administration Guide.
The VM FolderThis optional folder contains a text file which describes the virtual environment in which InCenter is running. Details should include the hypervisor type and version number.