排除工作流程

InsightConnect中的工作流程失败可以源于许多地方，从工作流程中的错误范围到工作流程所依赖的服务中的临时中断。将错误放入上下文中是确定失败源的必要步骤。

故障诊断概述

InsightConnect工作流可以以3种方式触发：

  • 通过测试建筑师的按钮
  • 手动在活动工作流程页面上
  • 以响应工作流的触发器

在后两种情况下(通过工作流的触发器或从Active workflow页面手动)，作业将在Jobs页面上创建。但是，当从构建器测试工作流时，不会创建作业记录。

可用于排除故障的数据是相同的，无论如何触发工作流，但从构建器运行的工作流测试都不持久地，因此必须在故障排除期间保持页面，因此您可以引用数据。

从构建器中测试工作流程

在激活之前在工作流上自动执行多个检查。这些测试确保工作流程在内部一致，并且所有步骤都已完全配置。如果步骤失败检查，则会在构建器接口中变为橙色。

当这些内部检查失败时，您可以在构建器中测试工作流程。如果执行错误配置步骤，则会导致测试失败。

如果您在Builder中使用的测试功能，请确保在按照以下步骤之前确保所有步骤都是绿色的。

工作流程在过去工作，但现在每项工作都失败了

如果工作流没有改变，但它已经开始持续失败，那么问题很可能是在工作流之外。采取以下步骤:

  1. 检查Orchestrator是否健康设置>协调器。如果乐队是不健康的，请参阅排除Orchestrator文档以获取进一步说明。
  2. 检查工作流程使用的凭据。运行连接测试>插件和工具对于工作流利用的所有连接。
  3. 按照说明故障排除。

未触发工作流程（未创建作业）

如果Workflow根本不触发，则触发器一定是错误的。根据触发的类型，故障排除步骤会有所不同。

InsightIDR和InsightVM平台触发器

Insutigridr和Insightvm触发器配置在各自的产品中。要检查的第一件事是在这些接口中正确配置触发器。这有点不是包括InsightVM插件触发器。对于Insightvm Plugin触发器，请按照说明进行操作插件触发器部分排除故障。

InsightIdr工作流能见度

如果它在InsightConnect中处于活动状态，则具有InsightIdr触发器的自定义工作流程仅出现在insighidr中。如果您创建了未显示的InsightIdr工作流程，请确保它处于活动状态。

如果工作流触发但缺少预期数据，则意味着InsightIdr或InsightVM不会将数据发送到InsightConnect。警报触发工作流的可能性是错误的。

插件触发器（包括基于Insightvm Plugin的触发器）

基于插件的触发器在协调器上运行。它们连接到远程系统或服务，并监视特定的条件。当条件满足时，它们会触发工作流。

解决基于插件的触发器的步骤：

需要访问Orchestrator

您需要访问Orchestrator以访问基于插件的触发器的日志。一旦验证了触发器的配置，需要访问Orchestrator（使用SSH或虚拟机控制台）。这里强烈推荐熟悉Linux和Docker。

  1. 检查下面的协调器的运行状况设置-如果协调器没有显示为“健康的”，那么协调器本身有问题。使用排除Orchestrator记录以使康运人员进入健康状态。
  2. 使用三点菜单在插件上运行连接测试插件和工具页面下设置。解决指示的任何错误。
  3. 验证工作流中的触发配置是否正确。错误通常是由于配置导致触发器监控错误的数据（例如错误的邮箱）或丢弃您希望它触发的事件。
  4. 连接到Orchestrator（使用SSH或虚拟机控制台）。
  5. 触发器作为Orchestrator上的Docker容器运行。跑sudo docker ps-a | grep触发器要查看活动触发器容器。
  6. 根据显示的数据识别触发器(窗口越宽，越容易)。如果您无法识别触发器，请尝试停用工作流，等待大约2分钟，然后重新激活它。这将重新启动触发器。在列出活动触发器时，您将在容器的正常运行时间中看到这一点。
  7. 使用容器ID（输出中的第一列）来检查触发器的日志Sudo docker日志<容器id>。容器日志是触发器的诊断输出。你可以添加- 跟随旗帜实时观看它们（sudo docker日志 - 文件<容器ID>）

日志很复杂 - 支持可以提供帮助！

查看原始触发日志可能是一个具有挑战性的任务。如果你不舒服地看着日志，或者只需要第二组眼睛，请不要犹豫，达到Rapid7支持。

如果触发器容器不存在，请参阅排除Orchestrator文档和联系Rapid7支持。

工作流程是生成失败的作业，不断地或间歇地

工作流程由某些假设构建：触发器包含某些数据，它可以在其他系统和服务等中查找数据等。当作业间歇地生成失败的作业时，它意味着不会满足这些假设。通常，但并非总是，这意味着必须修改工作流以解释导致它失败的条件。

并非所有失败的步骤都是致命的

一些工作流有偶尔设计的步骤。这些步骤设置为“继续失败”，不会终止工作流程。这些工作流程专门设计用于适应该失败的步骤。在寻找导致作业失败的步骤时，请确保您正在查看工作中的最后一次失败。

  1. 在下面工作，选择失败的作业。
  2. 选择所有输出标签。
  3. 找到作业中的失败步骤。
  4. 检查输入步进输出的标签。验证输入是否既是您所期望的以及插件的期望。常见问题是缺失或畸形的输入。
  5. 如果输入不正确，请检查工作流程并确定输入来自的位置。不正确的输入通常意味着前一步是返回意外数据。
  6. 检查日志步进输出的标签。此日志包含与失败相关的诊断信息，例如从底层服务返回的错误消息。
  7. 如果日志表示权限问题，请运行连接测试>插件和工具页并验证凭据是正确的。如果连接测试成功，但是由于权限问题，步骤仍然失败，那么很可能插件没有正确的权限来执行操作。
  8. 如果日志指示的超时问题，则可能存在底层服务的服务中断，或者Orchestrator正在遇到基础服务的连接困难。

如果您没有看到任何错误，或有错误您无法修复，请截屏您的输入和日志，并联系Rapid7支持。