iLogtail observability enhancement

[linrunqi08]

Current Status：https://ilogtail.gitbook.io/ilogtail-docs/configuration/logging

1. Support Exporting ilogtail_profile and ilogtail_status by HTTP（promethus）
2. Improve C++partial monitoring data
3. Unified C++and Golang monitoring data

[linrunqi08]

iLogtail自身可观测性现状

iLogtail当前对外可见可观测指标通过snapshot目录下的ilogtail_status.LOG文件和ilogtail_profile.LOG文件对外暴露：

ilogtail_status.LOG：全局统计指标

资源消耗	CPU、MEM
配置	配置数量、更新时间等
文件读取	打开文件数、监控目录数、读取次数等
处理	处理队列大小、处理行数、字节数等
发送	发送次数、字节数、异常发送队列数等

当前自身可观测指标有这样几个问题：

1. 指标缺少明确定义，不知道count是次数还是条数，不知道统计周期等，指标很多但看不懂
2. 细粒度指标文件类和其他类型差别太大，不仅其他类型指标远少于文件采集，且即使相同指标口径也未必一致，不利于问题排查
3. 细粒度指标时间粒度不可调整
4. 缺少对数据流处理的洞察指标，例如每个配置，各个处理插件的统计指标，处理流程不透明
5. 指标缺少对外暴露能力，如通过Prometheus Format被第三方监控抓取或原生作为一种指标Input被采集处理发送到第三方存储
6. 实现上不同组件自由实现，相关代码散乱在各处，新增模块添加指标无从下手

期望的可观测性

• 统一：指标具有明确定义，且形成文档和命名规范便于理解。文件类（C++）和其他类型（Go）指标统计口径统一。
• 丰富：细粒度的每个插件实例的指标清晰展示，分为公共部分和特有部分，具备足够信息可视化还原处理流水线状态。
• 可导出：可以被Prometheus被抓取或原生作为一种指标Input被采集处理发送到第三方存储
• 可扩展：实现上具备良好的指标采集框架，新增插件可方便接入

长期目标

定义公共的指标和命名规范

采集器资源状态

cpu
mem
fd_open

Input

input_records_out_total
input_bytes_out_total

Processor

process_record_in_total
process_bytes_in_total
process_record_out_total
process_bytes_out_total

Flusher

flush_record_in_total
flush_bytes_in_total
flush_record_out_total
flush_bytes_out_total
flush_count_net_out_total
flush_bytes_net_out_total
flush_record_success_total
flush_bytes_success_total
flush_record_retried_total
flush_bytes_retried_total
flush_record_dropped_total
flush_bytes_dropped_total

层次（label）

1 全局：hostname="xx"、version="xx"、os="xx"

2 插件实例：name="plugin_type/plugin_id"

3 配置：config="xx"

4 采集对象实例：filename="xxx"、upstream="xxx"

指标类型

• Counter
• Gauge
• Summary

Exporter和导出插件

Metric相关接口

Plugin接口

GetMetrics

Metrics接口

CreateCounter

CreateGauge

用此类接口创建Metric，成员变量可以直接访问具体Metric

ForEachCounter

ForEachGauge

用此类接口遍历Metric，无论自定义多少Metric都可以全部遍历

Metric接口

Gauge

Set

Add

Inc

Sub

Dec

Get

Counter

Set

Add

Inc

Get

Summary

短期怎么做

C++当前实现

Go当前实现

使用统一数据结构改造，无锁化。Go复用v2的metric模型。

C++保留一个集中的InternalMetrics收集类，使用插件注册的形式告知其要收集数据的模块实例

文件dump功能作为消费模块独立

MetricExporter和MetricInput复用Go现有框架，暂时通过插件暴露指标。

C++侧指标通过cgo插件允许Go访问。

[wangpeix]

采集延迟指标也是需要的，用来衡量采集延迟多久。如采集延迟时间...

[messixukejia]

收到，这个在考虑了。

[linrunqi08]

Golang

每个plugin会hold一个metric对象，LogstoreConfig会hold一个metric对象的列表，在加载每个plugin的时候，将Metric对象放到列表中，这样每个插件只对自己的metric对象进行操作，不需要锁

C++

支持Push or Pull
● Pull or Push？监控系统如何选型）
● Pull模式在开源场景下基本上可以说是行业标准

[wangpeix]

指标支持主动推送到下游的kafka吗。
有几万台机器， 每台机器上一个logtail，指标支持推送到下游kafka，方便下游统一处理

[messixukejia]

后面是可以考虑下作为一种数据采集到任意下游 @linrunqi08

[cyshallchan]

@linrunqi08 老哥有些图挂了，方便补一下吗？

[linrunqi08]

// 基础指标类
class BaseMetric{
    struct MetricObj {
        /* counters and gauges */
        std::atomic_long val;

        std::atomic_long timestamp;
    };
    public:
        BaseMetric();
        BaseMetric(MetricObj* metricObj);
        ~BaseMetric();
        MetricObj* mMetricObj;
        
        // 指标操作 
        void baseMetricAdd(uint64_t val);
        MetricObj* getMetricObj();
        MetricObj* snapShotMetricObj();
};

// Pipeline指标，对基础指标进行封装
class PipelineMetric {
    public:
        // 指标名->指标的Map
        std::unordered_map<std::string, BaseMetric*> mBaseMetrics;
        // 标签，层级使用标签来区分
        std::unordered_map<std::string, std::string> mLabels;
};

[linrunqi08]

#914

[linrunqi08]

需求
允许增加、删除指标项（相同Label组合认为一项），但不是频繁操作，一般切文件才会增删
修改指标值，频繁操作，不能被block
读取指标，不是频繁操作，一般几秒一次
读写分离设计
gWriteMetrics用于被写
gReadMetrics用于被读
定期将gWriteMetrics快照到gReadMetrics中，同时重置gWriteMetrics中指标，清理gWriteMetrics中无效指标项
写Metrics设计
gWriteMetrics全局唯一
使用方使用CreateMetrics接口创建一个Metrics，接口形式为Metrics* CreateMetrics(Labels)
Metrics的Label不支持修改
Metrics可以增加具体指标值，通过XXX* Metrics::CreateXXX(Name)，XXX可以为Counter、Gauge等。
使用方通过在自己类内记录下这些WeatPtr直接修改指标值，无查找指标需求。
例如：

class Gauge {
    atomic_long mTimestamp;
    atomic_long mValue;
    void Set(long val) {
        mTimestamp = time();
        mValue = val;
    }
};
class Metrics {
    vector<pair<string>> mLabels;
    List mValues;
    Gauge* CreateGauge(string Name);
    Metrics* prev, next;
};

class WriteMetrics {
    Metrics* CreateMetrics(vector<string> Labels);
};

WriteMetrics* gWriteMetrics;

class Reader {
    bool Init() {
        vector<string> labels = {
            {"Config","config1"},            
            {"Path","path1"}, 
        };
        mMetrics = gWriteMetrics->CreateMetrics(labels);
        mOffsetGauge = mMetrics->CreateGauge("Offset");
    }
    ~Reader() {
        gWriteMetrics.Destroy(mMetics);
    }
    bool ReadLines() {
        mOffsetGause->Set(offset);
    }
    WeakPtr<Metrics> mMetrics;
    WeakPtr<Gauge> mOffsetGauge;
}

读Metics设计
gReadMetrics是全局唯一，可以具备自己的数据结构和方法，为读取优化，这里重点考虑数据怎么来。
gReadMetrics中的数据从gWriteMetrics中通过快照得到，因此需要能遍历gWriteMetrics中的数据。遍历的时候希望不要影响Metrics的写入，同时不要因指标项删除发生异常。因此考虑使用DoubleLinkedList数据结构存储Metrics，一写多读安全，同时使用延时删除技术避免指标项删除对读取到影响。

class WriteMetrics {
    Metrics* CreateMetrics(vector<string> Labels) {
      lock_guard(mMutex);
      // link new Metrics to mHead and return;
    }
    void DestroyMetrics(Metrics* metrics) {
      lock_guard(mMutex);
      // unlink metrics from mHead and add to mDeletedMetrics;
      // do not modify metrics's next pointer to let who is reading this Metrics can read next Metrics normally
    }
    void clearDeleted() {
      {
        lock_guard(mMutex);
        vector<Metrics*> toDelete;
        toDelete.swap(mDeletedMetrics);
      }
      // real delete pointers in toDelete
    }
    void DoSnapshot(Metrics*& snapshot) {
      for (Metrics* metrics = mHead; metrics != mTail; metrics=metrics->next) {
        // copy/swap metrics to snapshot
      }
      clearDeleted();
    }
    Metrics* mHead;
    Metrics* mTail;
    vector<Metrics*> mDeletedMetrics;
    mutex mMutex;
};

gReadMetrics没有实时写入的需求，但在做snapshot更新后，还是需要保证当前正在读的人正常因此可以简单加一下锁。

class ReadMetrics {
    void ReadMetrics(……) {
      rlock_guard(mMutex);
      // Do some read
    }

    void UpdateMetrics() {
      Metrics* snapshot;
      gWriteMetrics.DoShapshot(snapshot);
      Metrics* toDelete = mHead;
      {
        wlock_guard(mMutex);
        mHead = snapshot;
      }
      // do deletion
    }
    Metrics* mHead;
    shared_mutex mMutex;
};

class ReadMetricsIterater {
  ReadMetricsIterater() {
    rlock(gReadMetrics->mMutex);
  }
  ~ReadMetricsIterater() {
    unrlock(gReadMetrics->mMutex);
  }
}

[linrunqi08]

[linrunqi08]

mDeletedMetrics 去掉，采用标记删除的方式。在do snapshot的时候，边复制，边删除

[cyshallchan]

@linrunqi08 有个问题，现在的设计是c++部分和go插件部分产生的指标是分开来送出去吗？还是c++产生的指标先送到go插件系统里然后在统一送出去？

[messixukejia]

会汇集的，框架代码最近会入库，可以关注下。

如果有兴趣，可以一起来开发下发送到第三方系统的部分

[cyshallchan]

可以的

[liuhaoyang]

目前这个feature是什么进展了

[linrunqi08]

代码已合入，可以看下这几个pr：
#1015
#1106
#1167

[linrunqi08]

最新进展，可以看下pr: #1290 目前支持golang 部分 v1 pipeline完整指标统一通过Cpp exporter输出。

[linrunqi08]

目前Cpp Exporter需要实现Promethus API从而将指标暴露出来。希望有人认领一下改功能，比较简单

[linrunqi08]

当前状态:
整体：

C++

如何为插件添加自定指标？
https://github.com/alibaba/ilogtail/pull/1379/files#diff-7e45e30fb6876b0f28b367e761d31d38e7adadc8dda84ced6211d1987708ec13

[linrunqi08]

开发者招募：

在C++中实现HttpServer，以Prometheus 格式的API方式对外暴露指标数据

部分改动参考接口定义：
https://github.com/alibaba/ilogtail/tree/feature/metric_exporter

[linrunqi08]

关键PR

1. Golang插件指标重构代码： https://github.com/alibaba/ilogtail/pull/1290/files
2. C++插件指标重构代码： https://github.com/alibaba/ilogtail/pull/1015/files
3. C++插件添加指标demo：https://github.com/alibaba/ilogtail/pull/1106/files