agent api中"endpoint" 字段是否必须

[Liuyanglong]

我在想一个问题，agent提供的api中必须传一个endpoint字段，这个字段是否必须。

当前情况，允许用户通过api自push数据到transfer，但是又不对endpoin做限制，那么作为用户则可以天马星空的随意填写 endpoint值，那么一些淘气的rd会不会利用这一漏洞给数据造成一些混乱？

那么对于agent的定位就有了两种：
1、仅仅作为和host挂钩，收集和此host相关的item数据，那么 此时 就不应该开放endpoint字段，至少可以设置为如果此字段为空，就默认设置成当前部署agent的hostname；
2、将agent作为一项数据收集服务 对外ip为 $ip，所有的rd可以通过$ip:1988/v1/push 来进行item数据上传，此时endpint则不能为空；

我自己的想法是：
对于基础项（如cpu、mem、disk）等，采用第一种情况，且不允许业务线rd调用127.0.0.1:1988/v1/push，如若添加基础项，则以plugin的形式进行；
对于业务监控项，则采用第二种情况，提供一个统一的数据上传服务，业务组rd根据业务需求，自上传监控数据，此时应禁止agent 自采集项，相当于是当前agent的一个裁剪。

不知官方 对agent将来的定位是何种？

[UlricQin]

赞，有思路。

我们肯定是需要一个agent来采集linux基本监控项。问题焦点变成了：agent是否应该做转发，是否需要一个单独的转发组件。这个其实都可以，agent已经与服务端建立长连接了，用agent转发，效率OK，省事。

另一个问题是endpoint是否是必须的。这个其实也是见仁见智，我们说某个监控项，这个监控项总有个属主，表明是谁的监控项，这就是endpoint设计的初衷。如果把endpoint作为一个tag上传，其实问题也不大。

能想到这些说明对产品的理解很透彻，至于实现，适合你们的就是最好的。一个问题两个思路都可以解决，看不出明显优劣，那就看个人癖好了，呵呵

[oiooj]

agent应该只做本机的代理，上报和本机相关的数据（包括跑在本机上的业务），代理其他主机的数据上报得不偿失，也想不到场景。

endpoint 是必须 ，但是允不允许自定义可以讨论

[canghai908]

这种场景也是有的，有些环境下，网络环境限制，还是需要推送到一个机器agent上，agent再发到监控服务器。

[Liuyanglong]

@oiooj 如果只是做为本机的agent代理，那么此时我觉得endpoint可以取消，替换为自填充为本机的hostname