28. 可用性分析和数据收集¶
可用性数据收集包含在 Tower 中，用于收集数据以更好地了解 Tower 用户如何与 Tower 交互，从而帮助增强未来的版本，并继续简化您的用户体验。
只有安装 Tower 试用版或全新安装 Tower 的用户才会选择加入此数据收集。
如果您想更改参与此分析收集的方式，可以通过使用 Tower 配置用户界面选择退出或更改您的设置，该界面可从左侧导航栏的“设置”（
）图标访问。
Ansible Tower 会自动收集用户数据以帮助改进 Tower 产品。您可以通过在设置菜单中的“用户界面”选项卡中设置您的参与级别来控制 Tower 收集数据的方式。
从“用户分析跟踪状态”下拉列表中选择所需的数据收集级别
关闭：阻止任何数据收集。
匿名：启用数据收集，但不包括您的特定用户数据。
详细：启用数据收集，包括您的特定用户数据。
单击保存以应用设置，或单击取消以放弃更改。
有关更多信息，请参阅 Red Hat 隐私政策，网址为 https://www.redhat.com/en/about/privacy-policy。
28.1. 自动化分析¶
首次导入许可证时，您会获得与数据收集相关的选项，这些数据支持自动化分析，自动化分析是 Ansible 自动化平台订阅的一部分的云服务。 为了使自动化分析的加入有任何效果，您的 Ansible Tower 实例必须在 Red Hat Enterprise Linux 上运行。
与 Red Hat Insights 非常相似，自动化分析旨在仅收集必要的最小数据量。不会收集任何凭据密钥、个人数据、自动化变量或任务输出。 有关更多信息，请参阅下面的 数据收集的详细信息。
要启用此功能，请打开自动化分析的数据收集，并在设置菜单中位于“系统”配置窗口的“其他系统”选项卡中输入您的 Red Hat 客户凭据。
请注意，“自动化分析上传 URL” 字段已预先填充了将收集的洞察数据上传到的位置。
默认情况下，自动化分析数据每 4 小时收集一次，启用该功能后，数据将被收集至多一个月（或直到上次收集）。 您可以在“系统”配置窗口的“其他系统”选项卡中随时关闭此数据收集。
此设置也可以通过 API 启用，方法是在以下任一端点中指定 INSIGHTS_TRACKING_STATE = True
api/v2/settings/allapi/v2/settings/system
从该数据收集生成的自动化分析将在 Red Hat 云服务 门户网站上找到。
“集群” 数据是默认视图。 此图表表示一段时间内所有 Tower 集群的作业运行次数。 上面的示例显示了一周的时间跨度，采用堆积条形图样式，按成功运行的作业数（绿色）和失败的作业数（红色）进行组织。
或者，您可以选择单个集群以查看其作业状态信息。
此多线图表表示单个 Tower 集群在指定时间段内的作业运行次数。 此处的示例显示了一周的时间跨度，按成功运行的作业数（绿色）和失败的作业数（红色）进行组织。 您可以指定选定集群在时间跨度为一周、两周和每月增量时成功运行的作业数和失败的作业数。
从左侧导航窗格中单击“组织统计信息” 以查看以下信息
28.1.1. 按组织划分的使用情况¶
此饼图表示特定组织在所有作业中运行的任务数。
28.1.2. 按组织划分的作业运行¶
此饼图表示所有 Tower 集群中按组织划分的 Tower 使用情况，通过该组织运行的作业数计算。
28.1.3. 组织状态¶
此条形图显示了按组织和日期划分的 Tower 使用情况，它是根据特定日期该组织运行的作业数量计算得出的。或者，您可以指定显示每周、两周和每月增量中每个组织的作业运行次数。
28.2. 数据收集详细信息¶
自动化分析从 Ansible Tower 收集某些类别的 数据
基本配置，例如启用的功能以及使用的操作系统
Tower 环境和主机的拓扑结构和状态，包括容量和运行状况
自动化资源的数量
组织、团队和用户
清单和主机
凭据（按类型索引）
项目（按类型索引）
模板
计划
活动会话
正在运行和挂起的作业
作业执行详细信息（开始时间、结束时间、启动类型和成功）
自动化任务详细信息（成功、主机 ID、剧本/角色、任务名称和使用的模块）
您可以使用 awx-manage gather_analytics（不带 --ship）检查 Tower 发送的数据，以便解决您的数据收集问题。这将创建一个包含将发送到 Red Hat 的分析数据的 tar 包。
此文件包含多个 JSON 和 CSV 文件。每个文件包含一组不同的分析数据。
28.2.1. manifest.json¶
manifest.json 是分析数据的清单。它描述了收集中包含的每个文件以及包含的该文件架构的版本。清单示例如下
{
"config.json": "1.1",
"counts.json": "1.0",
"cred_type_counts.json": "1.0",
"events_table.csv": "1.1",
"instance_info.json": "1.0",
"inventory_counts.json": "1.2",
"job_counts.json": "1.0",
"job_instance_counts.json": "1.0",
"org_counts.json": "1.0",
"projects_by_scm_type.json": "1.0",
"query_info.json": "1.0",
"unified_job_template_table.csv": "1.0",
"unified_jobs_table.csv": "1.0",
"workflow_job_node_table.csv": "1.0",
"workflow_job_template_node_table.csv": "1.0"
}
28.2.2. config.json¶
config.json 文件包含集群配置端点 /api/v2/config 的一个子集。config.json 示例如下
{
"ansible_version": "2.9.1",
"authentication_backends": [
"social_core.backends.azuread.AzureADOAuth2",
"django.contrib.auth.backends.ModelBackend"
],
"external_logger_enabled": true,
"external_logger_type": "splunk",
"free_instances": 1234,
"install_uuid": "d3d497f7-9d07-43ab-b8de-9d5cc9752b7c",
"instance_uuid": "bed08c6b-19cc-4a49-bc9e-82c33936e91b",
"license_expiry": 34937373,
"license_type": "enterprise",
"logging_aggregators": [
"awx",
"activity_stream",
"job_events",
"system_tracking"
],
"pendo_tracking": "detailed",
"platform": {
"dist": [
"redhat",
"7.4",
"Maipo"
],
"release": "3.10.0-693.el7.x86_64",
"system": "Linux",
"type": "traditional"
},
"total_licensed_instances": 2500,
"tower_url_base": "https://ansible.rhdemo.io",
"tower_version": "3.6.3"
}
收集的字段参考
- ansible_version
主机上的系统 Ansible 版本
- authentication_backends
可用的用户身份验证后端。有关详细信息，请参阅 设置社交身份验证 和 设置 LDAP 身份验证。
- external_logger_enabled
是否启用外部日志记录
- external_logger_type
如果启用，则使用哪种日志记录后端。有关详细信息，请参阅 Tower 日志记录和聚合。
- logging_aggregators
发送到外部日志记录的日志记录类别。有关详细信息，请参阅 Tower 日志记录和聚合。
- free_instances
许可证中可用的主机数量。值为零表示集群完全消耗了其许可证。
- install_uuid
安装的 UUID（对所有集群节点相同）
- instance_uuid
实例的 UUID（每个集群节点不同）
- license_expiry
许可证到期时间（以秒为单位）
- license_type
许可证类型（在大多数情况下应为“企业”）
- pendo_tracking
可用性分析和数据收集 的状态
- platform
集群运行的操作系统
- total_licensed_instances
许可证中的主机总数
- tower_url_base
客户端使用的集群的基本 URL（显示在自动化分析中）
- tower_version
集群上软件的版本
28.2.3. instance_info.json¶
instance_info.json 文件包含有关构成集群的实例的详细信息，按实例 UUID 组织。instance_info.json 示例如下
{
"bed08c6b-19cc-4a49-bc9e-82c33936e91b": {
"capacity": 57,
"cpu": 2,
"enabled": true,
"last_isolated_check": "2019-08-15T14:48:58.553005+00:00",
"managed_by_policy": true,
"memory": 8201400320,
"uuid": "bed08c6b-19cc-4a49-bc9e-82c33936e91b",
"version": "3.6.3"
}
"c0a2a215-0e33-419a-92f5-e3a0f59bfaee": {
"capacity": 57,
"cpu": 2,
"enabled": true,
"last_isolated_check": "2019-08-15T14:48:58.553005+00:00",
"managed_by_policy": true,
"memory": 8201400320,
"uuid": "c0a2a215-0e33-419a-92f5-e3a0f59bfaee",
"version": "3.6.3"
}
}
收集的字段参考
- capacity
实例执行任务的容量。有关计算方法的详细信息，请参阅 <link>。
- cpu
实例的 CPU 内核
- memory
实例的内存
- enabled
实例是否启用并接受任务
- managed_by_policy
实例在实例组中的成员资格是由策略管理还是手动管理
- version
实例上软件的版本
28.2.4. counts.json¶
counts.json 文件包含集群中每个相关类别的对象总数。counts.json 示例如下
{
"active_anonymous_sessions": 1,
"active_host_count": 682,
"active_sessions": 2,
"active_user_sessions": 1,
"credential": 38,
"custom_inventory_script": 2,
"custom_virtualenvs": 4,
"host": 697,
"inventories": {
"normal": 20,
"smart": 1
},
"inventory": 21,
"job_template": 78,
"notification_template": 5,
"organization": 10,
"pending_jobs": 0,
"project": 20,
"running_jobs": 0,
"schedule": 16,
"team": 5,
"unified_job": 7073,
"user": 28,
"workflow_job_template": 15
}
此文件中的每个条目都对应于 /api/v2 中的相应 API 对象，但活动会话计数除外。
28.2.5. org_counts.json¶
org_counts.json 文件包含有关集群中每个组织的信息，以及与该组织关联的用户和团队数量。org_counts.json 示例如下
{
"1": {
"name": "Operations",
"teams": 5,
"users": 17
},
"2": {
"name": "Development",
"teams": 27,
"users": 154
},
"3": {
"name": "Networking",
"teams": 3,
"users": 28
}
}
28.2.6. cred_type_counts.json¶
cred_type_counts.json 文件包含有关集群中不同凭据类型的信息，以及每种类型存在的凭据数量。cred_type_counts.json 示例如下
{
"1": {
"credential_count": 15,
"managed_by_tower": true,
"name": "Machine"
},
"2": {
"credential_count": 2,
"managed_by_tower": true,
"name": "Source Control"
},
"3": {
"credential_count": 3,
"managed_by_tower": true,
"name": "Vault"
},
"4": {
"credential_count": 0,
"managed_by_tower": true,
"name": "Network"
},
"5": {
"credential_count": 6,
"managed_by_tower": true,
"name": "Amazon Web Services"
},
"6": {
"credential_count": 0,
"managed_by_tower": true,
"name": "OpenStack"
},
...
28.2.7. inventory_counts.json¶
inventory_counts.json 文件包含有关集群中不同清单的信息。inventory_counts.json 示例如下
{
"1": {
"hosts": 211,
"kind": "",
"name": "AWS Inventory",
"source_list": [
{
"name": "AWS",
"num_hosts": 211,
"source": "ec2"
}
],
"sources": 1
},
"2": {
"hosts": 15,
"kind": "",
"name": "Manual inventory",
"source_list": [],
"sources": 0
},
"3": {
"hosts": 25,
"kind": "",
"name": "SCM inventory - test repo",
"source_list": [
{
"name": "Git source",
"num_hosts": 25,
"source": "scm"
}
],
"sources": 1
}
"4": {
"num_hosts": 5,
"kind": "smart",
"name": "Filtered AWS inventory",
"source_list": [],
"sources": 0
}
}
28.2.8. projects_by_scm_type.json¶
projects_by_scm_type.json 文件按源代码管理类型细分了集群中的所有项目。projects_by_scm_type.json 示例如下
{
"git": 27,
"hg": 0,
"insights": 1,
"manual": 0,
"svn": 0
}
28.2.9. query_info.json¶
query_info.json 文件提供有关数据收集的时间和方式的详细信息。query_info.json 示例如下
{
"collection_type": "manual",
"current_time": "2019-11-22 20:10:27.751267+00:00",
"last_run": "2019-11-22 20:03:40.361225+00:00"
}
collection_type 为“manual”或“automatic”之一。
28.2.10. job_counts.json¶
job_counts.json 文件提供有关集群的作业历史记录的详细信息，描述了作业的启动方式以及其完成状态。job_counts.json 示例如下
{
"launch_type": {
"dependency": 3628,
"manual": 799,
"relaunch": 6,
"scheduled": 1286,
"scm": 6,
"workflow": 1348
},
"status": {
"canceled": 7,
"failed": 108,
"successful": 6958
},
"total_jobs": 7073
}
28.2.11. job_instance_counts.json¶
job_instance_counts.json 文件按实例细分提供了与 job_counts.json 相同的详细信息。job_instance_counts.json 示例如下
{
"localhost": {
"launch_type": {
"dependency": 3628,
"manual": 770,
"relaunch": 3,
"scheduled": 1009,
"scm": 6,
"workflow": 1336
},
"status": {
"canceled": 2,
"failed": 60,
"successful": 6690
}
}
}
请注意，此文件中的实例按主机名划分，而不是按实例信息中的 UUID 划分。
28.2.12. unified_job_template_table.csv¶
unified_job_template_table.csv 文件提供有关系统中作业模板的信息。每行包含作业模板的以下字段
- id
作业模板 ID
- name
作业模板名称
- polymorphic_ctype_id
模板类型的 ID
- model
模板的 polymorphic_ctype_id 名称。示例包括“project”、“systemjobtemplate”、“jobtemplate”、“inventorysource”和“workflowjobtemplate”。
- created
模板创建的时间
- modified
模板上次更新的时间
- created_by_id
创建模板的用户 ID。如果由系统完成，则为空。
- modified_by_id
最后修改模板的用户 ID。如果由系统完成，则为空。
- current_job_id
模板当前正在执行的作业 ID（如果有）
- last_job_id
作业的上次执行
- last_job_run
作业上次执行的时间
- last_job_failed
last_job_id 是否失败
- status
last_job_id 的状态
- next_job_run
模板的下一个计划执行（如果有）
- next_schedule_id
next_job_run 的计划 ID（如果有）
28.2.13. unified_jobs_table.csv¶
unified_jobs_table.csv 文件提供有关系统运行的作业的信息。每行包含作业的以下字段
- id
Job id
- name
作业名称（来自模板）
- polymorphic_ctype_id
作业类型的 ID
- model
作业的 polymorphic_ctype_id 名称。示例包括“job”、“worfklow”等等。
- organization_id
作业的组织 ID
- organization_name
organization_id 的名称
- created
When the job record was created
- started
作业开始执行的时间
- finished
作业完成的时间
- elapsed
作业的经过时间（以秒为单位）
- unified_job_template_id
此作业的模板
- launch_type
“manual”、“scheduled”、“relaunched”、“scm”、“workflow”或“dependnecy”之一
- schedule_id
启动作业的计划的 ID（如果有）
- instance_group_id
执行作业的实例组
- execution_node
执行作业的节点（主机名，而不是 UUID）
- controller_node
作业的控制器节点（如果作为独立作业运行，或在容器组中运行）
- cancel_flag
作业是否已取消
- status
作业的状态
- failed
作业是否失败
- job_explanation
无法正常执行的作业的任何其他详细信息
28.2.14. workflow_job_template_node_table.csv¶
workflow_job_template_node_table.csv 文件提供有关系统中工作流作业模板中定义的节点的信息。
每行包含工作流作业模板节点的以下字段
- id
Node id
- created
节点创建的时间
- modified
节点上次更新的时间
- unified_job_template_id
此节点的作业模板、项目、清单或其他父资源的 ID
- workflow_job_template_id
包含此节点的工作流作业模板
- inventory_id
此节点使用的清单
- success_nodes
在此节点成功后触发的节点
- failure_nodes
在此节点失败后触发的节点
- always_nodes
在此节点完成之后始终触发的节点
- all_parents_must_converge
此节点是否需要满足所有父条件才能启动
28.2.15. workflow_job_node_table.csv¶
workflow_job_node_table.csv 文件提供有关在系统上作为工作流的一部分执行的作业的信息。
每行包含作为工作流的一部分运行的作业的以下字段。
- id
Node id
- created
节点记录创建的时间
- modified
节点记录上次更新的时间
- job_id
此节点运行的作业的作业 ID
- unified_job_tempalte_id
此作业运行的作业模板、项目、清单或其他父资源的 ID
- workflow_job_id
此作业运行的父工作流作业
- inventory_id
此作业使用的清单
- success_nodes
在此节点成功后将被触发或已触发的节点
- failure_nodes
在此节点失败后将被触发或已触发的节点
- always_nodes
在此节点完成之后将被触发或已触发的节点
- do_not_run
由于其启动条件未触发而未在工作流中运行的节点
- all_parents_must_converge
此节点是否需要所有父条件都满足才能启动
28.2.16. events_table.csv¶
events_table.csv 文件提供有关系统中所有作业运行中的所有作业事件的信息。每行包含一个作业事件的以下字段。
- id
事件 ID
- uuid
事件 UUID
- created
事件创建的时间
- parent_uuid
此事件的父 UUID（如果有）
- event
Ansible 事件类型（如 runner_on_failed）
- task_action
与此事件关联的模块（如果有）（如“command”或“yum”）
- failed
事件是否返回“failed”
- changed
事件是否返回“changed”
- playbook
与事件关联的剧本
- play
剧本中的剧本名称
- task
剧本中的任务名称
- role
剧本中的角色名称
- job_id
此事件所属作业的 ID
- host_id
此事件关联的主机 ID（如果有）
- host_name
此事件关联的主机名称（如果有）
- start
任务的开始时间
- end
任务的结束时间
- duration
任务的持续时间
- warnings
任务/模块的任何警告
- deprecations
任务/模块的任何弃用警告