乐趣区

关于sentry:聊聊使用错误采集平台sentry踩到的坑

jiezi

前言

sentry 简介

Sentry 是一款业余的企业级谬误跟踪和日志剖析工具，旨在帮忙开发人员、管理员和产品经理跟踪、剖析和解决应用程序谬误和性能问题。

Sentry 的次要性能和长处包含:

谬误跟踪: Sentry 能够跟踪应用程序中的谬误，并将它们记录下来，以便开发人员可能疾速定位和解决问题。

日志剖析: Sentry 能够剖析应用程序的日志，并提供具体的信息，如谬误级别、调用堆栈、数据库拜访等，以帮忙开发人员疾速定位和解决问题。

告诉和警报: Sentry 能够通过电子邮件、Slack、PagerDuty 等渠道告诉开发人员谬误和性能问题的产生，以便及时响应和解决问题。

可扩展性: Sentry 反对自定义谬误音讯、扩大谬误跟踪性能等，开发人员能够依据本人的需要进行自定义和扩大。

团队合作: Sentry 反对团队合作，能够不便地共享谬误和日志信息，并反对多人同时编辑和评论。

总的来说，Sentry 是一款功能强大、易于应用的企业级谬误跟踪和日志剖析工具，能够帮忙开发人员和管理人员更好地治理和解决应用程序中的谬误和性能问题。

本文次要聊下在应用 sentry 过程中遇到的一些问题

问题锦集

问题一：uWSGI listen queue of socket “127.0.0.1:42563” (fd: 3) full !!! (101/100)

这是因为 uWSGI 的监听队列满了，默认的监听队列长度为 100，把监听队列调大就行

具体操作，批改 /onpremise/sentry/sentry.conf.py

SENTRY_WEB_OPTIONS = {
    ....
    "listen":10240,
   ....
}

不过调了，重启后大概率会报

Listen queue size is greater than the system max net.core.somaxconn (128)

此时要批改零碎参数，如果是通过宿主机部署，则执行 vim /etc/sysctl.conf，增加如下内容

# 用于设置内核无奈及时处理网络接口收到的数据包时容许发送到队列的最大数据包数目，默认为 128。也就是每个监听的 socket，在没有 accept 之前，期待解决的 socket 队列长度
net.core.somaxconn = 10240

而后执行 sysctl -p 从新加载参数。不过如果是基于 docker-compose 部署 sentry，这么加是没成果的。得通过在 docker-compose.yml 做如下配置

示例：

version: '3'
services:
   ...:
    image: ...
    container_name: ...
    privileged: true
    sysctls:
      net.core.somaxcomm: '10240'

能够查看如下文档
https://github.com/docker/compose/issues/3765#issuecomment-402929969

问题二：a client request body is buffered to a temporary file

在运行大略一周会，再次报

uWSGI listen queue of socket "127.0.0.1:43523" (fd: 3) full !!! (10241/10240)

阐明队列又满了，于是看了 nginx，呈现问题二的谬误，这个问题是因为客户端申请体的缓冲区太小导致写入临时文件

因而能够通过配置如下参数

client_max_body_size 100m;
 client_body_buffer_size 10M;

将申请体缓存区大小调大。不过调了这个并没解决

uWSGI listen queue of socket "127.0.0.1:43523" (fd: 3)

后边调大 uWSGI 线程数 (默认 workers 是 4，thread 是 3) 和 keepalive（默认是 30s）时长，具体操作如下，批改 /onpremise/sentry/sentry.conf.py，依据零碎的 cpu 核数，适当的调整 workers 数和 thread 数，示例配置如下

SENTRY_WEB_OPTIONS = {
   ....
    "so-keepalive": True,
    # Keep this between 15s-75s as that's what Relay supports"http-keepalive": 60,
    # the number of web workers
    "workers": 8,
    "threads": 8,
 
}

问题三：worker 3 lifetime reached, it was running for 86401 second(s)

程序运行大略一周后，不再报

uWSGI listen queue of socket "127.0.0.1:43523" (fd: 3) full

转而报问题三的错，后边通过 https://stackoverflow.com/questions/66489889/uwsgi-resets-worker-on-lifetime-reached-causes-downtime 找到解决方案，就是将 max-worker-lifetime 改为 max-worker-lifetime-delta
具体起因能够查看
https://github.com/unbit/uwsgi/issues/2020

示例配置

批改 /onpremise/sentry/sentry.conf.py

SENTRY_WEB_OPTIONS = {
    ....
    "max-worker-lifetime-delta":86400,
   ....
}

至此 sentry 运行了大半年都没呈现上述问题

总结

本文次要是记录在应用 sentry 过程中，遇到的问题，为什么会记录，因为我在排错的过程中，我一开始是去官网 github 看 issues，看有没有解决答案，其中看到要么是纯理论要么是倡议降级版本，通过搜索引擎查了一些材料，也试了很多，发现没解决问题，或者看似解决了，前面又复现了。于是就写了这篇文章，一来能够复盘一下，二来是心愿能够帮忙到有呈现相似问题的搭档

退出移动版