InCenter 2.2.2 On-Premises Data Collection Guide


Table of Contents

1. Introduction & Scope
2. Creating Tickets
3. Attachments

Chapter 1: Introduction & Scope

[Note] 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 also available in a framed HTML version.

The Scope of this Guide

This 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 Tickets

A 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 Important

If 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.

The information that is required and the information which is optional is described in Chapter 2, Creating Tickets as well as in Chapter 3, Attachments.

[Important] 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.

Chapter 2: Creating Tickets

This chapter looks in detail at how a Support Ticket is created when reporting an issue to Clavister support personnel.

Using the Support Ticket System

To create a new ticket in the Clavister support ticket system, use the following steps:

  1. 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.

  2. From the navigation menu, select Help Desk and then Register Support Ticket from the sub-menu.
  3. Drop-down boxes now allow the product, the product version and the product license to be selected. The MyClavister account entering the ticket must have the relevant product license assigned to it. It is not possible to create a ticket without an associated product license.
  4. 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.

  5. 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.

  6. At this point, the ticket is created and is automatically assigned a unique ticket number by the ticket system with the form TIC-NNNN.
  7. The ticket can now be opened in MyClavister by the user and the relevant attachments added. These attachments and the textual descriptions entered for a ticket are described further below.

Support Ticket Components

The following submitted components make up a support ticket:

A. The Issue Description

B. Attachments

These two components will now be described further.

A. The Issue Description

This part allows the entry of free text to describe the issue. The text description is in two parts:

  • A short one line summary description of the issue.
  • A longer, complete description of the issue.

The longer text description should cover the following:

  • Provide a further description of the issue.
  • Give a general description of the complete system. What is the computing platform and what is the software version?
  • Categorize the end-user impact by selecting a severity description from the list provided. The descriptions translate to one of the following severities:

    • Low
    • Medium
    • High
    • Emergency

  • Can the issue be easily reproduced?
  • What is the frequency of the issue?
  • Is the issue dependent on a specific change in the configuration?
  • Is the issue site specific?
  • What system activity was occurring when the issue appeared?
  • Have there been any changes to the system prior to the issue occurring.
  • Have there been any recent changes to the surrounding network prior to the issue occurring, such as the following:
    1. Have any other parts of the network been upgraded?
    2. Has there been significant changes in system loads?
    3. When dealing with remote networks or remote clients, has there been any recent change in those networks or clients?

B. Attachments

A 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 Creation

Once a ticket is created, there are three ticket options available to the administrator:

  • Add attachments - As described above, these are troubleshooting files provided by the customer in a single ZIP file which is added to a ticket after creation.
  • Enter a comment - This is the primary means for discussion about the issue with support personnel.
  • Change the status to Closed - This should be done if the issue is resolved or the ticket doesn't need further action.

The Ticket Life Cycle and Ticket States

A 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:

  • Open

    When the ticket has been created and is being examined and discussed, the ticket state is Open.

  • Awaiting Information

    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.

  • Fixed

    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.

  • Closed

    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 Notifications

Any 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 Ticket

Multiple 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 Hierarchy

Each 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.

Chapter 3: Attachments

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 Attachments

Attachments 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

  • The techsupport file generated by running the techsupport tool.
  • The InCenter configuration in backup file form.

B. Optional Attachments

  • Relevant CLI output in file form.
  • Relevant system log messages.
  • A description of the virtual environment.
  • Any other relevant information.

The Format and Folder Structure for Submitted Data

All 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:

  • TIC-nnn - Where nnn is the ticket ID. This ID is allocated automatically by the system when the ticket is created.
  • Eventn - Where n is the event ID. This is assigned by the customer. Information related to the first occurrence of an issue would use the name prefix Event1, the second Event2 and so on.
  • ICEnn - Where nn is the InCenter server ID.
  • YYYYMMDD_HHMM - The date and time when the issue occurred. The date and time for Event1 will be before Event2 which is before Event3 and so on.

Including Multiple Incidents/servers in One Ticket

When 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 Folder

This 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.gz
The 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 Folder

This 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:

$ ./techsupport.sh

The CLI Folder

This 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 Folder

This 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 Folder

This 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.