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

前言

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，看有没有解决答案，其中看到要么是纯理论要么是建议升级版本，通过搜索引擎查了一些资料，也试了很多，发现没解决问题，或者看似解决了，后面又复现了。于是就写了这篇文章，一来可以复盘一下，二来是希望可以帮助到有出现类似问题的伙伴