From 178d0e0de51abaed4c4ea24a6544d543417f9be0 Mon Sep 17 00:00:00 2001 From: Marcel Weinberg Date: Fri, 14 Aug 2020 22:19:58 +0200 Subject: [PATCH 1/7] Fix headlines on the metrics page to hide them from the navigation menu on the left --- docs/source/reference/metrics.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/source/reference/metrics.rst b/docs/source/reference/metrics.rst index e353bbd2b..d2fbafd30 100644 --- a/docs/source/reference/metrics.rst +++ b/docs/source/reference/metrics.rst @@ -7,7 +7,7 @@ or deployment related issues (e.g. long average duration for a particular action an issue with that action or similar). Configuring and Enabling Metrics Collection -=========================================== +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. note:: @@ -48,7 +48,7 @@ For a full list of config options, see the ``[metrics]`` section in the |st2| sa config here: https://github.com/StackStorm/st2/blob/master/conf/st2.conf.sample Configuring StatsD -================== +~~~~~~~~~~~~~~~~~~ |st2| ``statsd`` metrics driver is compatible with any service which exposes statsd compatible interface for receiving metrics via UDP. @@ -66,7 +66,7 @@ you get started with statsd and self hosted graphite and carbon cache instance can be found at https://github.com/StackStorm/st2/tree/master/conf/metrics. Exposed Metrics -=============== +~~~~~~~~~~~~~~~ .. note:: @@ -154,7 +154,7 @@ API requests in a particular time frame, you would use ``integral()`` graphite f ``integral(stats.counters.st2.api.requests.count)``). Example Graphite Dashboard -=========================== +~~~~~~~~~~~~~~~~~~~~~~~~~~ Below you can find code for an example Graphite dashboard which contains most of the common graphs you need to have a good operational visibility into |st2| deployment. @@ -171,7 +171,7 @@ during a particular point in time" and "total counts for a particular execution derived from the raw metric values. Pushing metrics to InfluxDB -=========================== +~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is possible to gather the StatsD data with Telegraf to push them to InfluxDB. The StatsD data are formatted in a different way than InfluxDB usually, so we can use the template feature that is availabie in the Telegraf StatsD importer to reformat them to something more convenients (with flags, etc..) @@ -182,7 +182,7 @@ Configure your InfluxDB and Telegraf InfluxDB output as usual, then on the Stats :language: toml Pushing metrics to Prometheus via the statsd_exporter -===================================================== +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Prometheus provides a service called `Statsd Exporter `_ which receives data in the StatsD format and acts as a scrape target for Prometheus. From e6846f4179df959a9442c88424ae726ddcd47a03 Mon Sep 17 00:00:00 2001 From: Marcel Weinberg Date: Fri, 14 Aug 2020 22:22:46 +0200 Subject: [PATCH 2/7] Drop reference to mistral configuration and logs from the debug_info_config.yaml --- docs/source/troubleshooting/__debug_info_config.yaml | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/source/troubleshooting/__debug_info_config.yaml b/docs/source/troubleshooting/__debug_info_config.yaml index e82048e81..cf8a4498c 100644 --- a/docs/source/troubleshooting/__debug_info_config.yaml +++ b/docs/source/troubleshooting/__debug_info_config.yaml @@ -1,9 +1,7 @@ --- log_file_paths: - /var/log/st2/*.log - - /var/log/mistral*.log st2_config_file_path: /etc/st2/st2.conf -mistral_config_file_path: /etc/mistral/mistral.conf s3_bucket_url: https://st2debuginfo.s3.amazonaws.com/ gpg_key_fingerprint: BDE989A1F308B18D29789C717064B11C82F62D6F gpg_key : | From 79e2d8f289a527b09128bbbfde5cade499e4a7a1 Mon Sep 17 00:00:00 2001 From: Marcel Weinberg Date: Fri, 14 Aug 2020 22:28:36 +0200 Subject: [PATCH 3/7] Drop the mistral issues trouble-shooting guide --- docs/source/troubleshooting/index.rst | 1 - docs/source/troubleshooting/mistral.rst | 56 ------------------------- 2 files changed, 57 deletions(-) delete mode 100644 docs/source/troubleshooting/mistral.rst diff --git a/docs/source/troubleshooting/index.rst b/docs/source/troubleshooting/index.rst index d1562bc70..ed465ab1a 100644 --- a/docs/source/troubleshooting/index.rst +++ b/docs/source/troubleshooting/index.rst @@ -11,7 +11,6 @@ and how to debug and troubleshoot them. basic_chatops_troubleshooting rules sensors - mistral ssh database rest_api_access diff --git a/docs/source/troubleshooting/mistral.rst b/docs/source/troubleshooting/mistral.rst deleted file mode 100644 index 3627c7d3c..000000000 --- a/docs/source/troubleshooting/mistral.rst +++ /dev/null @@ -1,56 +0,0 @@ -Mistral Issues -============== - -This section contains information on how to troubleshoot Mistral-related issues. - -Troubleshooting Mistral Database Upgrade ----------------------------------------- - -The ``mistral`` and ``mistral-api`` services must not be running at time of upgrading the st2mistral -package and the Mistral database schema. If the st2mistral package has been upgraded and the -services are started before the ``mistral-db-manage upgrade head`` CLI command is executed, then the -``mistral-db-manage upgrade head`` command may fail. - -When the ``mistral`` and ``mistral-api`` services run, SQLAlchemy automatically creates tables, -relationships, and indices that do not exist. If there are new database objects in the upgraded -database schema, the ``mistral-db-manage upgrade head`` command will fail because the actual schema -in the database is now different than its specifications, and it no longer can create the new database -objects. - -When that happens, the new database tables, relationships, and indices must be deleted before the -``mistral-db-manage upgrade head`` command can be re-run. For more details, review the version-specific -notes in the :doc:`/install/upgrades` documentation, for the version of Mistral and |st2| you are upgrading -too. - -.. _mistral-workflows-latency: - -Troubleshooting Mistral Workflow Completion Latency ---------------------------------------------------- - -Since v2.7, the results tracking mechanism is replaced with a callback mechanism from Mistral. Instead of |st2| -querying Mistral at regular intervals, Mistral is configured to callback |st2| on task and workflow completion. -See :ref:`mistral-workflows-completion-latency-and-performance` - -Prior to v2.7, |st2| queries Mistral to check on workflow execution status and the status of individual tasks -via st2resultstracker. This ``st2resultstracker`` process saves the state of outstanding workflow executions -in the database, and once a workflow is complete, deletes the state from the database. The process uses -eventlets to simultaneously query multiple workflow results. This can consume significant CPU cycles. - -There are two configurable values for controlling this. These are ``thread_pool_size`` (number of eventlets) -and ``query_interval`` (interval to space out the subsequent queries to Mistral for a single execution). You -can configure these values by editing the ``results_tracker`` section in ``/etc/st2/st2.conf``: - -.. sourcecode:: ini - - [resultstracker] - query_interval = 5 # in seconds - thread_pool_size = 10 - -These values are subject to load conditions in your infrastructure and the number of workflows -you are running. The default value for ``query_interval`` is set to ``5`` (seconds) which is a balance -between the workflow speed and the CPU overhead. With |st2| 2.2 and earlier, this value was ``0.1``. -We have now set the default value to ``5`` seconds to be conservative. This also means the time to detect -a completed workflow in Mistral by |st2| could take as long as 5 seconds. - -If this is unacceptable for you, you can reduce the ``query_interval`` and also -simultaneously check CPU usage for the ``st2resultstracker`` process. From cf744bde43a85e768c1cc4046e3112d45ea2969d Mon Sep 17 00:00:00 2001 From: Marcel Weinberg Date: Fri, 14 Aug 2020 22:32:08 +0200 Subject: [PATCH 4/7] Drop mistral from self_verification.rst --- docs/source/troubleshooting/self_verification.rst | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/source/troubleshooting/self_verification.rst b/docs/source/troubleshooting/self_verification.rst index 5e10e9bd6..0a91e13ee 100644 --- a/docs/source/troubleshooting/self_verification.rst +++ b/docs/source/troubleshooting/self_verification.rst @@ -9,7 +9,7 @@ The script covers the following aspects of |st2|: * Examples pack installation * Commands described in :doc:`/start` * :doc:`/packs` actions -* :doc:`/actionchain` and :doc:`/mistral` Workflows +* :doc:`/actionchain` Workflows To run the |st2| self-verification script: @@ -22,8 +22,7 @@ To run the |st2| self-verification script: sudo ST2_AUTH_TOKEN=$(st2 auth st2admin -p '' -t) /opt/stackstorm/st2/bin/st2-self-check -By default, ``st2-self-check`` will run Orquesta and Mistral tests, but will **not** run Windows tests. This can be -controlled with CLI options. You can also choose which st2tests branch to use: +By default, ``st2-self-check`` will run Orquesta tests, but will **not** run Windows tests. This can be controlled with CLI options. You can also choose which st2tests branch to use: .. code-block:: bash @@ -31,6 +30,5 @@ controlled with CLI options. You can also choose which st2tests branch to use: Options: -o Skip Orquesta tests - -m Skip Mistral tests -w Run Windows tests -b Which branch of st2tests to use (defaults to master) From 0b56679fd6d77f2fc6caa67e7f592b66c0dd232b Mon Sep 17 00:00:00 2001 From: Marcel Weinberg Date: Fri, 14 Aug 2020 22:33:56 +0200 Subject: [PATCH 5/7] Drop mistral from the submit_debug_info.rst --- docs/source/troubleshooting/submit_debug_info.rst | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/docs/source/troubleshooting/submit_debug_info.rst b/docs/source/troubleshooting/submit_debug_info.rst index 06d2a22b3..5e350962b 100644 --- a/docs/source/troubleshooting/submit_debug_info.rst +++ b/docs/source/troubleshooting/submit_debug_info.rst @@ -13,10 +13,7 @@ help us debug or troubleshoot your issue. By default, this utility sends us the following information: * All the |st2| services log files from ``/var/log/st2`` -* Mistral service log file from ``/var/log/mistral.log`` -* |st2| and Mistral config file (``/etc/st2/st2.conf``, - ``/etc/mistral/mistral.conf``). Prior to sending the config files we strip - sensitive information such as database and queue access information. +* |st2| config file (``/etc/st2/st2.conf``). Prior to sending the config files we strip sensitive information such as database and queue access information. * |st2| content (integration packs) minus the pack configs. All this information is bundled up in a tarball and encrypted using our @@ -103,7 +100,6 @@ from a YAML file. The following config options are supported: * ``log_file_paths`` - an additional set of log files to gather * ``st2_config_file_path`` - path to st2.conf -* ``mistral_config_file_path`` - path to mistral.conf * ``s3_bucket_url`` - the S3 bucket to upload the archive to * ``gpg_key_fingerprint`` - gpg fingerprint to use when encrypting the archive * ``gpg_key`` - gpg key to use when encrypting the archive From 14d3baf0ca953b4f57261b4ed73e005bae45be1e Mon Sep 17 00:00:00 2001 From: Marcel Weinberg Date: Fri, 14 Aug 2020 22:36:42 +0200 Subject: [PATCH 6/7] Drop mistral from the code_structure.rst --- docs/source/development/code_structure.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/source/development/code_structure.rst b/docs/source/development/code_structure.rst index 36a09e729..1086a28d9 100644 --- a/docs/source/development/code_structure.rst +++ b/docs/source/development/code_structure.rst @@ -44,8 +44,8 @@ RabbitMQ for incoming executions. Notifier and results tracker are also part of this code base. Notifier is the component that sends notification triggers and action triggers at the end of action execution. Results tracker -is an advanced async results querier for certain kind of runners like Mistral, where execution of -a workflow is kicked off remotely and you have to poll the Mistral APIs to collect results. +is an advanced async results querier for certain kind of runners like 3rd party integrations, where +execution of an action is kicked off and you have to poll the integrations APIs to collect results. st2client --------- From 463b592b7b1adfe16458f5a0a369d619f3e069af Mon Sep 17 00:00:00 2001 From: Marcel Weinberg Date: Fri, 14 Aug 2020 22:37:11 +0200 Subject: [PATCH 7/7] Drop mistral from the sources.rst --- docs/source/development/sources.rst | 8 -------- 1 file changed, 8 deletions(-) diff --git a/docs/source/development/sources.rst b/docs/source/development/sources.rst index 2452fde2b..b6ee2de9a 100644 --- a/docs/source/development/sources.rst +++ b/docs/source/development/sources.rst @@ -38,14 +38,6 @@ Fedora systemctl enable rabbitmq-server systemctl restart rabbitmq-server -Optional Requirements -~~~~~~~~~~~~~~~~~~~~~ - -Mistral -------- -Mistral workflow engine also has its own requirements. For more information, please refer to the -:github_mistral:`Mistral README `. - Project Requirements ~~~~~~~~~~~~~~~~~~~~