我正在开发一个日志框架,它将分层指标发送到Graphite服务器(表示为以点分隔的字符串,例如“site.login_page.page_load”)。为了使命名在多个团队中保持一致,开发人员不应该能够发送自由格式文本,因为它可能会通过使用不同的命名空间来影响度量标准聚合。我最初的想法是使用枚举:
public enum WaitingRoomMetrics
{
CheckIn,
WaitTime
}
}
LogTimeMetricInMs (WaitingRoomMetrics.CheckIn, 900000);
这会阻止开发人员创建不一致的自由格式指标,如下所示:
LogTimeMetricInMs ("waiting_room.checkin", 300000);
LogTimeMetricInMs ("waitingroom.TotalwaitTime", 900000);
目前,我对LogTimeInMetrics的接口定义是:
interface LogTimeInMetrics (Enum metric, long timeInMs);
虽然开发人员可以创建自己的枚举,但它并没有真正解决强制执行的问题。理想情况下,我希望每个离散组件都有一个不同的Nuget包,其中包含该应用程序组件可用的所有度量标准。然后,开发人员可以为他们需要公开的任何指标安装Nuget包。然而,除非我们在代码签入/拉取请求审核中提供强制执行,否则enums仍然感觉有点过于简单,他们仍然给开发人员太多免费统治。
基本上,我希望有一个Metrics.Base包,它包含某种具有内置验证的基类型。所有指标都需要从该基础分支继承。接口将如下所示:
interface LogTimeInMetrics (BaseMetric metric, long timeInMs);
但感觉就像为每个指标构建一个单独的类是过度杀戮并且可能是一个行政噩梦 - 基本上每个指标都只是一个“ToString()”。是否有更好的模型来管理跨多个Nuget包管理的基本Enum类型值的大型列表,提供Intellisense和命名空间/命名约定执行/验证的一些意义?或者放弃Intellisense并只维护一组常量?