LogoLogo
StackState.comDownloadSupportExplore playground
StackState v5.1
StackState v5.1
  • Welcome to the StackState docs!
  • StackState self-hosted v5.1 docs
  • Getting Started
  • 🚀Setup
    • Install StackState
      • Requirements
      • Kubernetes / OpenShift
        • Kubernetes install
        • OpenShift install
        • Required Permissions
        • Non-high availability setup
        • Override default configuration
        • Configure storage
        • Configure Ingress
        • Install from custom image registry
        • Migrate from Linux install
      • Linux
        • Before you install
        • Download
        • Install StackState
        • Install with production configuration
        • Install with development configuration
        • Install with POC configuration
        • Set up a reverse proxy
        • Set up TLS without reverse proxy
      • Initial run guide
      • Troubleshooting
    • Upgrade StackState
      • Steps to upgrade
      • Version specific upgrade instructions
      • StackPack versions
      • StackState release notes
    • StackState Agent
      • About StackState Agent V3
      • Docker
      • Kubernetes / OpenShift
      • Linux
      • Windows
      • Advanced Agent configuration
      • Use an HTTP/HTTPS proxy
      • Agent V1 (legacy)
      • Migrate Agent V1 to Agent V2
        • Linux
        • Docker
    • StackState CLI
      • CLI: sts
      • CLI: stac (deprecated)
      • Comparison between CLIs
    • Data management
      • Backup and Restore
        • Kubernetes backup
        • Linux backup
        • Configuration backup
      • Data retention
      • Clear stored data
  • 👤Use
    • Concepts
      • The 4T data model
      • Components
      • Relations
      • Health state
      • Layers, Domains and Environments
      • Perspectives
      • Anomaly detection
      • StackState architecture
    • StackState UI
      • Explore mode
      • Filters
      • Views
        • About views
        • Configure the view health
        • Create and edit views
        • Visualization settings
      • Perspectives
        • Topology Perspective
        • Events Perspective
        • Traces Perspective
        • Metrics Perspective
      • Timeline and time travel
      • Analytics
      • Keyboard shortcuts
    • Checks and monitors
      • Checks
      • Add a health check
      • Anomaly health checks
      • Monitors
      • Manage monitors
    • Problem analysis
      • About problems
      • Problem lifecycle
      • Investigate a problem
      • Problem notifications
    • Metrics
      • Telemetry streams
      • Golden signals
      • Top metrics
      • Add a telemetry stream
      • Browse telemetry
      • Set telemetry stream priority
    • Events
      • About events
      • Event notifications
      • Manage event handlers
    • Glossary
  • 🧩StackPacks
    • About StackPacks
    • Add-ons
      • Autonomous Anomaly Detector
      • Health Forecast
    • Integrations
      • About integrations
      • 💠StackState Agent V2
      • 💠AWS
        • AWS
        • AWS ECS
        • AWS X-ray
        • StackState/Agent IAM role: EC2
        • StackState/Agent IAM role: EKS
        • Policies for AWS
        • AWS (legacy)
        • Migrate AWS (legacy) to AWS
      • 💠Dynatrace
      • 💠Kubernetes
      • 💠OpenShift
      • 💠OpenTelemetry
        • About instrumentations
        • AWS NodeJS Instrumentation
        • Manual Instrumentation
          • Prerequisites
          • Tracer and span mappings
          • Relations between components
          • Span health state
          • Merging components
          • Code examples
      • 💠ServiceNow
      • 💠Slack
      • 💠Splunk
        • Splunk
        • Splunk Events
        • Splunk Health
        • Splunk Metrics
        • Splunk Topology
      • 💠VMWare vSphere
      • Apache Tomcat
      • Azure
      • Cloudera
      • Custom Synchronization
      • DotNet APM
      • Elasticsearch
      • Humio
      • Java APM
      • JMX
      • Logz.io
      • MySQL
      • Nagios
      • OpenMetrics
      • PostgreSQL
      • Prometheus
      • SAP
      • SCOM
      • SolarWinds
      • Static Health
      • Static Topology
      • Traefik
      • WMI
      • Zabbix
    • Develop your own StackPacks
  • 🔧Configure
    • Topology
      • Component actions
      • Identifiers
      • Topology naming guide
      • Topology sources
      • Create a topology manually
      • Configure topology synchronizations
      • Enable email event notifications
      • Send topology data over HTTP
      • Set the topology filtering limit
      • Use a proxy for event handlers
      • Use tags
      • Tune topology synchronization
      • Debug topology synchronization
    • Telemetry
      • Add telemetry during topology synchronization
      • Data sources
        • Elasticsearch
        • Prometheus mirror
      • Send events over HTTP
      • Send metrics data over HTTP
      • Set the default telemetry interval
      • Debug telemetry synchronization
    • Traces
      • Set up traces
      • Advanced configuration for traces
    • Health
      • Health synchronization
      • Send health data over HTTP
        • Send health data
        • Repeat Snapshots JSON
        • Repeat States JSON
        • Transactional Increments JSON
      • Debug health synchronization
    • Anomaly Detection
      • Export anomaly feedback
      • Scale the AAD up and down
      • The AAD status UI
    • Security
      • Authentication
        • Authentication options
        • File based
        • LDAP
        • Open ID Connect (OIDC)
        • KeyCloak
        • Service tokens
      • RBAC
        • Role-based Access Control
        • Permissions
        • Roles
        • Scopes
        • Subjects
      • Secrets management
      • Self-signed certificates
      • Set up a security backend for Linux
      • Set up a security backend for Windows
    • Logging
      • Kubernetes logs
      • Linux logs
      • Enable logging for functions
  • 📖Develop
    • Developer guides
      • Agent checks
        • About Agent checks
        • Agent check API
        • Agent check state
        • How to develop Agent checks
        • Connect an Agent check to StackState
      • Custom functions and scripts
        • StackState functions
        • Check functions
        • Component actions
        • Event handler functions
        • ID extractor functions
        • Mapping functions
        • Monitor functions
        • Propagation functions
        • Template functions
        • View health state configuration functions
      • Custom Synchronization StackPack
        • About the Custom Synchronization StackPack
        • How to customize elements created by the Custom Synchronization StackPack
        • How to configure a custom synchronization
      • Integrate external services
      • Mirroring Telemetry
      • Monitors
        • Create monitors
        • Monitor STJ file format
      • StackPack development
        • How to create a StackPack
        • Packaging
        • How to get a template file
        • How to make a multi-instance StackPack
        • Prepare a multi-instance provisioning script
        • Upload a StackPack file
        • Prepare a shared template
        • Customize a StackPack
        • Prepare instance template files
        • Prepare a StackPack provisioning script
        • Resources in a StackPack
        • StackState Common Layer
      • Synchronizations and templated files
    • Reference
      • StackState OpenAPI docs
      • StackState Template JSON (STJ)
        • Using STJ
        • Template functions
      • StackState Markup Language (STML)
        • Using STML
        • STML Tags
      • StackState Query Language (STQL)
      • StackState Scripting Language (STSL)
        • Scripting in StackState
        • Script result: Async
        • Script result: Streaming
        • Time in scripts
        • Script APIs
          • Async - script API
          • Component - script API
          • HTTP - script API
          • Prediction - script API
          • StackPack - script API
          • Telemetry - script API
          • Time - script API
          • Topology - script API
          • UI - script API
          • View - script API
    • Tutorials
      • Create a simple StackPack
      • Push data to StackState from an external system
      • Send events to StackState from an external system
      • Set up a mirror to pull telemetry data from an external system
Powered by GitBook
LogoLogo

Legal notices

  • Privacy
  • Cookies
  • Responsible disclosure
  • SOC 2/SOC 3
On this page
  • Overview
  • Upgrade instructions
  • Upgrade to v5.1.x
  • Upgrade to v5.0.x
  • Upgrade to v4.6.x
  • Unsupported versions
  • Upgrade to v4.5.x (EOL)
  • Upgrade to v4.4.x (EOL)
  • Upgrade to v4.3.x (EOL)
  • Upgrade to v4.2.x (EOL)
  • See also
  1. Setup
  2. Upgrade StackState

Version specific upgrade instructions

StackState Self-hosted v5.1.x

PreviousSteps to upgradeNextStackPack versions

Last updated 1 year ago

Overview

Review the instructions provided on this page before you upgrade!

This page provides specific instructions and details of any required manual steps to upgrade to each supported version of StackState. Any significant change that may impact how StackState runs after upgrade will be described here, such as a change in memory requirements or configuration.

Read all instructions from the version that you are currently running up to the version that you will upgrade to.

Upgrade instructions

Upgrade to v5.1.x

v5.1.6

The Zookeeper dependency of StackState has been upgraded. Before running helm upgrade the Zookeeper Statefulset has to be deleted.

kubectl delete statefulset -l app.kubernetes.io/component=zookeeper -n stackstate --cascade=orphan

Note: the command deletes Statefulset only, pods and pvc-s aren't affected. The helm upgrade command creates a new Statefulset for Zookeeper and rolls out the Zookeeper pods.

v5.1.0

  • The node sizing requirements for deploying the StackState platform have changed slightly. Check the .

  • A new stackstate/stackstate-agent helm chart is available to deploy the StackState Agent, Checks Agent, Node Agent and kube_state_metrics on Kubernetes and OpenShift clusters. Some values have been renamed in the new chart.

    • The old stackstate/cluster-agent chart is being deprecated and will no longer be supported.

    • If you were using the old stackstate/cluster-agent helm chart, you should before deploying with the new chart.

  • All Splunk checks can now run on Agent V3. If you have any Splunk checks running on Agent V1 (legacy) (Splunk Metrics, Splunk Events or Splunk Topology V1), you should .Agent V1 (legacy) and will be deprecated in a future release of StackState.

v5.1.0

  • The required version of JDK has been updated - StackState now requires OpenJDK 11. This must be the only version of JDK present on the installation machine before upgrading StackState. If a mismatching JDK version is installed, or there are multiple versions installed, StackState will fail to start.

  • All Splunk checks can now run on Agent V2 and V3. If you have any Splunk checks running on Agent V1 (legacy) (Splunk Metrics, Splunk Events or Splunk Topology V1), you should . Agent V1 (legacy) and will be deprecated in a future release of StackState.

Upgrade to v5.0.x

v5.0.2-v5.0.6

No manual action required.

v5.0.1

⚠️ Don't use. Please upgrade to StackState v5.0.2.

v5.0.0

  • With the release of the new sts CLI, the CLI released with previous versions of StackState has been renamed to stac:

  • StackPack updates:

v5.0.2-v5.0.6

No manual action required.

v5.0.1

⚠️ Don't use. Please upgrade to StackState v5.0.2.

v5.0.0

  • With the release of the new sts CLI, the CLI released with previous versions of StackState has been renamed to stac:

  • StackPack updates:

Upgrade to v4.6.x

v4.6.1

No manual action required.

v4.6.0

  • Change in supported platforms:

    • Support for Kubernetes 1.18 was dropped.

    • Support for OpenShift 4.7 was dropped.

  • StackPack updates:

      • Feature: Automatically add Open Telemetry HTTP health checks

        • Error count (sum) check

        • Request count (sum) check

        • Response Time (milliseconds) check

      • Improvement: Add OpenTelemetry information STAC-15902

      • Improvement: Documentation for agent.containerRuntime.customSocketPath option.

      • Improvement: Documentation for agent.containerRuntime.customSocketPath option.

v4.6.1

No manual action required.

v4.6.0

No manual action required.

StackPack updates:

    • Feature: Automatically add Open Telemetry HTTP health checks

      • Error count (sum) check

      • Request count (sum) check

      • Response Time (milliseconds) check

    • Improvement: Add OpenTelemetry information STAC-15902

    • Improvement: Documentation for agent.containerRuntime.customSocketPath option.

    • Improvement: Documentation for agent.containerRuntime.customSocketPath option.

Unsupported versions

The versions below have reached End of Life (EOL) and are no longer be supported.

Upgrade to v4.5.x (EOL)

v4.5.2 - v4.5.5

No manual action required.

v4.5.1

v4.5.0

  • ⚠️ This release is susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.5.1.

  • ⚠️ StackState v4.5.0 isn't compatible with StackState Agent v2.15.0.

  • Change in supported platforms:

    • Support for Kubernetes 1.17 was dropped.

    • Support for Amazon Elastic Kubernetes Service (EKS) 1.20 and 1.21 was added.

    • Support for Azure Kubernetes Service (AKS) 1.20 and 1.21 was added.

    • Support for OpenShift 4.4, 4.5 and 4.6 was dropped.

    • Support for OpenShift 4.7 and 4.8 was added.

v4.5.3

No manual action required.

v4.5.2

No manual action required.

v4.5.1

v4.5.0

  • ⚠️ This release is susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.5.1.

  • ⚠️ StackState v4.5.0 isn't compatible with StackState Agent v2.15.0.

Upgrade to v4.4.x (EOL)

v4.4.3

No manual action required.

v4.4.1 - v4.4.2

  • ⚠️ These releases are susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.4.3.

v4.4.0

  • ⚠️ This release is susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.4.3.

    • The requirements for the recommended highly available setup have grown (from 5) to 6 nodes with 32 GB of memory and 8 vCPUS.

    • The requirements for a minimal highly available setup have grown (from 4) to 5 nodes with 32 GB of memory and 8 vCPUS.

  • Baselines have been disabled in v4.4. The BaselineFunction and Baseline objects are still available, but they don't serve any purpose other than smooth transition to the Autonomous Anomaly Detector (AAD) framework. If you have custom StackPacks that auto-create baselines, this is the last opportunity to remove baselines from templates and make transition to the AAD. In release v4.5 baselines will be removed completely and templates using them will break.

  • Transparent propagation has been renamed to Auto propagation. The behavior remains the same.

  • The ElasticSearch Helm subchart elasticsearch-exporter has been renamed to prometheus-elasticsearch-exporter. This means that any configuration for that subchart needs to use the new subchart key elasticsearch.prometheus-elasticsearch-exporter.*

  • Security improvement for Authentication and Authorization. There is a single configuration for groups to roles mappings and a single authentication provider used for both the Base API and Admin API. The default StackState roles are now always available, these could previously be overridden - stackstate-admin, stackstate-power-user, stackstate-guest. Additionally, a new default role stackstate-platform-admin has been introduced.

    stackstate {
      authorization {
        adminGroups = ${stackstate.authorization.adminGroups} ["custom-admin-role-from-ldap-or-oidc-or-keycloak"]
        platformAdminGroups = ${stackstate.authorization.platformAdminGroups} ["custom-platform-admin-role-from-ldap-or-oidc-or-keycloak"]
        powerUserGroups = ${stackstate.authorization.powerUserGroups} ["custom-power-user-role-from-ldap-or-oidc-or-keycloak"]
        guestGroups = ${stackstate.authorization.guestGroups} ["custom-guest-role-from-ldap-or-oidc-or-keycloak"]
      }
    }

    Platform management and platform content management permissions have been separated into two groups - platformAdminGroup and adminGroup. Users in the group platformAdminGroup are limited to only platform management tasks, such as change database retention, clear database, clear caches and view logs. Users in the group adminGroup no longer have platform management permissions.

    How you should proceed with upgrade

    • File based authentication: Use the platformadmin username for platform management instead of admin. The admin user remains functional and has full content management rights as before.

    • External authentication (LDAP/OIDC/Keycloak): An additional role/group should be created in the external authentication system and mapped to the new StackState platformAdmin group.

      stackstate:
        authentication:
          roles:
            ...
            platformAdmin: ["new-external-platform-admin-role"]
            ...

      Users who are assigned this group/role will get platform management permissions. If you wish for one user to manage both the content and the platform, you will still need to configure the external authentication provider with two separate roles/groups and then assign both of those to a single user in the settings of the external authentication system. You should not map the same external role/group to different StackState authorization groups.

v4.4.3

No manual action required.

v4.4.1 - v4.4.2

  • ⚠️ These releases are susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.4.3.

v4.4.0

  • ⚠️ This release is susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.4.3.

  • Baselines have been disabled in v4.4. The BaselineFunction and Baseline objects are still available, but they don't serve any purpose other than smooth transition to the Autonomous Anomaly Detector (AAD) framework. If you have custom StackPacks that auto-create baselines, this is the last opportunity to remove baselines from templates and make transition to the AAD. In release v4.5 baselines will be removed completely and templates using them will break.

  • Transparent propagation has been renamed to Auto propagation. The behavior remains the same.

  • Security improvement for Authentication and Authorization. There is a single configuration for groups to roles mappings and a single authentication provider used for both the Base API and Admin API. The default StackState roles are now always available, these could previously be overridden - stackstate-admin, stackstate-power-user, stackstate-guest. Additionally, a new default role stackstate-platform-admin has been introduced.

    stackstate {
      authorization {
        adminGroups = ${stackstate.authorization.adminGroups} ["custom-admin-role-from-ldap-or-oidc-or-keycloak"]
        platformAdminGroups = ${stackstate.authorization.platformAdminGroups} ["custom-platform-admin-role-from-ldap-or-oidc-or-keycloak"]
        powerUserGroups = ${stackstate.authorization.powerUserGroups} ["custom-power-user-role-from-ldap-or-oidc-or-keycloak"]
        guestGroups = ${stackstate.authorization.guestGroups} ["custom-guest-role-from-ldap-or-oidc-or-keycloak"]
      }
    }

    Platform management and platform content management permissions have been separated into two groups - platformAdminGroup and adminGroup. Users in the group platformAdminGroup are limited to only platform management tasks, such as change database retention, clear database, clear caches and view logs. Users in the group adminGroup no longer have platform management permissions.

    How you should proceed with upgrade?

    This impacts you if you have a customized authentication section in the file application_stackstate.conf. If your authentication section has adminGroups, powerUserGroups, guestGroups definitions like in the example below:

    stackstate {
      api {
        authentication {
          ...
          adminGroups = ["your-custom-oidc-or-ldap-or-keycloak-admin-role"]
          powerUserGroups = ["your-custom-oidc-or-ldap-or-keycloak-power-user-role"]
          guestGroups = ["your-custom-oidc-or-ldap-or-keycloak-guest-role"]
          ...
        }
      }
    }

    The subject-role mappings must be moved to a centralized authorization configuration using the syntax xxxGroups = ${stackstate.authorization.xxxGroups} ["custom-role"] as shown in the example below.

    stackstate {
      authorization {
        adminGroups = ${stackstate.authorization.adminGroups} ["your-custom-oidc-or-ldap-or-keycloak-admin-role"]
        platformAdminGroups = ${stackstate.authorization.platformAdminGroups} ["your-custom-oidc-or-ldap-or-keycloak-platform-admin-role"]
        powerUserGroups = ${stackstate.authorization.powerUserGroups} ["your-custom-oidc-or-ldap-or-keycloak-power-user-role"]
        guestGroups = ${stackstate.authorization.guestGroups} ["your-custom-oidc-or-ldap-or-keycloak-guest-role"]
      }
      api {
        authentication {
          ...
          // no subject-role mappings here
          ...
        }
      }
    }

    The list of roles will be extended to include the new, custom roles. The default roles will remain available (stackstate-admin, stackstate-platform-admin, stackstate-guest and stackstate-power-user).

    Provider Specific Instructions

    • File based authentication: Use the platformadmin username for platform management instead of admin. The admin user remains functional and has full content management rights as before.

    • External authentication (LDAP/OIDC/Keycloak): An additional role/group should be created in the external authentication system and mapped to the new StackState platformAdmin group.

      stackstate {
        authorization {
          ...
          platformAdminGroups = ${stackstate.authorization.platformAdminGroups} ["your-custom-oidc-or-ldap-or-keycloak-platform-admin-role"]
          ...
        }
        ...
      }

      Users who are assigned this group/role will get platform management permissions. If you wish for one user to manage both the content and the platform, you will still need to configure the external auth provider with two separate roles/groups and then assign both of those to a single user in the settings of the external auth provider. You should not map the same external role/group to different StackState authorization groups.

Upgrade to v4.3.x (EOL)

v4.3.6

No manual action required.

v4.3.1 - v4.3.5

  • ⚠️ These releases are susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.3.6.

v4.3.0

  • ⚠️ This release is susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.3.6.

  • StackState is tested to run on Kubernetes v1.17, v1.18 and v1.19, or the equivalent OpenShift release (version 4.4, 4.5 or 4.6).

  • CPU limits have been added to all pods. If you have customized any of the CPU requests in your values.yaml, you will most likely need to also set the CPU limit for the same pod(s).

    • Guest users will no longer be able to create or edit event handlers.

    • Power Users will no longer be able to execute scripts using the HTTP script API.

    • Admin users won't be affected.

  • Dynatrace StackPack - The location of the Dynatrace check config file has moved. If you choose to upgrade to the version of the Dynatrace StackPack shipped with StackState v4.3, the Agent check configuration file should also be moved. The new location is /etc/sts-agent/conf.d/dynatrace.d/conf.yaml the previous location was /etc/sts-agent/conf.d/dynatrace_topology.d/conf.yaml.

v4.3.6

No manual action required.

v4.3.1 - v4.3.5

  • ⚠️ These releases are susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.3.6.

v4.3.0

  • ⚠️ This release is susceptible to the Apache log4j2 vulnerabilities CVE-2021-44228 and CVE-2021-45046. Resolved in version v4.3.6.

    • Guest users will no longer be able to create or edit event handlers.

    • Power Users will no longer be able to execute scripts using the HTTP script API.

    • Admin users won't be affected.

  • Dynatrace StackPack - The location of the Dynatrace check config file has moved. If you choose to upgrade to the version of the Dynatrace StackPack shipped with StackState v4.3, the Agent check configuration file should also be moved. The new location is /etc/sts-agent/conf.d/dynatrace.d/conf.yaml the previous location was /etc/sts-agent/conf.d/dynatrace_topology.d/conf.yaml.

Upgrade to v4.2.x (EOL)

v4.2.4

No manual action required.

v4.2.3

Authentication configuration for the Kubernetes Helm chart has been made easier for this release. If your StackState authentication was customized, it will need to be updated. To verify this, check if there is a stackstate.server.config or stackstate.api.config value that contains an authentication section in the values.yaml file(s) used for installation.

v4.2.0

  • The old stackstate-server pod has been replaced by a number of separate pods. Custom configuration in values.yaml should be updated:

    • Configured email details in stackstate.components.server.config should be moved to stackstate.components.viewHealth.config.

    • Other custom configuration in stackstate.components.server.config should be moved to stackstate.components.api.config.

v4.2.4

No manual action required.

v4.2.3

No manual action required.

v4.2.0

The following configuration must be manually added after upgrade:

  • etc/application_stackstate.conf

The following configuration changes must be manually processed if you are using a customized version of a file:

  • etc/stackstate-receiver/application.conf

    • Renamed the namespace stackstate. This is now stackstate.receiver.

    • Renamed the parameter apiKey. This is now named apiKeys and should be a list in the format [${stackstate.receiver.key}, ${?EXTRA_API_KEY}].

  • processmanager.conf

    • Added new parameter processes.kafkaToElasticsearch.topology-events.

  • processmanager/kafka-topics.conf`

    • Added new section kafka.topics.sts_topology_events.

See also

If you install the new sts CLI, you should .

The commands for the new sts CLI have changed. Check that any automation is using the correct CLI command (sts or stac).

Version 5.0.0 of StackState includes a breaking change to the output of the . The output uses the new and the data format changed. Any script making use of that API needs to be adapted to deal with the new output format.

The versions of Kubernetes and OpenShift that are supported to run StackState have been updated - AKS and EKS 1.19 are no longer supported. Refer to the requirements documentation for details of all supported platforms: .

If you install the new sts CLI, you should .

The commands for the new sts CLI have changed. Check that any automation is using the correct CLI command (sts or stac).

This version of StackState includes a breaking change to the output of the . The output uses the new and the data format changed. Any script making use of that API needs to be adapted to deal with the new output format.

See the for an up-to-date list of supported platforms.

:

Feature: Add Container integration DataSource and Sync Note that the previous release of StackState (v4.5.x) shipped with StackState Agent StackPack v4.4.12. .

:

:

:

:

Feature: Add Container integration DataSource and Sync Note that the previous release of StackState (v4.5.x) shipped with StackState Agent StackPack v4.4.12. .

:

:

:

Adds compatibility with StackState Agent v2.15.0. Read how to .

See the for an up-to-date list of supported platforms.

Adds compatibility with StackState Agent v2.15.0. Read how to .

The CPU and memory have been reassessed:

A has been added, the requirements for which are 3 nodes with 32 GB of memory and 8 vCPUS.

The passwordMd5 field in the has been renamed to passwordHash as it's now possible to use bcrypt type passwords.

If you are still not sure what you need to do, contact .

If you are still not sure what you need to do, contact .

CPU limits and requests have been re-evaluated and increased where needed for stable operation resulting in a change in the number and size of .

Two new have been added - manage-event-handlers and execute-restricted-scripts:

Baselines have been deprecated and will be removed in v4.4. To reflect this, baseline functions and check functions that use baselines have been renamed. Templates that resolve these functions by name will stop working after upgrade to StackState 4.3. The function identifiers haven't changed and can still be used to reference functions, however, it's advised that you migrate to using the .

A Slack integration StackPack is now available that includes a new Slack event handler. Existing Slack event handlers will continue to run in StackState v4.3, however, the old Slack event handler has been deprecated and will be removed in a future release of StackState. To continue using Slack event notifications, it's advised to install the Slack StackPack and to use the new Slack event handler in place of the old Notify via slack for component health state change. (deprecated) and Notify via slack for view health state change.(deprecated).

Two new have been added - manage-event-handlers and execute-restricted-scripts:

Baselines have been deprecated and will be removed in v4.4. To reflect this, baseline functions and check functions that use baselines have been renamed. Templates that resolve these functions by name will stop working after upgrade to StackState 4.3. The function identifiers haven't changed and can still be used to reference functions, however, it's advised that you migrate to using the .

A Slack integration StackPack is now available that includes a new Slack event handler. Existing Slack event handlers will continue to run in StackState v4.3, however, the old Slack event handler has been deprecated and will be removed in a future release of StackState. To continue using Slack event notifications, it's advised to install the Slack StackPack and to use the new Slack event handler in place of the old Notify via slack for component health state change. (deprecated) and Notify via slack for view health state change.(deprecated).

Refer to the to configure the same settings directly in the values.yaml file. After that, the authentication section can be completely removed. If this results in an empty config value it can be removed as well.

have been increased.

A new mandatory parameter stackstate.baseUrl has been added. This is the public URL of StackState (how StackState is reachable from external machines) and is exposed via the . The file values.yaml should be updated to include the new stackstate.baseUrl parameter. The old stackstate.receiver.baseUrl parameter has been deprecated and will be removed in a future release, however, when no stackstate.baseUrl is provided in StackState v4.2, the configured stackstate.receiver.baseUrl will be used instead.

New mandatory parameter stackstate.web.baseUrl. This is the public URL of StackState (how StackState is reachable from external machines) and is exposed via the . You can manually create a system environment variable called STACKSTATE_BASE_URL or add the value manually as a string in the file application_stackstate.conf.

🚀
Telemetry Script API
StreamingScriptApi
Telemetry Script API
StreamingScriptApi
requirements
StackState Agent (v4.5.0)
AWS (v1.2.0)
Kubernetes (v3.9.9)
OpenShift (v3.7.10)
StackState Agent (v4.5.0)
AWS (v1.2.0)
Kubernetes (v3.9.9)
OpenShift (v3.7.10)
requirements
non-high availability setup
file based authentication
StackState support
StackState support
permissions
Autonomous Anomaly Detector
configure view event handlers
permissions
Autonomous Anomaly Detector
configure view event handlers
Authentication configuration documentation
Steps to upgrade StackState
StackPack versions shipped with each StackState release
upgrade to Agent V2 or V3 and migrate any checks configured to run on Agent V1 (legacy)
upgrade to Agent V2 or V3 and migrate any checks configured to run on Agent V1 (legacy)
Which version of the sts CLI am I running?
Which version of the sts CLI am I running?
requirements > supported versions
requirements to run StackState 4.4 on Kubernetes
required nodes
Node sizing requirements
requirements to deploy StackState on Kubernetes or OpenShift
AWS v1.2.1
AWS v1.2.1
Kubernetes v3.9.12
Kubernetes v3.9.12
OpenShift v3.7.12
OpenShift v3.7.12
How to upgrade a StackPack
StackState Agent StackPack v4.5.2
StackState Agent StackPack v4.5.2
Read release notes for all versions
Read release notes for all versions
UI script API
UI script API
upgrade StackState Agent
upgrade StackState Agent
review and update your values.yaml file
Dynatrace v1.4.2
Dynatrace v1.4.2
upgrade the old sts CLI to stac
upgrade the old sts CLI to stac
VMware vSphere v2.3.3
VMware vSphere v2.3.3
ServiceNow v5.3.3
ServiceNow v5.3.3