Call-home / Alerting: Difference between revisions
mNo edit summary |
m QSTOR-12340: consolidate the Alert Manager docs into one page - inline Template:AlertManager, add Object Quota thresholds, SMTP Port, the 15 ITSM modules, Alert Types pause options and the alert CLI; correct the severity levels and navigation; re-shoot all screenshots on master at 800px |
||
| Line 1: | Line 1: | ||
[[Category:admin_guide]] | [[Category:admin_guide]] | ||
QuantaStor's '''Alert Manager''' is the central place to configure how a Storage | |||
Grid notifies you when its systems need attention -- media replacement, capacity | |||
exhaustion, service failures -- and to set the capacity thresholds that trigger | |||
those notifications. | |||
Alerts are delivered through '''every''' configured mechanism, so a system with | |||
both email and PagerDuty configured sends each event to both. The available | |||
mechanisms are: | |||
''' | * '''Email''' via your SMTP server -- see '''[[#Email Alerts|Email Alerts]]''' | ||
* '''IT Service Management (ITSM) webhooks''' -- 15 supported platforms, see '''[[#ITSM Integrations|ITSM Integrations]]''' | |||
* '''[https://wiki.osnexus.com/index.php?title=SNMP_Agent_Setup SNMP]''' -- see '''[[#SNMP|SNMP]]''' | |||
* '''Syslog''', by appending alerts to the local system log | |||
* '''A custom alert handler''' you supply -- see '''[[#Custom Alert Handlers|Custom Alert Handlers]]''' | |||
{{ | '''Navigation:''' Storage Management --> ''select a Storage System'' --> Alert Manager ''(toolbar)'' | ||
Note the '''Alert Manager''' toolbar button is inert until a Storage System is | |||
selected in the tree. | |||
All alerts are also written to the audit log -- see | |||
'''[[#Audit Logging|Audit Logging]]'''. | |||
== Email Alerts == | |||
[[File:alertmgr_email.png|thumb|center|800px|Alert Manager, Email Alerts tab.]] | |||
'''Navigation:''' Alert Manager --> Email Alerts ''(tab)'' | |||
=== Email SMTP Server Settings === | |||
These settings route alerts through your mail server. | |||
* '''SMTP Server Address''' -- the address of an accessible SMTP relay or mail server, for example <code>mail.example.com</code>. | |||
* '''SMTP Port''' -- leave as <code>Auto</code> to use the default port for the selected connection security, or set an explicit port when your relay listens elsewhere. | |||
* '''SMTP Connection Security''' -- '''None''', '''STARTTLS''', or '''SSL/TLS'''. Prefer STARTTLS or SSL/TLS; '''None''' sends credentials and alert content unencrypted. | |||
* '''SMTP User''' / '''SMTP Password''' -- credentials for an account with permission to relay through that server. Leave blank for a relay that accepts unauthenticated mail from the storage network. | |||
=== Email Sender/Recipient === | |||
* '''Sender Email Address''' -- the address that appears in the ''From'' line. Make it unique and identifiable per storage grid, so an administrator can tell at a glance which system an alert came from. | |||
* '''Recipient Email Address''' -- an address or distribution list for the administrators monitoring this grid. '''This address receives every severity level.''' | |||
To route different severities to different people, leave the grid-wide recipient | |||
for the catch-all mailbox and configure '''per-user alert subscriptions''' | |||
instead, on the Add User or Modify User dialog. Each user can subscribe to any | |||
combination of '''Critical''', '''Error''', '''Warning''', and '''Info'''. See | |||
[[User_Add|Add User]] and [[User_Modify|Modify User]]. | |||
=== Append Alerts to Syslog === | |||
Ticking this uses the <code>logger</code> tool to append every alert to | |||
<code>/var/log/syslog</code> as well, which is useful when a syslog collector | |||
is already aggregating the estate. | |||
== ITSM Integrations == | |||
[[File:alertmgr_itsm.png|thumb|center|800px|Alert Manager, ITSM Integrations tab.]] | |||
IT Service Management (ITSM) modules deliver alerts to a service provider via a | |||
webhook URL or service token, so storage alerts land in the same queue as the | |||
rest of your infrastructure. | |||
'''Navigation:''' Alert Manager --> ITSM Integrations ''(tab)'' | |||
To add an integration, choose the '''Module''', paste the '''Webhook URL''' (or | |||
service token) that the provider issued, and press '''Add'''. The grid lists the | |||
configured integrations; select a row and press '''Remove Selected''' to delete | |||
one. Several integrations can be configured at once, and all of them receive | |||
every alert. | |||
The '''?''' button beside the Module selector opens the OSNEXUS documentation | |||
page for the selected module. | |||
=== Supported Modules === | |||
[[File:alertmgr_itsm_modules.png|thumb|center|800px|The Module selector, listing the supported ITSM platforms.]] | |||
{| class="wikitable" | |||
! Module !! Integration notes | |||
|- | |||
| [[AlertOps Integration|AlertOps]] || Inbound Integration | |||
|- | |||
| [[Dynatrace Integration|Dynatrace]] || Events V2 Ingest API | |||
|- | |||
| [[Freshservice Integration|Freshservice]] || Webhook API | |||
|- | |||
| [[Google Chat Integration|Google Chat]] || Google Chat channel webhook | |||
|- | |||
| [[Mattermost Integration|Mattermost]] || Mattermost channel webhook | |||
|- | |||
| [[Microsoft Teams Integration|Microsoft Teams]] || Teams channel webhook | |||
|- | |||
| [[OpsGenie Integration|OpsGenie]] || Atlassian OpsGenie V2 Alerts API | |||
|- | |||
| [[PagerDuty Integration|PagerDuty]] || Events V2 API | |||
|- | |||
| [[Lightstep Integration|ServiceNow Lightstep]] || Generic Webhook API | |||
|- | |||
| Slack || Slack channel webhook | |||
|- | |||
| [[Solarwinds Service Desk|SolarWinds]] || Solarwinds Service Desk API | |||
|- | |||
| [[Splunk On-Call Integration|Splunk On-Call]] || Webhook API (formerly VictorOps) | |||
|- | |||
| [[Squadcast Integration|Squadcast]] || Webhook API | |||
|- | |||
| [[XMatters Integration|XMatters]] || Webhook API | |||
|- | |||
| [[Zabbix Integration|Zabbix]] || Monitoring via the Zabbix platform | |||
|} | |||
The module definitions live on each system at: | |||
<pre> | |||
/opt/osnexus/quantastor/conf/qs_alerthandlers.conf | |||
</pre> | |||
Additional modules may be present but disabled by default. A module is enabled | |||
by uncommenting its stanza in that file and restarting the QuantaStor service; | |||
the handler scripts for every module ship regardless, so no reinstall is needed. | |||
Note the configuration reader only treats <code>#</code> at the start of a line | |||
as a comment. | |||
For the full per-provider setup walkthroughs see the | |||
[https://wiki.osnexus.com/index.php?title=%2B_Integration_Guide_Overview#Alert_Manager_/_IT_Service_Management_(ITSM)_Integration Integration Guide]. | |||
== Capacity Alert Thresholds == | |||
[[File:alertmgr_capacity.png|thumb|center|800px|Alert Manager, Capacity Alert Thresholds tab -- nine thresholds across three resource types.]] | |||
Capacity alerts fire when a Storage Pool, a quota-limited Network Share, or a | |||
quota-limited Object user crosses one of three thresholds. | |||
'''Navigation:''' Alert Manager --> Capacity Alert Thresholds ''(tab)'' | |||
'''All nine values are expressed as "% remaining", not % full.''' A Pool | |||
Low-space Warning of <code>30</code> means the alert fires when the pool has 30% | |||
free space left -- that is, when it is 70% full. | |||
The three severities escalate: | |||
* '''Warning''' -- an early notice that free space is getting low. | |||
* '''Urgent''' -- a follow-up reminder after the warning level was crossed. | |||
* '''Critical''' -- action should be taken immediately. | |||
Thresholds are set independently for three resource types: | |||
{| class="wikitable" | |||
! Resource !! Warning !! Urgent !! Critical | |||
|- | |||
| '''Storage Pool''' low free space || 30% remaining || 10% remaining || 5% remaining | |||
|- | |||
| '''Share Quota''' low space || 20% remaining || 10% remaining || 5% remaining | |||
|- | |||
| '''Object Quota''' low space || 20% remaining || 10% remaining || 5% remaining | |||
|} | |||
(The values above are the shipped defaults; each has a slider and a numeric | |||
field.) | |||
Share and Object quota pressure is usually resolved by raising the quota. | |||
Storage Pools need real capacity added, so act early: expand a pool at around | |||
'''30% remaining''' to maintain performance. Pool performance can degrade once | |||
utilization passes 90% (10% remaining), depending on fragmentation, so the | |||
Urgent and Critical thresholds are deliberately late-stage warnings rather than | |||
planning tools. | |||
== Alert Types == | |||
[[File:alertmgr_alert_types.png|thumb|center|800px|Alert Manager, Alert Types tab. Each alert type carries an SNMP ID and can be disabled or paused.]] | |||
QuantaStor defines '''289 alert types'''. Each has a numeric '''SNMP ID''', a | |||
'''Title''', a '''Status''', and a '''Pause Duration'''. | |||
'''Navigation:''' Alert Manager --> Alert Types ''(tab)'' | |||
This tab is how you silence a persistent alert while maintenance is in progress, | |||
without disabling alerting as a whole. Set a type's '''Status''' to one of: | |||
* '''Enabled''' -- the default. | |||
* '''Disabled''' -- the alert type never fires. It stays off until you re-enable it. | |||
* '''Pause (1 day)''', '''Pause (1 week)''', '''Pause (1 month)''', '''Pause (1 quarter)''' -- the alert type is silenced for that period and then '''resumes automatically''' when the pause window ends. | |||
Prefer a '''Pause''' over '''Disabled''' for maintenance work: a paused type | |||
comes back on its own, whereas a disabled one stays off until somebody | |||
remembers it. | |||
With 289 types the list is long, so use the filter: click the '''Title''' column | |||
header, tick '''Filters''', and type the text to match. | |||
The '''SNMP ID''' is the identifier the alert carries when delivered by SNMP | |||
trap. An individual alert's SNMP ID is also visible in its properties, by | |||
selecting the alert in the '''Alerts''' tab at the bottom of the interface. | |||
== SNMP == | |||
[[File:alertmgr_snmp.png|thumb|center|800px|Alert Manager, SNMP tab.]] | |||
Alerts can be delivered as SNMP traps. | |||
'''Navigation:''' Alert Manager --> SNMP ''(tab)'' | |||
Tick '''Enable SNMP Agent''', then supply the '''Username''' and '''Password''' | |||
under '''SNMP Credential Settings''' to require authenticated access. | |||
Full agent configuration, including trap destinations and the MIB, is covered | |||
under [https://wiki.osnexus.com/index.php?title=SNMP_Agent_Setup SNMP Agent Setup]. | |||
== Generating Test Alerts == | |||
[[File:alertmgr_test_alert.png|thumb|center|800px|Send User Generated Alert dialog -- a message and a severity.]] | |||
The '''Generate Test Alert''' button is available from every tab of the Alert | |||
Manager. It raises a real alert through every configured mechanism, which is the | |||
quickest way to confirm that SMTP settings, ITSM webhooks, and SNMP are actually | |||
working. | |||
'''IMPORTANT:''' save your settings with '''OK''' or '''Apply''' '''before''' | |||
sending a test alert. An unsaved SMTP server address is not used for the test. | |||
The dialog takes a '''Message''' and a '''Severity'''. Send one at | |||
'''Warning''' level as a first check, since some ITSM integrations filter | |||
informational events by default. | |||
See [[Storage System User Alert|Send User Generated Alert]] for details. | |||
== Generating Alerts == | == Generating Alerts == | ||
QuantaStor systems | |||
QuantaStor systems raise alerts at four severity levels: '''Critical''', | |||
'''Error''', '''Warning''', and '''Info'''. These are the levels users subscribe | |||
to individually in their alert subscriptions. | |||
A single physical event commonly produces several alerts. A disk that needs | |||
replacing, for example, produces a ''Warning'' for the disk itself plus | |||
''Error'' level events from the controller, each of which raises its own alert. | |||
To raise an alert deliberately -- for a test, or from a script -- use the CLI: | |||
<pre> | |||
qs alert-raise --message="Scheduled maintenance window starting" --severity=warning | |||
</pre> | |||
...or the '''Generate Test Alert''' button described above. | |||
== Custom Alert Handlers == | |||
When none of the built-in mechanisms fit, you can supply your own handler. The | |||
per-vendor handlers that ship with QuantaStor are ordinary scripts in: | |||
<pre> | |||
/opt/osnexus/quantastor/bin/qs_alerthandler_*.py | |||
</pre> | |||
Any of them works as a worked example of the interface -- they read the alert | |||
from QuantaStor and post it onward. Handler registration is defined in: | |||
<pre> | |||
/opt/osnexus/quantastor/conf/qs_alerthandlers.conf | |||
</pre> | |||
== Audit Logging == | |||
Every management operation, alert included, is recorded in the audit log. Audit | |||
logging is on by default on all QuantaStor systems and cannot be disabled. | |||
<pre> | |||
/var/log/qs/qs_audit.log | |||
</pre> | |||
The file is NIST compliant CEE JSON, one object per line, so a log aggregator or | |||
SIEM can ingest it without custom parsing. A helper for reading and summarizing | |||
it is installed at: | |||
<pre> | |||
/opt/osnexus/quantastor/bin/qs_audit.py | |||
</pre> | |||
For the wider security picture -- password policy, RBAC, and per-user alert | |||
subscriptions -- see [[Security Configuration]]. | |||
== Managing Alerts from the CLI == | |||
The whole alerting subsystem is scriptable. The most useful commands: | |||
{| class="wikitable" | |||
! Command !! Purpose | |||
|- | |||
| <code>qs alert-list</code> || List current alerts | |||
|- | |||
| <code>qs alert-get</code> || Show one alert, including its SNMP ID | |||
|- | |||
| <code>qs alert-raise</code> || Raise an alert (test, or from a script) | |||
|- | |||
| <code>qs alert-clear</code> || Clear a specific alert | |||
|- | |||
| <code>qs alert-clear-all</code> || Clear all alerts | |||
|- | |||
| <code>qs alert-config-get</code> / <code>alert-config-set</code> || Read and write the Alert Manager configuration, including capacity thresholds | |||
|- | |||
| <code>qs alert-type-list</code> || List all 289 alert types with their SNMP IDs | |||
|- | |||
| <code>qs alert-type-get</code> || Show one alert type, including its status and pause state | |||
|- | |||
| <code>qs alert-emails</code> || Show the configured email recipients | |||
|- | |||
| <code>qs alert-severity</code> || Work with alert severity levels | |||
|- | |||
| <code>qs alert-report</code> || Produce an alert report | |||
|- | |||
| <code>qs alert-trigger</code> || Trigger alert evaluation | |||
|} | |||
Run any command with <code>--verbose</code> to see its full argument list. | |||
== GDPR Compliant Secure Log Send == | |||
Separate from alerting, QuantaStor has a '''Send Support Logs''' feature that | |||
sends system logs to OSNEXUS Support. | |||
'''Navigation:''' Storage Management --> Send Support Logs ''(toolbar)'' | |||
The collection gathers syslog, hardware configuration information, and much of | |||
what is under <code>/var/log/</code>. To ensure no personally-identifiable | |||
information is transmitted, the collection scrubs usernames and other security | |||
related information before sending, for GDPR compliance. QuantaStor log | |||
collection '''never''' collects data files from Storage Pools -- only system log | |||
and configuration files. | |||
See [[Security Configuration#GDPR Compliant Secure Log Send|Security Configuration]] | |||
for more detail. | |||
Revision as of 06:13, 2 September 2026
QuantaStor's Alert Manager is the central place to configure how a Storage
Grid notifies you when its systems need attention -- media replacement, capacity
exhaustion, service failures -- and to set the capacity thresholds that trigger
those notifications.
Alerts are delivered through every configured mechanism, so a system with both email and PagerDuty configured sends each event to both. The available mechanisms are:
- Email via your SMTP server -- see Email Alerts
- IT Service Management (ITSM) webhooks -- 15 supported platforms, see ITSM Integrations
- SNMP -- see SNMP
- Syslog, by appending alerts to the local system log
- A custom alert handler you supply -- see Custom Alert Handlers
Navigation: Storage Management --> select a Storage System --> Alert Manager (toolbar)
Note the Alert Manager toolbar button is inert until a Storage System is selected in the tree.
All alerts are also written to the audit log -- see Audit Logging.
Email Alerts

Navigation: Alert Manager --> Email Alerts (tab)
Email SMTP Server Settings
These settings route alerts through your mail server.
- SMTP Server Address -- the address of an accessible SMTP relay or mail server, for example
mail.example.com. - SMTP Port -- leave as
Autoto use the default port for the selected connection security, or set an explicit port when your relay listens elsewhere. - SMTP Connection Security -- None, STARTTLS, or SSL/TLS. Prefer STARTTLS or SSL/TLS; None sends credentials and alert content unencrypted.
- SMTP User / SMTP Password -- credentials for an account with permission to relay through that server. Leave blank for a relay that accepts unauthenticated mail from the storage network.
Email Sender/Recipient
- Sender Email Address -- the address that appears in the From line. Make it unique and identifiable per storage grid, so an administrator can tell at a glance which system an alert came from.
- Recipient Email Address -- an address or distribution list for the administrators monitoring this grid. This address receives every severity level.
To route different severities to different people, leave the grid-wide recipient for the catch-all mailbox and configure per-user alert subscriptions instead, on the Add User or Modify User dialog. Each user can subscribe to any combination of Critical, Error, Warning, and Info. See Add User and Modify User.
Append Alerts to Syslog
Ticking this uses the logger tool to append every alert to
/var/log/syslog as well, which is useful when a syslog collector
is already aggregating the estate.
ITSM Integrations

IT Service Management (ITSM) modules deliver alerts to a service provider via a webhook URL or service token, so storage alerts land in the same queue as the rest of your infrastructure.
Navigation: Alert Manager --> ITSM Integrations (tab)
To add an integration, choose the Module, paste the Webhook URL (or service token) that the provider issued, and press Add. The grid lists the configured integrations; select a row and press Remove Selected to delete one. Several integrations can be configured at once, and all of them receive every alert.
The ? button beside the Module selector opens the OSNEXUS documentation page for the selected module.
Supported Modules

| Module | Integration notes |
|---|---|
| AlertOps | Inbound Integration |
| Dynatrace | Events V2 Ingest API |
| Freshservice | Webhook API |
| Google Chat | Google Chat channel webhook |
| Mattermost | Mattermost channel webhook |
| Microsoft Teams | Teams channel webhook |
| OpsGenie | Atlassian OpsGenie V2 Alerts API |
| PagerDuty | Events V2 API |
| ServiceNow Lightstep | Generic Webhook API |
| Slack | Slack channel webhook |
| SolarWinds | Solarwinds Service Desk API |
| Splunk On-Call | Webhook API (formerly VictorOps) |
| Squadcast | Webhook API |
| XMatters | Webhook API |
| Zabbix | Monitoring via the Zabbix platform |
The module definitions live on each system at:
/opt/osnexus/quantastor/conf/qs_alerthandlers.conf
Additional modules may be present but disabled by default. A module is enabled
by uncommenting its stanza in that file and restarting the QuantaStor service;
the handler scripts for every module ship regardless, so no reinstall is needed.
Note the configuration reader only treats # at the start of a line
as a comment.
For the full per-provider setup walkthroughs see the Integration Guide.
Capacity Alert Thresholds

Capacity alerts fire when a Storage Pool, a quota-limited Network Share, or a quota-limited Object user crosses one of three thresholds.
Navigation: Alert Manager --> Capacity Alert Thresholds (tab)
All nine values are expressed as "% remaining", not % full. A Pool
Low-space Warning of 30 means the alert fires when the pool has 30%
free space left -- that is, when it is 70% full.
The three severities escalate:
- Warning -- an early notice that free space is getting low.
- Urgent -- a follow-up reminder after the warning level was crossed.
- Critical -- action should be taken immediately.
Thresholds are set independently for three resource types:
| Resource | Warning | Urgent | Critical |
|---|---|---|---|
| Storage Pool low free space | 30% remaining | 10% remaining | 5% remaining |
| Share Quota low space | 20% remaining | 10% remaining | 5% remaining |
| Object Quota low space | 20% remaining | 10% remaining | 5% remaining |
(The values above are the shipped defaults; each has a slider and a numeric field.)
Share and Object quota pressure is usually resolved by raising the quota. Storage Pools need real capacity added, so act early: expand a pool at around 30% remaining to maintain performance. Pool performance can degrade once utilization passes 90% (10% remaining), depending on fragmentation, so the Urgent and Critical thresholds are deliberately late-stage warnings rather than planning tools.
Alert Types

QuantaStor defines 289 alert types. Each has a numeric SNMP ID, a Title, a Status, and a Pause Duration.
Navigation: Alert Manager --> Alert Types (tab)
This tab is how you silence a persistent alert while maintenance is in progress, without disabling alerting as a whole. Set a type's Status to one of:
- Enabled -- the default.
- Disabled -- the alert type never fires. It stays off until you re-enable it.
- Pause (1 day), Pause (1 week), Pause (1 month), Pause (1 quarter) -- the alert type is silenced for that period and then resumes automatically when the pause window ends.
Prefer a Pause over Disabled for maintenance work: a paused type comes back on its own, whereas a disabled one stays off until somebody remembers it.
With 289 types the list is long, so use the filter: click the Title column header, tick Filters, and type the text to match.
The SNMP ID is the identifier the alert carries when delivered by SNMP trap. An individual alert's SNMP ID is also visible in its properties, by selecting the alert in the Alerts tab at the bottom of the interface.
SNMP

Alerts can be delivered as SNMP traps.
Navigation: Alert Manager --> SNMP (tab)
Tick Enable SNMP Agent, then supply the Username and Password under SNMP Credential Settings to require authenticated access.
Full agent configuration, including trap destinations and the MIB, is covered under SNMP Agent Setup.
Generating Test Alerts

The Generate Test Alert button is available from every tab of the Alert Manager. It raises a real alert through every configured mechanism, which is the quickest way to confirm that SMTP settings, ITSM webhooks, and SNMP are actually working.
IMPORTANT: save your settings with OK or Apply before sending a test alert. An unsaved SMTP server address is not used for the test.
The dialog takes a Message and a Severity. Send one at Warning level as a first check, since some ITSM integrations filter informational events by default.
See Send User Generated Alert for details.
Generating Alerts
QuantaStor systems raise alerts at four severity levels: Critical, Error, Warning, and Info. These are the levels users subscribe to individually in their alert subscriptions.
A single physical event commonly produces several alerts. A disk that needs replacing, for example, produces a Warning for the disk itself plus Error level events from the controller, each of which raises its own alert.
To raise an alert deliberately -- for a test, or from a script -- use the CLI:
qs alert-raise --message="Scheduled maintenance window starting" --severity=warning
...or the Generate Test Alert button described above.
Custom Alert Handlers
When none of the built-in mechanisms fit, you can supply your own handler. The per-vendor handlers that ship with QuantaStor are ordinary scripts in:
/opt/osnexus/quantastor/bin/qs_alerthandler_*.py
Any of them works as a worked example of the interface -- they read the alert from QuantaStor and post it onward. Handler registration is defined in:
/opt/osnexus/quantastor/conf/qs_alerthandlers.conf
Audit Logging
Every management operation, alert included, is recorded in the audit log. Audit logging is on by default on all QuantaStor systems and cannot be disabled.
/var/log/qs/qs_audit.log
The file is NIST compliant CEE JSON, one object per line, so a log aggregator or SIEM can ingest it without custom parsing. A helper for reading and summarizing it is installed at:
/opt/osnexus/quantastor/bin/qs_audit.py
For the wider security picture -- password policy, RBAC, and per-user alert subscriptions -- see Security Configuration.
Managing Alerts from the CLI
The whole alerting subsystem is scriptable. The most useful commands:
| Command | Purpose |
|---|---|
qs alert-list |
List current alerts |
qs alert-get |
Show one alert, including its SNMP ID |
qs alert-raise |
Raise an alert (test, or from a script) |
qs alert-clear |
Clear a specific alert |
qs alert-clear-all |
Clear all alerts |
qs alert-config-get / alert-config-set |
Read and write the Alert Manager configuration, including capacity thresholds |
qs alert-type-list |
List all 289 alert types with their SNMP IDs |
qs alert-type-get |
Show one alert type, including its status and pause state |
qs alert-emails |
Show the configured email recipients |
qs alert-severity |
Work with alert severity levels |
qs alert-report |
Produce an alert report |
qs alert-trigger |
Trigger alert evaluation |
Run any command with --verbose to see its full argument list.
GDPR Compliant Secure Log Send
Separate from alerting, QuantaStor has a Send Support Logs feature that sends system logs to OSNEXUS Support.
Navigation: Storage Management --> Send Support Logs (toolbar)
The collection gathers syslog, hardware configuration information, and much of
what is under /var/log/. To ensure no personally-identifiable
information is transmitted, the collection scrubs usernames and other security
related information before sending, for GDPR compliance. QuantaStor log
collection never collects data files from Storage Pools -- only system log
and configuration files.
See Security Configuration for more detail.