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 ...

前言何为sentrysentry是一个基于Django构建的现代化开源的实时谬误追踪零碎，能够帮忙开发者发现问题、追踪问题 sentry官网文档https://docs.sentry.io/ sentry装置咱们能够应用官网提供的https://github.com/getsentry/onpremise.git的我的项目进行装置。 装置步骤如下 以在centos7装置为例 1、克隆onpremise我的项目yum install gitgit clone https://github.com/getsentry/onpremise.git2、切换到onpremise目录，执行install.sh装置脚本 cd onpremise ./install.sh只有执行这两步，就能够悠哉的喝杯咖啡期待装置实现了。前面你会发现，这个装置的工夫，绝不是喝一杯咖啡的工夫就能够解决了，可能是要喝N杯。因为这个等待时间切实是有点漫长，我第一次装置耗时差不多有3个小时。因为有了这次体验，前面再装置，我就在思考如何晋升这个装置速度了 如何晋升onpremise我的项目装置senrty的速度通过观察执行的install.sh脚本的日志，发现他执行到 RUN apt-get update && apt-get install -y --no-install-recommends cron && \ rm -r /var/lib/apt/lists/*这句脚本就会十分慢，他会下载debian，而且一旦下载没胜利，就会报错退出，就得从新再来一次，让人会很抓狂。因为下载debian的地址是在国外，所以下载速度就异样慢，那咱们解决的思路就有要么翻墙，要么就是切换debian的镜像源。我的计划是前面一种 因而这句脚本执行前，咱们能够加如下脚本 Run sed -i 's#http://deb.debian.org#https://mirrors.163.com#g' /etc/apt/sources.list这句话的意思就是将debian的镜像源切换成163镜像源 或者你也能够用以下脚本，也能够达到下面的成果（不过不是很举荐这种形式，因为上面这句脚本的意思是装置debian10版本的镜像源，如果sentry依赖是高于debian10版本，那就完犊子） RUN mv /etc/apt/sources.list /etc/apt/sources.list.bak && \ echo deb http://mirrors.163.com/debian/ buster main non-free contrib >>/etc/apt/sources.list && \ echo deb http://mirrors.163.com/debian/ buster-updates main non-free contrib >>/etc/apt/sources.list && \ echo deb http://mirrors.163.com/debian/ buster-backports main non-free contrib >>/etc/apt/sources.list && \ echo deb http://mirrors.163.com/debian-security/ buster/updates main non-free contrib >>/etc/apt/sources.list && \ echo deb-src http://mirrors.163.com/debian/ buster main non-free contrib >>/etc/apt/sources.list && \ echo deb-src http://mirrors.163.com/debian/ buster-updates main non-free contrib >>/etc/apt/sources.list && \ echo deb-src http://mirrors.163.com/debian/ buster-backports main non-free contrib >>/etc/apt/sources.list && \ echo deb-src http://mirrors.163.com/debian-security/ buster/updates main non-free contrib >>/etc/apt/sources.list这个脚本的批改地位在onpremise/cron/Dockerfile,就是批改cron的Dockerfile。 ...

为什么咱们须要利用监控大家是否有过这样的体验： 产品新性能上线几周后，客户提工单反馈问题。研发同学经排查确认是 bug，且会产生脏数据。最终，修复 bug + 上线花了大半天，而编写修复脚本 + 修复数据消耗了一周。 如果发现 bug 的机会越早，那么修复老本就越低。 通过对利用中的谬误或异样进行监控和主动反馈，有助于咱们尽早发现荫蔽的问题，晋升产品质量和研发效率。 日志零碎不等同利用监控零碎可能有同学会说：程序的谬误和异样在咱们的日志零碎外面都有呀，为什么还须要专门的利用监控零碎？ 的确，日志中事无巨细地记录了大量的运行过程和异样信息。不过，这些信息可能也存在反复、有效、不足分割的弊病。而且，日志次要是在研发同学排查问题时应用，很少被用于被动监控和告警，日常存在着大量的错误信息始终未被关注和解决。 Sentry：一款受欢迎的利用监控产品Sentry 是一款开源的利用监控产品，应用 Python、JavaScript、HTML、CSS 打造。在 GitHub 上有 29k Stars，是利用监控畛域 Stars 数排行最高的开源我的项目，其官网声称有 1 百万名开发者和 7 万个组织在应用 Sentry。除了提供开源产品外，其幕后的公司也提供付费的 SaaS 服务：sentry.io。2021 年该公司发表取得了 6000 万美元的 D 轮融资，该轮融资使 Sentry 的总资金达到 1.27 亿美元，融资后估值为 10 亿美元。的确是一款值得关注的产品。 Sentry 有以下重要特点：产品体验好，功能完善 接入工作量少 官网和开源社区提供了各种支流开发语言和框架的 SDK，便于开发者接入，大多几十行代码内即可实现。 Sentry 专一于 Error、Exception、Crash 能够查看到具体的错误信息和调用栈，能疾速定位问题代码。 提供丰盛的上下文信息 SDK 会主动上报根底信息，也反对上报自定义的信息，便于排查问题。 主动合并反复问题 反复的报错被主动合并且累计次数，防止开发者在大量反复冗余的信息寻找 bug 的蛛丝马迹。 被动邮件告警 不必再等“客户告警”后才开始排查问题。 自部署 Sentry 的毛病部署依赖繁多 利用官网的提供的 Github 仓库，基于 Docker 和 Docker Compose 的确能够一键部署、开箱即用。不过，当看到 30 个容器列在背后时，还是会感觉迟疑。 ...

Sentry 简介Sentry ['sentri]n.哨兵v.站岗；在…设岗哨Sentry 是一个用于监控前后端出错和统计上报剖析一体的一个开源软件系统。 Sentry 适宜中等规模以上的网站的开发及生产线上出错治理。Sentry能够适应多租户多我的项目的治理。性能很欠缺。 官网地址： https://sentry.io/features/re... 因为软件架构比较复杂。倡议采纳官网的 docker-compose 脚本即onpremise 来装置。 Sentry 零碎占用内存较多，最好有8G以上内存。因资源受限，我用的是4G内存+4G Swap分区的形式在 CentOS 7 上装置的。在收集几千万个谬误上报后，零碎依然很晦涩，可见其性能低劣。 最新的 Sentry 零碎由28个容器组成： # docker ps --format 'table {{ .Ports }}\t{{.Names}}'PORTS NAMES0.0.0.0:9000->80/tcp sentry_onpremise_nginx_19000/tcp sentry_onpremise_subscription-consumer-events_19000/tcp sentry_onpremise_ingest-consumer_19000/tcp sentry_onpremise_cron_19000/tcp sentry_onpremise_subscription-consumer-transactions_19000/tcp sentry_onpremise_post-process-forwarder_19000/tcp sentry_onpremise_sentry-cleanup_19000/tcp sentry_onpremise_web_19000/tcp sentry_onpremise_worker_11218/tcp sentry_onpremise_snuba-subscription-consumer-transactions_11218/tcp sentry_onpremise_snuba-transactions-consumer_11218/tcp sentry_onpremise_snuba-sessions-consumer_11218/tcp sentry_onpremise_snuba-api_11218/tcp sentry_onpremise_snuba-outcomes-consumer_11218/tcp sentry_onpremise_snuba-consumer_11218/tcp sentry_onpremise_snuba-replacer_11218/tcp sentry_onpremise_snuba-subscription-consumer-events_13000/tcp sentry_onpremise_relay_11218/tcp sentry_onpremise_snuba-cleanup_19092/tcp sentry_onpremise_kafka_16379/tcp sentry_onpremise_redis_15432/tcp sentry_onpremise_postgres_13021/tcp sentry_onpremise_symbolicator_12181/tcp, 2888/tcp, 3888/tcp sentry_onpremise_zookeeper_125/tcp sentry_onpremise_smtp_18123/tcp, 9000/tcp, 9009/tcp sentry_onpremise_clickhouse_111211/tcp sentry_onpremise_memcached_13021/tcp sentry_onpremise_symbolicator-cleanup_1注: docker ps 后加 format 参数，能够管制输入字段和格局，很不便写文档用。详见Docker官网。以上的28个容器大略造成了以下的构造： ...