CN109328335B - 智能配置发现技术 - Google Patents

Abstract

在配置发现服务处，基于对从第一数据源获得的数据集的分析而为配置项生成唯一的服务侧识别符。确定不含所述服务侧识别符并且是从不同数据源获得的第二数据集也包括与所述相同配置项有关的信息。准备所述配置项的合并配置记录。将所述合并配置记录存储在存储库中并且将其用于响应编程查询。

Description

智能配置发现技术

背景技术

许多公司和其他组织运营使众多计算***互连以支持其运营的计算机网络，诸如其中计算***位于相同位置(例如，作为本地网络的一部分)或者替代地位于多个不同的地理位置(例如，经由一个或多个专用或公共中间网络进行连接)。例如，容纳大量互连的计算***的数据中心已变得司空见惯，诸如由单个组织运营和代表单个组织运营的私有数据中心(例如，企业数据中心)，以及由作为企业的实体运营来向客户提供计算资源的公共数据中心。一些公共数据中心运营者为由各种客户拥有的硬件提供网络访问、电源和安全安装设施，而其他公共数据中心运营者提供还包括可供其客户使用的硬件资源的“全面服务”设施。

用于商用硬件的虚拟化技术的出现已经在管理大规模计算资源方面为具有多种多样需要的许多客户提供了益处，从而允许各种计算资源由多个客户有效且安全地共享。例如，虚拟化技术可以允许通过向每个用户提供由单个物理计算机器托管的一个或多个虚拟机而在多个用户之间共享单个物理计算机器。每个这种虚拟机可以被认为是软件模拟，所述软件模拟充当向用户提供了他们是给定硬件计算资源的唯一操作者和管理员的错觉的不同逻辑计算***，同时还在各种虚拟机之间提供应用程序隔离。

复杂应用程序的执行环境可以跨越各种各样的资源-例如，应用程序的一些部件可以使用虚拟机运行，而其他部件可以使用非虚拟化服务器运行。在一些情况下，应用程序或一组相关应用程序的资源可以分布在若干不同的数据中心中。执行环境的复杂性可能使得难以获得对各种应用程序部件之间的关系和依赖性的全面理解。这种不清晰可能反过来使得更难以做出相应的业务决定，诸如将应用程序从客户拥有的驻地迁移到提供商网络环境。

附图说明

图1示出了根据至少一些实施方案的可以实现用于多数据中心应用程序的智能配置发现服务的示例***环境。

图2示出了根据至少一些实施方案的可用于组织配置信息的发现服务本体的示例部件。

图3示出了根据至少一些实施方案的从具有相应信任分数的多个数据源合并原始配置信息以产生策划属性值列表的示例。

图4示出了根据至少一些实施方案的可以在配置发现服务处实现的示例应用程序编程接口。

图5示出了根据至少一些实施方案的可以在发现服务处使用以自动检测配置项所扮演的角色的应用程序架构模式的示例。

图6示出了根据至少一些实施方案的在配置发现服务处对网络数据包使用源身份检测算法。

图7示出了根据至少一些实施方案的可以在配置发现服务处使用以将相关性分数分配给配置项的示例因素。

图8示出了根据至少一些实施方案的可以在配置发现服务处采用以改进对时间查询的响应的技术的概述。

图9是示出根据至少一些实施方案的可以在配置发现服务处执行的操作的各方面的流程图。

图10示出了根据至少一些实施方案的可以实现在发现服务处搜集的配置记录的可视化服务的示例***环境。

图11示出了根据至少一些实施方案的可以由可视化服务自动实现的视图之间的示例性基于上下文的转变。

图12示出了根据至少一些实施方案的可视化服务的图形用户界面的示例元素。

图13示出了根据至少一些实施方案的可以在可视化服务的帮助下显示的事务相关的信息的示例。

图14示出了根据至少一些实施方案的可以在可视化服务的帮助下显示的网络流量相关的信息的示例。

图15示出了根据至少一些实施方案的使用滑块控件以在可视化服务的帮助下获得随时间过去发生的配置变化的可视化的示例。

图16示出了根据至少一些实施方案的使用可视化服务来起始应用程序执行环境的分阶段迁移的示例。

图17是示出根据至少一些实施方案的可以由可视化服务执行以提供配置记录的图形表示的操作的各方面的流程图。

图18示出了根据至少一些实施方案的可以实现利用在配置发现服务处收集的数据的迁移市场服务的示例***环境。

图19示出了根据至少一些实施方案的客户端与迁移市场服务之间的示例编程交互。

图20示出了根据至少一些实施方案的迁移促进者与迁移市场服务之间的第一组示例编程交互。

图21示出了根据至少一些实施方案的迁移促进者与迁移市场服务之间的第二组示例编程交互。

图22示出了根据至少一些实施方案的可以存储在迁移市场服务的元数据存储库中的条目的示例。

图23示出了根据至少一些实施方案的可以由迁移市场服务实现的示例性基于网络的界面。

图24是示出根据至少一些实施方案的可以在迁移市场服务处执行的操作的各方面的流程图。

图25是示出了可以在至少一些实施方案中使用的示例计算装置的框图。

虽然在本文中通过若干实施方案和说明性附图的示例描述了实施方案，但是本领域技术人员将认识到，实施方案不限于所描述的实施方案或附图。应理解，附图及其详细描述并不意图将实施方案限于所公开的特定形式，而是相反，本发明将涵盖落入如通过随附权利要求书所限定的精神和范围内的所有修改、等效物以及替代方案。本文中使用的标题仅出于组织的目的，而非意在用于限制描述或权利要求书的范围。如本申请全文中所使用，词语“可”是以许可性意义使用(即，意味着有可能)，而非以强制性意义使用(即，意味着必须)。类似地，词语“包括”意味着包括但不限于。当用于权利要求书中时，术语“或”用作包括性或而非用作排他性或。例如，短语“x、y或z中的至少一者”意指x、y和z中的任一者以及其任何组合。

具体实施方式

描述了用于在网络可访问的发现服务处实现的智能配置发现技术，用于提供配置信息的自动更新视图的可视化技术，以及用于协助发现服务的客户以及迁移促进者做出关于应用程序迁移的决定的迁移市场服务的方法和设备的各种实施方案。在高层次上，配置发现服务可以使得能够(除了其他特征之外)基于各种数据源收集的原始数据自动检测配置项(诸如构成应用程序的物理或虚拟化计算服务器、存储装置、数据库、软件堆栈部件等)和分布式应用程序模式，将唯一识别符分配给配置项、跟踪项之间的交互(例如，事务、网络流量等)和相依性，应用程序配置随时间过去发生变化，以及以所要粒度级别对复杂应用程序执行环境进行性能监视。配置发现服务在一些环境中也可以被称为应用程序发现服务或资源发现服务，因为配置项是形成应用程序的部件。配置发现服务可以实现各种编程接口(例如，网络服务应用程序接口、命令行接口等)，所述程序接口可以由服务客户端使用以获得对配置相关的查询的响应，并且还可以用作其他服务(包括迁移市场服务和可视化服务)的构建块以提供更高级别的功能。在一些实施方案中，附属于配置发现服务或者作为配置发现服务的一部分的可视化服务可以充当配置发现服务的客户端的主要交互模式中的一者-例如，客户可能能够查看适用于所使用的特定客户端侧显示环境的应用程序执行环境的定制表示，经由可视化界面发出配置相关的查询，和/或起始从一组资源到另一组资源的部分或完整的应用程序迁移。在各种实施方案中，迁移市场可以充当中介服务，所述中介服务使得客户端能够识别合适的迁移促进者，并且供迁移促进者识别候选客户端-例如，用于将应用程序从客户端驻地移动到基于云的计算环境，或者从一个基于云的环境移动到另一个基于云的环境。

在至少一些实施方案中，可以在提供商网络处实现服务中的一些或全部。由实体(诸如公司或公共部门组织)建立以用于向一组分布式客户端提供可经由因特网和/或其他网络访问的一个或多个网络可访问服务(诸如各种类型的基于云的计算或存储服务)的网络在本文中可以被称为提供商网络。提供商网络有时可以被称为“公共云”环境。在一些情况下，提供商网络的资源可以分布在多个数据中心中，所述数据中心又可以分布在许多城市、州和国家中。注意，虽然配置发现服务、可视化服务和/或迁移市场服务可以在特定提供商网络内实现，但是这些服务中的一些或全部可以被授权并被授予适当许可以访问来自其他提供商网络(例如，来自不同商业组织经营的提供商网络)的信息。例如，在运营商O1经营的提供商网络PN1处运行的配置发现服务可能能够搜集从运营商O2经营的提供商网络PN2(以及从其他设施，诸如客户端拥有的数据中心和PN1自己的数据中心)收集的配置数据，在PN1处运行的可视化服务可以使客户端能够查看包括在PN2处运行的部件的分布式应用程序架构，和/或在PN1处运行的迁移市场服务可能能够向客户端提供关于迁移促进者的信息以用于将在PN2处运行的部件迁移到PN1。在一些实施方案中，可视化服务和/或迁移市场服务可以实现为配置发现服务的子部件。配置发现服务在本文中也可以简称为发现服务。

可以在配置发现服务处采用各种各样的数据源来构建配置记录的存储库。例如，在一些实施方案中，数据源可以包括客户端数据中心处的现有配置管理数据库(有时可以经由编程接口从所述配置管理数据库批量导入配置数据)，代表配置发现服务安装在各个资源处的代理或配置数据收集器、第三方或行业标准配置管理工具等等。每个数据源可以在一个或多个时间点向配置发现服务提供配置信息，例如，包括用于某组配置项的某一数目的属性-值对。在至少一些实施方案中，一些数据源可以按规则间隔提供原始配置数据，而其他数据源可以是事件驱动的。在各种实施方案中，值在服务处获得(例如，经由代表服务安装的代理)的配置项属性除了其他之外可以包括用户信息(诸如用户名称和主目录)、组信息(诸如组名称和组成员资格)、已安装软件包/程序列表，以及内核模块列表。在至少一些实施方案中，也可以收集关于许多不同类型的配置相关的事件的信息，所述配置相关的事件诸如进程创建/终止(利用相关联的进程识别符)、域名服务(DNS)查询和响应、在网络堆栈的各个层处的数据包发送和接收等等。可以从目标执行环境的装置收集物理和/或虚拟网络接口的各种属性的值(包括例如正在使用的网络互连的类型诸如以太网、所支持的最大带宽、相关联的媒体访问控制或MAC地址等)。可以识别在各种资源处使用的特定网络端口，诸如TCP(传输控制协议)或UDP(用户数据报协议)端口，并且可以收集TCP版本4或版本6连接属性(诸如在连接的任一端的进程的识别符、连接建立时间、连接保持打开的持续时间等)。在一些实施方案中，可以收集操作***相关的属性，包括例如在各种主机和虚拟机中使用的操作***的特定版本。在不同实施方案中，可以按各种间隔收集***性能和进程性能度量。在一些实施方案中，发现服务的多个代理可以安装在给定主机或装置处，以收集一个或多个配置项的配置属性值的相应子集；在其他实施方案中，单个代理或工具可能能够从若干不同的源提取属性值。

配置发现服务可以充当按相应粒度级别并且根据相应时间表从各种数据源收集的可能过时的、冲突的和/或模糊的原始配置信息的组合器和策划器。从完全不同的数据源，在一些实施方案中，配置发现服务可以负责生成并存储合并和策划的配置记录；这类合并记录可以充当可视化和迁移市场服务(或依赖于发现服务的其他服务)的配置数据的权威来源。在至少一些实施方案中，配置发现服务可以至少部分地基于由服务定义的本体来生成并为相应配置项分配唯一的服务侧识别符。例如，给定硬件服务器可以由一个数据源基于服务器的IP地址中的一者(其可以随时间而变化)，由另一数据源基于服务器名称或MAC(媒体访问控制)地址，由第三数据源基于服务器在分布式应用程序中扮演的角色(例如，“网络服务器”或“数据库服务器”)等等来识别。数据源可以各自在提供给配置发现服务的原始配置数据中包括它们自己对服务器的相应识别符/名称。这类识别符在本文中可以被称为数据源侧识别符。配置发现服务可以检查从不同数据源中的一者或多者接收的原始配置数据，并基于定义的本体和命名方案(其可以考虑原始数据的属性值的子集)为服务器生成唯一的服务侧识别符。

唯一的服务侧识别符可以与数据源使用的识别符/名称中的至少一些不同。在至少一些实施方案中，当在服务处接收到或分析一组新的原始配置数据时，所述服务可能能够确定原始数据的至少一部分适用的唯一识别的配置项，尽管在原始数据中不存在唯一识别符。在一些实施方案中，服务可以负责维护数据源提供的识别符与唯一的服务侧识别符之间的映射，并且负责解决与这种映射相关联的模糊性(例如，在数据源改变其用于给定配置项的识别符的情况下可能出现的模糊性)。在不同实施方案中可以使用多种机制-例如，基于关于在某一时间段内从其他数据源接收的原始配置数据的相关性分析，基于客户端反馈等等来解决模糊性。在一个示例情形中，例如，可能最初例如，基于从两个不同数据源接收的相应原始配置数据集DS1和DS2将两个不同的唯一的服务侧识别符(错误地)分配给相同配置项，以及因此可能将具有相应的不同的服务侧识别符的两个不同的合并配置记录R1和R2存储在服务存储库中。稍后，例如，在处理一个或多个额外原始数据集之后和/或在经由编程接口与客户端交互之后，可以检测到错误并进行校正。也就是说，服务可以确定值存储在R2中的属性实际上是对应于R1的基础配置项的属性。例如，可以基于对资源消耗信息的分析来做出这种确定。如果最初错误地假定与R1和R2相关联的两个配置项是不同的硬件服务器，但是发现关于两个项的CPU利用率水平或网络数据包流出的所收集度量在一段时间内非常相似或相同，则可以将记录R1和R2识别为指代相同服务器。在这种情形中存储在R2中的信息中的一些可以用于更新R1，并且可以删除R2(或者相反，R1中的信息可以用于修改R2，并且然后可以删除R1)。在至少一个实施方案中，可以由发现服务实现纠错API，使得客户端(和/或其他授权实体，诸如提供商网络运营商的专业服务分析员、顾问或合作伙伴)能够向服务通知这些错误。经由这类API提供的校正可以用于在各种实施方案中更广泛地改进服务操作-例如，由一个授权实体关于给定服务客户的给定配置数据集进行的校正可以被一般化并用于检测和校正关于相同客户或其他客户的其他配置数据集的可能错误。

在至少一些实施方案中，配置发现服务可以使相应的信任分数与不同数据源相关联，并且当决定要接受一组可能冲突或过时的配置数据元素中的哪一个时，可以使用这种信任分数。信任分数本身可能随时间而变化-例如，如果在服务处获得表示客户端数据中心的客户端的配置管理数据库的转储，则可以将客户端的数据库的初始信任分数设置为高值，但是随着时间的推移，分数可能降低，并且客户端数据中心会发生配置变化。在至少一些实施方案中，当从原始配置数据生成合并配置记录时，可以使用信任分数-例如，与从低信任数据源获得的属性值相比，从高信任数据源获得的属性值可以较大的概率被包括在合并记录中。在来自具有当前信任分数TS1的数据源DS1的属性值V1与来自具有较高当前信任分数TS2的不同数据源DS2的属性值V2矛盾或冲突的情形中，来自具有较高信任分数的源的属性值(在这种情况下为V2)可以被包括在合并配置记录中，并且可以排除来自具有较低信任分数的源的属性值。在至少一些实施方案中，可以采用机器学习技术来生成并随时间更新信任分数。

下文提供了关于配置发现服务的操作的各个方面的额外细节，包括基于模式的自动分组和应用程序部件的标记，用于检测经由混淆中介接收的网络数据包的源的算法，使相关性分数与配置项相关联，用于增加对查询的响应的数据模型和预加载技术等。在讨论了发现服务的细节之后，讨论了可视化服务和市场迁移服务。

示例***环境

图1示出了根据至少一些实施方案的可以实现用于多数据中心应用程序的智能配置发现服务的示例***环境。如所示，在所示实施方案中，***100可以包括多个提供商网络，诸如提供商网络102A和102B，以及客户驻地网络172。在提供商网络102中的每一者内，一个或多个网络可访问服务可以由相应的提供商网络运营商实现。例如，提供商网络102A包括配置发现服务104、虚拟化计算服务132，以及一个或多个迁移相关的服务130，迁移相关的服务130可以由潜在客户利用以将其应用程序从提供商网络102A外部的执行环境迁移到提供商网络102A。下文提供了关于迁移相关的服务的额外细节。提供商网络102B可以包括其自己的虚拟化计算服务192，在该虚拟化计算服务192处可以利用与在虚拟计算服务132中使用的不同的虚拟化计算服务器的方法-例如，可以使用不同类型的管理程序或虚拟化管理软件堆栈，可以支持几组不同的程序接口以获取和使用虚拟机等等。

在所示实施方案中，可以使用提供商网络102A和102B和/或客户驻地网络172的资源代表各种客户运行多个分布式应用程序。用于给定应用程序或一组相关应用程序的一组资源在本文中可以被称为应用程序执行环境(AEE)144。给定AEE可以包括各种各样的资源-例如，虚拟和/或物理计算服务器、存储装置、联网装置、多层软件堆栈等。资源中的至少一些可以包括配置项(CI)136，关于所述配置项的各组配置信息(例如，属性值的集合)被收集并存储在配置发现服务104内。一般来说，从配置发现服务及其客户端的角度来看，配置项136可以包括任何物理、虚拟或逻辑实体，其配置设置和/或状态信息可用于管理一个或多个应用程序，并且可以由配置发现服务经由编程接口获得。示例配置项除了其他之外可以包括非虚拟化硬件服务器、虚拟机、软件进程或相关进程的集合、诸如旋转磁盘或固态驱动器(SSD)的存储装置、诸如路由器的网络装置等等。在一些实施方案中，配置发现服务可以迭代地-例如，按规则间隔或响应于指定事件的发生而从一个或多个配置数据源(CDSrcs)134获得关于给定配置项136的配置数据的相应数据集。在后一种情形中，存储在服务104处的配置数据可以包括用于配置项的多个带时间戳的记录。在各种实施方案中可以采用许多不同类型的配置数据收集器或源，诸如例如代表配置发现服务104安装的软件和/或硬件代理、行业标准配置管理工具、定制配置管理工具、客户配置管理数据库等。

一些AEE，诸如AEE 144A或AEE 144C，可以包括给定网络边界内的资源。AEE 144A包括客户驻地网络172的配置项136Q、136R和136S，而AEE 144C包括提供商网络102B的配置项136I和136J。其他AEE可以包括分布在多个网络和/或数据中心中的配置项。例如，AEE144B包括提供商网络102A的配置项136A-136D，以及提供商网络102B的配置项136H。注意，随着时间的推移，至少在一些实施方案中，AEE 144与AEE的配置项所在的网络之间的映射可以改变-例如，一个或多个配置项可以迁移到不同的提供商网络，从客户驻地网络到提供商网络，或从提供商网络到客户驻地网络。

在所示实施方案中，每个网络可以包括多个配置数据源134，配置数据源134可以与配置发现服务104通信。例如，提供商网络102A包括共同负责获得配置项136A-136F的配置数据集并且将其发射到服务104的配置数据源134A-134C。类似地，提供商网络102B包括负责对配置项136H-136L进行报告的数据源134E-134G，而客户驻地网络172包括负责将与配置项136N和136P-136S有关的配置数据集发射到服务104的数据源134H和134I。在一些情况下，给定配置数据源134可以负责收集与多个配置项136有关的配置数据，而在其他情况下，配置数据源134可以对单个配置项136进行报告。至少对于一些配置项136，配置数据集可以由多个配置数据源134-例如，按相应的粒度级别和/或在软件/硬件堆栈的各个层收集。在一些实施方案中，给定配置数据源134可以是配置项136的子部件-例如，作为在服务器处运行的表示配置项的进程或执行线程。例如，数据源134G被示为配置项136L的一部分。一些配置数据源可以包括现有配置管理工具的子部件-例如，在所示实施方案中，客户的配置管理数据库167包括向服务104报告的数据源134G。

在所示实施方案中，配置发现服务104可以实现一组或多组编程接口150，所述编程接口150中的任一者可以包括例如应用程序编程接口(API)、基于网络的控制台、命令行工具和/或图形用户界面。面向客户端的编程接口150A可以例如由客户用来识别和/或授予与其应用程序执行环境144相关联的配置数据搜集许可，以查看由服务104收集的配置信息(例如，使用下文进一步详细讨论的可视化服务)，以获得关于可能需要客户端反馈的事件或条件的通知等等。在所示实施方案中，一组数据收集和/或服务侧编程接口150B可以用于配置数据源134与服务104之间的交互，以及用于由迁移相关的服务130和/或其他服务使用服务104的所收集的配置数据来构建额外特征。

在所示实施方案中，配置发现服务104可以包括若干子部件，诸如配置记录存储库108、负责合并原始配置数据/消除原始配置数据的模糊性的部件110，和/或负责分配/修改数据源134的相应信任分数和/或分配/修改配置记录的相关性分数的一个或多个评分部件112，如下文所讨论。在至少一些实施方案中，服务可以包括如下文所讨论的具有不同性能能力和/或数据模型的多个数据存储区-例如，配置记录可以从中央存储库108预加载到低等待时间高速缓存中以增加对预期查询类型的响应。

在所示实施方案中，配置数据源134可以以多种格式并按不同的间隔向配置发现服务104提供原始配置数据集。在一些情况下，在服务104处关于一个或多个配置项136接收的原始数据可能是陈旧的或过时的或不准确的。此外，在由不同数据源134提供的原始数据集中识别配置项的方式在某些情况下可能不一致-例如，如果给定硬件服务器配置项具有多个IP地址，则该服务器可以由不同的配置数据源使用不同的IP地址指代，或者由其他数据源用名称或位置(诸如“数据中心DC1的房间3中的机架R1的服务器5”)来指代。在所示实施方案中，配置发现服务104可以负责使用各种技术来对原始配置数据集进行合并、消除模糊和策划。在一个这种技术中，当接收到一组原始配置数据时，服务104可以试图辨别数据是否指代已知配置项136(先前已在服务处接收并记录配置数据的项)。如果新接收的数据看起来不对应于已知配置项，则可以使用命名方案或算法来至少部分地基于在服务104处定义的本体和/或基于在原始数据中指示的配置项的一个或多个属性值来生成原始数据所对应的配置项的唯一的服务侧识别符。至少在一些实现方式中，唯一的服务侧识别符可能不同于数据源在原始数据集中使用的识别符。实际上，在这类实现方式中，服务104可以负责维护数据源报告的识别符与唯一的服务侧识别符之间的映射。当在服务处接收到后续原始数据集时，在一些实施方案中，合并/消除模糊部件110可以利用这种映射和/或使用原始配置数据与先前看到的数据的相关性来识别原始数据集所适用的配置项。在一些实施方案中，分配给给定配置项136的服务侧识别符在存储在服务104处的配置记录的整个集合内可以是唯一的，而在其他实施方案中，识别符在特定配置域或命名空间(例如，与给定客户相关联的域或命名空间)内可以是唯一的。

关于配置项的可用配置数据被分析并用于生成唯一的服务侧识别符的方式在不同实施方案中可以不同。在一个实施方案中，可以首先剖析原始配置数据并且将其规范化为通用格式，所述原始配置数据可以由不同数据源以XML(可扩展标记语言)、JSON(JavaScript对象表示法)、纯文本或诸如CBOR(简明二进制对象表示)的二进制格式提供。可以在原始或规范化数据中对为与某个命名空间内的唯一性相关联的关键词(诸如，用于因特网协议地址的“IPAddr”或用于中值访问控制地址的“MACAddr”)提供的属性值执行搜索，并且搜索结果可以与对象类型名称(例如，“数据库服务器”或“虚拟化主机”)组合/结合以生成唯一的服务侧识别符(例如，“DB服务器.<DB供应商名称>.<IP地址>)。在一个实施方案中，机器学习技术可用于改进为配置项生成唯一的服务侧名称的进程。例如，可以使用从提供商网络(例如，配置发现服务运行所在的相同提供商网络)的虚拟化计算服务的各种部件收集的大型匿名配置数据集来训练用于生成识别符的机器学习模型。由模型的早期版本做出的命名决定中的一些可能是错误的-例如，相同基础配置项可能被赋予两个不同的唯一识别符，或者两个配置项可能被赋予相同的识别符。随着时间的推移，当模型训练随着较大的输入数据集而进展时，可以降低错误率。

在至少一些实施方案中，相应信任分数可以分配(例如，通过评分部件112)给相应的配置数据源134，并且用于实际上决定两个可能冲突的源中的哪一个在给定时间点可能更准确。例如，数据源中的一些可以包括发现服务104的代理，发现服务104可能已在被安装之前由提供商网络102B的运营商的人员设计、开发和测试，而与其他数据源相关联的起点和/或测试级别可能不太为人所知。在后一种情形中，有时可以将较高信任分数分配给更熟悉或更好理解的数据源。在一些实施方案中，给定数据源的信任分数可以基于正在考虑的值所属的属性或者生成属性值的软件/硬件堆栈的级别而变化。例如，数据源DS1和DS2可以各自提供关于给定程序或进程的CPU使用的相应度量C1和C2。如果DS1在管理程序层收集其CPU利用率度量版本C1，而DS2使用操作***提供的工具收集其版本C2，则可以将不同的信任分数分配给来自两个源的CPU使用属性值。在其中多个数据源可以为相同属性提供相应值的至少一些实施方案中，可以为每个数据源(或{数据源、属性}对)分配指示当前信任级别的相应权重，并且所述权重可以用于确定发现服务将使用和保存的属性的最终值。在一个实施方案中，如果从相应数据源134接收到对应于相同配置项136的两个不同的原始数据集，并且一个原始数据集的至少一个属性值与另一原始数据集中指示的属性值冲突或相矛盾，则可以生成排除具有较低信任分数的数据源的冲突属性值的合并配置记录并且将其存储在存储库108中。在一些实施方案中，不同数据源134的信任分数可以是时间加权的-例如，如果在时间T1由一个数据源CDSrc1收集原始配置数据并且在时间T2(其中T2晚于T1)由另一数据源CDSrc2收集明显冲突的原始数据，则可能认为更近地收集的原始数据更值得信任。在各种实施方案中，由合并/消除模糊部件110生成的合并数据记录可用于提供对经由编程接口150A和/或150B接收的配置查询(例如，来自客户或来自提供商网络102A的其他服务)的响应。

除了策划或合并从数据源134接收的原始配置数据之外，在至少一些实施方案中，发现服务104的部件可以执行许多其他功能，诸如自动识别一起对应于分布式应用程序模式的配置项组，将这些组内的角色分配给相应配置项，实现源可能已被中介装置混淆的网络流量的流量源检测算法，主动准备配置数据以支持高性能查询等等。下文提供了关于这些和其他功能的额外细节。

如前所述，在至少一些实施方案中，配置发现服务可以定义和利用配置项的本体。图2示出了根据至少一些实施方案的可用于组织配置信息的发现服务本体的示例部件。在所示实施方案中，本体202可以包括多个对象类型，以及与每个对象类型相对应的一个或多个属性的列表。给定配置项的给定属性列表的属性中的至少一些的相应值可以包括在由各种配置数据源发射到配置发现服务的原始配置数据集中。在各种实施方案中，本体和原始属性值可用于为配置项生成唯一的服务侧识别符。例如，在一些实施方案中，可以通过将若干属性值(其中一些可能从不同数据源获得)与服务生成的文字识别符前缀结合来构造配置项的唯一的服务侧识别符。

例如，对象类型204A对应于物理主机或服务器。对应属性列表205A可以包括CPU类型、CPU或核的计数、当前分配的主机名称、管理程序(如果安装了的话)、操作***信息的各种元素(OS数据)、一个或多个IP地址等等。诸如205A的属性列表的给定属性的值本身可以包括若干不同的数据元素-例如，“CPU类型”属性可以包括关于CPU支持的指令集架构、CPU供应商、CPU的时钟频率、型号名称等等的信息。

对象类型204B表示进程(即，服务器处的执行单元)。进程的属性丢失205B除了其他之外可以包括进程的名称、用于调用进程的命令行、主机操作***处对应于用于进程的可执行程序的位置和/或对应于进程的主目录的路径、进程的线程数目等等。

对象类型204C表示网络连接(假设在该示例中是使用传输控制协议/因特网协议或TCP/IP套件建立)。属性列表205C包括源和目的地IP地址(分别为srcIP和destIP)(例如，其中源被识别为发出connect()调用以建立连接的端点)、源和目的地进程识别符(分别为srcProcess和destProcess)和/或目的地端口(destPort)。

对象类型204D对应于使用从特定技术供应商V1获得的虚拟化框架生成的虚拟机。虚拟机的属性列表205D包括供应商定义的虚拟机识别符(VMID)、虚拟机正在运行或已运行所在的数据中心的识别符，以及虚拟机当前在运行、计划运行，或已运行所在的主机。

在各种实施方案中，可以在本体202中定义许多其他对象类型。例如，在一些实施方案中，可以为存储装置、诸如数据库实例的实体、诸如负载平衡器/路由器等联网装置等定义相应对象类型。在一个实施方案中，可以为地理或其他资源分组定义相应对象类型-例如，数据中心可以具有其自己的对象类型，或者服务器机架可以具有其自己的对象类型。在一些实施方案中，本体可以定义各种对象之间的分层或包含关系-例如，许多进程可以在给定主机处运行并且因此可以包含在主机内，应用程序的主进程可以产生可以被指定为主进程的子进程的各种其他进程等等。在至少一些实现方式中，可以以面向对象的方式定义本体的各种实体之间的关系。

合并和策划的配置记录

图3示出了根据至少一些实施方案的从具有相应信任分数的多个数据源合并原始配置信息以产生策划属性值列表的示例。在所示实施方案中，包括与给定配置项有关的数据集320A、320B和320K的多个原始配置数据集320由相应数据源310(例如，数据源310A、310B和310K)发射到发现服务。每个原始配置数据集320包括相应属性值列表325。例如，对于给定主机，属性及其对应值可能包括“名称：主机100”、“IP地址：a.b.c.d”、“操作***：<OS版本>”等等。在至少一些实施方案中，并非所有属性值都必定对应于单个配置项-例如，配置数据源中的一者或多者可以对多个配置项进行报告。不同数据集320可以表示不同粒度级别-例如，一个数据集可以包括应用程序级信息，诸如发出或接收的数据库事务的数目，而另一数据集可以包括较低级别的细节，诸如发射或接收的网络数据包的数目。由两个不同数据源发送的原始配置数据中的一些可以对应于不同时间-例如，数据集320A可能已经在与数据集320K不同的时间被收集。在某些情况下，与给定配置项有关的属性值中的两个或更多个可能彼此冲突-例如，情况可能是一个数据集指示在一个主机H1处具有进程识别符PID1的特定进程负责与不同主机通信，而另一数据集可能指示具有另一进程识别符PID2的进程负责这类通信。在一些实施方案中，配置数据源中的至少一些可以为配置项生成相应识别符，所述配置数据源向发现服务提供用于所述配置项的数据，并且将这些识别符包括在数据集320中。这种识别符可以被称为数据源侧识别符，以将它们与发现服务生成的识别符区分开。两个数据源有时可以使用不同的数据源侧识别符来指代相同的基础配置项-例如，一个数据源可以用名称(例如，“主机K.<域名>)指代主机，另一数据源可以用IP地址指代相同主机，并且另一数据源可以用功能(例如，“数据库服务器DBS1”)指代。

在所示实施方案中，配置发现服务的合并/消除模糊部件360可以检查和处理所有原始配置数据集320并更新(或创建)对应于一个或多个配置项的相应合并配置记录350，所述一个或多个配置项的原始数据包括在数据集320中。在一个实施方案中，可以用于合并来自两个不同源的两个原始配置数据集的算法可以包括以下步骤中的至少一些。首先，可以关于数据集中的每一者是否包括与相同类型的配置项(诸如主机、进程、虚拟机等，其在图2的本体202中被定义为对象类型)有关的属性值做出决定。为此，在一些实施方案中，可以将属性名称与为发现服务的本体中的各种配置项定义的属性列表(例如，图2的AttrList205)进行比较。在某些情况下，属性列表可以指示同义词-例如，相同的属性名称由一个数据源经由名称AttrName1识别，并且由另一数据源经由名称AttrName2识别。如果确定两个数据集至少包含与相同配置项类型有关的一些属性值，则可以检查那些<属性：值>对的相关性、匹配或重复。例如，如果两个数据集都指示(a)在特定时间间隔内主机的CPU利用率约为75％，(b)并且在该时间间隔内从该主机发送了2500个UDP数据包，则这可能被解释为指示数据集指的是相同主机，即使将不同的数据源侧识别符用于相同主机。如果检测到这种匹配(具有某种最小置信水平)，则可以决定为主机创建单个合并记录；否则，可以认为两个数据集指的是两个不同的主机，并且可以生成单独的合并记录。在单个合并记录内，可以并入从一个或两个数据集获得的<属性：值>对的某个子集。例如，可以丢弃冗余/重复的属性值，某些属性值可能不包括在合并记录中，因为它们包含的信息可从所包括的其他属性值推导出，或者因为知道相同数据的更准确的数据源。取决于数据集中包括的数据种类，在某些情况下，可以更新现有合并配置记录的一个或多个元素或属性值(或将新属性添加到现有合并配置记录)，而不是生成新的合并配置记录。

合并配置记录350通常可以提供比本可能从任何单个原始配置数据集320获得的更完整的配置项表征。合并配置记录350可以包括用于配置项的唯一的服务侧识别符352，其在所示实施方案中可以与原始数据集320中指示的相应数据源侧识别符不同，并且可以至少部分地基于配置发现服务的本体和/或原始配置数据集的元素而生成。在至少一些实施方案中，合并配置记录350可以包括策划属性值列表354，其可能不一定包括与配置项有关的所有属性值列表325的并集。相反，例如，合并/消除模糊部件可以丢弃来自一个或多个数据源的一些属性值，因为所述值是陈旧的(例如，因为所述值已被从其他源获得的相同的基础属性的较新值取代，或者仅仅因为收集值的时间与处理值的时间之间的差异超过阈值)。在一些实施方案中，不同数据源的相应信任分数315(例如，分数315A-315K)也可以或替代地用于确定给定属性值是否将被包括在合并配置记录中。当两个不同数据源提供对应于相同属性的原始数据时，信任分数可能尤其有用：在这种情形中，由具有较高信任分数的源提供的属性值可以占优先。在其中每个原始数据集320具有指示何时收集数据的相关联的时间戳的一些实施方案中，考虑时间戳和信任分数两者(实际上，得到时间加权的信任分数)的公式可以用于选择应将哪些属性包括在策划属性值列表354中。

在一些实施方案中，如果原始数据集320内的一个或多个给定项所关于的配置项不清楚，则配置发现服务的合并/消除模糊部件360可以利用模式匹配方法来识别配置项。例如，考虑一种简单的情形，其中原始数据集320B和320K都对某个配置项在给定时间间隔内的大致出站网络流量进行报告，并且数据集320B包括配置项的主机名称但数据集320K不包括。在这个普通的示例情形中，合并/消除模糊部件360可以试图找到包含在数据集320K中的属性值，所述属性值在相似时间段内与其他数据集中的属性值相匹配。如果出站网络流量速率在数据集320K与320B之间匹配到某个阈值精度或准确度水平，则可以假设两个数据集(在没有任何矛盾证据的情况下)指的是相同基础配置项。

如前所述，在各种实施方案中，可以在配置发现服务处使用多种编程接口。图4示出了根据至少一些实施方案的可以在配置发现服务处实现的示例应用程序编程接口。示出了配置数据摄取接口(用于向服务提供原始配置数据集)的四个示例，并且示出了配置数据消费接口(用于获得针对服务的查询的响应)的一个示例。

在至少一个实施方案中，配置发现服务460可以提供批量导入/导出应用程序编程接口(API)415A，其可以例如用于将大量信息从客户端的配置管理数据库410传送到服务。在至少一些实施方案中，服务可以提供(例如，经由下载)多个不同的软件代理412，软件代理412可以安装在各种物理或虚拟装置处，将要从所述物理或虚拟装置获得配置数据。这类代理可以使用代理API 415B来与服务通信。在各种实施方案中，代理412中的至少一些可以收集关于特定事件的数据(例如，每X秒一次，可以在服务器处调度CPU利用率收集事件)，并且因此与经由导出/导入API 415A传送的数据量相比，经由代理的API 415B一次发射的数据量可能相对较小。

在一些实施方案中，配置发现服务可以接受来自多种配置工具414的原始配置数据，配置工具414包括例如利用简单网络管理协议(SNMP)、Windows管理规范(WMI)或WBEM(基于网络的企业管理)的示例工具。可以实现工具特定API 415C以用于这类工具与配置服务发现之间的交互。还可以为在一些实施方案中可能被开发和部署的定制数据源416(即，本身不是代理，不与第三方配置工具相关联并且不附属于客户端配置管理数据库的数据源)实现通用报告API 415D。

可以为消费发现服务的合并配置信息的实体实现许多不同的查询API 416。这种实体可以包括提供商网络的其他服务，诸如可视化服务和/或一个或多个迁移相关的服务，包括迁移市场服务或迁移计划服务，以及配置发现服务所处的提供商网络的客户。一些查询API 416可以利用诸如结构化查询语言(SQL)的众所周知的查询语言的变体。在一个实施方案中，面向时间序列的查询语言(诸如OpenTSDB支持的语言)可以用于时间配置相关的查询。

基于模式的分组和角色分配

图5示出了根据至少一些实施方案的可以在发现服务处使用以自动检测配置项所扮演的角色的应用程序架构模式的示例。在各种实施方案中，服务可以支持查询以搜索用以对配置项进行分组的应用程序、软件和/或硬件配置模式。在所示实施方案中，配置发现服务的配置项组描述符数据库590可以包括多个组描述符510，诸如510A或510B。每个组描述符510可以包括相应模式名称577(例如，577A或577B)，诸如“三层网络应用程序”或“分阶段拆分和组合应用程序”，以及共同实现应用程序或一组相关应用程序的各种实体之间的关系的表示。

每个实体可以在应用程序模式内扮演特定的逻辑角色，并且可以在组描述符510中指示期望由分配了不同角色的实体展现的通信行为。例如，组描述符510A定义了四个角色：负载平衡器(LB)角色511、网络服务器角色512、应用程序服务器(App服务器)角色513和数据库服务器(DB服务器)角色514。在对应于描述符510A的一组配置项的实例中，诸如511A-511C的一个或多个负载平衡器可以经由网络数据包与诸如512A-512N的一个或多个网络服务器交互。网络服务器512中的每一者还可以与一个或多个应用程序服务器513(例如，513A-513K)交互，并且每个应用程序服务器又可以与诸如514A-514J的一个或后端数据库服务器交互。在组描述符510B中，角色可以包括：负责将任务细分为子任务的任务拆分器551，负责执行子任务的阶段1工作者552，负责收集阶段1任务的结果以及分割结果以用于阶段2分析的阶段1结果组合器553，负责分析分割的结果的阶段2工作者554，以及搜集阶段2分析的结果的最终结果组合器555。对应于至少一些角色的配置项的具体数目从一组实例到另一组实例可以不同。例如，尽管单个任务拆分器、阶段1结果组合器和最终结果组合器实体可以在对应于描述符510B的配置项组内实例化，但是配置为阶段1工作者或阶段2工作者的配置项的数目从描述符的一个实现方式示例到另一实现方式示例可以不同。

在一些实施方案中，发现服务的客户端可以经由编程接口向服务提交描述符510的表示，并且服务可以识别展现描述符中指示的模式的配置项的对应示例。给定描述符510可以包括分布式应用程序的各方面的指示，诸如与应用程序相关联的配置项的预期互连拓扑、与应用程序相关联的预期项名称列表(例如，进程名称或路径)，和/或与应用程序相关联的一对配置项之间的预期通信模式(例如，表示特定类型的请求-响应行为或初始化/终止握手程序的数据包的交换)。服务可以设法将观察到的各种配置项的行为与描述符元素进行匹配，以确定配置项扮演的角色。例如，在图5所示的实施方案中，使用从各种数据源收集的配置数据，服务可能已经确定由合并配置记录580A表示的具有唯一的服务侧识别符582A的配置项正在扮演由项组ID 586A识别的组模板中的一者的特定实例(例如，四层网络应用程序的实例1)内的项组角色ID 588A指示的角色(例如，网络服务器角色)。其他配置项，诸如由合并配置记录580B表示的项，可能不一定扮演与任何给定模式或组描述符相关联的角色；在所示实施方案中，可以将用于这种配置项的字段项组角色ID和项组ID设置为空。在一些实施方案中，用于项组角色ID和项组ID的标签可以用作指代扮演相同角色或展现相同行为模式的多个配置项的“标签”。这些标签可用于识别发现服务的客户端所请求的各种操作的操作数-例如，查询的逻辑等效物“列出数据中心DC1中具有标签′网络服务器′的所有配置项”或命令“起始数据中心DC1中具有标签‘DB服务器’的配置项到数据中心DC2的自动迁移”可以由客户端发出。在一些实施方案中，客户端可以以编程方式指定各种配置项的标签，并且这些标签可以由发现服务使用以接着识别更大的模式或组描述符。在一个实施方案中，由发现服务的一个客户指示的模式和/或标签可以由发现服务使用(例如，在提供模式/标签的客户的许可下)以用于在其他客户的配置项之间分组并分配角色。

混淆的网络流量源的自动检测

在许多应用程序中，诸如网络地址转换(NAT)装置、端口转换装置等的联网中介有时可以一定方式修改网络数据包，使得给定数据包的真实源可能不可由与那些数据包的目的地相关联的配置数据源直接检测到。图6示出了根据至少一些实施方案的在配置发现服务处对网络数据包使用源身份检测算法。这种源身份检测算法在本文中也可以被称为源端点检测算法。如所示，在所示实施方案中，可以经由一个或多个地址混淆中介612将来自流量源端点610(其可以在发现服务中表示为配置项)的数据包集622发送到流量目的地端点628。地址混淆中介还可以用于反向流量，例如，从端点628到端点610。目的地端点和源端点两者都可以具有与其相关联的负责将配置数据发射到发现服务的一个或多个配置数据源。然而，由于一个或多个中介612执行的混淆操作(例如，数据包报头改变、包封数据包内的封装等)，附属于目的地端点628的数据源可能不清楚所接收的数据包集623(其对应于发送的数据包集622)的发送者的身份。从在端点610和628处被代表使用发现服务的客户的角度来看，或从获得有关一个或两个端点的配置信息的另一服务(例如，迁移相关的服务)的角度来看，发现发送者的身份可能很重要。

发现服务可以采用多种技术中的任一者来识别所接收的数据包集623的发送者端点。在其中命令可以从服务发出到的相应数据源在两个端点处运行的至少一个实施方案中，可以经由一个或多个混淆中介612从端点628向端点610发出特殊数据包序列655以作为端点检测算法的一部分。例如，可以由与端点628相关联的数据源以数据包序列655发出间隔开恰好T毫秒的N个“额外”数据包(不是正常应用程序流量的一部分)，并且包括端点610的各种其他端点处的数据源实际上可以监视传入流量中的这种完全间隔的数据包。假设沿着端点之间的路径没有联网瓶颈或问题，则端点610处的数据源可能将所接收的额外数据包的到达间隔时间与端点628处的数据源的发射间时间进行匹配，从而以合理的高概率确认数据包集623的发送者的身份。在一些实施方案中，虽然可以在中介612处对各种数据包的IP地址和/或端口进行模糊处理，但是可以不修改数据包的序列号，并且可以分析数据包的序列号以在接收者和发送者的数据源处进行匹配以在端点检测算法中识别数据包的源。在一个实施方案中，可以从端点628向端点610发出连接建立请求迅速跟随连接拆除请求的序列，并且这种不寻常的管理请求模式可以用于在端点检测算法中识别数据包源。在一个实施方案中，诸如在端点628处运行的服务代理的数据源可以向在端点610处运行的数据源(诸如另一服务代理)发出对服务侧唯一的服务侧识别符的请求，并且该唯一的服务侧识别符可以用于识别发送者。无论用于检测发送者的特定端点检测算法如何，在已经识别发送者之后，在各种实施方案中可以更新指示发送者的身份的合并配置记录。

相关性分数

图7示出了根据至少一些实施方案的可以在配置发现服务处使用以将相关性分数分配给配置项的示例因素。相关性分数可以用于至少确定针对配置项的查询的初始响应-例如，对诸如“列出在主机H1处运行的进程”的一般查询的响应可以包括已被分配高于阈值的相关性分数的进程，从而减小了响应的总大小并且避免了噪声或低信息响应。尽管图7中示出的具体示例因素适用于进程，但是在各种实施方案中也可以关于其他类型的配置项采取类似方法。

给定物理或虚拟化计算服务器可以包括数百个进程，包括许多低级或后台进程，所述进程通常不消耗许多资源并且用于(例如，在操作***级或内核级)执行后台任务或响应于异常情况。许多这种进程可以存在于给定版本操作***的所有实例中-例如，在包括五十个Linux服务器的执行环境中，类似的一组守护进程可以在所有五十个服务器处运行。配置服务的数据的至少一些消费者可能对应用程序特定的进程更感兴趣，并且因此在默认情况下不一定出现在每个服务器的进程列表中。因此，配置服务可以在其相关性分数分配算法710中考虑在不同主机或服务器处的给定频率的重复频率712，其中在每个主机(或几乎每个主机)处运行的那些进程被分配较低的相关性。在所示实施方案中，进程的资源使用级别，诸如最近的CPU使用714、网络端口使用716(例如，无论所述进程是经由一个或多个网络端口发射还是接收流量)和/或I/O装置使用718可以各自与相关性分数正相关-例如，倾向于消耗非常低级的资源和/或与网络断开的那些进程可被认为是低相关的。在至少一些实施方案中，配置发现服务可以跟踪特定地针对给定种类的进程的查询(例如，来自给定客户端、客户端集合或所有客户端/消费者)(例如，针对名称为“httpd”的进程的查询)的数目。查询历史度量724还可以用于确定进程的相关性-例如，如果在先前的X天内已存在通过名称或角色专门针对进程的查询，则可以将高相关性分数分配给所述进程。

在所示实施方案中，由算法710生成的相关性分数可用于将进程分类或排名为至少两个类别-在所示实施方案中为具有高于选定阈值的分数的“令人较感兴趣的”进程730，以及具有小于或等于阈值的分数的“不太令人感兴趣的”进程732。在所示实施方案中，除非给定的进程相关的查询指定将所有进程都包括在响应中，或者特别请求关于恰好被归类为“不太令人感兴趣的”进程的特定查询的信息，否则可以使用令人较感兴趣的进程的列表来准备查询响应。在至少一些实施方案中，类似的启发式方法可用于清除或缩短对关于其他类型的配置项的查询的响应。在各种实施方案中，图1中示出的评分部件112可以利用机器学习技术来生成相关性分数、信任分数等。

提高配置查询性能

发现服务的许多客户可能具有大型应用程序执行环境，所述环境可能包括分布在多个数据中心中的数千个配置项。与旧的配置数据相比，最近对应用程序部件的配置的改变，和/或应用程序部件的性能或行为的最近趋势通常令这类客户更感兴趣。随着时间的推移，在给定应用程序执行环境内在发现服务处收集和存储的配置数据的总量可能变得非常大，从而可能减慢查询响应，尤其是对于某些传统数据模型可能未被优化的时间查询。图8示出了根据至少一些实施方案的可以在配置发现服务处采用以改进对时间查询的响应的技术的概述。

由数据源802获得的原始配置数据集871可以在发现服务的合并部件804处使用，以生成或更新带时间戳的合并配置记录872，每个合并配置记录872与如先前所讨论的配置项的一个或多个唯一的服务侧识别符相关联。在所示实施方案中，合并配置记录872可以存储在自动缩放的分区数据存储区820中，其形成一组持久性发现服务存储库810的一部分。在一个实现方式中，每个分区可以包含选定的最大量的配置记录数据，诸如M千兆字节，其中发现服务的每个客户端最初被分配一个分区。当客户端的配置数据接近客户端的现有分区的最大分区大小时，可以为客户端自动创建具有一组相关联的资源(例如，分派的存储空间和/或计算容量)的新分区，并且在一些实现方式中，可以将客户端数据的某个子集移动到新分区以进行负载平衡。在一些实施方案中，由提供商网络实现的数据库服务和/或存储服务可以用于持久性存储库810。在一些实施方案中，持久性存储库还可以包括用于先前生成的查询结果的任选存储区822。持久性存储库810可以具有用于记录检索的平均等待时间L1。

在图8所示的实施方案中，至少一些配置记录可以被主动预加载到针对某些预期类型的查询而优化的低等待时间存储库850中，如箭头875所示。在各种实施方案中，记录可以各自包括创建和/或最近修改时间戳。在至少一些实施方案中，可以以反向时间顺序加载记录，例如，将较高优先级分配给预先加载的更近地更新的(或更近地创建的)记录。从存储库850访问记录的平均等待时间L2可以小于对存储库810的记录访问的等待时间L1。在至少一些实现方式中，存储库850可以包括在发现服务的各种计算装置处的易失性存储器的被指定用于处置客户端查询部分，所述客户端查询包括主要针对最近的配置数据的时间或时间序列查询。在一些实施方案中，存储库850处的配置数据高速缓存852可以实现专门针对时间查询(例如，“列出在最后一小时中在服务器S1和S2处发生的配置变化”的逻辑等效物)的数据模型，诸如OpenTSDB中使用的数据模型。在至少一些实施方案中，可用于高速缓存852的最大空间可以小于持久性记录存储库处可用的空间，并且因此可以根据需要丢弃较旧的高速缓存条目892以为较新的条目腾出空间。在至少一些实施方案中，一些查询的结果可以可选地存储在查询结果存储区822中，并且可以根据需要重新使用，如箭头877所示。

在一些实施方案中，可以使用除了图8中所示的之外的额外存储层-例如，后端冷存储层可以用于已经达到阈值年龄(诸如一个月或六个月)的配置数据。与主要持久性数据存储库相比，这种冷存储层可以具有较低成本(并且在一些情况下针对数据使用更有空间效率的格式)；然而，从冷存储装置中检索记录的等待时间可能更多。在至少一些实施方案中，可以由配置发现服务实现一组基于快照的编程接口(或其他面向时间的编程接口)，以使得能够从所使用的不同存储层中的任一者检索对应于指定时间戳或时间段的配置记录。在一个实施方案中，可以自动地或按需要创建并存储客户端配置数据在不同时间点的相应快照作为发现服务的不同对象，这可以实现对至少一些基于时间的配置查询的快速响应。在各种实施方案中可以根据需要(或者在预期需要时)将对应于各个时间点的快照从其他层加载到高速缓存852中。在一个实施方案中，基于快照的API可以使客户端能够确定两个快照配置是否足够相似以使比较有用，并且如果是，则提供这种比较的结果(在概念上类似于配置快照级别处的“diff”命令的结果)。

支持配置发现服务的方法

图9是示出根据至少一些实施方案的可以在配置发现服务处执行的操作的各方面的流程图。如元素901中所示，可以确定将在发现服务处起始来自客户端的一个或多个应用程序执行环境的配置信息的自动发现。执行环境可以包括一个或多个提供商网络处(例如，在实现发现服务本身的相同的提供商网络以及在其他提供商网络处的虚拟计算服务和/或存储服务处)和/或在客户拥有或客户管理的驻地处的资源。可以例如响应于经由发现服务的编程接口从客户接收的请求而确定将起始自动发现。例如，该服务可能会暴露开始数据收集API，所述API可以使服务的代理起始自动发现。例如，代理可以被配置为向API轮询状态变化。当发现服务改变数据库中的状态以开始收集数据时，代理可以接收该状态更新并开始收集数据。

可以例如通过发现服务代理来识别一组初始的配置数据源(元素904)，并且可以在发现服务与数据源之间(例如，经由代理)建立网络连接。可以使用各种数据源，例如，包括客户端的现有配置管理数据库、第三方配置管理和/或性能管理工具，和/或专门为客户端生成的定制数据源。所述服务可以实现编程接口以从不同类别的数据源接收原始配置数据集，所述数据源包括批量导出/导入接口、用于事件驱动的配置更新的接口等。代理可以被配置为将数据发送到编程接口。例如，可以使用识别编程接口的端点的信息对代理进行编程。

所述服务可以开始从数据源收集原始配置数据集(元素907)。每个数据集可以包括用于相关联的配置项的某组属性值和一些识别信息(例如，由数据源获得的识别符)。在所示实施方案中可以例如基于组合数据源侧识别符、属性值和/或在发现服务处定义的本体的元素的命名方案为各种配置项创建唯一的服务侧识别符(元素910)。服务侧识别符可以与数据源提供的识别符中的至少一些不同，并且在一些实施方案中可以用于在其生命周期内唯一地识别诸如服务器的配置项，即使配置项被物理地移动、重新部署用于不同目的等等。在一些实施方案中，取决于应用于特定配置项的配置变化的程度，发现服务可以随时间修改唯一的服务侧识别符。用于改变服务侧识别符的阈值条件从一类配置项到另一类配置项可以不同。在一个示例情形中，例如，如果将存储器或磁盘空间添加到主机，则主机的服务侧唯一的识别符可能不会改变，但是如果交换出CPU或母板，则唯一的识别符可能改变。

在所示实施方案中，可以在发现服务处合并来自各种数据源的原始配置数据集，所述原始配置数据集可以包括关于相同基础实体的不同粒度、不同时间或使用不同工具的配置细节(元素913)。在一些实施方案中，原始数据集可能不使用公共识别符来识别配置项(例如，可以为相应的原始配置数据集中的相同配置项提供不同的数据源侧识别符)，并且服务可以利用从不同源接收的各种属性值之间的相关性或匹配来检测两个不同数据集中的配置数据实际上是指相同配置项。可以生成合并配置记录并且将其存储在发现服务的一个或多个持久性存储库中。

在至少一些实施方案中，相应的信任分数可以与不同数据源相关联，并且这种信任分数可以用于解决报告的配置数据之间的冲突，和/或任选地丢弃从不太可信的源接收的一些属性值(元素916)。因此，合并的策划配置记录可以排除原始配置数据集中指示的属性值的某个子集。除了由于信任分数而排除之外或替代于由于信任分数而排除，可以由于陈旧性(例如，因为自收集值以来已过去的时间超过在服务处选择的阈值)而排除一些属性值。可以例如使用机器学习技术和/或客户端反馈随时间调整信任分数本身。

在各种实施方案中，发现服务可以维护用于根据应用程序模式对配置项进行分组的描述符。如果配置项的行为和/或通信模式与这种描述符中指示的行为或模式相匹配，则服务可以用对应的角色识别符自动标记配置项的配置记录(元素919)。例如，服务处收集的配置数据(例如，网络数据包流的模式)可能足以使服务辨识出特定服务器是多层网络应用程序模式的网络服务器，另一服务器是该模式的应用程序服务器等等，而无需客户端告知服务器扮演的角色。

在一些实施方案中，合并和策划的配置记录的至少一部分可以从存储它们的原始持久性存储库预加载到低等待时间存储库中，在该低等待时间存储库中实现适合于预期类型的查询的数据模型(元素922)。低等待时间存储库可以包括高速缓存(例如，在易失性存储器中实现)，在一些实施方案中可以从所述高速缓存提供对时间查询的快速响应。在一些实施方案中，可以以反向时间顺序(使用合并记录的更新时间戳)预加载数据，使得将针对更近的改变或度量的查询列入优先。可以响应于经由发现服务的编程接口接收的查询来提供合并记录的内容(元素925)。

已发现配置信息的可视化服务

图10示出了根据至少一些实施方案的可以实现在发现服务处搜集的配置记录的可视化服务的示例***环境。如所示，***1000包括提供商网络1002A和1002B，以及客户驻地网络1072。许多网络可访问的服务，包括与上文在图1到图9的上下文中描述的类似的配置发现服务1004可以在提供商网络1002A处实现。在所示实施方案中，可视化服务1006可以实现为配置发现服务1004的部件，例如以提供存储在发现服务1004处的配置数据的定制图形表示。在其他实施方案中，可视化服务1006可以实现为从发现服务1004获得配置记录的独立服务。

在所示实施方案中，***1000包括许多配置项1036，包括在提供商网络1002A处的配置项1036A-1036C、在提供商网络1002B处的配置项1036F-1036H，以及在客户驻地网络1072处的配置项1036L-1036N。可以在各种配置数据源(CDSres)1034处获得与配置项相关联的原始配置数据集(例如，属性值集)，所述配置数据源诸如提供商网络1002A的数据源1034A和1034B、提供商网络1002B处的数据源1034K，和客户驻地网络1072处的数据源1034M。可以将原始配置数据集发射到配置发现服务1004，其中可以如前所述从原始数据生成合并配置记录并且将其存储在一个或多个存储库中。

在所示实施方案中可视化服务1006可以向客户端提供复杂应用程序环境的配置的动态更新的上下文敏感的图形表示。当给定客户端登录可视化控制台或以其他方式发送需要客户端的应用程序执行环境的图形表示的指示时，可视化服务可以使用发现服务的编程接口发出一个或多个查询以识别与客户端相关联的一组配置项，将为所述客户端显示配置数据。配置项1036的集合在本文中可以被称为可视化目标环境(VTE)，将在给定客户端侧显示环境下代表客户端可视化针对所述配置项1036的信息。给定VTE可以包括分布在不同网络的多个数据中心中的配置项。例如，客户端C1的VTE 1044A可以包括在提供商网络1002A的一个或多个数据中心处的配置项1036B和1036C，以及在提供商网络1002B的一个或多个数据中心处的配置项1036F和1036G。在所示示例中，客户端C2的VTE 1044B可以包括在提供商网络1002B处的配置项1036H和在客户驻地网络1072处的配置项1036L。

在至少一些实施方案中，可视化服务1006可能能够检测将要示出VTE的图形表示的显示环境的各种性质或约束(例如，可用于显示器的屏幕的种类、负责呈现显示器的客户端侧装置的计算能力等)，并相应地调整将要显示的内容。给定客户端可能能够利用若干不同的显示环境-例如，客户端C1的显示环境1082A包括具有多个监视器的桌面，而客户端C1的显示环境中的另一者1082B可以包括平板计算装置。客户端C2的显示环境1082C包括具有1084x768像素屏幕的13英寸膝上型计算机。在一些情况下，可以代表单个客户端同时使用多个显示环境，并且可视化服务可以将不同粒度级别的信息发射到不同的显示环境。

至少部分地基于已被识别为给定客户端的VTE 1044的一部分的一组配置项，并且至少部分地基于显示环境的约束或特性，可视化服务可以选择将显示VTE的粒度级别。在客户端与可视化服务的交互式会话期间，可以提供客户端的配置信息的各种子集(或全部)的多个不同视图，其中取决于客户端在会话内的目标而提供视图的特定组合或序列。例如，在一个会话期间，客户端可能希望对性能问题进行故障排除，在另一会话期间，客户端可能希望查看应用程序配置在某个时间段内的变化，在第三会话期间，客户端可能希望识别网络数据包的源等等。这种会话或工作流程可以各自包括图形显示或视图的相应序列。在所示实施方案中，可视化服务可以支持显示配置数据的几种不同模式，其可以被称为“视图类别”，诸如例如分层或面向树的视图、图形或面向网络的视图，或表视图。在至少一些实施方案中，可以由可视化服务自动选择在给定会话期间用于给定显示的特定视图类别。所述选择可以至少部分地基于被认为与会话或工作流程的当前状态最相关的特定类型的配置数据(例如，性能测量、网络连接信息、配置的时间变化、配置项之间的分层/包含关系、特定类型的配置项基于客户端特定的准则的排名等)，和/或至少部分地基于服务关于客户端目标的预测或预期。在需要时可以向客户端提供控制元件(例如，按钮、下拉菜单等)以覆盖视图类别选择-例如，客户端可以发出将视图从表视图改变为分层视图的请求或者反过来。可以将可用于生成动态定制配置可视化1022(例如，可视化1022A-1022C)的数据和/或指令以及将要使用的视图类别一起发射到客户端的显示环境的装置，每个配置可视化1022表示选定粒度级别的VTE的至少一部分。然后可以呈现对应于VTE部件的数据以供在客户端的装置处查看。在至少一些实施方案中，可视化服务可以并行地起始相同VTE的若干不同表示的显示。

在至少一些实施方案中，除了起始VTE 1044的全部或一部分的图形表示的生成之外，可视化服务还可以提供将包括在客户端的仪表板中的高优先级或高重要性内容。可视化服务可以例如确定时间窗口的边界，并且使得关于在时间窗口期间发生的至少一些配置变化的信息显示在仪表板的“最近变化”部分中。在各种实施方案中仪表板还可以用于接收关于由可视化服务和/或发现服务识别的模糊的客户端反馈，如下文进一步详细描述。在至少一些实施方案中，还可以基于客户端的显示环境的约束和能力来修改仪表板的布局和呈现。

当在发现服务1004处搜集新配置信息时，可视化服务可以自动更新提供给客户端的图形表示。可以使许多交互控件在视觉界面中对客户端可用，所述交互控件诸如用于重放随时间而变的配置信息的滑块，如下文进一步详细讨论。

基于上下文的视图转变

在各种实施方案中，可视化服务可能能够预见用于查看配置数据的客户端工作流程的步骤，并自动调整所显示的内容以提供最有用的视图。图11示出了根据至少一些实施方案的可以由可视化服务自动实现的视图之间的示例性基于上下文的转变。示出了三个示例视图类别：表视图1120A、树或分层视图1120B，以及图形或网络视图1120C。在一些情况下，可能可以使用视图类别中的一些或全部来显示关于同一组配置项，诸如配置项1102A-1102F。

在所示实施方案中，可视化服务可以基于各种因素-例如，基于预期接下来将由客户端录入的交互工作流程的特定阶段，基于将要显示的配置数据的类型、为显示选择的粒度等等来选择将要使用的特定视图类别。在各种实施方案中可用于选择视图类别的配置数据类型的示例除了其他之外可以包括性能测量、事务流、配置的时间变化、诸如活动连接的数目的网络连接指示符、包含/分层关系信息、配置项的基于位置的分组、诸如图5所示的应用程序模式中的成员资格等。在至少一些实施方案中，这种自动的基于工作流程上下文的转变1105(例如，转变1105A-1105C)可以由客户端覆盖-例如，可以为客户端提供所使用的图形界面的链接或其他控制元件以请求改变用于显示的数据的视图类别。

在至少一些实施方案中可视化服务可以维护常用客户端工作流程的知识库，其中每个工作流程表示通常在与可视化服务的会话期间提供给客户端以实现客户端的目标的相应显示序列。例如，一个这种工作流程可以从客户端登录可视化控制台开始，并且被提供选定类型的配置项(诸如用于客户端应用程序的所有主机)的表视图。在表视图中，可以为不同主机提供各种属性(例如，主机名称、IP地址、当前运行时间、最近时间间隔内的平均CPU利用率、最近时间间隔内消耗的平均网络带宽等)的值等。在一个实现方式中，可以例如在客户端的偏好设置中指示在客户端登录之后最初将以表形式呈现的特定配置项类型。如果客户端没有为初始登录后显示指定偏好，则在一个实施方案中，可视化服务可以试图找到与客户端的可视化目标环境相关的最大或最具包括性的分层配置项类型(例如，其中分布了客户端资源的数据中心、客户端使用的网络子网、类似于图5中所示的应用程序模式的实例，或主机)，并且列出该类型的配置项。

可以基于客户端与第一显示的交互(其可以被解释为客户端在工作流程中的目标的指示，例如，基于与先前使用的工作流程的匹配)来选择用于工作流程的下一显示的视图类别。如果第一显示包括主机信息表，并且客户端请求基于网络带宽使用度量对主机进行分类，例如，服务可以假设客户端希望在下一显示中查看网络连接信息。因此，接下来可以显示一组选定主机的网络视图，从而指示例如主机之间的网络路径、主机之间打开的连接等等。假设客户端希望查看包含的配置项，如果第一显示包括诸如可用容器或数据中心的分层容器的列表，并且客户端点击容器中的一者，则可以选择分层或树视图类别以用于下一显示。在各种实施方案中，对于自动视图类别选择可以考虑除了将要显示的配置数据的类型以及与先前使用的工作流程的匹配之外的若干因素：例如，在工作流程的给定阶段可获得的信息所针对的客户端配置项的总数目、客户端的显示环境的预期大小(例如，以像素为单位)等等可能影响类别视图选择。例如，如果客户端的应用程序使用一千个主机，并且智能手机被检测为客户端的显示环境，则可以提供主机的分层或概括视图(例如，基于数据中心位置，或基于子网成员资格)而不是所有一千个主机的表视图。在一个实施方案中，客户端可以请求保存他们与可视化服务的交互的记录(在某些情况下其可以包括对自动视图类别选择决定的客户端覆盖)，并且这种定制记录可以用于在后续会话中选择视图类别。

示例可视化界面部件

如前所述，可视化服务可以提供一个或多个应用程序执行环境的至少一部分的图形视图，以及仪表板。图12示出了根据至少一些实施方案的可视化服务的图形用户界面的示例元素。如所示，在所示实施方案中，可视化界面1202可以示出可视化目标环境1205的一部分或全部和仪表板1270。在一些实施方案中，图形用户界面可以呈现为浏览器的一部分，而在其他实施方案中，可以采用独立的工具。

VTE部分1205可以示出配置项的多个基于位置的分组。在所示示例中，关于在提供商网络1220和客户拥有的数据中心1230处发现的配置项的信息包括在VTE部分中。在至少一些实施方案中，提供商网络可以被组织成多个地理区域，并且每个区域可以包括一个或多个可用性容器，所述可用性容器也可以被称为“可用性区”。可用性容器又可以包括一个或多个不同位置或数据中心中的一部分或全部，所述位置或数据中心以一定方式设计(例如，具有独立的基础设施部件，诸如电力相关设备、冷却设备或物理***件)，使得给定可用性容器中的资源与其他可用性容器中的故障隔离。不可期望一个可用性容器中的故障导致任何其他可用性容器中的故障；因此，给定资源的可用性概况旨在独立于不同可用性容器中的资源的可用性概况。因此可以通过在相应的可用性容器中启动多个应用程序实例来保护各种类型的服务和/或应用程序以免在单个位置处出现故障。对于至少一些提供商网络客户，提供分派给客户的资源在不同可用性容器中的分布的视觉表示可能是有用的。在图12所示的情形中，分派给客户的虚拟机分布在至少两个可用性容器中。虚拟机(VM)1222A和1222B在提供商网络1220的可用性容器1210A内运行，而VM 1222K和1222L在第二可用性容器1210B内运行。

例如基于关于位置细节的不同许可，由可视化服务关于提供商网络显示的基于位置的组有时可能与关于客户驻地网络显示的组不同。例如，虽然将虚拟机1222示出为按可用性容器分组，但是按房间和服务器机架对客户拥有的数据中心1230内示出的资源进行分组。数据中心1230的房间1214包括客户的VTE的两个机架1232A和1232B。机架1232A包括两个服务器1234A和1234B，而机架1232B包括服务器1234C。还可以显示在配置项之间建立的网络连接-例如，VM 1222A被示出为连接到服务器1234A和VM 1222K，VM 1222B连接到VM1222L和服务器1234K等等。可以由虚拟化服务例如基于配置项的总数目、显示环境性质等等自动选择基于位置的分组的粒度。在至少一个实施方案中，可以从包括例如提供商网络的可用性容器边界、数据中心边界、机架边界、房间边界、网络互连拓扑边界、物理机边界、处理容器边界或虚拟机边界的集合中选择将自动(不接收这样做的明确请求)包括在特定图形表示中的基于位置的边界类别。例如，可以在单个硬件主机处支持与各个隔离的应用程序集相对应的多个处理容器，并且对于某些视图可视化服务可以提供服务器内的容器的图形表示。

在所示实施方案中仪表板1270可以包括两种类型的信息：最近的配置变化(在部分1271中在选定时间窗口内示出)，以及消除模糊部分1272。在所示实施方案中，可以对在最近的时间窗口中发生的配置变化进行排名(例如，基于上文讨论的种类的相关性分数和/或基于其他因素)并且在部分1271中按顺序或排名显示所述配置变化。这可以使客户端能够快速理解其应用程序执行环境如何变化。

在一些实施方案中，配置发现服务可以利用可视化界面来获得客户端反馈以有助于确认或解决关于配置项的身份的问题。如果确定将起始特定配置项的身份的基于客户端反馈的消除模糊，则可以在界面的部分1272中示出消除模糊请求。例如，请求可以用请求确认所提出的身份的符号(例如，问号或文本批注)来指示配置项的提出的身份和/或一个或多个属性值。客户端可以通过录入反馈(例如，复选标记)来确认身份，或者提供替代识别符或名称。在所示实施方案中，如果在客户端的反馈的帮助下解决了模糊身份，则配置发现服务可以更新(或标记为已验证)其配置记录，并且可以从部分1272中移除消除模糊请求。

在一些实施方案中，可视化服务可以使客户端能够检查与配置发现服务所识别的各种类型的事务相关联的细节(例如，等待时间)。图13示出了根据至少一些实施方案的可以在可视化服务的帮助下显示的事务相关的信息的示例。如所示，可视化界面1302可以包括“示出事务”控制元件1350(例如，按钮)以及使客户端能够增大或减小显示信息的粒度的缩放控制元件1349。缩放控制元件1349可以用于例如达到某一粒度级别，以该粒度级别示出了个别虚拟机1322(在提供商网络1320内)和服务器1334(在客户拥有的数据中心1330内)。当客户端点击“示出事务”按钮时，可以更新显示以示出区域1370A和1370B。区域1370A示出了在某个时间段(在该示例中为100秒)期间将对12500个事务(其中事务的定义可以是服务选择或客户端选择的)的请求从客户拥有的数据中心的房间1314的机架1332A处的服务器1334B发射到提供商网络1320的可用性容器1310B的虚拟机1322K。平均吞吐量为每秒12.5个事务，并且平均事务等待时间或响应时间为500毫秒。类似地，区域1370B示出了从服务器1334K提交到虚拟机1322B的事务的计数、吞吐量和等待时间。

在所示实施方案中，最近的事务列表1385可以包括在显示中。对于与可视化目标环境的当前显示部分相关联的一些最近事务，诸如提交者配置项1387(例如，自其起始事务的进程或主机)的识别符、响应者1388、提交时间戳1389、事务命令/请求细节1390，以及完成时间和状态(例如，进行/中止)1391的细节。客户端可能能够使用可视化界面基于选定属性对最近的事务进行分类，请求显示选定时间段的事务，和/或查看关于事务发送者或事务响应者的额外细节。在一些实施方案中，客户端可以经由可视化服务提交事务描述符(例如，指示数据包流序列、事务请求和响应的格式等)，从而使得配置发现服务能够在事务发生时监视事务。在其他实施方案中，发现服务可能能够检测各种配置项之间的通信中的频繁请求/响应模式，并且可以使用这些模式来定义事务。

图14示出了根据至少一些实施方案的可以在可视化服务的帮助下显示的网络流量相关的信息的示例。如前所述，情况有时可能是网络流量路径可能包括诸如地址转换器或端口转换器的混淆装置，所述混淆装置使得更难以检测发送一个或多个数据包的真实源。在所示实施方案中，可视化服务可以提供控制元件(诸如控制元件1448)以示出关于在选定配置项(例如，虚拟机1422A)处接收的网络数据包的数目的统计。在所示的示例情形中，区域1470指示在某个选定时间间隔内，在可用性容器1410A和提供商网络1420的虚拟机1422A处接收到总共4500个数据包。

标示为“示出流量源”的控制元件1450可用于经由可视化服务向配置发现服务提交对所接收的数据包的源检测查询。作为响应，发现服务可以采用若干源身份检测算法中的任一者，诸如在图6的上下文中讨论的那些，以断定可能已经经由混淆中介将数据包发射到虚拟机1422A的配置项的可能身份。算法可以包括例如以异常模式发送多个连接建立和拆除请求，密切跟踪数据包到达间隔时间并且将它们与发射间时间进行匹配，监视序列号等。在所示示例中，如区域1471A和1471B中所指示，配置发现服务已将服务器1434A识别为4500个数据包中的500个的可能源，并且将服务器1434K识别为剩余的4000个数据包的可能源。注意，一些数据包的源识别可能不一定需要调用这里讨论的各种身份检测算法：不经过混淆中介的数据包的源可以由配置发现服务简单地从其数据包报头获得。

在一些实施方案中，可视化界面可以包括最近接收的数据包列表区域1485，在该区域1485中可以显示诸如接收时间戳1487、表观发送者IP地址1488、接收者IP地址1489、数据包大小1490和/或序列号1491的细节。客户端可能能够经由可视化界面提供的控件根据需要对最近接收的数据包列表区域1485的内容进行分类和/或重新布置。

图15示出了根据至少一些实施方案的在可视化服务的帮助下使用滑块控制元件以获得随时间过去发生的配置变化的可视化的示例。滑块控制元件1571可以使客户端能够查看其可视化目标环境在各个时间点的状态。在所示示例中，可视化界面1502A示出客户端的目标环境包括从元件1574A中指示的时间点起的五个配置项(提供商网络1520的可用性容器1510A处的CI 1522A和1522B、可用性容器1510B处的CI 1522K和1522L，以及外部数据中心1533处的CI 1522P)。

当例如取决于客户端所使用的显示环境使用鼠标或指尖使滑块向右移动时(如箭头1551所指示)，元件1574A中所示的时间可以前进，并且界面中所示的配置项可能会改变。例如，在对应于元件1574B的时间，界面1502B示出已将两个新配置项添加到客户端的目标环境。配置项1522R已被添加到可用性容器1510B，而配置项1522S已被添加到外部数据中心。在至少一些实现方式中，可以突出显示(例如，暂时以不同颜色示出)新添加的配置项，如箭头1555所指示。在一些实施方案中，可以为基于时间的配置显示提供除滑块之外的交互式控件(例如，无线电式按钮或快进/快退控件)。所述界面还可以提供与时间查询相关联的额外控件，例如以便使客户端能够捕获其可视化目标环境在各个时间点的状态的机器可读快照，以便仅示出在指定时间点的配置差异，以便绘制时间线的变化等等。在各种实施方案中，可视化界面的滑块1571和其他面向时间的控件可以依赖于发现服务的基于快照和/或其他面向时间的API(上文在图8的上下文中所讨论的)。

在一些实施方案中，可视化服务可以提供准许客户端将应用程序部件从一个数据中心或提供商网络迁移到另一数据中心或提供商网络的机制。图16示出了根据至少一些实施方案的使用可视化服务来起始应用程序执行环境的分阶段迁移的示例。在所示情形中，可以在可视化界面1602A中指示标签，所述标签指示应用程序模式内的各种配置项所扮演的角色。例如，基于客户端的配置项之间的交互模式，配置发现服务可能已经识别出多层网络应用程序。在外部数据中心1633处运行的配置项1622Q可能已被识别为多层网络应用程序的网络服务器，而配置项1622R可能已被识别为多层网络应用程序的数据库服务器。可能已经分别为配置项1622Q和1622R生成了标签1674A和1674B。

在所示实施方案中可能已经例如在迁移计划和实现服务处生成了分阶段将多层网络应用程序的部件迁移到提供商网络1620的计划。迁移的每个阶段可以涉及将扮演特定角色(例如，“网络服务器”或“数据库服务器”)的配置项转变到提供商网络。可以使用控件1633A(针对数据库服务器)和1633B(针对网络服务器)查看每个角色的迁移计划细节。可以提供控制元件1675以使客户端能够起始与特定标签相关联的配置项的分阶段迁移。

如果在所示示例中客户端请求迁移标记有用于数据库服务器的标志“DB”的配置项，则在所示实施方案中可视化服务可以以编程方式将对应请求发射到发现服务和/或迁移实现服务。在对应于配置项1622R的数据库服务器已经作为阶段迁移的一部分转变到提供商网络1620的可用性容器1610B之后，可以更新客户端的视图以示出迁移的配置项(标示为1674C)，如界面1602B中所示。

在至少一些实施方案中，可视化服务还可以支持能够关于迁移进行之前和之后的性能比较的接口。例如，在迁移之前的应用程序性能的基线视图(例如，吞吐量、事务等待时间/响应时间等)可以在区域1646中示出，而对应的迁移后性能统计可以在区域1647中示出。如果后性能统计令人不满意，则客户端可以根据需要起始反向迁移(例如，在所示示例中将数据库服务器移回到外部数据中心)。

在一个实施方案中，可视化界面可以由客户端使用来直接指定与应用程序内的配置项所扮演的各种角色相关联的标签。例如，可以为客户端提供“添加标签”控件以定义新标签或经由接口使现有标签与选定配置项相关联。随着时间的推移，可以累积标签库，并且客户端可以使用可视化界面来检验可用标签，发出关于库的现有标签的标记请求，或者向库添加新标签。实际上，客户端可以使用由可视化服务提供的这种控件关于应用程序模式对发现服务进行“教导”。在客户端使用可视化服务使例如网络服务器标签与一个或多个配置项相关联之后，发现服务可以监视标记项的行为(例如，与其他配置项的网络交互的模式)。发现服务可能能够基于观察到的行为生成启发，其可以用于用与客户端提供的示例相同的标志/标签来自动地标记其他配置项，而无需客户端明确请求这样做。例如，在客户端在实现多层网络应用程序架构的环境内提供了网络服务器或数据库服务器的一些示例之后，发现服务可能能够自己识别实现类似的应用程序架构的其他环境内的其他网络服务器和/或数据库服务器，并且相应地显示自动生成的标签。

支持配置数据可视化服务的方法

图17是示出根据至少一些实施方案的可由可视化服务执行以提供配置记录的图形表示的操作的各方面的流程图。如元素1701中所示，例如，当客户端登录可视化工具或控制台时，或者当客户端经由编程接口发出可视化请求时，可以确定将提供与客户端的一个或多个应用程序执行环境相关联的配置信息的图形表示。应用程序执行环境可以包括分布在一个或多个数据中心中的资源。数据中心中的一些可能是相应提供商网络的一部分，而数据中心中的其他可能位于客户拥有的驻地。使用针对发现服务的合并配置记录的存储库的一个或多个查询，可视化服务可以识别将要显示其信息的一个或多个特定可视化目标环境(元素1704)。在一些实施方案中，可视化服务可以在配置发现服务外部，而在其他实施方案中，可视化服务可以形成配置发现服务的一部分。在某些情况下，可视化服务(或发现服务)的给定客户帐户可能具有与该帐户相关联的若干不同的应用程序执行环境，并且可以查看的一组特定配置项从一个客户端侧显示环境到另一客户端侧显示环境可能不同。例如，从位于客户办公室内的工作站，可以经由可视化而不是从平板计算机访问客户端的应用程序执行环境的较大子集。在至少一些实施方案中，身份和访问管理***可用于确定可提供其显示的配置项的种类。

可视化服务可以识别客户端侧显示环境的各种特性(例如，使用客户端侧装置操作***支持的API)(元素1707)。特性可以包括可用屏幕的数目和大小、将要提供图形表示所在的客户端侧装置的计算能力、可用于服务与客户端装置之间的通信的网络带宽等等。基于可用于可视化目标环境的配置数据量和/或基于显示环境的特性，可以在可视化服务处做出关于将为客户端生成的初始图形表示的一些决定。这些决定可以包括选择将要显示配置信息的粒度(例如，在数据中心级别、可用性容器级别、房间级别、服务器级别等聚集)和将要使用的视图类别(例如，表视图、图形/网络视图或树/分层视图)(元素1710)。

在至少一些实施方案中，可以确定例如将使用可视化界面的仪表板部分突出显示的配置变化所关于的时间窗口(元素1713)。可以在客户端侧显示环境处起始使用选定粒度和视图类别的可视化目标环境的动态更新显示(元素1716)。当新配置数据变得可从发现服务获得时，或者响应于客户端以编程方式发出的请求，可以更新显示(元素1719)。在一个实施方案中，有时可以认为客户端侧显示环境的特性不足以显示客户端请求的信息。例如，可用的屏幕空间可能太小而无法示出客户端请求的细节程度，或者客户端装置可用的网络带宽可能太小而无法在合理的时间量内传送所请求的数据量。在一些这类情形中，例如基于与经由当前客户端侧显示环境实现可视化请求相关联的资源使用的估计，可视化服务可以发射建议以利用离线工具(或与当前使用的不同的客户端侧显示环境)来显示可视化请求中请求的信息。

迁移市场服务

如在图1的上下文中所提到的，在一些实施方案中，提供商网络可以实现一个或多个迁移相关的服务，其中高级目标是使客户能够根据需要将应用程序或应用程序部件从一组物理或虚拟平台转移到另一组物理或虚拟平台，例如，以帮助降低成本、提高应用程序的可用性或弹性、简化管理等。如前所述，发现服务收集的信息可能有助于做出迁移相关的决定。然而，部分由于复杂应用程序堆栈的部件之间的许多相依性，将应用程序从一个环境转变到另一环境的进程有时可能受益于在应用程序拥有者组织内可能无法获得的专业知识。在一些实施方案中，配置发现服务运行所在的提供商网络可以通过实现迁移市场服务充当迁移促进者或专家与应用程序拥有者之间的中介。能够帮助计划和/或实现应用程序或应用程序部件从一组执行平台到另一组执行平台，诸如从客户拥有的数据中心到提供商网络或从一个提供商网络到另一提供商网络的迁移的商业实体在本文中可以被称为迁移促进者或迁移实践者。如果迁移促进者与运营(将要将应用程序迁移至的)一组目标执行平台的实体不同，并且与其应用程序被迁移的实体不同，则迁移促进者可以称为第三方迁移促进者。至少一些迁移促进者可能不被定性为第三方-例如，在一些实施方案中，作为将要向其/自其执行迁移的提供商网络中的一者的一部分(或附属于所述提供商网络中的一者)的专业服务或咨询组织也可以利用迁移市场服务作为迁移促进者的角色。从高层次下，迁移市场服务可以使应用程序拥有者能够了解可以有助于复杂应用程序迁移任务的潜在合作伙伴，并且可以使迁移促进者能够找到客户。在各种实施方案中，迁移促进者可能包括工具提供者(例如，开发可供客户端使用以实现应用程序迁移的迁移工具的独立软件供应商或ISV)、可用于实际地计划和实现迁移而不是如此提供工具的技术专家、专业服务组织、提供商网络运营商的合作伙伴等等。

图18示出了根据至少一些实施方案的可以实现利用在配置发现服务处收集的数据的迁移市场服务的示例***环境。如所示，***1800包括提供商网络1802，在该提供商网络1802处实现多个网络可访问的服务。所述服务包括虚拟化计算服务1810、打包程序执行服务1812、一个或多个存储装置或数据库服务1814、配置发现服务1804、迁移市场服务1806，以及迁移计划和实现服务1808。在所示实施方案中每个服务可以实现一组编程接口，所述编程接口可以用于服务与其客户端之间的交互，并且在一些情况下还可以用于服务间交互。与虚拟化计算服务1810相关联的VCS编程接口1844可用于获取、使用和释放虚拟机。打包程序执行服务1812的PES接口1845可用于提交执行程序的请求，而无需向请求者明确地分派服务器，以及用于接收程序执行的结果。SDS编程接口1846可用于存储和访问与各种应用程序相关联的数据集。如前所述，发现服务1804的CDS编程接口1841可以用于起始配置信息的自动发现，并查看自动发现的结果。迁移计划和实现服务1808的MPIS接口1843可用于生成详细的迁移计划并执行计划。

在所示实施方案中，迁移市场服务1806可以利用图18中所示的其他服务中的一些或全部。迁移市场服务的MMS编程接口1842可以由至少两种类型的实体利用-潜在迁移客户端1834(例如，可以迁移的应用程序的拥有者)和迁移促进者1836。根据一个实施方案，客户端1834可以向迁移市场服务发射请求，以使一个或多个迁移促进者能够至少访问与客户端的应用程序相关联的配置信息的某个子集。将被授予访问许可的配置信息可以例如存储在发现服务1804处维护的存储库的合并配置记录中。如先前所讨论的，客户端1834的给定应用程序执行环境可以包括分布在多个平台中的配置项或资源，例如，包括提供商网络1802外部的一些资源和/或位于提供商网络1802内的一些资源。在一些实施方案中，客户端1834可以请求在将配置细节提供给迁移促进者之前混淆或匿名化配置细节中的至少一些-也就是说，可以准许促进者访问配置信息的某些方面而不向其提供完整的细节。在一些情况下，客户端可以仅允许一组指定的迁移促进者来检查配置信息，而在其他实施方案中，已经由迁移市场服务注册或批准的任何迁移促进者可以被授予访问许可。响应于共享对客户端的配置记录集合的访问的客户端请求，迁移市场服务1806可以起始对配置记录的一个或多个安全设置的修改(例如，在由迁移市场服务本身维护的元数据内，或者在发现服务1804的元数据内)。

在所示实施方案中，迁移市场服务1806可以经由MMS编程接口1842从迁移促进者接收相应的成员资格请求。在至少一些实施方案中，迁移市场服务可以在将迁移促进者注册为市场的授权成员之前起始一组验证程序(例如，以核实促进者的身份和商业背景)。

在所示实施方案中，注册的迁移促进者可以经由接口1842发射迁移候选者匹配请求1837。这类请求可以包括例如对促进者的专业知识或能力的描述(例如，促进者过去帮助进行迁移的应用程序堆栈的种类)和/或促进者更喜欢的迁移客户端的种类的特性(例如，待迁移应用程序执行环境的最小或最大大小、待迁移应用程序执行环境的地理位置或迁移目的地环境等)。可以使用迁移促进者已被授予访问的配置信息在服务1806处生成对迁移候选者匹配请求1837的响应，所述迁移候选者匹配请求1837从发现服务1804的客户端中识别促进者的一个或多个潜在客户。在下文进一步详细讨论的一些实施方案中，迁移市场服务1806可以执行服务生成的算法以找到匹配的客户，而在其他实施方案中，促进者可以供应其自己的可执行代码模块以找到潜在客户，并且促进者供应的代码可以在预先打包的程序执行服务1812或某些其他平台处运行。

迁移促进者1836可以检查关于由服务1806提供的潜在迁移候选者的所提供信息，并且经由接口1842将迁移提议提交给服务1806。该提议可以描述促进者愿意提供的协助的各个方面，包括例如用于迁移应用程序执行环境的指定子集或全部的初步成本估计、初步时间表或实现计划等。在一些实施方案中，如果迁移促进者是提供迁移工具的独立软件供应商而不是对实际实现迁移感兴趣的技术专家，则该工具(其可由客户端用于迁移其应用程序)的名称可以包括在提议中。然后，服务1806可以经由编程接口1842将提议1837的表示发射到潜在迁移客户端1834。在一些实施方案中，服务1806可以接收针对相同潜在迁移客户端1834的给定应用程序环境的许多提议，所述提议中的每一者可以以编程方式提供给客户端。

如果客户端1834发现提议中的一者是可接受的并且希望继续进行详细的迁移计划和/或实现，则在一些实施方案中，可以经由接口1842将批准消息发射到迁移市场服务。响应于这类批准消息，在一个实施方案中，迁移市场服务可以起始操作以例如通过无缝地和以编程方式将进一步迁移交互传送到MPIS接口1842而使客户端1834能够执行迁移计划/实现服务1808的工作流程。因此，在至少一些实施方案中，迁移市场服务1806可能不一定负责迁移的详细计划和实际实现；相反，迁移市场服务1806的主要角色可以包括在开始计划和执行迁移的详细工作之前充当潜在迁移客户端与迁移促进者之间的受信任的信息管道。在其他实施方案中，迁移市场服务可以负责计划和/或协调迁移的至少一些方面的实现。应注意，在一些实施方案中，本文在图10至图17的上下文中讨论的可视化服务也可以与迁移市场服务1806和/或迁移计划/实现服务1808一起使用。在这类实施方案中，可视化服务可以提供一组统一的无缝图形接口，所述图形接口可以用于查看应用程序执行环境配置数据，识别用于应用程序迁移的潜在促进者，以及根据需要计划和实现这类迁移。

与迁移市场服务的编程交互

图19示出了根据至少一些实施方案的客户端与迁移市场服务之间的示例编程交互。如所示，客户端1920可以经由编程接口向迁移市场服务1922的一个或多个计算装置提交发现数据访问许可请求1925。发现数据访问许可请求1925可以包括例如对应于客户端的配置记录集合的一组应用程序环境识别符1928、一个或多个安全约束1931和/或促进者列表1934。促进者列表1934可以指示在需要时将对其公开客户端1920的配置信息的一个或多个特定促进者，或者可以指示可以向任何注册/授权的促进者提供配置信息。安全约束1931可以指示是否对所揭示的配置数据施加任何限制(例如，客户端可能更喜欢不会在个别配置项级别上显示某些类型的配置项的细节，尽管可以揭示聚集信息)，配置信息的哪些方面(如果有)要匿名或混淆等等。

至少部分地基于请求1925的内容，迁移市场服务1922可以例如在市场元数据存储库1955和/或配置发现服务1957处修改与客户端的配置记录相关联的安全设置。可以经由编程接口将指示已经应用所请求的访问许可变化的确认消息1975发射到客户端1920。

图20示出了根据至少一些实施方案的迁移促进者与迁移市场服务之间的第一组示例编程交互。在所示实施方案中，迁移促进者2020可以经由编程接口向迁移市场服务2022提交迁移候选者识别查询2025。查询2025可以包括促进者能力2028的相应描述符(例如，促进者有兴趣为其迁移提供协助的应用程序的类型)和候选者偏好2031(例如，促进者希望协助其迁移的最小和/或最大应用程序配置大小、从促进者的角度看优选的地理区域或位置等等)。

响应于候选者识别查询2025，可以在迁移市场服务2022处准备用于从配置发现服务数据库2040检索匹配的配置数据的过滤器规范2037。在一些实施方案中，配置数据匿名器2034可以参与过滤器规范2037的准备，使得仅检索到潜在迁移客户端经由在图19的上下文中讨论的种类的访问许可请求被准予访问的配置数据的子集。在各种实施方案中，可以使用混淆准则(例如，由潜在迁移客户端提供，或者由迁移市场服务基于启发生成)来准备过滤器以避免破坏客户端配置安全性或机密性。在一个实施方案中，替代于或除了生成过滤器规范之外，配置数据匿名器2034可以处理从发现服务数据库检索的配置数据，以确保不违反潜在迁移客户端指示的任何安全约束。

可以经由服务的编程接口将指示与迁移促进者2020的能力和偏好相匹配的应用程序执行环境和/或客户端的策划候选环境列表2046发射到促进者。促进者又可以向服务2022提交迁移提议的列表2049，其对应于列表2046中指示的候选环境和客户端中的一些或全部。然后，在所示实施方案中迁移市场服务可以经由服务的编程接口将迁移提议2051(例如，2051A和2051B)的表示发射到适当客户端2080(例如，2080A或2080B)。在所示实施方案中提议2051中的至少一些可以包括针对所提出的迁移努力的初步成本估计2054(例如，2054A或2054B)的相应指示。在一个实施方案中，提议2051还可以或替代地包括迁移时间表估计，或指示由与提议相关联的促进者实现的早期迁移的反馈记录(例如，评论或评级/排名分数)。

图21示出了根据至少一些实施方案的迁移促进者与迁移市场服务之间的第二组示例编程交互。图21与图20之间的主要差异在于在图21所示的情形中，迁移促进者可以发射可以被执行以识别与促进者的要求相匹配的迁移候选者的可执行程序代码模块，而不是依赖于迁移市场服务使用服务生成的匹配算法。这种方法可以例如使迁移促进者能够减少关于必须提供给市场服务的促进者的能力或约束的详细信息量，并且还可以减少市场服务开发准确且高效的匹配算法的负担。

在图21所示的实施方案中，迁移促进者2120向迁移市场服务2122提交包括可执行的候选者匹配算法代码模块2128的指示的迁移候选者识别查询2125。在一些实现方式中，查询2125可以包括要在其上运行候选者匹配代码模块2128的执行平台或服务的某种指示。服务2122将代码2128发射到选定执行服务2175(例如，图18的打包程序执行服务1812)。使用打包程序执行服务可能具有以下益处：可能不必为迁移促进者预先分派资源；相反，打包程序执行服务可以简单地从平台池中找到可用的执行平台，在该平台上运行模块并提供执行结果。迁移促进者可能只负责实际用于执行模块的计算资源。在一些情况下，可以使用其他执行平台，诸如提供商网络的虚拟化计算服务的虚拟机。

作为匹配算法代码的执行的结果，可以将过滤器规范2178发射到配置发现服务，并且可以相应地生成一组匹配的候选配置环境2181。匹配算法代码可以使用候选配置环境来产生发射到迁移市场服务的迁移提议列表2183。然后，在所示实施方案中，可以将列表的个别提议2184(例如，2184A或2184B)发射到适当的客户端2180(例如，2180或2180B)。

市场元数据

图22示出了根据至少一些实施方案的可以存储在迁移市场服务的元数据存储库中的条目的示例。如所示，元数据存储库2205可以包括至少两类信息：迁移促进者记录2231和发现服务客户端记录2251。

迁移促进者记录2231可以包括例如促进者能力2233的描述符或专业知识(例如，促进者对其迁移具有经验的应用程序堆栈促进者的类型)。在各种实施方案中，记录2231还可以包括促进者关于使迁移候选者适合于促进者的特性的偏好或要求2235(例如，迁移前或迁移后配置项的地理分布、待迁移应用程序环境的可接受范围或优选大小，或者促进者的优选地理区域或操作位置)。在至少一个实施方案中，记录2231还可以包括反馈2237或指示促进者的早期协助的评估的证明书。在一些实施方案中，反馈可以包括评级或排名(例如，1与5之间的星星数，其中1指示不良评级，而5指示优秀评级)以及文字评论。在所示实施方案中，记录2231还可以包括迁移提议历史2239(指示由促进者在过去生成的一个或多个提议)和指示客户端接受的提议的子集的提议转换历史2241。

发现服务客户端记录2251可以包括与各种客户端相对应的配置数据访问许可2253。另外，在至少一个实施方案中，还可以维护指示客户端的迁移历史的条目2255。应注意，在一些实施方案中，图22中所示的元素种类中的至少一些可能不一定存储在迁移市场服务处。

基于网络的市场服务界面

图23示出了根据至少一些实施方案的可以由迁移市场服务实现的示例性基于网络的界面。如所示，界面包括网页2302，网页2302包括消息区域2310、对应于相应的注册的迁移促进者的一些广告区域2315(例如，2315A-2315D)，以及交互控件(例如，按钮或网络链接)2325、2327和2329。

消息区域2302可以向迁移市场服务的客户端告知可以通过广告中指示的链接获得关于各种迁移促进者的额外信息。广告中的每一者可以指示特定促进者愿意协助的应用程序堆栈-例如，广告区域2315A中的促进者F1支持的应用程序堆栈2322A、广告区域2315B中的促进者F2支持的应用程序堆栈2322B等等。在一些实施方案中，用于促进者的排名/评级反馈2324以及示例定价信息2325也可以包括在广告中。

客户端可以经由网页2302的按钮控件2325获得指示迁移应用程序(例如，从客户拥有的数据中心到提供商网络)的益处的案例研究。可以经由按钮控件2327访问关于配置项的自动发现和/或迁移计划的额外信息(例如，***或在线指南)。在所示实施方案中，客户端可以使用控件2329注册关于迁移促进者的建议。在各种实施方案中，客户端可以使用迁移市场服务的接口来提交对迁移协助的请求。例如，在一些实施方案中，提供商网络的尚未开始使用发现服务但可能在将来某个时间对迁移其应用程序感兴趣的客户端可以经由市场服务的编程接口发射请求以起始配置项的自动发现。响应于这类请求，迁移市场服务可以代表客户端调用配置发现服务的编程接口，使得可以开始从与客户端的应用程序相关联的数据源中检索配置信息。所收集的信息可以稍后用于将客户端与适当的迁移促进者进行匹配。在至少一个实施方案中，已经被代表在发现服务处收集配置数据的客户端可以向迁移市场服务提交迁移协助请求。迁移市场服务可以基于客户端的配置数据和关于促进者存储的元数据(例如，在图22的存储库2205中)执行其自己的匹配算法，并且向客户端提供促进者建议。

支持迁移市场的方法

图24是示出根据至少一些实施方案的可以在迁移市场服务处执行的操作的各方面的流程图。如元素2401中所示，可以在提供商网络的迁移市场服务处接收使迁移促进者能够访问客户端的应用程序环境的配置记录的请求。可能已从附属于如前所述的配置发现服务的各种数据源收集了配置记录。可以相应地修改客户端的配置记录集合的安全元数据(元素2404)。如前所述，在一些情况下，可以在发现服务处修改安全设置，而在其他实施方案中，可以由迁移市场服务本身维护安全元数据。

可以在市场服务处从迁移促进者接收迁移候选者识别请求或查询(元素2407)。可以将基于客户端的许可授予和/或数据混淆要求而限制从发现服务数据库检索的配置数据的过滤器规范或查询发射到发现服务(元素2410)。在一些实施方案中，迁移市场服务可以发射过滤器规范或查询。在其他实施方案中，用于迁移候选者匹配算法的可执行代码可以由迁移促进者供应，并且可以在提供商网络的不同服务处运行(诸如不需要为代码预先分派服务器的打包程序执行服务)，从而导致提交过滤器规范或查询。

响应于过滤而检索的配置信息可以用于生成例如指示迁移促进者对协助客户端的执行环境的迁移感兴趣的一个或多个迁移提议(元素2413)。在至少一些实施方案中，提议可以包括初步成本估计。市场服务可以经由其编程接口将提议的表示发射到提议所适用的客户端(元素2416)。任选地，响应于客户端经由编程接口接受提议，迁移市场服务可以起始单独的迁移计划或实现服务的工作流程(元素2419)。

注意，在各种实施方案中，除了图9、图17和图24的流程图中所示的操作之外的至少一些操作可以用于实现上述配置发现相关的技术和迁移市场相关的技术。所示操作中的一些在一些实施方案中可能不被实现或可能以不同的顺序实现，或并行地而不是顺序地实现。

使用情况

上文描述的来自多个网络处的各种源的配置数据的自动收集、合并和可视化，以及实现迁移相关的在线市场的技术在各种实施方案中可能是有用的。对于分布在客户拥有和提供商拥有的资源中的复杂应用程序堆栈，所描述的配置发现服务可能能够以不同的粒度级别、信任度和准确度来组合和策划来自多种多样的源的应用程序配置数据。所述服务可以经由易于使用的编程接口暴露根据标准化的基于本体的命名模式组织的所收集数据，所述编程接口包括可用于构建更高级别服务，诸如帮助客户计划和实现其应用程序到提供商网络环境的迁移的服务的API。配置发现服务信息的可视化部件可以使客户更易于获得其整个应用程序堆栈的概述，以及深入到任何所需的细节级别，这可以有助于资源容量计划、调试性能和故障排除。迁移市场服务可以充当中介，所述中介可以向可能能够帮助具有迁移需求的应用程序拥有者的迁移促进者或专家介绍应用程序拥有者，所述应用程序拥有者可能对将其应用程序迁移到提供商网络感兴趣，但是可能没有必要的技术专业知识来确定如何计划和实现迁移。迁移服务可以确保关于给定应用程序环境提供的信息满足应用程序拥有者的安全准则，并且可以向已经选择迁移促进者的客户支持到迁移计划和实现服务的平稳过渡。

可以鉴于以下条款来描述本公开的实施方案：

1.一种***，所述***包括：

网络可访问配置发现服务的一个或多个计算装置；

其中所述一个或多个计算装置被配置为：

从第一数据源接收与特定客户端相关联的配置项有关的第一数据集，

至少部分地基于对所述第一数据集的分析，生成与所述特定客户端相关联的特定配置项的服务侧识别符，其中所述第一数据集包括第一配置项的第一数据源侧识别符，并且其中所述第一数据集包括所述特定配置项的一个或多个属性的第一集合；

从第二数据源接收与所述特定客户端相关联的配置项有关的第二数据集；

确定所述第二数据集包括所述特定配置项的一个或多个属性的第二集合，并且其中所述第二数据集不包括所述第一数据源侧识别符；

至少部分地基于与所述第一数据源相关联的第一信任分数，并且至少部分地基于与所述第二数据源相关联的第二信任分数，更新与所述特定配置项对应的合并配置记录，其中所述合并配置记录包括所述特定配置项的多个属性；

响应于经由编程接口接收的查询，发射所述合并配置记录的至少一部分的表示。

2.如条款1所述的***，其中所述一个或多个计算装置被配置为：

经由批量导入编程接口接收所述第一数据集；并且

经由事件级编程接口接收所述第二数据集。

3.如条款1所述的***，其中所述一个或多个计算装置被配置为：

经由编程接口接收第一项组描述符的指示，其中所述第一项组描述符指示以下各项中的一者或多者：(a)与应用程序相关联的多个配置项的预期互连拓扑，(b)与所述应用程序相关联的预期项名称列表，或(c)与所述应用程序相关联的一对配置项之间的预期通信模式；并且

至少部分地基于所述特定配置项的一个或多个属性，并且至少部分地基于所述第一项组描述符，将所述特定配置项指定为具有特定项组标签的特定项组的成员；并且

存储所述特定项组标签被分配给第一合并配置记录的指示。

4.如条款1所述的***，其中所述一个或多个计算装置被配置为：

至少部分地基于对第三数据集的分析，确定已经在接收端点处经由混淆中介从发送端点接收到一个或多个网络数据包，其中所述接收端点由所述配置发现服务处的第二配置项表示，并且其中在所述配置发现服务处尚未确定所述发送端点的代表性配置项的身份；并且

起始对于所述发送端点的端点检测算法的执行；并且

至少部分地基于所述端点检测算法的结果，更新第二合并配置记录。

5.如条款1所述的***，其中所述一个或多个计算装置被配置为：

将相应的相关性分数分配给包括所述特定配置项的多个配置项中的个别配置项；并且

至少部分地基于分配给所述特定配置项的相关性分数，生成对第二查询的响应。

6.一种方法，所述方法包括：

通过网络可访问配置发现服务的一个或多个计算装置执行以下操作；

至少部分地基于对由第一配置数据源产生的第一数据集的分析，生成与特定客户端相关联的特定配置项的服务侧识别符，其中所述第一数据集包括所述特定配置项的一个或多个属性的第一集合；

确定第二数据集包括所述特定配置项的一个或多个属性的第二集合，其中所述第二数据集不包括所述服务侧识别符；

至少部分地基于与所述第一配置数据源相关联的第一信任分数，更新对应于所述特定配置项的第一合并配置记录；以及

响应于经由编程接口接收的查询，发射所述第一合并配置记录的至少一部分的表示。

7.如条款6所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

经由所述网络可访问配置发现服务的批量导入编程接口接收从所述客户端的配置管理数据库导出的所述第一数据集；以及

经由所述网络可访问配置发现服务的事件级别编程接口接收所述第二数据集。

8.如条款6所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

至少部分地基于对第三数据集中包括的一个或多个属性的第三集合的检查，生成被指定用于第二配置项的第二服务侧识别符；

存储与所述第二配置项相关联的第二合并配置记录；

在存储所述第二合并配置记录之后，确定一个或多个属性的所述第三集合与所述第一合并配置记录被更新的所述特定配置项相关联；

至少部分地基于所述第二合并配置记录的内容，修改所述第一合并配置记录；以及

移除所述第二合并配置记录。

9.如条款8所述的方法，其中所述确定一个或多个属性的所述第三集合与所述特定配置项相关联包括以下各项中的一者或多者：(a)经由编程接口接收校正请求或(b)执行资源使用相关分析。

10.如条款6所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

经由编程接口接收第一项组描述符的指示，其中所述第一项组描述符指示以下各项中的一者或多者：(a)与应用程序相关联的多个配置项的预期互连拓扑，(b)与所述应用程序相关联的预期项名称列表，(c)与所述应用程序相关联的一对配置项之间的预期通信模式；以及

至少部分地基于所述特定配置项的一个或多个属性，并且至少部分地基于所述第一项组描述符，将所述特定配置项指定为具有特定项组标签的特定项组的成员；以及

存储所述特定项组标签被分配给所述第一合并配置记录的指示。

11.如条款6所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

至少部分地基于对第三数据集的分析，确定已经在接收端点处经由混淆中介从发送端点接收到一个或多个网络数据包，其中所述接收端点由所述配置发现服务处的第二配置项表示，并且其中在所述配置发现服务处尚未确定所述发送端点的代表性配置项的身份；以及

起始对于所述发送端点的端点检测算法的执行；以及

至少部分地基于所述端点检测算法的结果，更新第二合并配置记录。

12.如条款11所述的方法，其中所述端点检测算法包括以下各项中的一者或多者：(a)发出连接建立和连接终止请求的序列，(b)将连续网络数据包的接收之间的延迟与连续网络数据包的发射之间的延迟进行匹配，或(c)分析数据包序列号。

13.如条款6所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

将相应的相关性分数分配给包括所述特定配置项的多个配置项中的个别配置项；以及

至少部分地基于分配给第二配置项的相关性分数，生成对第二查询的响应。

14.如条款13所述的方法，所述方法还包括通过所述一个多个计算装置执行以下操作：

至少部分地基于以下各项中的一者或多者来确定所述第二配置项的相关性分数：(a)与所述第二配置项相关联的重复频率，(b)与所述第二配置项相关联的资源使用，或(c)与所述第二配置项相关联的查询历史。

15.如条款6所述的方法，所述方法还包括通过所述一个多个计算装置执行以下操作：

将与特定应用程序相关联的多个合并配置记录存储在第一数据存储区处，其中所述第一数据存储区具有第一平均记录检索等待时间，并且其中所述多个合并配置记录中的个别合并配置记录具有相关联的时间戳；

相对于所述相关联的时间戳以反向时间顺序至少将所述多个合并配置记录的子集从所述第一数据存储区加载到第二数据存储区，其中所述第二数据存储区所具有的第二平均记录检索等待时间小于所述第一平均记录检索等待时间；以及

使用所述第二数据存储区提供对针对所述特定应用程序的时间查询的响应。

16.一种存储程序指令的非暂时性计算机可访问存储介质，所述程序指令当在一个或多个处理器上执行时：

至少部分地基于对由第一配置数据源提供的第一数据集的分析，生成与特定客户端相关联的特定配置项的服务侧识别符，其中所述第一数据集包括所述特定配置项的一个或多个属性的第一集合，并且其中所述第一数据集不包括所述服务侧识别符；

确定第二数据集包括所述特定配置项的一个或多个属性的第二集合，其中所述第二数据集不包括所述服务侧识别符；

至少部分地基于与所述第一配置数据源相关联的第一信任分数，更新对应于所述特定配置项的第一合并配置记录；并且

响应于经由编程接口接收的查询，发射所述第一合并配置记录的至少一部分的表示。

17.如条款16所述的非暂时性计算机可访问存储介质，其中所述指令当在所述一个或多个处理器上执行时：

确定第一项组描述符的内容，其中所述第一项组描述符指示以下各项中的一者或多者：(a)与应用程序相关联的多个配置项的预期互连拓扑，(b)与所述应用程序相关联的预期项名称列表，(c)与所述应用程序相关联的一对配置项之间的预期通信模式；并且

至少部分地基于所述特定配置项的一个或多个属性，并且至少部分地基于所述第一项组描述符，将所述特定配置项指定为具有特定项组标签的特定项组的成员；并且

存储所述特定项组标签被分配给第一合并配置记录的指示。

18.如条款16所述的非暂时性计算机可访问存储介质，其中所述指令当在所述一个或多个处理器上执行时：

至少部分地基于对第三数据集的分析，确定已经在接收端点处经由混淆中介从发送端点接收到一个或多个网络数据包，其中所述接收端点由发现服务处的第二配置项表示，并且其中在所述发现服务处尚未确定所述发送端点的代表性配置项的身份；并且

起始对于所述发送端点的端点检测算法的执行；并且

至少部分地基于所述端点检测算法的结果，更新第二合并配置记录。

19.如条款16所述的非暂时性计算机可访问存储介质，其中所述指令当在所述一个或多个处理器上执行时：

将相应的相关性分数分配给包括所述特定配置项的多个配置项中的个别配置项；并且

至少部分地基于分配给所述特定配置项的相关性分数，生成对第二查询的响应。

20.如条款16所述的非暂时性计算机可访问存储介质，其中所述第一配置数据源在第一提供商网络运营商的数据中心处被实例化，并且其中所述指令当在所述一个或多个处理器上执行时：

建立到包括所述第一配置数据源、第二配置数据源和第三配置数据源的多个数据源的网络连接，以获得与所述特定客户端的一个或多个应用程序有关的配置数据，其中所述第二配置数据源在第二提供商网络运营商的数据中心处被实例化，并且其中所述第三配置数据源在不是提供商网络的一部分的数据中心处被实例化。

说明性计算机***

在至少一些实施方案中，实现本文中描述的技术中的一者或多者的一部分或全部的服务器可以包括通用计算机***，所述计算机***包括或被配置用来访问一个或多个计算机可访问的介质，本文中描述的技术包括实现配置发现服务、相关联的可视化服务和/或迁移市场服务的部件的技术。图25示出了这类通用计算装置9000。在所示实施方案中，计算装置9000包括一个或多个处理器9010，所述一个或多个处理器经由输入/输出(I/O)接口9030联接到***存储器9020(其可以包括非易失性和易失性存储器模块两者)。计算装置9000还包括联接到I/O接口9030的网络接口9040。

在各种实施方案中，计算装置9000可以是包括一个处理器9010的单处理器***，或包括若干处理器9010(例如，两个、四个、八个或另一合适的数目)的多处理器***。处理器9010可以是能够执行指令的任何合适的处理器。例如，在各种实施方案中，处理器9010可以是通用或嵌入式处理器，所述通用或嵌入式处理器实现多种指令集架构(ISA)中的任一者，诸如x86、PowerPC、SPARC或MIPS ISA或任何其他合适的ISA。在多处理器***中，处理器9010中的每一者通常可以但不一定实现相同的ISA。在一些实现方式中，替代常规的处理器或除常规的处理器外，可以使用图形处理单元(GPU)。

***存储器9020可以被配置为存储可由处理器9010访问的指令和数据。在至少一些实施方案中，***存储器9020可以包括易失性和非易失性部分；在其他实施方案中，可以使用仅易失性存储器。在各种实施方案中，可以使用任何合适的存储器技术来实现***存储器9020的易失性部分，所述存储器技术诸如静态随机存取存储器(SRAM)、同步动态RAM或任何其他类型的存储器。对于***存储器的非易失性部分(其可以包括例如一个或多个NVDIMM)，在一些实施方案中，可以使用基于闪存的存储器装置，包括NAND闪存装置。在至少一些实施方案中，***存储器的非易失性部分可以包括电源，诸如超级电容器或其他电力存储装置(例如，电池)。在各种实施方案中，基于忆阻器的电阻式随机存取存储器(ReRAM)、三维NAND技术、铁电RAM、磁阻RAM(MRAM)或各种类型的相变存储器(PCM)中的任一者可以至少用于***存储器的非易失性部分。在所示实施方案中，实现一个或多个所要功能(诸如上文描述的那些方法、技术和数据)的程序指令和数据被示出为作为代码9025和数据9026存储在***存储器9020内。

在一个实施方案中，I/O接口9030可以被配置为协调处理器9010、***存储器9020与装置中的任何***装置(包括网络接口9040或诸如各种类型的持久性和/或易失性存储装置的其他***接口)之间的I/O流量。在一些实施方案中，I/O接口9030可以执行任何必要协议、时序或其他数据变换以将来自一个部件(例如，***存储器9020)的数据信号转换成适于由另一部件(例如，处理器9010)使用的格式。在一些实施方案中，I/O接口9030可以包括对通过各种类型的***总线，诸如例如***部件互连(PCI)总线标准或通用串行总线(USB)标准的变体附接的装置的支持。在一些实施方案中，I/O接口9030的功能可以拆分为两个或更多个单独的部件，诸如例如北桥和南桥。并且，在一些实施方案中，I/O接口9030的功能中的一些或全部，诸如到***存储器9020的接口，可以直接并入到处理器9010中。

网络接口9040可以被配置为允许在计算装置9000与附接到网络9050的其它装置9060(诸如例如图1至图24中所示的其他计算机***或装置)之间交换数据。在各种实施方案中，网络接口9040可以经由任何合适的有线或无线通用数据网络(诸如例如多种以太网)支持通信。另外，网络接口9040可以经由诸如模拟语音网络或数字光纤通信网络的电信/电话网络、经由诸如光纤通道SAN的存储区域网络，或经由任何其他合适类型的网络和/或协议来支持通信。

在一些实施方案中，***存储器9020可以是被配置为存储如上文针对图1至图24所描述的用于实现对应方法和设备的实施方案的程序指令和数据的计算机可访问介质的一个实施方案。然而，在其他实施方案中，可以接收、发送程序指令和/或数据或将其存储在不同类型的计算机可访问介质上。一般来说，计算机可访问介质可以包括非暂时性存储介质或存储器介质，诸如磁性或光学介质，例如经由I/O接口9030联接到计算装置9000的磁盘或DVD/CD。非暂时性计算机可访问存储介质还可以包括任何易失性或非易失性介质，诸如RAM(例如，SDRAM、DDR SDRAM、RDRAM、SRAM等)、ROM等，所述易失性或非易失性介质在计算装置9000的一些实施方案中可以被包括作为***存储器9020或另一类型的存储器。此外，计算机可访问介质可以包括经由诸如网络和/或无线链路的通信介质传送的传输介质或信号，诸如电信号、电磁信号或数字信号，所述通信介质诸如可以经由网络接口9040实现。在各种实施方案中多个计算装置(诸如图25所示的计算装置)中的一部分或全部可用于实现所描述的功能性；例如，在多种不同的装置和服务器上运行的软件部件可以协作以提供所述功能性。在一些实施方案中，除使用通用计算机***实现外或替代于使用通用计算机***实现，所描述的功能的一部分可以使用存储装置、网络装置或专用计算机***来实现。如本文中所使用的术语“计算装置”至少指代所有这些类型的装置，并且不限于这些类型的装置。

总结

各种实施方案还可以包括接收、发送根据前面的描述实现的指令和/或数据或将其存储在计算机可访问介质上。一般来说，计算机可访问介质可以包括存储介质或存储器介质诸如磁性或光学介质(例如，磁盘或DVD/CD-ROM)、易失性或非易失性介质诸如RAM(例如，SDRAM、DDR、RDRAM、SRAM等)、ROM等，以及经由通信介质(诸如网络和/或无线链路)传送的传输介质或信号诸如电信号、电磁信号或数字信号。

如附图中所示且在本文中描述的各种方法表示方法的示例性实施方案。所述方法可以用软件、硬件或其组合实现。可以改变方法的顺序，并且可以添加、重新排序、组合、省略、修改各种元素等。

可以进行各种修改和改变，如对受益于本公开的领域的技术人员将显而易见。意图涵盖所有这类修改和改变，且因此，以上描述应以说明性而非限制性意义看待。

Claims (15)

1.一种用于配置发现的方法，所述方法包括：

通过网络可访问配置发现服务的一个或多个计算装置执行以下操作：

至少部分地基于对由第一配置数据源产生的第一数据集的分析，生成与特定客户端相关联的特定配置项的服务侧识别符，其中所述第一数据集包括所述特定配置项的一个或多个属性的第一集合；

确定第二数据集包括所述特定配置项的一个或多个属性的第二集合，其中所述第二数据集不包括所述服务侧识别符并且是从不同于第一配置数据源的数据源接收的；

至少部分地基于与所述第一配置数据源相关联的第一信任分数，更新对应于所述特定配置项的第一合并配置记录，其中第一合并配置记录包括来自于所述第一集合的一个或多个属性和来自于所述第二集合的一个或多个属性；以及

响应于经由编程接口接收的查询，发送所述第一合并配置记录的至少一部分的表示。

2.如权利要求1所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

经由所述网络可访问配置发现服务的批量导入编程接口接收从所述客户端的配置管理数据库导出的所述第一数据集；以及

经由所述网络可访问配置发现服务的事件级别编程接口接收所述第二数据集。

3.如权利要求1所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

至少部分地基于对第三数据集中包括的一个或多个属性的第三集合的检查，生成被指定用于第二配置项的第二服务侧识别符；

存储与所述第二配置项相关联的第二合并配置记录；

在存储所述第二合并配置记录之后，确定一个或多个属性的所述第三集合与所述第一合并配置记录被更新的所述特定配置项相关联；

至少部分地基于所述第二合并配置记录的内容，修改所述第一合并配置记录；以及

移除所述第二合并配置记录。

4.如权利要求3所述的方法，其中所述确定一个或多个属性的所述第三集合与所述特定配置项相关联包括以下各项中的一者或多者：(a)经由编程接口接收校正请求或(b)执行资源使用相关分析。

5.如权利要求1所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

经由编程接口接收第一项组描述符的指示，其中所述第一项组描述符指示以下各项中的一者或多者：(a)与应用程序相关联的多个配置项的预期互连拓扑，(b)与所述应用程序相关联的预期项名称列表，(c)与所述应用程序相关联的一对配置项之间的预期通信模式；以及

至少部分地基于所述特定配置项的一个或多个属性，并且至少部分地基于所述第一项组描述符，将所述特定配置项指定为具有特定项组标签的特定项组的成员；以及

存储所述特定项组标签被分配给所述第一合并配置记录的指示。

6.如权利要求1所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

至少部分地基于对第三数据集的分析，确定已经在接收端点处经由中介从发送端点接收到一个或多个网络数据包，其中所述接收端点由所述配置发现服务处的第二配置项表示，并且其中在所述配置发现服务处尚未确定所述发送端点的代表性配置项的身份；以及

发起对于所述发送端点的端点检测算法的执行；以及

至少部分地基于所述端点检测算法的结果，更新第二合并配置记录。

7.如权利要求6所述的方法，其中所述端点检测算法包括以下各项中的一者或多者：(a)发出连接建立和连接终止请求的序列，(b)将连续网络数据包的接收之间的延迟与连续网络数据包的发送之间的延迟进行匹配，或(c)分析数据包序列号。

8.如权利要求1所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

将相应的相关性分数分配给包括所述特定配置项的多个配置项中的个别配置项；以及

至少部分地基于分配给第二配置项的相关性分数，生成对第二查询的响应。

9.如权利要求8所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

至少部分地基于以下各项中的一者或多者来确定所述第二配置项的相关性分数：(a)与所述第二配置项相关联的重复频率，(b)与所述第二配置项相关联的资源使用，或(c)与所述第二配置项相关联的查询历史。

10.如权利要求1所述的方法，所述方法还包括通过所述一个或多个计算装置执行以下操作：

将与特定应用程序相关联的多个合并配置记录存储在第一数据存储区处，其中所述第一数据存储区具有第一平均记录检索等待时间，并且其中所述多个合并配置记录中的个别合并配置记录具有相关联的时间戳；

相对于所述相关联的时间戳以反向时间顺序至少将所述多个合并配置记录的子集从所述第一数据存储区加载到第二数据存储区，其中所述第二数据存储区所具有的第二平均记录检索等待时间小于所述第一平均记录检索等待时间；以及

使用所述第二数据存储区提供对针对所述特定应用程序的时间查询的响应。

11.一种用于配置发现的***，该***包括联接到存储器的处理器，所述存储器包括在被执行时使所述***进行以下操作的指令：

至少部分地基于对由第一配置数据源提供的第一数据集的分析，生成与特定客户端相关联的特定配置项的服务侧识别符，其中所述第一数据集包括所述特定配置项的一个或多个属性的第一集合，并且其中所述第一数据集不包括所述服务侧识别符；

确定第二数据集包括所述特定配置项的一个或多个属性的第二集合，其中所述第二数据集不包括所述服务侧识别符并且是从不同于第一配置数据源的数据源接收的；

至少部分地基于与所述第一配置数据源相关联的第一信任分数，更新对应于所述特定配置项的第一合并配置记录，其中第一合并配置记录包括来自于所述第一集合的一个或多个属性和来自于所述第二集合的一个或多个属性；以及

响应于经由编程接口接收的查询，发送所述第一合并配置记录的至少一部分的表示。

12.如权利要求11所述的***，其中所述指令在被执行时进一步使所述***进行以下操作：

确定第一项组描述符的内容，其中所述第一项组描述符指示以下各项中的一者或多者：(a)与应用程序相关联的多个配置项的预期互连拓扑，(b)与所述应用程序相关联的预期项名称列表，(c)与所述应用程序相关联的一对配置项之间的预期通信模式；以及

至少部分地基于所述特定配置项的一个或多个属性，并且至少部分地基于所述第一项组描述符，将所述特定配置项指定为具有特定项组标签的特定项组的成员；以及

存储所述特定项组标签被分配给所述第一合并配置记录的指示。

13.如权利要求11所述的***，其中所述指令在被执行时进一步使所述***进行以下操作：

至少部分地基于对第三数据集的分析，确定已经在接收端点处经由中介从发送端点接收到一个或多个网络数据包，其中所述接收端点由发现服务处的第二配置项表示，并且其中在所述发现服务处尚未确定所述发送端点的代表性配置项的身份；以及

发起对于所述发送端点的端点检测算法的执行；以及

至少部分地基于所述端点检测算法的结果，更新第二合并配置记录。

14.如权利要求11所述的***，其中所述指令在被执行时进一步使所述***进行以下操作：

将相应的相关性分数分配给包括所述特定配置项的多个配置项中的个别配置项；以及

至少部分地基于分配给所述特定配置项的相关性分数，生成对第二查询的响应。

15.如权利要求11所述的***，其中所述第一配置数据源在第一提供商网络运营商的数据中心处被实例化，并且其中所述指令在被执行时还使所述***进行以下操作：

建立到包括所述第一配置数据源、第二配置数据源和第三配置数据源的多个数据源的网络连接，以获得与所述特定客户端的一个或多个应用程序有关的配置数据，其中所述第二配置数据源在第二提供商网络运营商的数据中心处被实例化，并且其中所述第三配置数据源在数据中心处被实例化，该数据中心不是提供商网络的一部分。

Images