前言
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，看有没有解决答案，其中看到要么是纯理论要么是倡议降级版本，通过搜索引擎查了一些材料，也试了很多，发现没解决问题，或者看似解决了，前面又复现了。于是就写了这篇文章，一来能够复盘一下，二来是心愿能够帮忙到有呈现相似问题的搭档