返回首页
最新
嗨，HN！我们是Ethan和Danny，Tangent的作者（<a href="https://github.com/telophasehq/tangent" rel="nofollow">https://github.com/telophasehq/tangent</a>），这是一个基于Rust的日志管道，所有的规范化、增强和检测逻辑都作为WASM插件运行。
我们在OCSF（<a href="https://ocsf.io" rel="nofollow">https://ocsf.io</a>）社区中不断看到相同的问题：
1) 模式不断变化。大型公司有专门的团队负责保持供应商与OCSF的映射更新。
2) 没有共享的映射库，因此每个人都在重复相同的工作。
3) 编写映射器是一项乏味且重复的工作。
4) 大多数管道使用专有的DSL，难以共享，也难以让工具/大型语言模型生成。
Tangent采取了不同的方法：没有DSL——映射和增强只是编译为WASM的普通代码，可共享的插件——我们维护一个社区库（<a href="https://github.com/telophasehq/tangent-plugins" rel="nofollow">https://github.com/telophasehq/tangent-plugins</a>），互操作性——我们可以在WASM中运行其他引擎的DSL（例如，Bloblang），以便于迁移，完全灵活性——插件可以验证模式，调用外部API（<a href="https://github.com/telophasehq/tangent/blob/main/examples/enrichment/main.go#L58" rel="nofollow">https://github.com/telophasehq/tangent/blob/main/examples/enrichment/main.go#L58</a>），或执行复杂的转换（<a href="https://github.com/telophasehq/tangent-plugins/blob/main/zeek-ocsf/conn/main.go#L312" rel="nofollow">https://github.com/telophasehq/tangent-plugins/blob/main/zeek-ocsf/conn/main.go#L312</a>）。
以下是一个示例Python转换插件，用于从日志中删除除`message`以外的所有字段：
```python
import json
from typing import List
from wit_world.imports import log
# `log.Logview`是Tangent的零拷贝JSON访问器类型。
def process_logs(self, logs: List[log.Logview]) -> bytes:
out = bytearray()
for lv in logs:
msg = lv.get("msg")
value = msg.value if msg is not None else ""
out.extend(json.dumps({"message": value}).encode() + b"\n")
return bytes(out)
```
我们在代码库中还有更多示例。
由于插件只是Go/Python/Rust，LLMs可以轻松创建新的映射器。例如，我问：
```plaintext
从AWS Security Hub Finding生成一个到OCSF的映射器
```
只需进行一些小的调整。（<a href="https://github.com/telophasehq/tangent-plugins/blob/main/aws-ocsf/security_hub/main.go" rel="nofollow">https://github.com/telophasehq/tangent-plugins/blob/main/aws-ocsf/security_hub/main.go</a>）
在性能方面，一台16核的Amazon Linux服务器在处理约100字节的JSON日志时，端到端（TCP → Rust-WASM转换 → 接收器）可处理约480 MB/s。CLI包含用于本地搭建、测试和基准测试插件的工具。以下是我们如何实现这一性能的深入分析：<a href="https://docs.telophasehq.com/runtime" rel="nofollow">https://docs.telophasehq.com/runtime</a>。
我们非常希望听到您的反馈！您觉得怎么样？
我创建了 rapid-rs，以消除在启动新的 Rust 网络服务时所需的冗余代码。<p>只需一条命令即可获得：
- 自动配置的数据库、日志记录、CORS
- 在 /docs 提供的 OpenAPI/Swagger UI
- 请求验证
- 适用于生产环境的可观察性<p>基于 Axum 构建。初步基准测试显示每秒约 50,000 个请求，内存占用在 10-20MB 之间。<p>这是 v0.1 版本，欢迎反馈！<p>库链接：<a href="https://crates.io/crates/rapid-rs" rel="nofollow">https://crates.io/crates/rapid-rs</a>
我正在考虑迁移一台Windows服务器（Windows Server 2012 R2 Standard），想了解是否有办法查看哪些文件正在被读取。我知道操作系统会保存这些元数据，但我也了解到这些元数据并不可靠。请问是否有第三方工具或某种PowerShell脚本可以用来跟踪这些数据？
嗨，HN，
几个月前，我发布了这个Chrome扩展的早期版本。从那时起，我对其进行了优化，修复了一些稳定性问题，并且最近它在Chrome Web商店的“推荐”栏目中被展示，这让我感到很惊喜。
这个扩展的功能：
- 直接在浏览器中检测活动的推文或线程
- 收集相关上下文（父推文、作者信息、线程结构）
- 格式化提示并发送给OpenAI API
- 将生成的回复直接插入Twitter的原生回复框
所有这些操作都在X.com的DOM内部进行，不会存储任何用户数据。
技术细节：
- 使用MutationObserver跟踪X.com不断变化的DOM
- 处理动态插入的推文节点、影子DOM和线程扩展
- 防抖上下文提取，以避免不必要的重复运行
- 模拟原生输入事件来注入回复，使其感觉像是内置的
- 避免后端状态；除了最终的API调用，所有操作都在客户端读取
挑战：
- X.com经常改变UI结构，因此选择器会不稳定
- 防止在DOM重新渲染时重复注入
- 保持提示大小足够小以实现快速生成
- 减少开销，以免扩展拖慢页面速度
最近的改进：
- 更稳定的推文/线程检测
- 更好的上下文选择逻辑
- 回复弹窗中的UI更简洁
- 小幅性能修复和竞争条件修复
Chrome商店页面：[链接](https://chromewebstore.google.com/detail/xinsightai-ai-reply-assis/ngppfaclmbaaagondnfjkigkmacfphhc)
希望能收到那些有构建浏览器扩展或处理X.com DOM模式经验的人的反馈。欢迎讨论任何细节。