最新

<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 我希望能听到那些调试过“神秘”日志账单的人的反馈： - 你是否已经以更简洁的方式解决了这种映射（账单 → 具体日志位置）？ - 在你的设置中，逐行聚合是否真的有用，还是与更好的日志组约定相比，这种方法显得过于复杂？