Service status

Remember that the most up-to-date information regarding the status of the TraceView service is at status.tv.solarwinds.com. Subscribe for alerts to service interruptions and incident reports.

Supported browsers

TraceView supports Chrome 35+, Safari 6.0+, and Firefox 24+. Internet Explorer is not supported.

End of support

Customers receive support for the duration of their contract. TraceView delivers new software on a continuous basis, and appliances have an auto-update setting, which is toggled on by default. If you experience an issue, and are not running the latest version, our support team will first ask you to upgrade, and then proceed with investigation from there. The net effect is that as a SaaS company, we offer full support for the latest version of our software, rather than specific historic versions.

Data retention and roll-up

Appliances
  • Appliances that have been in a connection lost state for 365 days and do not have an active base license will be purged.
TraceView
  • All data is fully retained for 45 to 90 days depending on your plan type. Certain aggregate statistics are retained for up to 180 days. Saved traces will be retained until they are explicitly deleted by a user.

TraceView security

This section provides information about what information is collected by and transmitted to TraceView in the course of monitoring web app performance.

Layer instrumentation

TraceView provides instrumentation modules to provide insight at various levels of the stack. Each of these modules collects information about web requests that traverse the various levels. All of our instrumentation collects timing data, hostname, and process/thread id.

Webserver instrumentation

At the webserver level, TraceView may collect the following information: http request details (http status and method), requested domain and url, including query string, client ip address, and request size (bytes in and bytes out). This specifically excludes POST bodies and cookies.

Language instrumentation

All application languages dynamically change a number of functions within the application server’s runtime in order to capture performance information. All of these modifications are simple wrappers; no results or parameters are altered, with the exception of reading or injecting our tracking string (e.g., adding an x-trace header when making external http calls). We gather the following information: location of outbound service calls (e.g., http urls, thrift rpc endpoints, etc.), success of cache operations, memory usage, stack traces, error and exceptions, and database queries; instrumentation can be configured to suppress reporting of query literals. This specifically excludes: arbitrary function arguments and return values, global application environment, sensitive configuration or connection information.

We always build our instrumented packages using the latest version officially available for supported distros, with all security updates applied. When a new security update is released by your distribution, if our build system has not yet produced a new package for the updated version, then your package manager chooses the newest version number, rather than our instrumented version. This means you are just as safe against security vulnerabilities as before you enabled our instrumentation. Security updates always trump the TraceView-instrumented version. You can begin using the instrumented version again once new packages have been published to our repositories.

We always build our instrumented packages using the latest version officially available for supported distros, with all security updates applied. When a new security update is released by your distribution, if our build system has not yet produced a new package for the updated version, then your package manager chooses the newest version number, rather than our instrumented version. This means you are just as safe against security vulnerabilities as before you enabled our instrumentation. Security updates always trump the TraceView-instrumented version. You can begin using the instrumented version again once new packages have been published to our repositories.

We always build our instrumented packages using the latest version of the original source package with all security updates applied. When a new security update is released by your distribution, if our build system has not yet produced a new package for the updated version, then apt-get/aptitude will choose the newest version number, rather than our instrumented version. This means you are just as safe against security vulnerabilities as before you enabled our instrumented libcurl: security updates always trump TraceView-instrumented versions. Our build system will rebuild packages as new updates are released, and publish them to our repositories when available. At that point you may begin using TraceView-instrumented versions again.

Tracelyzer daemon

Installation of TraceView also includes a lightweight agent, the Tracelyzer daemon. Tracelyzer is started as root, and immediately drops privileges to run as an unprivileged user. It collects information from instrumentation modules via a configurable udp port. No analysis or inspection is done by this agent. Tracelyzer ferries data to our collection service. All data is encrypted and compressed during transport using ssh, and connections are authenticated using our collection service’s ssh public key and a customer-specific private key. We use ssh to forward a local port over a secure tunnel to our service’s collection port. No information is sent back to the client machines over this port. The daemon will occasionally update its settings over the same secure tunnel. These settings are communicated via a shared memory page that is mapped read-only by instrumentation modules. This allows new settings to be read without requiring blocking communication with the daemon. We use ssh keys to authenticate our customers’ connections to us—kind of like an API key or ssl client certificates—and generate a unique ssh key for each customer. We do not change these ssh keys unless a customer requests them to be changed. Possession of an ssh key only allows someone to send us trace data, not read the data or access the app. The keys cannot be used to tunnel back to customer servers and pose no risk to the security of a customer’s hosts or data.

Data storage

TraceView is hosted on Amazon Web Services. We use industry accepted, best practices to secure this installation, including Amazon security groups, firewalled ports, ssh-key based machine logins, and key rotation. Data access is restricted solely to TraceView employees, all of whom are under strict confidentiality agreements. Only key engineers may access production data, and then only for the purpose of debugging data-related issues as a last resort. In addition, support engineers may access your web console to provide guidance as a result of specific incidents or requests. The raw trace data is stored and backed up in Amazon S3 and encrypted at rest using Amazon S3 server-side encryption. Other metadata derived from trace data is also backed up hourly to S3 and is encrypted at rest. The authentication and user database is stored in Amazon RDS, which provides backups. These are not encrypted at rest. Passwords are salted and hashed using glibc crypt() method number 6 (SHA-512). Credit card data, including card numbers and billing address, is not stored by TraceView and is touched only by our payment providers.

Access to TraceView

Access to TraceView is protected by a username/password pair, which is salted and hashed before storage using standard industry password security algorithms. All console data is available only over https/ssl. Billing information is available only to a subset of users with administrative privileges.

License information