ABRT的工作原理

当应用程序崩溃时，崩溃事件由ABRT的语言或运行时相关的钩子之一处理，该钩子将崩溃信息转发给 abrt daemon . 守护进程将数据存储在 /var/spool/abrt 并运行一系列事件，例如收集有关系统的更多数据、从核心转储生成回溯或通知用户。在这个过程之后，会自动或手动向各种受支持的目标（如bugzilla或ABRT Analytics）报告 (ABRT分析 ）

报告

目前，典型的桌面报告工作流程包括生成所谓的 μ报告 （微报告）设计成完全匿名的，这样它可以自动发送和处理，避免了昂贵的bugzilla查询和人力。

在这种情况下，ABRT分析（过去也称为ABRT服务器）就像是第一道防线——收集大量类似的报告，并在已知问题的情况下使用跟踪器url进行响应。

如果用户有幸遇到ABRT Analytics不知道的独特问题，则报告链将继续向bugzilla报告，这是一个更复杂的过程，需要用户拥有bugzilla帐户，并经历许多步骤，包括验证报告不包含敏感数据。

ABRT还具有无人值守报告的可能性，包括电子邮件报告、上传功能以及与Spacewalk或Foreman等工具的集成，用于大规模部署场景。

组件

abrt

用于处理崩溃和监视错误日志的守护程序和工具集合。负责存储和处理各种挂钩造成的碰撞。

gnome-abrt

用于问题管理和报告的简单GUI应用程序。

libreport

库提供了一个API，用于通过电子邮件、bugzilla、ABRT分析、scp上载等不同路径报告问题。。

ABRT分析

崩溃收集服务器，也称为ABRT分析（或ABRT服务器在过去）。提供传入报告的准确统计信息，并在bugzilla（或任何其他问题跟踪程序）前面作为代理自动报告崩溃。它是用来接收匿名的 μReports 并在它们之间找到类似的报告。对于已知的报告，用户会收到快速响应，其中包含指向ABRT Analytics的问题页面、问题跟踪程序或知识库的条目的链接，其中包含许多众所周知的问题，如专有内核模块的使用或不支持的模块导致的浏览器崩溃。

satyr

Satyr是用于程序故障处理、分析和报告的低级算法的集合，支持内核空间、用户空间、Python和Java程序。考虑到故障处理，它允许从各种源解析故障描述，例如GDB创建的堆栈跟踪、带有未捕获异常描述的Python堆栈跟踪以及内核oops消息。还可以从意外终止的用户空间进程的核心转储和二进制文件的机器可执行代码中提取信息。考虑到失效分析，可以对失效进程的堆栈跟踪进行规范化、修剪和比较。可以计算类似堆栈轨迹的簇。在多线程堆栈跟踪中，可以发现导致故障的线程。考虑到故障报告，库可以生成指定格式的故障报告，并且可以将报告发送到远程机器。

回溯服务器

回溯服务器通过使用HTTP协议的网络提供核心转储分析和回溯生成服务。

隐私

μ报告 由适合以完全自动化的方式进行分析的结构化数据组成，尽管它们不一定包含足够的信息来解决根本问题。报告的设计不包含任何潜在的敏感数据，以消除提交前审查的需要。