最新

请说明工作地点，如果是远程工作，请注明“REMOTE”，如果国家有限制，请使用“REMOTE (US)”或类似的表述；如果不支持远程工作，请注明“ONSITE”。<p>请仅在您本人是招聘公司的成员时发布信息——不接受招聘公司或招聘网站的帖子。每家公司只允许发布一条信息。如果您的公司不是家喻户晓的名字，请解释一下公司所做的业务。<p>请仅在您正在积极招聘并承诺回复申请者时发布信息。<p>评论者：请不要在招聘帖子下回复抱怨任何事情。这与主题无关。<p>读者：请仅在您个人对该职位感兴趣时发送电子邮件。<p>求职者：可以尝试访问以下链接：<a href="https://dheerajck.github.io/hnwhoishiring/" rel="nofollow">https://dheerajck.github.io/hnwhoishiring/</a>，<a href="http://nchelluri.github.io/hnjobs/" rel="nofollow">http://nchelluri.github.io/hnjobs/</a>，<a href="https://hnresumetojobs.com" rel="nofollow">https://hnresumetojobs.com</a>，<a href="https://hnhired.fly.dev" rel="nofollow">https://hnhired.fly.dev</a>，<a href="https://kennytilton.github.io/whoishiring/" rel="nofollow">https://kennytilton.github.io/whoishiring/</a>，<a href="https://hnjobs.emilburzo.com" rel="nofollow">https://hnjobs.emilburzo.com</a>，或这个（非官方）Chrome扩展：<a href="https://chromewebstore.google.com/detail/hn-hiring-pro/mpfaljjblphnlloddaplgicpkinikjlp" rel="nofollow">https://chromewebstore.google.com/detail/hn-hiring-pro/mpfal...</a>。<p>不要错过这个其他精彩的主题：<i>谁想被雇佣？</i> <a href="https://news.ycombinator.com/item?id=46108940">https://news.ycombinator.com/item?id=46108940</a>

如果您正在寻找工作，请分享您的信息。请使用以下格式：<p><pre><code> 地点： 远程工作： 愿意搬迁： 技术： 简历： 电子邮件： </code></pre> 请仅在您本人正在寻找工作时发布信息。代理机构、招聘人员、招聘网站等内容不在此讨论范围内。<p>读者：请仅通过这些地址发送电子邮件以讨论工作机会。<p>您可以在 <a href="https://www.wantstobehired.com" rel="nofollow">https://www.wantstobehired.com</a> 上搜索这些帖子。

<a href="https://huggingface.co/deepseek-ai/DeepSeek-V3.2" rel="nofollow">https://huggingface.co/deepseek-ai/DeepSeek-V3.2</a><p><a href="https://api-docs.deepseek.com/news/news251201" rel="nofollow">https://api-docs.deepseek.com/news/news251201</a>

我们在记录成本方面不断遇到相同的模式： - CloudWatch / GCP Logging / Datadog 告诉你哪个日志组/索引很昂贵 - 但并没有告诉你代码中具体哪些日志语句是导致成本高的原因 因此，回应总是： - 调整保留策略/层级 - 添加过滤器和采样 ……而且通常要到很久之后你才会发现，问题出在某几行 DEBUG 代码、冗长的 HTTP 跟踪，或者循环中的有效负载转储。 在某个时刻，我们想要一个简单的答案： > “对于当前已部署的代码，哪些日志调用位置消耗了最多的预算？” ——— ### LogCost 的功能 LogCost 是一个小型的 Python 库 + 命令行工具，它： - 封装了标准的日志模块（可选打印） - 跟踪每个调用位置的指标： {文件, 行, 级别, 消息模板, 计数, 总字节数} - 应用提供商定价（例如 GCP/AWS）来估算成本 - 定期导出聚合统计信息（不包含原始日志负载） - 可以发送 Slack 通知，列出最昂贵的前 N 行日志 它旨在作为当前部署的快照：在正常负载下运行，查看哪些行主导了成本，修改它们，重新部署，重复此过程。 ——— ### 工作原理（高层次） - 它封装了 logging.Logger._log，并使用文件、行和级别记录每个调用位置的关键。 - 消息大小是根据格式化字符串的长度加上可配置的每个事件开销来估算，并按调用位置累积。 - 后台线程定期将聚合数据刷新到磁盘上的 JSON 文件中。 - 命令行工具读取该 JSON 并打印： - 成本摘要（基于当前提供商定价），以及 - 每个调用位置的“主要成本驱动因素”表。 根据设计，它从不存储原始日志负载，只存储像这样的聚合数据： { "file": "src/memory_utils.py", "line": 338, "level": "DEBUG", "message_template": "Processing step: %s", "count": 1200000, "bytes": 630000000, "estimated_cost": 315.0 } 这样做部分是出于隐私考虑，部分是因为这旨在补充你的日志平台，而不是替代它。 ——— ### 示例输出 报告可能会显示： - 提供商：GCP，货币：美元 - 总字节数：900,000,000,000 - 估算成本：450.00 主要成本驱动因素： - src/memory_utils.py:338 [DEBUG] Processing step: %s → $157.50 - src/api.py:92 [INFO] Request: %s → $73.20 - … Slack 通知只是相同数据的格式化版本，按可配置的时间间隔发送（可选的提前“测试” ping 以便你验证连接）。 ——— ### 范围和状态 - 目前仅支持 Python（Flask/FastAPI/Django / K8s sidecar 示例） - MIT 许可，无需后端服务 - 导出格式为简单的 JSON，因此如果需要，可以后续供中央聚合器使用 代码库： https://github.com/ubermorgenland/LogCost 我希望能听到那些调试过“神秘”日志账单的人的反馈： - 你是否已经以更简洁的方式解决了这种映射（账单 → 具体日志位置）？ - 在你的设置中，逐行聚合是否真的有用，还是与更好的日志组约定相比，这种方法显得过于复杂？