首页 互联网资讯 网络技术 地区报价 解决方案

网络技术

你的位置:欧冠赛程APP下载 > 网络技术 > Sentry 企业级数据安好经管规划

Sentry 企业级数据安好经管规划

发布日期:2022-08-07 00:36    点击次数:177

日志记载

Relay 将日志生成到标准舛误流 (stderr),默认环境下具有 INFO 日志记载级别。譬如,启动 Relay 后,您可以或许会看到以下输出:

INFO  relay::setup > launching relay from config folder .relay INFO  relay::setup >   relay mode: managed INFO  relay::setup >   relay id: cde0d72e-0c4e-4550-a934-c1867d8a177c INFO  relay::setup >   log level: INFO 

此示例体现具有默认日志记载级别 (INFO) 的音讯,您可以或许编削该级别以体现更多或更少的信息。无关设置日志记载的详细信息,请参阅选项页面上的日志记载部份。

https://docs.sentry.io/product/relay/options/#logging 舛误报告

默认环境下,Relay 将舛误记载到设置的 logger 中。您可以或许在 Relay 设置文件中的 Sentry 中为您的名目启用舛误报告:

sentry:   enabled: true   dsn: <your_dsn> 

可以或许在选项页面上找到无关可用选项及其含义的更多信息。

https://docs.sentry.io/product/relay/options/#internal-error-reporting 健康查抄

Relay 供应了两个 URL 来查抄体系形态:

GET /api/relay/healthcheck/live/: 测试 Relay 是否正在运行并监听 HTTP 要求。 GET /api/relay/healthcheck/ready/: 测试 Relay 是否经由过程上游验证并畸形运行。

告成时,两个端点都前去 200 OK 照顾:

{   "is_healthy": true } 
指标

您可以或许经由过程将 metrics.statsd key 设置为 ip:port 元组来向 StatsD server 提交统计信息。可以或许设置为 ip:port 元组。

示例设置

metrics:   # Endpoint of your StatsD server   statsd: 127.0.0.1:8126   # Prefix all metric names with this string   prefix: mycompany.relay 

用于设置指标报告的选项记载在选项页面上。

https://docs.sentry.io/product/relay/options/#statsd-metrics Relay 采集下列指标

event.accepted (Counter)

今后时段担任的信封数量。

这默示已告成经由过程速率限定和过滤器并已发送到上游的要求。

event.corrupted (Counter)

已破损(不成打印)事宜属性的事宜数。

而今,这会查抄 environment 和 release,我们晓得某些 SDK 可以或许会发送破损的值。

event.processing_time (Timer)

同步处理惩罚信封所花费的时光(以毫秒为单位)。

此时序涵盖 CPU 池中的端到端处理惩罚,蕴含:

event_processing.deserialize event_processing.pii event_processing.serialization

在 Relay 处于处理惩罚情势时,这还蕴含下列时序:

event_processing.process event_processing.filtering event_processing.rate_limiting

event.protocol (Counter)

射中任何近似 store 的端点的事宜数量:Envelope、Store、Security、Minidump、Unreal。

事宜在被速率限定、过滤或以任何编制处理惩罚从前被计数。

该指标标记为:

version: 事宜和谈版本号默以为 7。

event.queue_size (Histogram)

行列中的信封数。

行列生活生涯在 Relay 中特守时光正在处理惩罚的全体信封:

当 Relay 收到要求时,它确保提交的数据被包装在一个信封中。 信封担任一些开端处理惩罚以肯定它是否可以或许被处理惩罚或是否必须被推卸。 一旦做出此选择,创立信封的 HTTP 要求就会截至,假定要进一步处理惩罚该要求,则信封将进入行列。 在信封实现处理惩罚并被发送到上游后,信封被视为已处理惩罚并来到行列。

行列大小可以或许经由过程 cache.event_buffer_size 设置。

event.queue_size.pct (Histogram)

行列中的信封数占行列中可存储的最大信封数的百分比。

该值的领域从行列为空时的 0 到行列已满且没法增加额外事宜时的 1。行列大小可应用 event.queue_size 设置。

event.rejected (Counter)

今后时光段内推卸的信封数量。

这蕴含信封因名目舛误或处理惩罚进程中的任何别的舛误而被推卸(蕴含过滤事宜、有效负载和速率限定)。

要查抄推卸启事,请查抄 events.outcomes。

event.size_bytes.raw (Histogram)

从要求中提取后由 Relay 看到的 HTTP 要求正文的大小(以字节为单位)。

对付信封要求,这是信封的完备尺寸。 对付 JSON 存储要求,这是 JSON 正文的大小。 对付崩溃报告和附件的分段上传,这是 multipart body 的大小,蕴含界限。

假定这个要求包孕一个 base64 zlib 压缩的有效载荷,而没有准确的 content-encoding 头,那末这是解压前的大小。

最大要求 body 大小可以或许经由过程 limits.max_envelope_size 举行设置。

event.size_bytes.uncompressed (Histogram)

Relay 在解压和解码后看到的要求 body 的大小(以字节为单位)。

JSON 存储要求可以或许包孕 base64 zlib 压缩负载,而没有准确的 content-encoding 头。在这类环境下,该指标包孕解码后的大小。否则,它总是等于 event.size_bytes.raw。

event.total_time (Timer)

信封从领受到实现处理惩罚并提交给上游的总时光(以毫秒为单位)。

event.wait_time (Timer)

在 Relay 中领受要求(即要求处理惩罚起头)和 EnvelopeProcessor 中起头同步处理惩罚之间花费的时光。该指标次要默示事宜处理惩罚中的积压。

event_processing.deserialize (Timer)

将事宜从 JSON 字节反序列化为 Relay 在其上运行的原生数据构造所花费的时光(以毫秒为单位)。

event_processing.filtering (Timer)

在事宜上运行入站数据过滤器所花费的时光(以毫秒为单位)。

event_processing.pii (Timer)

今后事宜的数据清理所花费的时光(以毫秒为单位)。数据清理最后发生在将事宜序列化回 JSON 从前。

event_processing.process (Timer)

在事宜上运行事宜处理惩罚器以举行标准化所花费的时光(以毫秒为单位)。事宜处理惩罚发生在过滤从前。

event_processing.rate_limiting (Timer)

查抄构造、名目和 DSN 速率限定所花费的时光(以毫秒为单位)。

事宜第一次被限速后,限速会被缓存。在此以落后入的事宜将在要求行列中更早地被扬弃并且不会达随处理惩罚行列。

event_processing.serialization (Timer)

将事宜从其内存默示转换为 JSON 字符串所花费的时光。

events.outcomes (Counter)

推卸信封的 outcome 和 reason 的数量。

该指标标记为:

outcome: 推卸事宜的根抵启事。 reason: 形貌导致 outcome 的划定端方或机制的更详细的标识符。 to: 形貌 outcome 的目标地。可以是 kafka(处于处理惩罚情势时)或 http(在外部 relay 中启用 outcome 时)。

可以或许的 outcome 是:

filtered: 被入站数据过滤器扬弃。reason 指定成家的过滤器。 rate_limited: 被构造、名目或 DSN 速率限定扬弃,以及逾越 Sentry 设计配额。reason 包孕超出的速率限定或配额。 invalid: 数据被视为有效且没法光复。启事评释验证失利。

http_queue.size (Histogram)

列队等待发送的上游要求数。

尽管即便使跟尾对立流动。跟尾对立关上形态 15 秒不流动或 75 秒流动。假定全体跟尾都忙,它们将列队,这回响反映在此指标中。

该指标标记为:

priority: 要求的列队优先级,可以是 "high" 或 "low"。优先级选择了执行要求的优先按次。

并发跟尾数可以或许设置为:

limits.max_concurrent_requests 跟尾总数 limits.max_concurrent_queries 默示并发高优先级要求的数量

metrics.buckets (Gauge)

Relay 的指标聚合器中的 metric bucket 总数。

metrics.buckets.created.unique (Set)

计算创立的仅有 bucket 的数量。

这是一组 bucket 键。指标根抵上等同于单个 Relay 的 metrics.buckets.merge.miss,但对付肯定多个实例正在运行时有几多重复 bucket 可以或许颇有效。

Hash 而今取决于平台,因而发送此指标的全体 Relay 应在沟通的 CPU 架构上运行,否则此指标不成靠。

metrics.buckets.flushed (Histogram)

在全体名目标一个周期中刷新的 metric buckets 总数。

metrics.buckets.flushed_per_project (Histogram)

每个名目在一个周期中刷新的 metric buckets 数。

Relay 定期扫描 metric buckets 并刷新过期的桶。为每个正在刷新的名目记载此直方图。直方图值的计数相当于正在刷新的名目数。

metrics.buckets.merge.hit (Counter)

每次并吞两个 bucket 或两个 metric 时递增。

按 metric 范例和名称标记。

metrics.buckets.merge.miss (Counter)

每次创立 bucket 时递增。

按 metric 范例和名称标记。

metrics.buckets.parsing_failed (Counter)

从信封中剖析指标 bucket 名目失利的次数。

metrics.buckets.scan_duration (Timer)

扫描指标 bucket 以刷新所花费的时光(以毫秒为单位)。

Relay 定期扫描指标 bucket 并刷新过期的 bucket。此计时器体现执行此扫描并从外部缓存中删除 bucket 所需的时光。将指标桶发送到上游不在此计时器领域内。

metrics.insert (Counter)

针对拔出的每个指标递增。

按指标范例和名称标记。

outcomes.aggregator.flush_time (Timer)

outcome 聚合器刷新聚合 outcomes 所需的时光。

processing.event.produced (Counter)

搁置在 Kafka 行列上的音讯数

当 Relay 作为 Sentry 服务运行并且一个 Envelope 名目被告成处理惩罚时,每个 Envelope 名目都市孕育发生一条对付 Kafka 摄入主题的公用音讯。

这个指标被标记为:

event_type: 向 Kafka 生成的音讯范例。

音讯范例可以是:

event: error 或 transaction 事宜。舛误事宜发送到 ingest-events,事件发送到 ingest-transactions,带有附件的舛误发送到 ingest-attachments。 attachment: 与舛误事宜联络纠葛的附件文件,发送到 ingest-attachments。 user_report: 来自用户回响反映对话框的音讯,发送到 ingest-events。 session: release health session 更新,发送到 ingest-sessions。

processing.produce.error (Counter)

在信封已列队发送到 Kafka 后发生的临蓐者舛误数。

譬如,这些舛误蕴含 "MessageTooLarge" 当 broker 不担任逾越特定大小的要求时的舛误,这平日是由于有效或不一致的 broker/producer 设置构成的。

project_cache.eviction (Counter)

从缓存中驱散的古老名目标数量。

Relay 会以 cache.eviction_interval 设置的安稳时光间隔扫描内存名目缓存中的古老条目。

可应用下列选项设置名目形态的缓存继续时光:

cache.project_expiry: 名目形态过期的时光。假定要求在过期后引用了名目,网络技术则会自动刷新。 cache.project_grace_period: 过期后名目形态仍将用于领受事宜的时光。一旦缓期日到期,缓存将被逐出,新要求将等待更新。

project_cache.hit (Counter)

从缓存中查找名目标次数。

缓存可以或许包孕过期或过期的名目形态。在这类环境下,纵然在缓存射中后,名目形态也会更新。

project_cache.miss (Counter)

名目查找失利的次数。

登时创立缓存条目,并从上游要求名目形态。

project_cache.size (Histogram)

今后生活生涯在内存名目缓存中的名目形态数。

可应用下列选项设置名目形态的缓存继续时光:

cache.project_expiry: 名目形态计为过期的时光。假定要求在名目过期后引用该名目,它会自动刷新。 cache.project_grace_period: 到期后名目形态仍将用于摄入事宜的时光。一旦缓期日到期,缓存被逐出,新要求等待更新。

缓存名目标数量没无限定。

project_state.eviction.duration (Timer)

驱散过期和未应用的名目所花费的总时光(以毫秒为单位)。

project_state.get (Counter)

从缓存中查找名目形态的次数。

这蕴含对缓存名目和新名目标查找。作为个中的一部份,会触发对过期或过期名目缓存的更新。

相干指标:

project_cache.hit: 用于告成的缓存查找,纵然是过期的名目。

project_cache.miss: 对付导致更新的失利查找。 project_state.no_cache (Counter)

应用 .no-cache 要求名目设置的次数。

这有效地计算了应用响应 DSN 发送的信封或事宜的数量。对付这些名目形态要求,对上游的理论查询可以或许仍会举行重单数据删除。

每个 project key 每秒至多准许 1 个此类要求。此指标仅计算准许的要求。

project_state.pending (Histogram)

内存名目缓存中等待形态更新的名目数。

无关名目缓存的更多分化,请参阅 project_cache.size。

project_state.received (Histogram)

每个批处理惩罚要求从上游 前去 的名目形态数。

假定同时更新多个批次,则会屡次报告此指标。

无关名目缓存的更多分化,请参阅 project_cache.size。

project_state.request (Counter)

名目形态 HTTP 要求的数量。

Relay 批量更新名目。每个更新周期,Relay 从上游要求 limits.max_concurrent_queries 批次的 cache.batch_size 名目。这些要求的继续时光经由过程 project_state.request.duration 报告。

请留心,更新循环实现后,可以或许会有更多名目等待更新。这由 project_state.pending 指点。

project_state.request.batch_size (Histogram)

对付每个批处理惩罚要求,来自上游的 requested 名目形态数量。

假定同时更新多个批次,则会屡次报告此指标。

批量大小可以或许经由过程 cache.batch_size 设置。无关名目缓存的更多分化,请参阅 project_cache.size。

project_state.request.duration (Timer)

取得要经管的列队名目设置更新要求所花费的总时光(以毫秒为单位)。

Relay 批量更新名目。每个更新周期,Relay 从上游要求 limits.max_concurrent_queries * cache.batch_size 名目。此指标测量此循环中全体并发要求的挂钟时光。

请留心,更新循环实现后,可以或许会有更多名目等待更新。这由 project_state.pending 指点。

requests (Counter)

抵达 Relay 的 HTTP 要求数。

requests.duration (Timer)

在 HTTP 照顾前去给客户端从前处理惩罚入站 Web 要求的总继续时光(以毫秒为单位)。

这纰谬应于完备的事宜摄入时光。由于舛误数据或缓存速率限定而未登时推卸的事宜要求一直前去 200 OK。齐全验证和标准化是异步发生的,由 event.processing_time 报告。该指标标记为:

method: 要求的 HTTP 编制。 route: 端点的仅有虚线标识符。

requests.timestamp_delay (Timer)

负载中划定的时光戳与领受时光之间的耽误。

SDK 没法在全体环境下登时传输有效载荷。偶尔,崩溃需求在从头启动应用顺序后发送事宜。一样,SDK 在网络停机时期缓冲事宜以供今后传输。该指标衡量事宜发生时光与其抵达 Relay 时光之间的耽误。该指标衡量事宜发生时光与其抵达 Relay 时光之间的耽误。

仅捕获耽误逾越 1 分钟的有效载荷。

该指标标记为:

category: 有效载荷的数据类别。可以是下列之一:event、transaction、security 或 session。

responses.status_codes (Counter)

已实现的 HTTP 要求数。

该指标标记为:

status_code: HTTP 形态代码编号。 method: 要求中应用的 HTTP 编制(大写)。 route: 端点的仅有虚线标识符。

scrubbing.attachments.duration (Timer)

花费在附件清理上的时光。这默示评估附件清理划定端方和附件清理本身所花费的总时光,而不论是否应用了任何划定端方。请留心,未能剖析的 minidumps(scrubbing.minidumps.duration 中的 status="error")将作为通俗附件举行清理并计入此内容。

scrubbing.minidumps.duration (Timer)

花在 minidump 清理上的时光。

这是剖析和清理 minidump 所花费的总时光。纵然没有应用 minidump 的 PII 清理划定端方,仍将剖析并在剖析的 minidump 上评估划定端方,此继续时光在此处报告,形态为 "n/a"。

这个指标被标记为:

status: Scrubbing status: "ok" 默示洗涤告成, "error" 默示清理进程中出现舛误,最后 "n/a" 默示清理告成但未应用清理划定端方。

server.starting (Counter)

Relay server 启动的次数。

这可用于跟踪由于崩溃或截至而导致的不需求的重启。

unique_projects (Set)

默示今后时光片内的流动名目数

upstream.network_outage (Gauge)

Relay 相对付上游跟尾的形态。可以或许的值为 0(畸形操作)和 1(网络中缀)。

upstream.requests.duration (Timer)

将要求发送到上游 Relay 并处理惩罚照顾所花费的总时光。

该指标标记为:

result: 要求发生了什么,具有下列值的罗列: success: 要求已发送并前去告成代码 HTTP 2xx response_error: 要求已发送并前去 HTTP 舛误。 payload_failed: 要求已发送,但在说明呼当令犯错。 send_failed: 由于网络舛误,没法发送要求。 rate_limited: 要求被限速。 invalid_json: 没法将照顾剖析回 JSON。 route: 在上游调用的端点。 status-code: 可历时要求的形态码,否则为"-"。 retries: 重试次数存储桶 0、一、二、很少(3 - 10)、良多(逾越 10)。

upstream.retries (Histogram)

计算每个上游 http 要求的重试次数。

该指标标记为:

result: 要求发生了什么,具有下列值的罗列: success: 要求已发送并前去告成代码 HTTP 2xx response_error: 要求已发送并前去 HTTP 舛误。 payload_failed: 要求已发送,但在说明呼当令犯错。 send_failed: 由于网络舛误,没法发送要求。 rate_limited: 要求被限速。 invalid_json: 没法将照顾剖析回 JSON。 route: 在上游调用的端点。 status-code: 可历时要求的形态码,否则为"-"。