自从去年sentry又挂了之后，再加上大部分项目都是 C# 的，使用 ExceptionLess 的体验已经很不错了，所以我们就一直没再使用 sentry 🦎

　　前天刚把 Gitlab 配置好，接下来有一些其他语言☕️的项目要监控，我想着继续把 sentry 也重启了。然后 ExceptionLess 也很久没更新了，官方已经出到8.x版本，我们还在用 7.x，这次也顺便升级一下⛰️

　　在软件开发的世界里，错误跟踪和性能监控是保证应用健康和用户满意度的关键。这就是 Sentry 发挥作用的地方。Sentry 是一个开源的实时错误跟踪工具，它能有效帮助开发者监控和修复各种编程语言中的错误。无论是前端 Java 错误还是后端 Python 异常，Sentry 都能捕捉到，并提供详尽的错误报告和分析。

　　详细的错误报告：每个错误报告都包含了足够的信息，帮助开发者快速定位问题源头。这些信息包括错误发生的堆栈跟踪、受影响的用户、错误发生的时间以及错误前后的应用状态。

　　性能监控：不仅可以跟踪错误，还能监控应用的性能状况，如页面加载时间、API响应时间等，帮助开发者优化用户体验。

　　Sentry 的使用场景广泛，它不仅适用于大型企业的复杂应用，也适合小型开发团队和个人项目。例如，在开发过程中集成 Sentry 可以持续监控应用状态，一旦部署新版本后出现问题，Sentry 可以帮助快速回滚并修复。此外，其用户友好的界面和强大的配置能力，让它成为处理错误和提升应用质量的得力工具。

　　为什么会折腾那么久，最后总结下来最主要的就是网络问题，其次是版本问题，官方文档用的是 24.1.0，我一开始用了 github 上最新的 24.7.0 一直不行🙅‍♀️

　　Sentry 的本体是基于 Django 开发的，Python 的灵活性和生态系统中的丰富库使其成为开发复杂应用程序如 Sentry 的一个理想选择，前端页面是 React 开发的。

　　整个 sentry 还是比较复杂的，当前版本跑起来之后有28个容器，对服务器的性能有一定要求。

　　ClickHouse: 一个高性能的列式数据库，专门用于处理大规模数据分析，Sentry 用它来存储和查询事件数据。

　　Redis: 一个内存中的数据结构存储系统，用作数据库、缓存和消息代理，Sentry 用它来处理队列和缓存任务。

　　PostgreSQL: 一个强大的开源关系数据库，Sentry 使用它来存储核心数据，包括项目配置和用户数据。

　　Kafka: 一个分布式流处理平台，Sentry 使用 Kafka 来处理事件流和确保数据的弹性处理。

　　Relay: 一个独立的服务，用于处理从客户端发送到 Sentry 的事件，提供数据清洗和安全性控制。

　　这些容器共同构成了 Sentry 的复杂架构，确保从数据收集到处理再到存储的每一环节都能高效、稳定地运行。

　　嘿，亲爱的开发者朋友们！有没有想过，如果你的代码中有一个小小的守护精灵，它会帮你捕捉所有那些调皮的错误和异常百度不越狱shadowrocket，然后偷偷地告诉你哪里出了问题，让你的调试工作变得轻松又愉快呢？好消息，这个小精灵已经存在了，它的名字叫Exceptionless！🎉

　　Exceptionless 不仅仅是一个工具，它是一个超级可爱的、功能强大的开源错误和事件报告服务。它就像是你的编程旅程中的忠实伙伴，一旦集成到你的应用中，它就会自动捕获未处理的异常和事件。想象一下，无论何时你的代码有点小插曲，Exceptionless 都会在第一时间抓住它们，并把这些信息安静地放在你的仪表板上，等你去查看。🐞

　　自动化监控：你只需轻轻一集成，Exceptionless 就会自动开始监控，你甚至不需要告诉它从何处开始！

　　深入洞察：不仅仅是告诉你“出错啦”，Exceptionless 还会告诉你为什么出错，哪里出错，甚至是谁遇到了这个错误。🕵️‍♂️

　　是否厌倦了那些冷冰冰的日志文件？让 Exceptionless 加入你的开发生活吧！它会用它那可爱的方式，带给你错误跟踪的全新体验。它不仅能帮助你修复错误，还能帮助你优化你的应用，让用户体验更上一层楼！

　　所以，让我们一起欢迎 Exceptionless，让它成为我们代码世界中的小英雄吧！使用 Exceptionless，一起把“糟糕”的时刻变成“搞定啦”的时刻！🌟

　　ExceptionLess 的文档比 sentry 差太多了，写得不清不楚的，不过好在我已经熟练使用这玩意了。

　　Elasticseach 版本升级问题: 之前是7.x版本，现在升级后是8.x版本，这俩版本的数据文件都不一样，需要做迁移，但因为前一天部署 sentry 把环境搞烂了，这次 ExceptionLess 也跑不起来，最后干脆整个 Elasticsearch 都删掉了

　　docker 内部的DNS解析问题: 很奇怪，其他的项目都不会这样，后面也莫名其妙解决了，真实奇怪，盲猜和代理可能有点关系？🥱

　　一会就各种连不上，最终在代理服务器的日志上发现了一堆标红的 elasticsearch:9200 访问，才发现问题出在代理上。

　　但我把环境变量、~/.docker/config.json 的代理都去掉了，还是会走代理，真的服了，这也成玄学问题了。

　　现在的容器一般都是基于 alpine 这种轻量级发行版构建，没有 curl 之类的工具可以测试网络

　　没事，我们可以创建一个临时容器，加入到这组 compose 的网络里来测试，本文里这个网络名称是 exless