henryzhx8
henryzhx8
[service_wineventlog](https://github.com/alibaba/ilogtail/tree/main/plugins/input/input_wineventlog) 插件提供了采集windows事件的能力。需要提供[开源版本的文档](https://ilogtail.gitbook.io/ilogtail-docs/v/pre-release/data-pipeline/overview)。 具体企业版参见：https://help.aliyun.com/document_detail/101177.html
1. 新增ProcessQueueItem类，并将处理队列的元素类型由LogBuffer*改为unique_ptr\ 2. 处理队列的成员mArray由T[SIZE]调整为vector\ 3. LogEvent类中新增成员mFileOffset和mRawSize，用于记录位移和读取长度 - 日志读取阶段，将__file_offset__从LogEvent的content中删除，转而记录到mFileOffset中 - 日志切分阶段，需要同步更新mFileOffset和mRawSize，但仅当mAppendingLogPositionMeta为true时，才在LogEvent的content中增加__file_offset__字段 4. 对PipelineEventGroup的metadata和tag、ProcessorTagNative的处理逻辑进行重新调整，按照如下原则： - 文件输入组装PipelineEventGroup时 - 在mMetadata中保存文件名、inode、topic、source id和容器元信息 - 在mTag中保存inode（仅当mAppendingLogPositionMeta为true时）、多余的topic和externalxxxtag（k8s) - ProcessorTagNative的处理逻辑 - 挑选PipelineEventGroup的部分mMetadata字段到mTag中 - 将进程级信息放到mTag中，包括hostname、ip、user_defined_id、env tag和file tag 5. exactlyonce恢复支持在聚合阶段重新打包 6....
1. 重构处理队列 a. 新增`FeedbackQueue`模版类，作为处理队列和发送队列（待重构）的基类； b. 新增`ProcessQueue`类，其包含若干下游的发送队列（`mDownStreamQueues`）和若干上游反馈接口（`mUpStreamFeedbacks`)。 - 这里使用“若干”而非“一个”主要是为了远期可扩展考虑，即一条流水线支持多输入和多输出。现阶段“若干”就是“一个”。 - 上游反馈接口比较抽象，是输入插件根据需要定义的，由`InputFeedbackInterfaceRegistry`类统一管理。对于文件和stdout采集来说，反馈接口就是`BlockedEventManager`类。 2. 重构处理队列管理类，新增`ProcessQueueManager`类，负责创建和管理所有流水线的处理队列（不含exactly once队列，它们由`ExactlyOnceQueueManager`类负责），同时负责队列的push和pop（代理exactly once队列）。 3. 新增`ExactlyOnceQueueManager`类，负责创建和管理所有的exactly once处理和发送队列。 4. 新增`QueueKeyManager`类，负责配置名和队列key之间的映射管理，队列除创建时均使用key来索引，提升查询效率。 5. 处理队列调整为1个流水线1个，exactly once流水线不生成配置级的处理队列。 6. 处理队列支持指定优先级。
- 问题：Go的profile信息无法发送到C++部分 - 原因：自监控没有独立的流水线，只有一个假的flusherSLS，而且这个flusher无法走常规的初始化流程，包括建队列等，因此go的自监控信息发送到C++会找不到相应的队列。 - 处理：特殊处理，发的时候看一下队列有没有，没的话现场建一个